Anonymity Coverage Across Prototypes

Each of Connect's seven research prototypes exercises a different slice of the four anonymity layers defined in the Anonymity Lifecycle taxonomy — L1 Identity, L2 Network, L3 Social, and L4 Temporal. This page maps each prototype against those layers, identifies which are structurally exercised and which are absent or deferred, and highlights the gaps that no current prototype covers.

Key finding: identity and network anonymity are exercised most consistently across the set. Temporal anonymity is the weakest. Social anonymity is only structurally exercised by Prototype 3, and only for key exchange — not for messaging or feed replication. No prototype yet exercises all four layers simultaneously at production fidelity.

This page is a different angle from the Anonymity Lifecycle, which traces the four layers across the lifecycle of a single contact relationship. Here the question is: which layer does each prototype actually exercise, and where are the research gaps?

The Four Layers

From Anonymity Lifecycle:

L1 Identity — keypair only, no PII; feed_id = SHA-256(pubkey); no name, phone number, or email required at any layer
L2 Network — no IP traffic in offline mode; Tor hidden service when online; observer bounded to physical proximity for BLE/WiFi
L3 Social — no global namespace; no directory; no friends-of-friends replication; local names only; contacts know only their direct subgraph
L4 Temporal — forward secrecy via Double Ratchet chain-key deletion; BLE MAC rotation; message expiry via tombstone

Coverage Matrix

Verdict codes: Full = structurally exercised as designed; Partial = some aspects present, documented limitations; Deferred = explicitly out of scope for this prototype; Out of scope = this layer is not a variable in the prototype's design space.

Layer	P1 Tor Chat	P2 BLE Messenger	P3 Key Exchange	P4 Encrypted Feed	P5 WiFi Relay	P6 BLE Dead Drop	P7 LoRa Mesh
L1 Identity	Full	Full	Full	Full	Partial	Full	Partial
L2 Network	Full	Full	Full	Out of scope	Partial	Full	Full
L3 Social	Deferred	Partial	Full	Deferred	Partial	Partial	Partial
L4 Temporal	Partial	Deferred	Out of scope	Partial	Out of scope	Out of scope	Deferred

Rationale — Per Cell

L1 Identity:

P1 Full — .onion address as identity; Ed25519 private key in filesDir; no PII; contacts added by QR only.
P2 Full — X25519 static keys; QR contact exchange; no name or phone required; only ciphertext on disk.
P3 Full — Ed25519 + X25519 + ML-KEM-768 key bundle; feed_id = SHA-256(pubkey); no PII in any advertisement at any time.
P4 Full — Ed25519 keypair is the identity; feed_id derivation matches the full system; key material in platform keychain, never in SQLite.
P5 Partial — relay derives a truncated feed_id (16 bytes vs. full 32) for routing; session tokens expose feed_id[0:16] to the relay operator, which is a partial identity leak the full system mitigates with ephemeral pairwise identifiers. Prototype explicitly documents this as a known limitation.
P6 Full — phone encrypts before deposit; relay stores only recipient hash (8 bytes); relay holds no key material and cannot link a hash to a real identity at prototype scale.
P7 Partial — sender_id in the LoraEnvelope is 8 bytes of SHA-256(Ed25519 pubkey), not the full key. The Meshtastic packet header carries the node ID (4-byte integer) in cleartext, required for flood-routing. A passive LoRa observer can correlate node ID with sender_id over time.

L2 Network:

P1 Full — all traffic tunnelled over Tor v3 hidden services; relay operator sees opaque ciphertext; guard node sees IP (documented residual risk).
P2 Full — offline only; no IP packets; BLE is the transport; observer bounded to physical proximity.
P3 Full — offline only; no IP packets; BLE advertisements carry only random bytes; NFC tap generates no network traffic.
P4 Out of scope — transport is file export, USB push, or local TCP socket; the prototype deliberately excludes network transport to isolate the data model. Network anonymity is not a variable here.
P5 Partial — relay is reached via LAN WiFi, not internet. Relay operator sees sender/recipient feed_id hashes, message size, and timestamps. This is the prototype's primary stress test of what a relay can see — the Partial verdict is the finding, not a failure. TLS is deferred to v0.1+; v0.1 uses plain HTTP on the local hotspot (passive eavesdrop by other hotspot phones is a documented limitation).
P6 Full — BLE GATT only; no IP traffic; relay holds no keys; no internet uplink. Observer bounded to BLE range of the fixed device.
P7 Full — LoRa ISM band; no internet infrastructure; no IP packets. All relay nodes carry opaque ciphertext. Passive interception of LoRa frames is possible with commodity hardware (documented), but E2E encryption and Meshtastic's outer AES-256-CTR layer together prevent content recovery.

L3 Social:

P1 Deferred — two users and one contact relationship; no namespace, no directory. Social graph structure is not exercised because there is no multi-contact scenario, no BLE discovery, no group. The no-global-namespace property is inherited but not empirically tested.
P2 Partial — BLE advertisements carry a truncated SHA-256 of the identity key (8 bytes) as manufacturer-specific data, which allows known contacts to recognise each other. This is a weak but non-zero identity signal in the advertisement. QR exchange prevents a stranger from resolving the truncated hash. No global directory or friends-of-friends replication exists.
P3 Full — the prototype's primary L3 contribution: a 16-byte random BLE beacon payload (no identity, no persistent token) that rotates every 15–20 minutes; no identity in any advertisement; BLE challenge-response over GATT reveals identity only to mutually authenticated contacts; no namespace, no directory, no social graph inference possible from passive BLE observation.
P4 Deferred — transport-agnostic; social graph structure is not exercised. Friends-of-friends replication is disabled by design in the feed sync model (audience=contacts is not gossiped), but this is not empirically tested in the prototype.
P5 Partial — relay stores (sender_feed_id, recipient_feed_id, timestamp) tuples for every message. This is a pairwise social graph edge visible to the relay operator. The prototype documents this explicitly as a known limitation and points to ephemeral pairwise identifiers (SimpleX queue model) as the production mitigation.
P6 Partial — recipient routing uses an 8-byte hash of feed_id, not the full identifier. Relay cannot reconstruct the social graph from the hash alone, but the hash is stable for a given feed_id within a prototype deployment. No friends-of-friends, no directory.
P7 Partial — Meshtastic node ID (4-byte integer, cleartext) is required for duplicate suppression. A persistent observer can correlate node IDs with physical locations and infer social relationships from co-presence patterns. The 8-byte sender_id in the LoraEnvelope is not directly linkable to the node ID by a passive observer, but both appear in the same LoRa frame.

L4 Temporal:

P1 Partial — Signal Protocol Double Ratchet (X3DH + per-message ratchet) is fully implemented via libsignal-android. This is the strongest L4 implementation across all prototypes. However, the hidden service private key is stored in filesDir; app-data-clear loses the .onion address (no backup). Message expiry is not implemented in the prototype.
P2 Deferred — static X25519 keys, no ratchet. Forward secrecy is explicitly documented as out of scope. If the key is compromised, all past messages encrypted to that key are recoverable (if ciphertext was captured). MAC rotation in BLE advertisements is handled by Android's built-in MAC randomisation, not by the prototype.
P3 Out of scope — this prototype establishes keys and exercises BLE mutual auth; it does not carry message content. There are no messages to protect under L4. BLE beacon payload rotates every 15–20 minutes — this is a L4-adjacent presence-unlinkability control but not temporal anonymity of content.
P4 Partial — hash chain with tombstone: the original envelope row is retained; only content_json is dropped on soft-delete. This preserves chain integrity while dropping content. Double Ratchet is stubbed as single-key AEAD (no ratchet) — forward secrecy is explicitly deferred.
P5 Out of scope — relay is the store-and-forward layer; phone-side encryption uses a static X25519 shared secret (same limitation as P2). The relay itself has no L4 concern — it sees only ciphertext. Message TTL (72 hours) provides a weak temporal bound.
P6 Out of scope — TTL (72 hours) plus explicit ACK-triggered deletion. No ratchet, no forward secrecy at the relay layer. Phone-side encryption uses Tink AES-256-GCM AEAD with no ratchet.
P7 Deferred — explicitly documented: static X25519 shared secrets, no Double Ratchet. A full X3DH handshake requires 6+ LoRa frames, potentially 30+ minutes under EU duty-cycle constraints — impractical. Past messages are recoverable if captured ciphertext is available and the static key is later compromised.

Per-Prototype Anonymity Profile

P1 — Tor Chat

L1 and L2 are the prototype's headline contributions: the .onion address as a stable but network-anonymous identity, and all traffic through Tor v3 hidden services. L4 is partially exercised via the Signal Protocol Double Ratchet — the strongest forward secrecy of any prototype in the set. L3 is not exercised because the prototype is a two-party chat with no BLE, no discovery, and no multi-contact scenario. The Tor guard node seeing the user's IP is the principal residual L2 risk, and is correctly documented in the spec. See Spec: Tor Chat.

P2 — BLE Messenger

Offline-first design gives strong L2 (no IP packets). L1 is clean: only ciphertext on disk, QR contact exchange, no PII. The critical L4 gap — static X25519 key, no ratchet — is explicitly documented. L3 is weakly present: the 8-byte truncated hash in BLE advertisements is not a full identity reveal, but it is not the fully unlinkable random beacon that P3 achieves. The prototype's primary value is empirical BLE characterisation, not anonymity fidelity. See Spec: BLE Messenger.

P3 — Proximity Key Exchange

P3 is the L3 centrepiece of the prototype suite: unlinkable BLE beacons (16 random bytes, rotated every 15–20 minutes), no identity in any advertisement, GATT challenge-response that reveals identity only to authenticated contacts. L1 is full — Ed25519 + X25519 + ML-KEM-768 key bundle, feed_id derivation matching the full system. L2 is full (offline). L4 is not applicable — the prototype carries no message content. The beacon rotation interval is the residual L3 risk: chipset fingerprinting (clock drift and RSSI signature) can correlate a device across rotation events. See Spec: Proximity Key Exchange.

P4 — Encrypted Feed

L1 is fully exercised: Ed25519 signing, feed_id derivation, audience-keyed AEAD, key material in platform keychain. L4 is partially exercised: the tombstone preserves chain integrity while dropping content, and the hash chain provides tamper detection. The Double Ratchet stub (single-key AEAD, no ratchet) is the principal L4 limitation. L2 and L3 are not variables — the prototype's transport-agnostic design deliberately excludes them. See Spec: Encrypted Feed.

P5 — WiFi Relay

P5's primary research question is L2 at the relay boundary: what does a relay operator see when all content is E2E encrypted? The answer — sender/recipient feed_id hashes, message size, timestamps — is the prototype's key finding, and constitutes a partial L3 violation (pairwise edges visible to relay). L1 is partial because the truncated feed_id and stable session tokens are a simplification the full system resolves with ephemeral identifiers. L4 is not a relay concern — phone-side static-key AEAD is the same limitation as P2. See Spec: WiFi Relay.

P6 — BLE Dead Drop

The delay-tolerant, fixed-location variant of P5's relay model. L1 and L2 are clean: phone encrypts before deposit, relay holds only hash-routed ciphertext, no internet uplink. The 8-byte recipient hash is a partial L3 mitigation — stable for a given feed_id but not the full identifier. No forward secrecy (Tink AEAD, static key): L4 is absent. The prototype's value is demonstrating the asynchronous BLE relay model, not anonymity completeness. See Spec: BLE Dead Drop.

P7 — LoRa Mesh

L2 is strong: no internet infrastructure, ISM-band radio, all relay nodes carry opaque ciphertext. L1 is partially compromised by the cleartext Meshtastic node ID required for flood-routing duplicate suppression — a structural constraint of the Meshtastic firmware layer, flagged as an open question in the spec. L3 inherits the same node-ID problem. L4 is explicitly deferred: static X25519 shared secrets, no ratchet, EU duty-cycle constraints make a ratchet handshake impractical. See Spec: LoRa Radio Mesh.

Gaps

Gap 1 — No prototype exercises all four layers simultaneously

The full system requires L1 + L2 + L3 + L4 to hold simultaneously. The prototype suite reaches full coverage of L1 and L2 across multiple prototypes, but no single prototype fully exercises L3 (only P3, and only for key exchange — not for messaging or feed replication) or L4 at production fidelity with a real transport (P1 has the ratchet but no BLE/WiFi; P2 has the transport but defers the ratchet). A future integration prototype combining P3 (discovery), P4 (feed), and P1's Double Ratchet over a P5-style relay would be the first end-to-end four-layer exercise.

Gap 2 — Temporal anonymity (L4) has no transport-on-device prototype

P1 implements the Double Ratchet, but only over Tor — no BLE or WiFi Direct. P2 defers forward secrecy. P7 explicitly excludes it. The only L4 exercise is P4's partial hash-chain-and-tombstone work, which is not a ratchet. No prototype has yet run the Double Ratchet over a BLE or WiFi transport with real device constraints (Doze, background restrictions, OEM BLE stack bugs). The feasibility of per-message ratchet steps under real BLE throughput and battery constraints is unknown — this is the most significant open question across the set.

P3 exercises L3 for key exchange only. For the feed replication scenario (P4) and the relay scenarios (P5, P6, P7), L3 controls — no global namespace, no friends-of-friends, ephemeral pairwise identifiers at the relay — are either deferred or explicitly noted as partial violations. The production architecture requires relay sessions to use ephemeral pairwise identifiers rather than stable feed_id hashes. No prototype has implemented this.

P5 correctly identifies that a relay storing (sender_feed_id, recipient_feed_id, timestamp) tuples creates social graph edges visible to the operator. The production mitigation (SimpleX-style ephemeral queue IDs) is referenced but not prototyped. Until a relay prototype implements ephemeral pairwise identifiers, the L3 guarantee at the relay layer remains unvalidated. See also Threat Composition for the cross-layer treatment of this gap.

Gap 5 — Meshtastic node ID is an unresolved L1/L3 leak in P7

The cleartext 4-byte node ID required for Meshtastic flood-routing duplicate suppression is a structural constraint of the firmware. The open question — whether ephemeral node IDs can rotate without breaking relay functionality — requires firmware modifications outside the prototype scope. Until resolved, P7 cannot claim full L1 or L3 coverage.

Open Questions

Is a ratchet variant (for example, a simplified one-directional chain-key scheme) compatible with LoRa's bandwidth and EU duty-cycle constraints? This would partially close Gap 2 for P7.
Can the recipient_hash in P6's GATT protocol be rotated per-session (derived from feed_id plus a session nonce) without losing the routing property? This would close Gap 3 for the BLE dead-drop scenario.
At what contact count does the audience=contacts O(N) fan-out in P4 become the primary battery concern, and does this change the L4 ratchet feasibility calculation for a BLE-transport integration prototype?
Should an integration prototype (P3 + P4 + Double Ratchet + P5 relay) be the next step, or should the ratchet-on-BLE feasibility question be isolated first?

Cross-References

Anonymity Lifecycle — canonical source for the four-layer taxonomy; traces the same layers across the lifecycle of one contact relationship
Threat Model — adversary analysis per layer; residual risks that inform the verdict rationale in this page
Threat Composition — cross-layer attack surfaces; the Gap 3 and Gap 4 entries here relate directly to the relay metadata and audience field findings there
Key Revocation & Recovery — revocation window stresses all four layers simultaneously; relevant to Gap 1
Spec: Tor Chat — P1 full spec
Spec: BLE Messenger — P2 full spec
Spec: Proximity Key Exchange — P3 full spec
Spec: Encrypted Feed — P4 full spec
Spec: WiFi Relay — P5 full spec
Spec: BLE Dead Drop — P6 full spec
Spec: LoRa Radio Mesh — P7 full spec