Architecture Decision Records

ADRs record decisions that constrain Komms across implementations. An accepted ADR is normative until another ADR explicitly supersedes it. A proposed ADR is design work under review: it may guide experiments, but it is not a shipped product promise merely because the file exists.

ADR	Status	Decision area
0001	Accepted	Rust core and crate boundaries
0002	Accepted	XChaCha20-Poly1305 for AEAD
0003	Accepted	Double Ratchet with hybrid PQXDH
0004	Accepted	libp2p internet transport
0005	Accepted	Meshtastic-first off-grid transport
0006	Accepted	AGPLv3 licensing
0007	Accepted	Recipient-scoped delivery tokens
0008	Accepted	In-tree hardened mDNS
0009	Accepted	Token-blind internet↔mesh bridging
0010	Accepted	UniFFI embedded runtime
0011	Accepted	Mnemonic-sealed backup
0012	Accepted	Sender-key group messaging
0013	Proposed	Real-time call transport and gating
0014	Accepted	Versioned encrypted message content
0015	Proposed; implementation exists	Encrypted attachment pipeline and no-airtime policy
0016	Accepted	Canonical group-mention content
0017	Proposed	Optional service modes and trust boundary
0018	Proposed	Rotating pairwise rendezvous
0019	Proposed	Capability-gated native wake

The attachment implementation follows ADR-0015 and its hard no-airtime rule, but the ADR file still carries Proposed status. This index reports that governance state rather than silently treating implementation as acceptance.

Use the template for a new decision. Protocol, cryptographic, transport, replicated-state, or persisted-format changes require an ADR before implementation; ordinary local UI work does not.

Return to Start Here, the Architecture, or the Feature Delivery Plan.