Skip to Content
Dial v1 live 🎉

🚧 Protocol Overview

Status: Draft — This specification is under active development and subject to change.

The Dial Alpha Protocol is a layered architecture for decentralized communication. Each layer builds on the one below, creating a composable stack from identity to media.

Layers

Layer 0: Identity & Auth

The foundation. Every participant has a Principal (stable Dial identity) with one or more Signers (wallets, email, phone, WebAuthn). Authentication is challenge-response: prove ownership of a signer to get a session.

  • Principal = dial_identity (UUID)
  • Signer = wallet address (CAIP-10), email, phone, WebAuthn credential, embedded wallet
  • Policy = rules governing what signers can do (add/revoke signers, rotate anchor, recover)

Layer 1: Verified Comms

The trust layer. Every communication is wrapped in a DVE (Dial Verification Envelope) — a cryptographic envelope containing a device signature, delegation proof, and optional anchor signature. Recipients can verify authenticity without trusting the transport.

  • Device Keys (Ed25519) for low-risk signing
  • Delegation Certificates bind device keys to the anchor wallet
  • Identity Cards are anchor-signed snapshots of the identity state
  • Change Log provides an append-only audit trail

Layer 2: Channels & Messages

The transport layer. Communication happens through Channels — typed connections between principals. Channels carry Messages (text, structured data, verified actions) and Streams (audio, video, screen share, data).

Layer 3: Spaces & Rooms

The topology layer. Rooms are multi-participant real-time sessions (calls, meetings). Spaces are persistent communities with membership and permissions. Broadcasts are one-to-many live events.

Layer 4: Providers

The integration layer. Each capability (auth, media, messaging, storage) is abstracted behind a provider interface. Implementations can be swapped without changing the protocol semantics.

Design Constraints

  1. No central message store required — DVE makes messages self-verifying
  2. Provider-agnostic — the protocol doesn’t mandate specific backends
  3. Offline-verifiable — DVE envelopes can be verified without contacting the server
  4. Multi-chain — supports EVM, Solana, Bitcoin, and future chains via CAIP-10
  5. Progressive adoption — each layer is independently useful
Last updated on