Real-time collaboration and end-to-end encryption pull in opposite directions. Collaboration wants a smart central server that can take everyone's changes, reconcile them into one coherent document, and hand back the merged result. Encryption wants that server to be a dumb relay that sees only ciphertext. Reconciling these is one of the more interesting engineering problems in privacy software, and the way it is solved shows both what is possible and where the honest limits sit.
Why the Naive Approach Fails
The obvious idea, encrypt the whole document and have each editor download it, change it, and upload the new version, collapses immediately under concurrency. If two people edit at the same time, whoever saves last overwrites the other's work, because the server cannot merge two opaque encrypted blobs. It has no idea what changed inside them. Merging requires understanding structure, and understanding structure is exactly what encryption denies the server.
So the problem cannot be solved by encrypting documents as monolithic files. It has to be solved by changing how edits themselves are represented, so that merging can happen without a central authority reading anything. That is where a class of data structures called CRDTs comes in.
Instead of syncing the document, sync the edits, structured so any two sets of edits merge to the same result regardless of order or timing. Encrypt those edits. Now the server can store and relay them, and reconciliation happens on each client after decryption. The server coordinates without ever understanding.
CRDTs: Merging Without a Referee
A CRDT, or conflict-free replicated data type, is a data structure designed so that concurrent changes from different participants can always be merged automatically into a consistent result, without a central server deciding who wins. Each edit is expressed as a small operation, inserting a character at a stable position, deleting one, tagged with enough identity information that any client applying the same set of operations, in any order, arrives at the identical document.
This property is what makes encrypted collaboration possible. Because the merge logic lives in the mathematics of the operations rather than in a smart server, the server can be reduced to a message relay. It receives encrypted operations from each editor and fans them out to the others. Every client decrypts the operations and applies them locally, and the CRDT guarantees they all converge on the same text. The server never sees the document, never sees the operations in the clear, and is not needed to resolve conflicts.
Where the Keys Live
For this to be end-to-end encrypted, the editing key must be shared only among the collaborators and never with the server. This is the same key-distribution problem that secure group chat solves, and the solutions rhyme. A document key is generated on a client, and access is granted by encrypting that key to each new collaborator's public key, so the server only ever handles wrapped keys it cannot open.
Adding and removing collaborators is the hard part, exactly as it is in group messaging. Removing someone should ideally mean they can no longer read future edits, which requires rotating the document key and re-sharing it with the remaining members, a process with the same post-compromise properties that group encryption protocols work hard to provide. Systems differ in how rigorously they handle this, and it is a fair question to ask of any encrypted collaboration tool: what actually happens, cryptographically, when someone is removed from a document.
What Still Leaks
A blind server is not an omniscient-blind server. Even when it cannot read the document, it observes a good deal, and pretending otherwise would repeat the overclaiming this whole field should avoid.
| Signal | What the relay server can still see |
|---|---|
| Document existence and size | That a document exists, roughly how large it is, and how it grows over time from the volume of operations. |
| Collaborator set | Which accounts connect to which document, unless additional metadata protection is layered on. |
| Editing activity | When editing happens and how intense it is. A burst of operations at 2 a.m. is visible even if the words are not. |
| Access patterns | Who opened a document and when, which can reveal relationships and interest independent of content. |
Encrypting the content of a collaborative document is the solved part. Hiding who collaborates with whom, when, and on how large a thing, is the same metadata problem that every private system runs into, and it does not disappear just because the words are encrypted.
The Offline and Trust Bonus
The CRDT approach carries two side benefits worth noting. Because merging is deterministic and local, encrypted collaborative editors tend to work offline gracefully: you edit while disconnected, and your operations merge cleanly when you reconnect, with no central conflict resolution needed. And because the server is only a relay, the trust you place in the operator shrinks dramatically. A compromised or compelled server can disrupt availability or observe metadata, but it cannot read your documents, which is a categorically better position than trusting a provider not to look at content it can plainly see.
This is the same shift that runs through all of end-to-end encryption: moving trust from the middle of the system to its edges. The server stops being a party you have to trust with your data and becomes a party you only have to trust for delivery. That is a much smaller ask, and a much easier one to verify.
Evaluating a Tool
If you are choosing an encrypted collaboration tool, the useful questions follow from the architecture. Is the encryption genuinely end to end, meaning the server never holds a usable key, or is it merely encrypted at rest with a key the provider controls, which is a very different guarantee. What happens cryptographically when a collaborator is removed. And what metadata does the service acknowledge it can see. A tool that answers these clearly is being straight with you; one that just says "encrypted collaboration" is leaving the important parts unstated.
The reassuring news is that the hard technical problem, merging concurrent edits without a trusted referee, has real solutions in CRDTs, and they compose cleanly with client-side encryption. Encrypted real-time collaboration is not a contradiction. It is an engineering achievement with a well-understood shape, and a well-understood set of limits.
Where Haven Fits
Haven's focus is encrypted email and messaging rather than document editing, but the design philosophy is the same one this problem forces on you: reduce the server to a relay that cannot read what it carries, and put the keys with the people, not the provider. Our group messaging uses MLS (RFC 9420) to solve the same collaborator-key-rotation problem that encrypted documents face when membership changes.
The throughline across secure chat, encrypted documents, and private mail is one idea: coordination does not require comprehension. A server can help many people work together without understanding a word of what they are working on. When it is built that way, the trust you extend to the operator gets much smaller, and much easier to justify.