Sending a friend a message usually means opening the same messaging app and letting the platform deliver it. Even when the content is end-to-end encrypted, the conversation still depends on that platform. Could we reach a friend’s endpoint, verify who we’re talking to, and send the message there?
DHttp’s Workspace offers this kind of chat. The interface is familiar: add a contact, send some text, share a photo or file, or record a voice message. Behind the interface, the two endpoints exchange messages with each other.
First, though, how do you know you’re talking to the right person?
A DHttp identity consists of a domain-style name, a public–private key pair, and a certificate. The name lets others find your endpoint, while the certificate binds that name to your public key. During connection setup, you prove possession of the matching private key, which stays on your device.
But verifying someone’s identity doesn’t give them unrestricted access to your services.
If I want Bob to send me messages, I allow his identity to make POST requests to my messaging endpoint. If Bob wants to receive my messages, he grants permission on his side too. Workspace puts this into the contact interface: each person chooses what access to request and what to offer. Accepting a contact doesn’t automatically grant chat permission, and allowing someone to send messages doesn’t let them read my entire chat history.
This also works when we’re on different home networks. DHttp handles endpoint discovery and NAT traversal underneath, attempting a direct connection and using a relay when needed. We don’t have to configure a VPN or join the same virtual private network first. For chat, I’d like knowing someone’s name and having their permission to be enough to reach them, without first arranging for our devices to share a private network.
That’s the part I find interesting. What looks like agreeing to receive someone’s messages is an access rule tied to their verified identity. Knowing my name doesn’t give them access to my other services. Both endpoints still need to be online and reachable, and private keys need to be kept safe. Peer-to-peer changes how we communicate; it doesn’t take care of every security concern for us.
