Interesting. If I’m following this correctly, the architecture is very similar to how services like Tailscale and Zerotier work; every client contacts a central server to say where it can be reached, and then the central server shares that information with authorized parties, but the actual communication is all peer to peer.
Assuming I’ve grasped this correctly, this sounds like a very smart use of a proven architecture. I guess my main question would be, how does the central server determine when to share contact info between two clients? Is everyone essentially aware of everyone else (on the backend at least) and then some client side component restricts who can actually communicate, or is there some pre-shared secret that would authorize the server to connect your client to someone else’s?
Edit to add: The other thing I was going to note is that obviously removing the central server means there’s no way to retrieve your messages if you lose or wipe your phone, but I see you’ve already included robust backup options. Thumbs up for that.
Edit 2: Just to clarify my question, I see that theres a system for scanning or importing QR codes in order to add someone as a contact (I do want to suggest that you should also be able to use a code; not everyone always wants to be sending an image in place of, effectively, a phone number), but my question is more about how this is architectured on the backend. Does the key encoded in the QR code authorize the TURN server to connect you with the other user?


Modern routers have a feature that’s typically known as “hairpin NAT” or “NAT loopback”. This means that if the DNS lookup resolves to the router’s public IP, it routes the packet internally instead of passing it out to the internet. So for your subdomains all of the traffic should stay local. Typically this feature is enabled by default, but you may want to check just to be sure.