DSIP: A Decentralized Protocol for Secure Voice, Video, and Messaging

Version: Draft v0.3
Status: Proposal
Editors: James Ferris — jferris5@gmail.com

1. Abstract

DSIP (Decentralized SIP) is a next-gen real-time communications protocol that replaces carrier registrars, phone numbers, and hop-by-hop trust with self-sovereign identity (DIDs), cryptographically signed signaling, and distributed discovery/presence. DSIP unifies voice, video, and messaging with end-to-end verifiability, selective privacy, optional micro-payments for relays, and straightforward interop with SIP/PSTN during migration. DSIP requires verifiable geolocation to support emergency services and network optimization while preserving user consent and privacy.

2. Motivation

Identity is broken in PSTN/SIP: spoofable CNAM, regulator/cert chains, and numbers owned by carriers.
Fragmentation: Calls/messaging stuck in silos; no portable trust.
Security: Mostly hop-by-hop assurances; weak end-to-end provenance.
Mobility: IPs change constantly; discovery is centralized.
Regulatory reality: We still need 911/112 with reliable location and verifiable identity.

DSIP goal: Internet-native, decentralized comms with provable identity, resilient discovery, privacy by default, and built-in safety.

3. Core Principles

Self-sovereign identity — Users/devices control DIDs (no registrar lock-in).
End-to-end verifiability — Every DSIP message is signed; identity is intrinsic, not asserted.
Decentralized discovery — Presence via DHT; no single directory or registrar.
Privacy by design — Disposable DIDs, selective disclosure, E2EE, minimal metadata.
Programmable & extensible — JSON/CBOR envelopes, capability flags, optional payments.
Pragmatic interop — Gateways for SIP/PSTN; optional ledger anchoring (not required).
Safety — Emergency routing with verifiable geolocation + consent.

4. Identity Layer (DIDs)

4.1 Methods

Individuals/devices: did:key (no hosting, derived from pubkey).
Orgs/brands: did:web (HTTPS + DNS/TLS; human-readable).
Optional: ledger-anchored (did:ion, did:ethr) for immutable audit trails.

4.2 DID Document (minimal)

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:web:voice.example:users:alice",
  "verificationMethod": [{
    "id": "#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:web:voice.example:users:alice",
    "publicKeyMultibase": "z6Mkun..."
  }],
  "authentication": ["#key-1"],
  "service": [{
    "id": "#dsip",
    "type": "DSIPService",
    "serviceEndpoint": {
      "ws": ["wss://relay.voice.example/dsip"],
      "libp2p": ["/ip4/203.0.113.8/udp/443/quic-v1/p2p/12D3KooW..."],
      "turn": ["turns:turn.voice.example?transport=udp"],
      "sfu": ["wss://sfu.voice.example"]
    }
  }]
}

4.3 Human-friendly aliases

WebFinger acct:alice@voice.example → DID
DNS TXT/SRV _did.alice.voice.example TXT "did=did:web:voice.example:users:alice"
ENS/Handshake (optional) alice.voice → DID

5. Discovery & Presence

5.1 Presence record (dynamic;homeserver)

Signed by the caller’s DID key (and optionally by a device key for geo-attestations). Short TTL (60–300s); includes sequence number to prevent replay.

{
  "did": "did:web:voice.example:users:alice",
  "endpoints": {
    "libp2p": ["/ip4/203.0.113.12/udp/443/quic-v1/p2p/12D3K..."],
    "ws": ["wss://relay.voice.example/dsip/conn/abcd"]
  },
  "geo": { "geohash": "dr5r", "method": "gps", "ts": 1733871542 },
  "exp": 1733871800,
  "seq": 58,
  "sig": "base64url(signature-by-DID-key)"
}

5.2 Lookup algorithm (caller)

Resolve DID → DID Doc (cache; HTTPS/ledger verified).
Fetch presence via DHT (sha256("dsip-presence:" + DID)).
Prefer direct endpoints; else use relay from DID Doc.
If offline, store-and-forward encrypted envelope at callee’s relay + push wake.

6. Signaling Protocol (JSON/CBOR over QUIC/WS)

All DSIP envelopes are signed (JWS/COSE) by the sender’s DID key.

6.1 Core messages

{
  "type":"dsip.invite","id":"uuid","ts":1733871542,
  "from":"did:key:z6MkCaller","to":"did:web:voice.example:users:bob",
  "cap":{"ver":"1.0","features":["webrtc","payments","e2ee"]},
  "media":{"sdp":"v=0...","codecs":["opus/48000/2"]},
  "net":{"ice":{"ufrag":"...","pwd":"..."},"candidates":[],"hints":{"sfu":["wss://sfu.voice.example"]}},
  "identity":{"proof":"DIDAuth-JWS","credentials":[ ]},
  "economics":{"rate_msat_per_sec":0,"dest":null},
  "sig":{"alg":"Ed25519","kid":"did:key:z6MkCaller#key-1","jws":"..."}
}

{ "type":"dsip.answer","correlates":"uuid","media":{"sdp":"v=0..."},"net":{"ice":{"ufrag":"...","pwd":"..."},"candidates":[]},"sig":{"alg":"Ed25519","kid":"did:web:voice.example:users:bob#key-1","jws":"..."} }

{ "type":"dsip.ice","correlates":"uuid","candidate":"candidate:...","sig":{...} }

{ "type":"dsip.update","correlates":"uuid","changes":{...},"sig":{...} }

{ "type":"dsip.bye","correlates":"uuid","reason":"hangup","sig":{...} }

6.2 Rich Caller ID (RCID)

Attach verifiable display info:

{
  "type":"rcid.v1",
  "displayName":"James Ferris",
  "avatar":"ipfs://bafy.../avatar.png",
  "credentials":[
    {
      "type":["VerifiableCredential","DisplayNameCredential"],
      "issuer":"did:web:voice.net",
      "credentialSubject":{"id":"did:key:z6MkCaller","displayName":"James Ferris"},
      "proof":{"type":"Ed25519Signature2020","jws":"..."}
    },
    {
      "type":["VerifiableCredential","ReputationScore"],
      "issuer":"did:web:trustgraph.org",
      "credentialSubject":{"id":"did:key:z6MkCaller","score":812},
      "proof":{"type":"Ed25519Signature2020","jws":"..."}
    }
  ]
}

7. Media Plane

Transport: WebRTC (ICE/DTLS/SRTP). Topologies: P2P for 1:1; SFU for groups; TURN when NAT blocks. E2EE groups via Insertable Streams/SFrame or MLS.

SFU options: LiveKit (Go), mediasoup (C++/Node), Jitsi Videobridge (Java), ion-sfu/Pion (Go), Janus (C).
TURN: coturn with short-lived REST credentials.

Payments/metering (optional): INVITE may include economics intent. SFU/TURN accepts a JWT with DID + prepaid balance/reputation claims. Meter per-MB/second; throttle on low balance.

8. Messaging Layer

1:1: Signal Double Ratchet (X3DH/Noise bootstrap) using DID keys or published prekeys.
Groups: MLS (RFC 9420).
Delivery: live over DSIP; offline via encrypted store-and-forward envelopes + push tokens.

Message envelope:

{
  "type":"dsip.msg","id":"b9f8...","ts":1733871600,
  "from":"did:key:z6MkAlice","to":["did:web:voice.example:users:bob"],
  "content":{"enc":"v1","ciphertext":"base64url(...)","aad":"base64url(...)"},
  "sig":{"alg":"Ed25519","kid":"did:key:z6MkAlice#key-1","jws":"..."}
}

Receipts, typing, edits:

{ "type":"dsip.receipt","for":"b9f8...","kind":"delivered|read","ts":1733871700,"from":"did:web:...#key-1","sig":{...} }
{ "type":"dsip.typing","thread":"th-123","state":"on|off","ts":1733871701,"sig":{...} }
{ "type":"dsip.msgUpdate","for":"b9f8...","patch":{...},"sig":{...} }

Anti-spam: first-contact policy requiring Reputation VC or micro-payment/PoW; rate limits at relays; community signed block/allow lists.

9. Reputation & Trust

Verifiable Credentials: DisplayName, Organization, ReputationScore, Role (Support, Legal, etc.). Selective disclosure via ZK proofs. Client/relay policy engine enforces issuer allowlists and thresholds.

10. Privacy & Security

Threats & mitigations: caller ID spoofing (signatures + VC), replay (ts/id/TTL; presence seq/exp), metadata leakage (encrypted envelopes; opaque push), key compromise (rotation; pinning), relay exposure (E2EE), correlation (ephemeral DIDs).

11. Network Components

Client (DSIP Agent): DID wallet, resolver, presence publisher, signaling, media/messaging engines.
Resolver mesh: caches DID Docs; verifies TLS/DNSSEC/ledger proofs.
DHT (libp2p/Kademlia): presence overlay (region-bucketed).
Relay/Homeserver: store-and-forward encrypted envelopes; push integration; policy.
SFU/TURN: media relays; token auth; metering hooks.
Gateway: DSIP↔SIP/PSTN B2BUA; identity translation best-effort.

12. Example Call Flow

1) Alice scans Bob’s DID (QR).
2) Resolve Bob DID → DID Doc → presence record (DHT).
3) INVITE (signed) sent to Bob’s endpoint (direct or via relay).
4) Bob verifies signature & VCs → shows RCID with “Verified by voice.net”.
5) ANSWER; ICE completes; SRTP flows (direct/SFU/TURN).
6) Optional: micro-payment to SFU; call rating → Reputation VC updated.

13. Example Messaging Flow (offline callee)

1) Alice fetches prekeys from Bob’s DID Doc → runs X3DH → establishes session.
2) Alice posts encrypted envelope to Bob’s relay; relay issues push with opaque token.
3) Bob’s phone wakes, retrieves envelope, decrypts, replies; subsequent messages go direct when online.

14. Deployment & Federation

Anyone can run resolver, relay, SFU, TURN nodes. DID:web integrity via DNSSEC/TLS; did:key local; ledger optional. DHT bootstraps via public nodes; region sharding with geohash.

15. Migration from SIP/PSTN

Gateway mapping: dsip.invite ⇄ SIP INVITE; RCID ⇄ SIP Identity/P-Asserted-Identity (limited); WebRTC ⇄ RTP/SRTP via B2BUA. Optional E.164 ↔ DID mapping via VC (not public by default).

16. Compliance

GDPR/CCPA: local data control, explicit consent. NG911/112: emergency DID namespaces + verifiable geolocation; SIP gateways for ESInets. Audit: optional ledger anchoring of key rotations/VC hashes.

17. Economic Model

Free P2P; metered relays/SFUs (msats/sec or per-MB egress) via prepaid JWT tokens; reputation as collateral; anti-abuse via small costs + reputation.

18. Conclusion

DSIP provides a cryptographically verifiable, privacy-preserving, and developer-friendly foundation for global voice, video, and messaging—without numbers, registrars, or centralized caller ID systems, and with robust paths for emergency services and interop.

19. Emergency & Safety Services

19.1 Emergency DID namespaces

did:web:911.us, did:web:112.eu, etc. (government/NGO-operated). DID Doc lists verified endpoints (relay/SFU) + keys.

19.2 Emergency call flow

1) Client selects region (GPS geofence or user setting).
2) Resolve did:web:911.<region>; verify DID Doc.
3) dsip.invite with priority:"emergency" + geo-attestation.
4) PSAP verifies: caller DID, VC, and device/geo signatures; prioritizes routing.

19.3 Fallback

If DSIP unavailable, device falls back to native 911 (PSTN). DSIP↔NG911 gateways provide interop where required.

20. Geolocation & Device Attestation (Required)

20.1 Geolocation tiers

1: GPS/GNSS (±5m) — Emergency, trust, routing
2: Wi-Fi/Cell (±50m) — General calls
3: IP geolookup (±10km) — Fallback only
Devices without 1 or 2 run in limited mode (no emergency).

20.2 Signed geo-attestation (dual-sig)

{
  "did": "did:key:z6MkUser...",
  "location": {
    "lat": 42.746, "lon": -73.759, "alt": 72,
    "accuracy": 5, "timestamp": 1733871542,
    "method": "gps",
    "signature": "sig-by-device-secure-element"
  },
  "seq": 84, "exp": 1733871800,
  "sig": "sig-by-DID-key"
}

20.3 Privacy modes

Normal: not shared; DHT region bucketing only (geohash).
Trusted call: E2E share with peer.
Emergency: share with did:web:911.* only.
Reputation proof: ZK region proof (no exact coords).

20.4 Certification levels

Bronze: software location verification.
Silver: GNSS + secure element signing.
Gold: GNSS + continuous attestation + tamper detection (required for emergency).

21. Appendices

21.A DSIP Error Model

{ "type":"dsip.error","correlates":"uuid","code":403,"reason":"policy:reputation-too-low","sig":{...} }

4xx caller issues (auth, policy); 5xx callee/relay issues (capacity, unavailable); 6xx global failures (blocked).

21.B Encrypted store-and-forward envelope

{
  "type":"dsip.envelope.v1",
  "to":"did:web:voice.example:users:bob",
  "from":"did:key:z6MkCaller",
  "payload_enc":"base64url(ECIES(X25519)+AES-GCM ciphertext of dsip.invite or dsip.msg)",
  "nonce":"r4nd",
  "exp":1733873260,
  "sig":"base64url(signature-by-sender)"
}

Relays store envelope + minimal metadata (size, TTL); content unreadable to operator. Push notifications carry only {relay, envelope_id} (opaque).

21.C Presence DHT Keys

Presence key: sha256("dsip-presence:" + DID)
Region bucket: sha256("dsip-presence:geo:" + geohash_prefix)

21.D Name & DID Discovery

WebFinger: /.well-known/webfinger?resource=acct:user@domain
DNS TXT: _did.user.domain.tld TXT "did=did:web:domain.tld:users:user"
ENS text record: did=did:web:domain.tld:users:user

21.E Minimal Client Checklist

DID wallet (did:key + did:web resolve)
Resolver cache (TLS/DNSSEC pinning)
Presence publisher (DHT; TTL/seq/sig)
Signaling (INVITE/ANSWER/ICE/UPDATE/BYE)
WebRTC glue (P2P + SFU + TURN)
Messaging (X3DH/DR; MLS groups)
Encrypted envelopes + push wake
RCID rendering (VC verification)
Reputation policy engine
Emergency mode + geo-attestation

22. Glossary

DID — Decentralized Identifier
VC — Verifiable Credential
DHT — Distributed Hash Table
SFU — Selective Forwarding Unit
TURN — Traversal Using Relays around NAT
MLS — Messaging Layer Security
RCID — Rich Caller ID (verifiable)

DSIP: A Decentralized Protocol for Secure Voice, Video, and Messaging — Technical Proposal