Security Properties

Mediator blindness, spam prevention, authentication, and the threat model that underpins the protocol.

Mediator Blindness

Mediators handle only ciphertext. They cannot:

• Derive root secrets or epoch keys — requires ephemeral private keys that never leave client devices and are wiped once the handshake completes
• Derive storage keys — never transmitted to anyone
• Forge event signatures — requires the sender's Ed25519 private key
• Tamper with events undetected — event-level signatures bind content to metadata, including the event ID
• Make one event count twice — a re-delivered event carries the same signed event ID, so the recipient stores and applies it once

Mediators are not blind to metadata, though. To route commands and verify and enforce contracts, a mediator learns:

• Participants — who has a contract with whom and who sends to whom, i.e. the social graph
• Timing and sizes of commands and events
• Contract terms — DIDs, ephemeral public keys, timestamps, and signatures
• Contract and epoch of each event — every private payload carries its contract_id and epoch in the clear; the mediator already knows the pair, so this adds which day's key an event uses
• Revocations — your own mediator knows whom you revoked and when (the other side's mediator learns nothing)
• Tag equality — which stored events share an encrypted tag
• Repeated saves — when a SAVE_EVENTS entry repeats an event the owner already stores (equal dedupe key), but not the event ID

It never learns event content, root secrets, chain or epoch keys, storage keys, or tag plaintext. Hiding the social graph would need a sealed-sender design, which is out of scope for the protocol today.

Spam Prevention

The TWO_WAY_PRIVATE channel requires a valid bilateral communication contract on the recipient's mediator. Without a contract, the mediator rejects the message immediately.

This means unsolicited messages are impossible. The sender must have established a mutually accepted contract first. Spam is architecturally eliminated, not filtered.

Consent can also be withdrawn. Revoking a contract on your own mediator deletes it, drops whatever that contact still had queued for you, and refuses their messages from then on with the same error a stranger gets. They aren't told. If they request a new contract, they are a stranger again, subject to the mediator's cap on pending requests from strangers.

Authentication

Every command and every event carries an Ed25519 signature. The mediator:

1. Resolves the sender's DID to extract their public signing key
2. Verifies the signature over the canonical JSON payload
3. Records the command nonce (only after the signature is valid) and rejects replays
4. Applies a per-sender rate limit
5. Checks for active registration and (for TWO_WAY_PRIVATE) active bilateral contracts

Event-level signatures provide end-to-end authentication that remains verifiable even if the mediator is compromised.

The sender a recipient sees is always the authenticated one. Before storing a received event, the client overwrites its claimed meta.senderDid and meta.eventId with the sender the mediator authenticated and the event ID signed in the envelope. A contact can't pose as another contact, or reuse someone else's event ID to get their event dropped as a duplicate.

Tag Privacy

Encrypted tags are HMAC-SHA256 values of plaintext tag strings, keyed with a tag key derived from the owner's storage key. They function as deterministic pseudo-random values — only the owner can compute a tag for a given string. The mediator performs exact-match indexing and lookup on these opaque blobs without knowing what they represent, and it cannot test guesses because it lacks the tag key. (Earlier tags were Ed25519 signatures, which the mediator could verify against the public key in the DID document to confirm a guessed tag.) Equal tags remain linkable.

Threat Model

The protocol assumes:

• Users maintain control over their devices and private keys
• Ed25519, X25519, and AES-256-GCM remain secure against practical attacks
• At least one mediator per identity operates honestly (for availability, not confidentiality)

The protocol does not assume:

• Mediator confidentiality — mediators are assumed to be curious
• Network transport security — all security comes from end-to-end encryption
• Coordination between service providers — mediators operate independently

All security guarantees derive from end-to-end cryptographic protection, not from trusting infrastructure.