| Work | What it does | What Tandem takes or leaves |
|---|---|---|
| Kolab groupware | Stores contacts, calendars and tasks as XML attachments in IMAP messages, with folders typed via IMAP METADATA (RFC 5464); "IMAP as a NoSQL store". | Proof that mail servers make a durable object store, and that ordinary mail clients will show such folders (harmless on a dedicated account). Tandem adds encryption, CRDT merge and per-collection keys, which Kolab leaves to server ACLs. |
| Apple Notes over IMAP (pre-iCloud Notes) | Notes kept as messages in a Notes IMAP folder. |
Same storage idea, single user, no merge. |
| Delta Chat / webxdc | Apps exchange state updates as email messages between chat members; apps use CRDTs because updates arrive in different orders. | Confirms email works as a CRDT transport. Webxdc sends updates between mailboxes over SMTP; Tandem shares one mailbox, which avoids SMTP rate limits and gives a single change feed. |
| secsync (Serenity Notes) | Relays end-to-end encrypted CRDT snapshots and updates through a central service; the relay can't inject data; key exchange is out of scope. | Same trust model for the relay (here, the mailbox). Tandem specifies the key management and membership that secsync leaves out. |
| Keybase | Per-device keys in a user sigchain; paper keys for recovery; per-user keys rotated on device revocation; per-team keys rotated on removal, lazily by admins. | Earlier drafts followed this closely: device chains, paper keys, per-user keys. Without a server to order events a device chain can fork, and settling that safely was never finished (§19). v1 has one secret per user, and per-device keys are the first candidate for a later version (Q15). |
| Matrix | Room membership validated by authorization rules over an event DAG; Megolm group sessions. | Matrix merges concurrent changes to who-may-do-what. An earlier draft of Tandem did the same and it proved too easy to get wrong (§19); a collection now has one signer and no rule for resolving two histories (§9.4). Megolm's ratchets give forward secrecy Tandem v1 lacks. |
| MLS (RFC 9420) | Standard group key agreement with forward secrecy and post-compromise security. | A candidate for a later version if forward secrecy matters. RFC 9420 §14 leaves it to the application to resolve competing commits; a single owner per collection would supply that order. Adoption and implementation cost are separate decisions. |
| Keyhive / BeeKEM (Ink & Switch) | Local-first capabilities and a decentralised TreeKEM variant for E2EE groups without a server. | The most relevant research direction; the formal paper is from 2026. Too new to depend on; worth tracking for v2. |
| JMAP Sharing (RFC 9670) and the JMAP Mail Sharing draft | Server-side sharing of data between accounts on the same server. | Would let each user have their own account, but it's server-specific, not end-to-end encrypted, and mailbox sharing is still a draft. Tandem keeps access control in cryptography so any mail account works. |
| Nostr | Signed events on public relays. | Considered as the transport. The relay pool is public infrastructure that shrinks and grows on others' terms; a mailbox you pay for is more predictable. The abstract store (§10.1) would admit a Nostr binding later. |
| CloudKit | Apple's sync with zone-wide shares. | The status quo being replaced: Apple-only, Apple-ID-bound sharing, opaque failure modes. |
References for the CRDT parts: Shapiro, Preguiça, Baquero, Zawirski, "Conflict-free Replicated Data Types" (2011); Preguiça et al., "Dotted Version Vectors" (2012); Kulkarni et al., "Logical Physical Clocks" (2014); Kleppmann, "Making CRDTs Byzantine Fault Tolerant" (PaPoC 2022).