EteSync Fork, SilentSuite: What Was Forked, Rebuilt, and Kept Compatible

SilentSuite is an open-source, end-to-end encrypted calendar, contacts, and tasks sync system built on the Etebase protocol. Its public repository combines three documented derivatives of EteSync projects with new web, shared-core, deployment, and documentation layers.

That distinction matters. SilentSuite did not replace Etebase with a new sync protocol, and it did not merely rename the complete EteSync product. The server and Android app preserve upstream provenance in NOTICE files, while bridge source files identify their etesync-dav origin. Other components use the same protocol to provide a maintained product around it. SilentSuite is independent and is not affiliated with or endorsed by EteSync or Etebase.

Why did SilentSuite fork EteSync instead of waiting for upstream?

SilentSuite needed an actively maintained path for the complete product, not only a protocol specification. When the fork was assembled in March 2026, the Etebase server repository had not received a code update since July 2024, and the Etebase JavaScript repository's latest commits were from January 2023. That left core server and web-client dependencies without the release cadence needed for current deployment, security, and product work.

This does not mean every EteSync repository was abandoned. The Android app and etesync-dav received later maintenance. The problem was that no single upstream release train maintained the server, modern web product, Android integration, desktop bridge, self-hosting bundle, documentation, and operational checks as one supported system. Forking let SilentSuite maintain those pieces together while preserving Etebase's proven client-side encryption and sync model.

The result is better for users who need a current, supported product: security and dependency fixes can ship without waiting for dormant core repositories, web and Android behavior can be tested against the same release, and self-hosters receive versioned deployment and recovery tooling. The fork was therefore a maintenance and product-continuity decision, not an attempt to invent unreviewed replacement cryptography.

Which parts of SilentSuite were forked from EteSync?

Two component notices make direct ancestry clear. The server NOTICE says the SilentSuite server is based on Etebase Server by Tom Hacohen and EteSync contributors. Its changelog records the March 2026 fork point as Etebase Server 0.14.2. The Android NOTICE says the Android app is based on EteSync for Android. It also preserves attribution for DAVdroid/DAVx5, cert4android, ical4android, vcard4android, and the Etebase client library.

Bridge source files also state that they were forked and adapted from etesync-dav. SilentSuite has since changed the local account flow, cache, storage adapter, packaging, and installers, but the retained source attribution makes the derivative relationship explicit.

The licenses follow those lineages. The server, bridge, and repository are distributed under AGPL-3.0, while the Android subtree is distributed under GPL-3.0. Those are source and licensing facts, not a claim that every line in each derivative is unchanged from upstream.

What did SilentSuite build for the new product, and what got better?

The current web client is a SilentSuite Next.js application, not a renamed copy of the historical EteSync web interface. It uses a shared TypeScript package for collection access, sync orchestration, and iCalendar and vCard data handling. That package depends on the published Etebase JavaScript client. This separates the application interface from the cryptographic sync library beneath it.

SilentSuite also maintains its adapted local bridge as a standalone component. The bridge uses Etebase upstream and exposes CalDAV and CardDAV to software on the same device through Radicale. Encryption and decryption happen locally, so the bridge is an adapter around encrypted sync rather than a plaintext DAV endpoint on the hosted server. The self-host bundle, web documentation, release packaging, and operational checks are SilentSuite layers around the protocol server.

In practical terms, the work is larger than a rename or a server fork:

• A new web application and shared TypeScript core provide current calendar, contacts, and tasks interfaces, shared data models, import and export flows, and one maintained sync implementation.
• A maintained product release train tests the web app, Android sync, bridge, server, and packaging together instead of asking users to assemble independently versioned projects.
• Safer self-hosting and operations add pinned Compose releases, verification scripts, signup controls, health checks, update tooling, and documented backup and restore procedures.
• A more complete local integration path packages the bridge and installers while keeping plaintext DAV on the user's device, not on the hosted server.

These are SilentSuite-specific application and deployment layers. Public history does not prove clean-room authorship for every imported line, so “built for SilentSuite” is the precise claim. It does not mean replacing Etebase's cryptographic client libraries or removing upstream attribution. SilentSuite improves maintainability, release safety, usability, and deployment while retaining the protocol boundary that made Etebase valuable in the first place.

The public monorepo starts with a consolidated SilentSuite release on March 19, 2026. Because that first commit imports several components at once, commit timestamps inside this repository do not prove that every imported line was first written on that date. The component notices and retained upstream changelogs are the stronger provenance evidence.

Which Etebase compatibility contracts does SilentSuite retain?

The retained contract is the Etebase model: client-side encryption, authenticated accounts, encrypted collections and items, revision history, and sync tokens. SilentSuite also keeps the established PIM collection identifiers etebase.vevent, etebase.vtodo, and etebase.vcard. The SilentSuite-specific preferences collection is separate from those three PIM types.

The protocol documentation at docs.etebase.com explains the client and server model. SilentSuite's public repository shows where that model is used today. Together, those sources support a protocol-lineage claim. They do not support saying that arbitrary old applications can be pointed at any SilentSuite deployment without testing.

Can an existing EteSync app or account connect directly to SilentSuite?

Not as a general promise. Protocol compatibility and product compatibility are different claims. A client may speak Etebase while still depending on a particular server URL, account flow, collection convention, operating-system integration, or app version. An EteSync account also belongs to its original server. Sharing a protocol does not move credentials, encrypted collections, invitations, or billing state between services.

SilentSuite therefore documents the clients and paths it supports instead of treating common ancestry as universal interoperability. For current product differences and tested migration instructions, read Looking for an EteSync alternative? This article stays narrower: it records source lineage and the interface boundaries visible in the code.

The same caution applies to DAV. CalDAV and CardDAV compatibility comes from the local SilentSuite bridge. A desktop calendar connects to that localhost adapter, and the adapter communicates with the encrypted server through Etebase. That does not mean the hosted server exposes a conventional plaintext CalDAV or CardDAV service.

FAQ

EteSync and Etebase supplied the protocol foundation and substantial upstream code in the documented server, Android, and bridge derivatives. SilentSuite keeps that attribution visible while maintaining the system as a combined web, Android, bridge, server, and self-hosted project.