P2P video calls without an account

Every mainstream video call platform routes your media through servers it owns and gates entry behind an account. A peer-to-peer call does neither: peers find each other directly, media flows directly, and your key is your identity.

Why video calls have accounts

A browser cannot accept incoming network connections. Two browsers that want to talk need a third party to introduce them, and that introduction service (signaling) is why platforms exist: you make an account, the platform's servers know who is calling whom, and your media flows through or is coordinated by their infrastructure.

WebRTC, the browser technology underneath every call you have ever joined in a browser, does not require any of that. The connection between two participants can be fully direct. What it needs from outside is just the introduction: an exchange of offer and answer messages through any channel the two sides share.

Take away the central introduction service and you take away the account requirement, the server bill, and the data trail.

How VIMS does it

VIMS replaces the signaling server with a DHT. Peers announce themselves on the Hyperswarm DHT under a topic hash derived from a shared key. Anyone holding the key can find the peers; anyone without it cannot even see that the topic exists (Blog 06: P2P Surfaces).

The three connection modes:

• Desktop to desktop: direct Hyperswarm connection, no intermediary at all. Two laptops on different networks find each other and sync a room in seconds.
• Desktop to browser: the browser tab connects to a sidecar WebSocket relay, which handles the Hyperswarm connection on the browser's behalf. The sidecar is a transport relay, not a data store: it forwards, it does not persist.
• Browser to browser: the sidecars exchange WebRTC offer and answer messages through the DHT, then the browsers establish a direct WebRTC data channel. After the handshake, data flows directly between the two tabs.

For media, small rooms (up to about 20 peers) run a full WebRTC mesh: every participant connects to every other. Larger rooms use selective forwarding, where a subset of peers relay for the rest.

Identity without accounts

No accounts means something has to replace them. In VIMS that thing is keys. Every peer holds a Nostr keypair; the public key (npub) is the peer's identity on the swarm. Joining a room is a signature over a challenge, verified against the known key. There is no signup, no email, no password reset. Share the room key and you are in; rotate it and you are out.

Agents join the same way, as identified peers with their own audio streams. A meeting agent transcribes with local whisper.cpp, reasons with the configured LLM, and speaks with local Piper, all on the host machine, with sub-second latency (Blog 07: Voice and Meeting Agents).

What you give up

Honest accounting: a DHT rendezvous is slower than a platform's global signaling fleet, NAT traversal occasionally needs a relay, and there is no vendor to call when something breaks. Room durability depends on peers holding replicas, with public ingress nodes as always-on rendezvous points rather than data stores.

What you get back: no accounts, no per-seat pricing, no media touching a server you do not control, and cryptographic identity baked into every participant.

To try it, open the Meeting surface, share the room key, and call.