DocsCore, node and desktop
Core, node and desktop
All the cryptography runs on your device. The network only stores and forwards.
| Part | Runs on | Holds |
|---|---|---|
| Core | Your device | Every protocol and crypto step: MLS groups, the sealed envelope, identity, media, franking |
| App layer | Your device | The one interface the desktop shell calls; no protocol logic of its own |
| Desktop app | Windows, Linux | The window you use: a bundled interface that loads nothing remote |
| Node | Servers | Sealed envelopes, media parts, the handle directory and the alpha gate |
The core
One library holds all of Pigeon's protocol and cryptography, so every client behaves the same. It builds and opens MLS messages, seals each one into an envelope for the network, keeps your account's key-event log, encrypts files, and checks message franking. Nothing outside it encrypts or decrypts.
The desktop app
A native window built with Tauri 2 over the core. Its interface is bundled with the app and makes no request to the web; it uses the system's webview (WebView2 on Windows, WebKitGTK on Linux). Your messages live in one encrypted database on your computer, whose key sits in the system keystore.
The node
A node is a durable store-and-forward server for opaque bytes. It speaks HTTPS over TLS 1.3 only and has no plaintext listener. It never parses what it stores: it checks an envelope's identifiers for shape and keeps it until the recipient collects it. It stores hashes of the capabilities and acknowledgement keys that let a device fetch and delete, never the values themselves.
One message, end to end
text
→ MLS application message (group key, RFC 9420)
→ franking commitment (HMAC-SHA256, in the MLS AAD)
→ sealed envelope v3 (HPKE, X-Wing, RFC 9180)
→ PUT to 5 replicas (counted sent at 3)
→ recipient fetches, opens, saves, then acks
→ ack deletes; a tombstone stays 7 daysRead on: encryption, how messages travel, delivery.