decentrl.
Communication

Communication Contracts

Bilateral cryptographic agreements that establish secure channels between identities — no data flows without mutual consent.

Formal spec: DCTRL-0003 — Communication Contracts defines the contract schema, creation/acceptance flows, root secret derivation, and rotation protocol.

Communication contracts are the core innovation of Decentrl. They are bilateral cryptographic agreements that establish secure channels between two identities. Unlike platforms that decide who can message whom, Decentrl requires explicit mutual consent before any private communication can occur.

What's in a Contract

Each contract contains:

  • Both parties' DIDs — who is in this relationship
  • Ephemeral encryption keys — fresh X25519 key pairs, generated specifically for this contract, used to derive a shared root secret via Diffie-Hellman
  • Expiration timestamp — contracts have a natural lifetime
  • Bilateral Ed25519 signatures — both parties must sign under identical terms

The dual-signature requirement prevents coercion, spam, and unauthorized communication. You can't send someone a message unless they've explicitly agreed to receive messages from you.

How Contracts Are Established

The full contract establishment flow is walked through step-by-step in the Alice and Bob protocol walkthrough. The key insight:

  1. Alice generates a fresh ephemeral X25519 key pair and signs a contract request
  2. The request is encrypted with Bob's pre-key — only Bob can read it, not even his mediator
  3. Bob decrypts, verifies, generates his own ephemeral key pair, and counter-signs
  4. Both parties independently derive an identical root secret via X25519(own_ephemeral_private, their_ephemeral_public) — no secret is ever transmitted
  5. The contract ID is a deterministic SHA256 hash of the contract data

What Contracts Solve

Contracts solve multiple problems simultaneously:

  • Spam prevention — you can't message someone without a mutual contract. The mediator rejects messages from identities without an active contract.
  • Shared encryption — both parties derive a shared root secret without exposing it to any server.
  • Proof of consent — bilateral signatures provide cryptographic proof that both parties explicitly agreed to communicate.
  • Bounded exposure — contracts expire, limiting the window of any key compromise. Contracts can be rotated to further limit exposure.
  • Revocability — either party can revoke a contract at any time, immediately cutting off communication.

Contracts Are Universal

The same contract primitive handles every relationship in the network:

  • User-to-user — Alice and Bob establish a contract to chat
  • User-to-mediator — Alice establishes a contract with her mediator (this is registration)
  • User-to-group — Alice establishes a contract with a group's DID
  • User-to-service — Alice establishes a contract with an automated news feed

One primitive, every relationship.

Contract Schema

type CommunicationContract = {
  requestor_did: string
  recipient_did: string
  requestor_signing_key_id: string
  recipient_signing_key_id: string
  requestor_encryption_public_key: string   // ephemeral X25519
  recipient_encryption_public_key: string | null  // null until recipient accepts
  expires_at: number
  timestamp: number
}

type SignedCommunicationContract = {
  communication_contract: CommunicationContract
  requestor_signature: string   // Ed25519 (signs contract with recipient key = null)
  recipient_signature: string   // Ed25519 (signs completed contract)
}

The asymmetric signature scope is intentional — the requestor signs before the recipient's key is known, and the recipient signs the complete contract. This prevents either party from modifying the terms after the other has signed.