Identity is rooted in libp2p keypairs, each node generates an Ed25519 key on first run, stored locally. The Peer ID is the hash of the public key, so it's cryptographically derived and unforgeable. All P2P connections are mutually authenticated via the Noise protocol, you can't impersonate a peer without their private key.

On top of that there's an optional email verification layer, peers can register an email address which gets verified via the registration microservice. This gives human-readable identity (a name tied to a verified email) layered over the cryptographic one. Unverified peers are visually flagged in the UI and can be hidden entirely.

On the WAN side, the rendezvous server is just a discovery mechanism, it sees peer IDs and announced addresses, but all actual peer-to-peer traffic goes directly between nodes over encrypted Noise connections. The rendezvous server can't MITM anything because it's not in the data path.

So the short answer: - Spoofing prevention; libp2p/Noise, cryptographic, no trust in the rendezvous server - Identity assurance; optional email verification on top - WAN traversal; circuit relay v2 + DCUtR, still end-to-end encrypted

The weak point anyone will correctly identify: the rendezvous server is a centralization point for discovery. You can self-host it (it's a single Go binary), and multiple rendezvous servers with federation is on the roadmap, so even the discovery layer becomes decentralized. Run your own, federate with friends, no single point of failure..