Feature Scope

The roadmap orders the engineering milestones (M0 to M6) that build the protocol, transports, and app shells. This document is the other axis: which product features (the surface a messenger-app user recognizes) belong in Komms, and under what constraints. It exists so feature requests get triaged against the architecture instead of against a competitor's feature list.

The sequenced implementation work for every approved item is in 12: Feature Delivery Plan.

The organizing question is never "does app X have this?" It is: does the feature survive a decentralized, metadata-blind, delay-tolerant, offline-first system whose lowest-bandwidth carrier is a LoRa mesh? A feature that assumes a central coordinator, always-on connectivity, or generous bandwidth either gets redesigned to fit those constraints or is declined.

Each item notes where it lands: which crate or milestone already covers it, or what it would take. Nothing here loosens a security or scope commitment in 01: Why or the roadmap; where a feature touches the protocol, transports, or crypto, it lands only behind an ADR that shows it surviving the threat model and the mesh bandwidth floor (the implemented C7 Beta audio path is the current example: direct internet/LAN QUIC only under accepted ADR-0013, with physical-platform qualification still required).

Build (fits the architecture as-is)

These are either already carried by the core crates, stay local to a device, or fit the architecture without changing its security model. Their implemented/planned status and prerequisites are tracked in the delivery plan.

• Text and audio messages. Both are implemented. Recorded audio is an asynchronous encrypted F3 attachment, never a live call: every shell records the same bounded mono PCM WAV profile that omits source metadata, requires local review and explicit send/discard, and derives duration/waveform only on the endpoint. F4 explains the current carrier at confirmation. Under ADR-0015's hard rule, a mesh-only route holds every audio clip for a faster link and emits zero bulk airtime frames.
• End-to-end encryption. Native to kult-crypto; not optional and not a toggle. Every message is sealed; there is no unencrypted mode to add.
• Post-quantum upgrades. Already the design: the handshake is hybrid PQXDH (see 04: Cryptography). No user-facing feature, listed because users ask for it by name.
• Usernames / contact names. Identity is a keypair and the authoritative human label is a local petname, never a phone number or central-registry name (see 06: Identity & Trust). B5 local rename is implemented through every interface with NFC normalization, duplicate/confusable/bidi/ invisible review, exact peer targeting, restart durability, and zero network work. An optional signed self-display name may later be advertised as a non-unique suggestion, but it is not implemented and could never silently override the recipient's petname.
• Connect-code discovery. Implemented for Beta: a kc2 code binds the stable account digest to a random rotatable discovery capability. Fixed-size encrypted weekly records carry bounded authority, ingress, admission, and mailbox-only public data. Standard/Private never publish direct routes; Sovereign requires an explicit warning acknowledgement. Rotation preserves identity and safety numbers, paired contacts update over authenticated sessions, and a visible legacy mailbox-only bridge can be retired.
• Secure backups. Implemented: the KKR10 mnemonic-sealed backup (Argon2id under a 24-word BIP-39 phrase, ADR-0011/ADR-0012), including sealed local metadata and note-to-self history, terminal ephemeral tombstones, and signed group authority plus linked-device recovery state. KKR1 through copied-root KKR7 remain readable only through the visible new-identity archive-reset flow; they do not resume their former identity. Stored locally or moved by sneakernet; no cloud.
• Note to self. Implemented as a sealed local conversation in kult-store, with the reserved note_to_self identity across every shell and no peer, envelopes, receipts, queue entries, or transport activity. Text is supported; attachments follow the attachment shell work.
• Scheduled / queued messages. Implemented. Ordinary queued delivery waits honestly for a carrier; scheduled delivery adds a durable absolute-UTC gate in core storage and the node scheduler, plus shared RPC/CLI/UniFFI operations for create/list/edit/cancel, so app exit or suspension cannot send early. Desktop, Android, and iOS now provide local-time composer controls plus distinct editable/cancellable scheduled rows before the ordinary queued, sent, and delivered states.
• Text formatting. Implemented through every front door and shell as one bounded CommonMark-style source subset: emphasis, strong, inline/fenced code, quotes, and lists. Exact source remains the authenticated stored/transmitted value; shells render only the shared inert block/run model and copy a readable plain- text projection. Raw HTML, links, images, URL schemes, remote fetches, and scriptable content are never interpreted. See 16: Safe Text Formatting.
• Conversation pins. Implemented for pairwise contacts, groups, and note-to-self through the sealed F5 store and every wrapper and shell. Exact typed identity, manual order, idempotent append/unpin, complete-set reorder including stale targets, deterministic activity tie-breaking, cleanup, and reactivation stay local. Folder selection and label filtering precede one leading pinned block. The limit is 8,192; KKR10 and authenticated own-device C2 sync are the only portability paths, and every operation creates zero network, notification, crypto, or transport work. Message pins remain a separate design because they require stable message references.
• Dark mode. Implemented as the exact system / light / dark preference under the sealed F5 appearance.theme key, exposed through node, RPC/CLI, UniFFI, and every shell. System is the first-run default and follows native changes live; desktop uses semantic CSS roles, Android uses DayNight resources, and iOS uses adaptive system colors. Reference palettes meet WCAG normal-text contrast, high-contrast and reduced-motion behavior remains native, and color is never the only security or delivery signal. KKR10 is the authoritative portability path; a small non-sensitive device cache exists only to style the pre-unlock gate without a flash.
• Custom icons. Implemented for contacts, groups, folders, and note-to-self over the sealed F5 record and every wrapper/shell. Missing records render generated initials; eight bundled glyphs and selected local JPEG/PNG inputs become exact 256×256 RGBA PNGs that omit source metadata after orientation normalization and square crop. Animated/decompression-heavy inputs fail closed. Limits are 512 KiB per icon, 1,024 records, and 64 MiB aggregate; reads safely fall back after corrupt or legacy non-canonical bytes. Portability is limited to KKR10 and authenticated own-device C2 sync. Icons never enter avatar URLs, peer sync, envelopes, capabilities, queues, notifications, DHT state, or transport work.
• Screen security. Implemented as an always-on pre-unlock policy. The shared node/RPC/CLI/UniFFI contract names exact native capability levels and limits; shells enforce them locally. Android applies FLAG_SECURE to every activity. iOS obscures inactive/app-switcher and live-captured scenes but cannot universally block still screenshots. Desktop requests best-effort native content protection, obscures on focus loss, and provides Ctrl/Cmd+Shift+L rapid lock. It is not stored, backed up, synchronized, notified, or sent and creates zero transport work. See 13: Screen Security.
• Incognito keyboard. Implemented as an always-on pre-unlock policy across the shared node/RPC/CLI/UniFFI contract and every shell text editor. Android sets the documented no-personalized-learning request on all editors; iOS disables correction and uses secure passphrase/mnemonic fields; desktop applies autocomplete, correction, capitalization, and spellcheck hints. Automated inventories cover message, future search, passphrase, mnemonic, and naming classes. It is not stored, synchronized, notified, or sent and creates zero transport work. Keyboard/OS/webview compliance remains explicitly best effort. See 14: Incognito Keyboard.
• Local still-image editing. Implemented across desktop, Android, and iOS through one bounded Rust helper: JPEG/PNG orientation normalization, free/preset crop, 90-degree rotation, and manual blur/pixelation are applied before encryption. The exact PNG re-encoded without source metadata is reviewed and is the only asset sealed; protected originals and intermediates are cleaned locally. No protocol involvement.
• Mentions. Group mentions are implemented through explicit current-roster pickers and canonical typed content, with exact readable fallback text and stable encrypted peer references rather than ambiguous free-form @name parsing. Semantic send fails closed unless every current co-member has fresh authenticated support; an explicit plain-text fallback never notifies. Mention notifications are endpoint-local and opportunistic, with no server-push guarantee.
• Private labels. Implemented for pairwise contacts, groups, and note-to-self through the sealed F5 metadata store and every wrapper and shell. Stable random IDs remain separate from exact names and canonical colors; duplicates use color plus deterministic order rather than raw IDs in human-facing UI. Accessible managers, non-color badges, assignment actions, stale-record cleanup, and deterministic match-any/match-all filters are local presentation only. Limits are 128 live labels, 8,192 assignments, 32 labels per conversation, and 256 UTF-8 bytes per name. KKR10 preserves exact identity, ordering, membership, and stale behavior. Labels do not affect messages, delivery, search, unread truth, notifications, or transports and do not sync to contacts or services. C2 may converge them only between authorized devices of the same account. Message labels and shared tags remain separate work; B11 conversation pins compose independently after label filtering.
• Private conversation folders. Implemented for pairwise contacts, groups, and note-to-self through F5 and every wrapper and shell. One stable typed conversation belongs to at most one folder; All and Unfiled are virtual views. Exact duplicate-capable names use stable random IDs plus durable manual order, never display-name inference. Create, rename, complete-set reorder, move, unfile, deletion review/cascade, and stale cleanup are atomic local operations. Folder selection runs before the independent B18 any/all label filter. Limits are 128 folders, 8,192 assignments, and 256 UTF-8 bytes per name. KKR10 preserves exact identity, order, membership, and stale behavior. Folders do not affect messages, delivery, search, unread truth, notifications, transports, or contact/service state; C2 may converge them only between authorized devices of the same account.

Build with constraints (needs transport-awareness or local-first sync)

Realistic, but only if they respect carrier bandwidth or tolerate offline/delayed peers. The recurring rule: the app must know which carrier a peer is reachable on and degrade honestly, exactly as the delivery ladder already does.

• File sharing. The bounded F3 pipeline is implemented across desktop, Android, and iOS: independently sealed resumable chunks, explicit consent and lifecycle controls, protected export, exact progress, and pairwise/encrypt-once group transfer. Safe generic rows now share a fail-closed filename/media-type policy, explicit warned open for reviewed matches, and export-only handling for active, mismatched, unknown, or nameless files. A hard no-airtime class still holds every bulk object for a faster link; no scanner, remote preview, or new transport behavior is implied.
• Linked devices. Implemented across the core, strict RPC/CLI, UniFFI, and every shell. One account identity uses separately authenticated device keys, per-device sessions, strict-majority KDA2 authority, recovery epochs, and deterministic ordinary-data sync. Linking happens proximately through a mutually confirmed QR/paste ceremony, never by copying the account root, live ratchet databases, or depending on cloud sync. Forks and same-epoch recovery conflicts remain visible and fail closed; routine KKR10 is root-free. Physical-device, independent-review, and independent-interoperability qualification remain P0 gates. See 22: Linked Devices and ADR-0026.
• Message editing. Implemented for canonical pairwise and group Text through every front door and shell. Immutable events target exact author/content ids, retain inspectable versions, and converge under offline reorder by maximum (revision, edit id) without clocks. Pairwise and current sender-key group authorship is authenticated; group recipients verify an account/device-bound origin tag before chain advance or edit application. Pairwise capability and complete current-group capability/origin exchange are required before send; legacy membership-authenticated text, attachments, mentions, and edits keep their historical label and remain non-editable. Editing is not erasure. See 18: Authenticated Message Editing and ADR-0029.
• Disappearing messages / view-once media. Implemented for pairwise and groups through every front door and shell. Exact authenticated local deadlines, terminal sealed tombstones, KKR6 plaintext/media exclusion, and first-output view-once consumption compose with a coarse hour-aligned envelope-v2 deletion hint for mailboxes/bridges. The promise is local to each installation: relays and recipients may retain copies, and Komms does not promise remote erasure or screenshot prevention. See 19: Disappearing Messages and View-Once Attachments.
• Group polls. Implemented through every front door and shell as content-v1 kind 6 over sender-key groups. Stable poll/option IDs, fixed creation-time electorates, visible vote heads, creator-claimed closure, and local deterministic tallies converge after duplicate, delayed, reordered, removed-member, restart, and restore paths. Votes are explicitly not anonymous. Each current voter and creator is authenticated separately to every recipient device without making the transcript publicly verifiable. See 20: Group Polls, ADR-0022, and ADR-0029.
• Admin / role controls. Implemented through every front door and shell as a fixed owner/admin/member model. Canonical generation-bound full state, ownership-transfer certificates, admin requests, and moderation snapshots are identity-signed; the sole owner serializes transitions and every accepted change re-keys. Stale/demoted requests and losing transfer forks fail closed; KKR6 introduced authority and KKR10 carries it forward. The new-identity legacy archive reset omits groups. See 21: Group Roles, Ownership, and Moderation and ADR-0023.
• Live voice and video calls. The Beta audio is implemented across transport, node, RPC/CLI, UniFFI, desktop, Android, and iOS. It is strictly confined to a fresh direct QUIC path reached through internet libp2p or LAN discovery, never a relay-only, TCP, mailbox, sneakernet, or radio-mesh route. DCUtR may upgrade a relayed path before the call becomes available. Bounded signaling stays inside ordinary ratcheted message content; a fresh per-call secret derives directional authenticated keys for one reliable /komms/call/1 Opus substream. There is no coordinator, call history, backup state, or delayed fallback. Recorded audio/video clips remain asynchronous F3 payloads. Real NAT, sustained network, battery, native audio-route, background, and lock qualification remains a release gate. Video starts only after audio passes. See 23: Live Audio Calls.
• Optional hybrid reachability and native wake. In scope only as a reversible convenience plane over the unchanged server-independent core. Established peers may use rotating provider-specific rendezvous slots for encrypted route hints, and a sender may emit a content-free APNs/FCM wake only after a direct peer or recipient-selected mailbox accepted the sealed envelope. DHT/QR remains first-contact discovery, mailboxes remain durable delivery, encrypted receipts remain delivery truth, and complete service failure falls back to Sovereign mode. Standard mode discloses service-use metadata; Private mode reduces source/target linkage through Tor or a non-colluding OHTTP relay without promising global anonymity. The feature is governed by ADR-0017 through ADR-0019. All three are accepted and implemented for the local Beta profile across the common mode contract, pinned HTTPS/Tor clients, signed replaceable provider configuration, direct APNs, Play-only FCM, an inspected Google-free artifact, every shell, and dedicated service artifacts. A fixed-mapping OHTTP relay is also implemented as an operator artifact, but no compatible client/gateway path or non-collusion evidence exists. No convenience default ships until deployment, Private-ingress, external, and named physical-field qualification gates close. See Operating modes and provider configuration and Native-wake mobile qualification.

Deferred or declined (fights the model)

Structurally incompatible with offline-first, metadata-blind, low-bandwidth-floor operation, or would collapse a mesh. Any of these would need a compelling ADR to move.

• Call links. A reusable link needs a rendezvous and routing design for a caller who has no established pairwise session with a reachable endpoint. ADR-0018 deliberately creates slots only after pairing and does not solve this first-contact problem. No acceptable design has been accepted. Declined.
• Very large groups (1,000+). Over mesh/radio, fanning one message out to hundreds of members causes packet collisions and network collapse. Group caps stay low for mesh-reachable groups; large-group work (OpenMLS, M6) targets internet-carried groups with explicit caps, never unbounded mesh broadcast.
• Stories / ephemeral broadcast media. Global broadcast of ephemeral media is heavy vertical overhead that conflicts with a delay-tolerant, data-conserving mesh model. Declined.

How to change this document

Adding a "Build" feature must also update the delivery plan with its status and prerequisites. Moving anything out of "Deferred or declined," or adding a feature that touches the protocol, transports, crypto, or replicated state requires an ADR listed in the ADR index that shows the feature surviving the threat model and the mesh bandwidth floor. This keeps the feature surface honest about the same constraints the rest of the design is held to.