DSIP: Rethinking Real-Time Communications from the Ground Up

Since my last post, “Do We Need SIP v3? A Call to Modernize Real-Time Communications,” my brain’s been in overdrive imagining what a next-gen protocol could unlock. The conclusion I keep coming back to: it’s time for a complete rethink—not a patch. Enter DSIP.

What is DSIP?

DSIP (Decentralized SIP) is a next-generation 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, and straightforward interop with SIP/PSTN during migration.

Think of DSIP as doing for communications what Bitcoin and blockchains did for finance: a self-governed, open, and verifiable network that doesn’t depend on gatekeepers.

Why now?

Identity is broken: phone numbers are spoofable and owned by carriers, not people.
Security is leaky: trust is hop-by-hop instead of end-to-end.
Mobility is messy: IPs change, users roam, routing is glued together with duct tape.
Expectations have changed: we want privacy, portability, and global reach—without spam.

The big ideas (in plain English)

Users own identities via DIDs (did:key for individuals, did:web for orgs) instead of phone numbers.
Every signal is signed. INVITE, ANSWER, ICE—everything is cryptographically verifiable.
Discovery is decentralized. Presence lives on a distributed hash table (DHT), not a single registrar.
Calls & groups scale with modern media relays (SFUs) and TURN, while remaining end-to-end encrypted.
Messaging is first-class with Signal-style Double Ratchet (1:1) and MLS for groups.
Reputation & verification travel with you using Verifiable Credentials (VCs). Rich caller ID that’s actually trustworthy.
Emergency calling works with reserved emergency DIDs (e.g., did:web:911.us) and verifiable geolocation.
Optional micro-payments let community-run relays/SFUs monetize bandwidth without compromising privacy.

What a DSIP call looks like

Alice scans Bob’s DID (QR code, link, or DNS alias).
Alice resolves Bob’s DID Document and fetches his signed presence from the DHT.
Alice sends a signed DSIP INVITE (JSON over QUIC/WebSocket).
Bob verifies Alice’s signature & credentials → sees Rich Caller ID (“Verified by X”).
Media flows P2P or via a community SFU (still end-to-end encrypted).
Optional: tiny, automated payments to SFU/TURN for premium quality.

Built-in safety: 911/112

Emergency services get first-class treatment:

Reserved DIDs (e.g., did:web:911.us) route calls directly to PSAP networks.
Devices attach signed geo-attestations (GPS with hardware-rooted signatures) only for emergency use.
Gateways bridge DSIP → NG911 where needed.
No carrier? No problem.

Privacy without the handcuffs

Ephemeral DIDs for contexts, stable DIDs for relationships.
Selective disclosure: prove your reputation score ≥ X without revealing the exact number.
Encrypted store-and-forward for offline delivery—relays can’t read content.
Zero-trust infra: treat relays/SFUs as blind routers; encryption lives at the edge.

What DSIP is not

Not a blockchain you must buy into. Ledgers are optional (for auditing/anchoring), not required.
Not a “rip and replace” overnight. SIP/PSTN gateways make migration gradual.
Not a central directory. Discovery is federated and cacheable.

Why builders will like this

JSON/CBOR signaling you can reason about and extend.
Drop-in SFUs (LiveKit, mediasoup, Jitsi, ion-sfu, Janus) with DSIP tokens for auth + metering.
Open identity: DID methods you already know (did:key, did:web), plus VCs for trust.

Try it, break it, shape it

I’ve published a technical proposal with flows, schemas, and examples:

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

I’d like your feedback, especially from folks running SIP at scale, WebRTC/SFU maintainers, wallet/DID devs, NG911 experts, and spam-fighting pros.