Network Architecture

The Decentrl network consists of two types of participants — clients and mediators — connected through communication contracts.

Two Types of Participants

The protocol operates through exactly two types of participants:

Clients

Clients are the primary users of the network — human identities or automated systems that require secure communication. Each client:

• Maintains sovereignty over their cryptographic identity (three keys)
• Holds all their communication history (encrypted on their mediator)
• Builds application state locally by querying encrypted events from their mediator
• Chooses which mediator to use based on trust, performance, jurisdiction, or cost

Mediators

Mediators are lightweight relay servers that provide message routing and encrypted storage. Think of them as encrypted mailboxes. Each mediator:

• Has its own DID and cryptographic identity
• Makes autonomous decisions about which clients to serve
• Operates encryption-blind — it routes messages and stores encrypted data but cannot access message contents, conversation metadata, or user relationships
• Exposes HTTP APIs for commands and queries
• Optionally supports WebSocket connections for real-time push

Anyone can operate a mediator. Individuals, small businesses, or enterprises. This creates thousands of small infrastructure providers instead of a few massive server farms.

Cross-Mediator Communication

The network is not a single system — it's a federation of independent mediators. When Alice on mediator A sends a message to Bob on mediator B:

1. Alice encrypts the message with the contract's root secret
2. Alice sends the encrypted message to Bob's mediator for delivery
3. Alice re-encrypts a copy with her storage key and saves it on her own mediator

Alice's Device                          Bob's Device
     │                                       │
     │  ┌─────────────────┐                  │
     ├──│ Alice's Mediator │                  │
     │  └─────────────────┘                  │
     │         storage copy                   │
     │                                       │
     │         transit copy                   │
     │  ┌───────────────┐                    │
     └──│ Bob's Mediator │────────────────────┘
        └───────────────┘

Both parties maintain complete conversation records on their own infrastructure. No coordination between mediators is required. Users can switch mediators, change providers, or run personal infrastructure without affecting their ability to communicate.

Registration as a Contract

There is no special "sign up" flow for mediators. Registration is a communication contract — Alice establishes a bilateral cryptographic agreement with the mediator's own DID:

1. Alice creates a contract request where recipient_did = mediator_did
2. She encrypts it using the mediator's pre-key
3. The mediator decrypts, auto-accepts, and signs the contract
4. Both store the signed bilateral contract

An active, non-expired contract with the mediator is registration. When the contract expires, so does the registration. This unified model means there's exactly one primitive — the communication contract — that handles both user relationships and infrastructure relationships.