atcomm

atproto DMs over DIDComm

End-to-end encrypted direct messages for your atproto identity.

atproto-native. Your messaging identity is your atproto identity.
end-to-end encrypted. Only participants can read; infrastructure sees ciphertext.
open specification. The binding is published; any client can implement it.
self-hostable & FOSS. Every component runs from open source (Apache-2.0).
permissionless. Enroll by writing to your own PDS; no gatekeeper.
decentralized. Independently hosted mediators interoperate by construction.
frontend-agnostic. The contract is the mediator + lexicon, not any app.
no blockchain. atproto + DIDComm + DNS/HTTPS, no ledger.

Why it exists

Direct messages on today's atproto apps are not end-to-end encrypted, and there is no open, published way to do E2EE DMs bound to an atproto identity. Existing E2EE options are proprietary. atcomm publishes an open binding, a small lexicon plus a DIDComm v2 profile, so any client, in any language, can interoperate.

How it works

Your messaging identity is your atproto identity. You publish a keyPackage record in your own PDS pointing at a DIDComm messaging key and the mediator(s) that hold your mail. To message someone, resolve their handle, fetch their keyPackage, and send a DIDComm v2 encrypted message via their mediator. Infrastructure sees ciphertext only.

handle  →  DID  →  PDS keyPackage  →  did:peer + mediator  →  DIDComm v2 (E2EE)

Roughly: an MX record for end-to-end-encrypted messaging.

The spec

The binding is published as two lexicons and a DIDComm message profile:

at.didcomm.keyPackage, the identity binding record
at.didcomm.dm, the message body schema
DIDComm message type https://didcomm.at/dm/1.0/message

See the spec for record shapes, the message envelope, and the raw lexicon files.

Self-hosting

Self-hosting atcomm is, at its core, running a DIDComm mediator: one standard, open-source component. Everything else is already open (the clients and the lexicon), so the only piece of infrastructure you run is the mediator. Two independently hosted mediators interoperate by construction, so you are never locked into ours.

A dedicated self-hosting guide is coming separately. For now, see the source repository.

Limitations

This is a proof of concept. What it does not do yet, stated plainly:

Not audited. Early software; no formal security audit. The spec is v1 and may change.
Keys are device-local, with no backup. Your messaging key is generated on your device and never leaves it; there is no backup or sync, so a new device means a new key. In the hosted web demo the key lives in browser storage on a page we serve, the weakest point; treat the demo accordingly.
Browser-delivered encryption is weaker. The demo is web-only for zero-install reach, but a web app re-fetches its code from a server on every visit, so each time you trust that the served page was not altered to leak your key. A native client does not re-deliver its code this way. Use the web demo to evaluate atcomm, not for sensitive messaging.
No forward secrecy yet. The encryption does not ratchet keys. Someone who records ciphertext and later obtains your key could read those past messages.
Metadata is not hidden. Encryption protects message content; mediators still see routing metadata: which messaging keys exchange messages, and roughly when.
No history or multi-device. Messages are delivered and removed; there is no server-side history or cross-device sync yet. Miss a pickup or switch devices and you won't see past messages.
Sender attribution is not yet verified. The claimed sender identity is carried but not cryptographically checked in the current build (see the FAQ).
Direct messages only. One-to-one; group messaging is a goal, not yet built.
The demo is hosted and invite-only. A convenience, not the architecture: the protocol is decentralizable and self-hostable; this particular demo runs on infrastructure we operate.

Request access

The demo is invite-only during the proof of concept.

Invites are coming soon. Check back shortly.