Decision: The first TalkCo profile should reduce accidental graph formation with opaque identifiers, fixed-size control traffic, context-scoped routing, queue rotation, and encrypted manifests. Mixnets, PIR, and ORAM remain bounded profiles for selected operations rather than default transport for every post and comment.
Metadata resistance is not a property that encryption supplies automatically. A relay can learn that two opaque endpoints exchange traffic. A storage provider can learn object size, access time, and shard placement. A discovery service can learn which identities are looked up. A group member can correlate an author, post, comment, attachment, and moderation event from the application envelope even when outsiders cannot. The policy must therefore state which observer is in scope for each protection and which leakage is accepted.
#Observer matrix
The matrix uses visible for direct observation, inferable for a useful inference from repeated observations, bounded for leakage reduced by a declared bucket or lifetime, and hidden only when the protocol has a stated guarantee against that observer. It is a design target, not a measured result.
| Observer | Payload | Object size | Timing | Membership | Peer identity | Shard placement | Post/comment relationship |
|---|---|---|---|---|---|---|---|
| Local process or OS | visible while unlocked or in process memory | visible | visible | visible | visible | visible | visible |
| Access network | encrypted | inferable without padding | inferable; endpoint pair visible | usually hidden, activity visible | IPs visible | hidden unless provider traffic is distinguishable | inferable from traffic shape |
| Relay or queue provider | encrypted if E2EE is correct | visible unless fixed blocks | visible at queue ingress/egress | inferable from queue and connection use | queue-scoped, not necessarily user identity | visible for objects it stores | inferable from ordering, fanout, and size |
| Discovery service | not applicable or encrypted | address-record size visible | lookup timing visible | inferable from queried records | visible for stable endpoint keys | usually hidden | inferable if lookups are content- or context-specific |
| Storage peer/provider | encrypted | visible | visible for reads/writes/leases | inferable from shared manifests or access schedules | provider-facing client identity visible | visible | inferable if identifiers or timing are reused |
| Group member | encrypted from non-members | visible in application envelope unless bucketed | visible locally | visible for their context | visible for peers they know | hidden unless manifests expose it | usually visible from signed parent/reference fields |
| Colluding providers | encrypted | visible across their observations | correlation possible | inferable across queues, discovery, and storage | linkable if identifiers or timing repeat | visible across their holdings | inferable unless contexts, batching, and identifiers are compartmentalized |
| Global passive observer | encrypted | inferable from packet lengths | inferable from traffic correlation | generally hidden only by a sufficiently populated privacy network | IP endpoints visible; application identity hidden only with a stronger overlay | hidden unless provider traffic is identifiable | inferable from correlated size/timing patterns |
The first policy should not attempt to hide the local process, unlocked group members, or a compromised running client. It should focus on preventing relays, providers, and ordinary network observers from turning transport and storage observations into a durable social graph.
#Evidence and practical limits
#Padding, batching, queues, and rotation
SimpleX is the strongest practical reference for the low-latency profile. Its current protocol uses unidirectional queues, 16,384-byte transport blocks, two-router forwarding, encrypted metadata envelopes, queue rotation, noise traffic, and separate connections to reduce cross-queue correlation. The same specification states that a busy router may act as a low-latency mix, but does not rely on that behavior for a security claim. This is a useful boundary for TalkCo: fixed blocks and disposable queues reduce leakage; they do not defeat a targeted observer who knows both endpoints or observes the client directly. SimpleX protocol overview, SMP v20
SimpleX Channels reuse the same two-router and fixed-block layers, while making the channel relay an application-level participant. Their documentation claims that the relay sees queue addresses rather than subscriber IP addresses, but also notes that participation privacy relies on independent queues and non-collusion between routers and relays. That is a composable pattern, not proof that a colluding global observer cannot correlate the traffic. SimpleX Channels
Tor provides a more general onion-routing substrate and specifies both connection-level and circuit-level padding. Its connection-level design gives a concrete cost reference: the default idle padding is expected to average about 103 bytes per second full duplex, or about 309 KB total for a roughly 50-minute idle connection. Tor's own circuit-padding specification says its deployed defense does not obfuscate inter-arrival timing and is aimed at particular circuit-setup patterns. Tor therefore improves endpoint and circuit exposure but does not turn ordinary interactive traffic into a globally unlinkable stream. Tor padding overview, connection-level padding, circuit-level padding
#Mixnets and cover traffic
Loopix-like systems combine fixed-size packets, probabilistic delays, and cover traffic. The original evaluation reports message latency in the order of seconds and relay throughput above 300 messages per second in its tested deployment, while explicitly treating latency and cover traffic as part of the anonymity trade-off. Katzenpost describes itself as a low-level mix network with fixed-length Sphinx packets, no reliable or in-order delivery, and a threat model that must be composed with a higher-level messaging protocol. Nym's public description likewise combines uniform packet sizes, cover traffic, mixing, and timing obfuscation. Loopix paper, Katzenpost specification, Katzenpost repository, Nym mixnet
The implication is operational: a mixnet can protect sender/receiver unlinkability against stronger observers, but only if TalkCo can afford delay, padding, battery use, relay diversity, cover traffic, abuse controls, and a meaningful anonymity set. It should be a sensitive-traffic profile for posts or comments whose authorship timing is itself dangerous, not the default path for every notification and attachment.
#Discovery and private DHTs
iroh is a direct-transport reference, not a metadata-resistant discovery protocol. Its endpoint ID is an Ed25519 public key; address lookup resolves a known endpoint ID into IP addresses or relay URLs. The project explicitly distinguishes address lookup from discovering unknown peers, and its relay path identifies clients by endpoint ID early in the connection. Mainline/Pkarr-style lookup can remove a single directory, but the signed endpoint record, queried key, relay URL, and timing remain observable to the relevant DHT or lookup operators. iroh 1.0, iroh address lookup, iroh FAQ
Waku is a useful counterexample. Its Relay protocol is peer-to-peer, but its Filter protocol explicitly discloses content topics to the serving peer, and its Store protocol exposes history queries to the store node. Waku documentation says anonymity or unlinkability is not guaranteed for these light protocols. Waku's RLN proof layer can limit spam without revealing publisher identity, but it is abuse control, not peer or relationship privacy. Waku protocols, Waku security features, Waku FAQ
The first TalkCo discovery policy should therefore use out-of-band invitations, context-scoped rendezvous records, short-lived opaque lookup handles, and multiple replaceable lookup providers. A global DHT may be tested as an adapter for already-known opaque handles; it should not index people, posts, comments, groups, or relationships.
#PIR and ORAM
PIR can hide which record a client retrieves from a database under a specific server or multi-server threat model. ORAM hides access patterns from an outsourced storage server, but practical costs depend strongly on workload. PRO-ORAM reports sub-second computational latency for read-only 256 KB blocks on large datasets, while earlier practical ORAM work reports roughly 20–35× overhead for a terabyte-scale design. These results do not make either technique a general solution for a social feed: writes, cache behavior, timing, result sizes, replica coordination, and the existence of the query target still require separate treatment. PRO-ORAM, Towards Practical ORAM
TalkCo should investigate PIR only for a narrow provider-index query, such as asking a storage peer for one of many opaque shard locations without revealing which handle was requested. It should investigate ORAM only for a bounded read-heavy index whose access-pattern leakage is a demonstrated requirement. Neither belongs in the first post/comment transport.
#Candidate profiles
| Profile | Main protections | Cost and failure | Best use | First falsifier |
|---|---|---|---|---|
| A. Opaque local-first | E2EE events, per-context opaque IDs, fixed control blocks, size buckets, queue rotation, independent relay/storage providers | Low-to-moderate bandwidth; low added latency; still vulnerable to global timing correlation and compromised clients | Default posts, comments, DMs, and attachments | A relay/provider can reconstruct stable context membership or post/comment edges from normalized traces alone |
| B. Onion/queue privacy | Profile A plus two-hop queue routing or Tor, connection isolation, delayed batching, optional cover traffic | Extra relay dependency, setup failures, battery and bandwidth overhead; targeted/global correlation remains possible | Sensitive DMs, invitations, membership changes, selected comments | Colluding entry/exit or access-network/relay observations link sender and receiver above the declared threshold |
| C. Mixnet-sensitive | Fixed-size Sphinx-like packets, batching, probabilistic delays, loop cover traffic, mix-provider diversity | Seconds-scale latency, continuous bandwidth and battery cost, lower availability, abuse and scheduling complexity | High-risk authorship or timing-sensitive posts/comments | A global passive simulation recovers message links at the declared anonymity-set and cover-traffic parameters |
| D. Private-query adjunct | Profile A/B plus PIR for selected index reads or read-heavy ORAM | Server CPU, client bandwidth, multi-server coordination, hard crash/recovery semantics | Storage-location or directory queries only | Provider learns the queried handle from request, response, timing, or cache behavior |
#What the trace harness can measure
The harness can compare profiles without deciding the product policy. Every adapter should emit a normalized trace containing:
- observer vantage and collusion set;
- logical event class, kept only inside the test oracle and never on the wire;
- packet/block size, padding bucket, direction, and count;
- send, enqueue, dequeue, retry, batching, and delivery time buckets;
- route, relay, lookup-provider, queue, and shard-handle lifetimes;
- connection reuse, circuit reuse, queue rotation, and provider overlap;
- cover-traffic rate, delay distribution, dropped/delayed packets, and battery/CPU/network counters;
- observed, inferred, padded, redacted, and unavailable fields.
It can then measure linkability, message delay, delivery probability, repair time, bytes per logical byte, wakeups, CPU, memory, and battery cost under controlled observers. It cannot decide whether a two-hop route, a 5-second delay, or a 16 KB block is acceptable; those are protocol/product decisions.
#Falsifiers and open decisions
The metadata stream is not complete until these experiments pass or produce a deliberate rejection:
- Stable-identifier falsifier: rotate queues, endpoint keys, lookup handles, and shard handles across contexts. Fail if the same observer can link contexts without collusion from the endpoints.
- Size/timing falsifier: replay identical logical posts and comments with different plaintext sizes and activity patterns. Fail if the profile claims bucketed privacy while size or timing classifiers recover the class above the declared threshold.
- Collusion falsifier: combine access-network, relay, discovery, and storage traces. Fail if the minimum policy implicitly assumes non-collusion without naming which parties must remain independent.
- Sparse-network falsifier: reduce background traffic and active peers. Fail if the privacy claim depends on a large anonymity set that the target deployment cannot maintain.
- Mobile-budget falsifier: run queue rotation, padding, batching, and cover traffic under suspend/resume and battery constraints. Fail if the policy cannot state its degraded mode.
- Discovery-query falsifier: compare invitation lookup, iroh address lookup, private DHT lookup, and Waku-style filter/store queries. Fail if any candidate requires a public relationship or content index for basic peer discovery.
- Storage-linkability falsifier: write the same logical asset through independent providers and repair a shard set. Fail if providers can link generations, parent posts, or comment relationships from handles, sizes, or repair timing.
#Minimum viable metadata policy
For the first encrypted social vertical slice:
- No global public identity, post, comment, membership, or shard-placement index.
- All application envelopes are end-to-end encrypted and use random, context-scoped identifiers; parent references are encrypted or replaced with opaque local references where the recipient set permits.
- Control traffic uses fixed-size blocks and bounded size buckets. Large ciphertext objects use padded chunk classes; no private-context deduplication based on a public content hash.
- Discovery begins with out-of-band invitations and short-lived opaque rendezvous handles. iroh, private DHT, and Waku adapters may resolve known handles but may not become the social directory.
- Queues, relay connections, and storage-provider identities are compartmentalized by context or privacy class. Rotation is supported before it is made continuous.
- Default transport uses modest batching and bounded jitter. Sensitive contexts can opt into onion routing and stronger delay/cover profiles; the client must expose latency, battery, and delivery trade-offs.
- Storage peers receive ciphertext shards and opaque manifests only. Shards use declared quotas and failure domains; repair is ciphertext-only and must not reveal parent or recipient relationships.
- PIR, ORAM, mixnets, global cover traffic, and ZK admission proofs remain optional experiments until a trace-based requirement shows that the MVP policy fails.
This policy does not claim perfect metadata privacy. It aims to prevent the architecture from creating a stable, searchable graph by default and gives stronger profiles a measurable place to plug in.
#Next dependency
The access-control and MLS streams must now decide the audience and revocation profiles that metadata traces will carry. After those profiles are fixed, metadata and peer-discovery experiments can share the same trace schema, and edge-storage research can evaluate whether shard handles and repair schedules create new relationship leakage.