Comment by klabb3

> [...] I don't think it's helpful for my intentions. My project is also web-based (first)

Yes, then it's a no-go. No excuses needed.

WebRTC is the only way to reasonably do p2p on the web. This is because of the lack of "raw" sockets and their options (just regular TCP/UDP with SO_REUSEPORT).

> So if you can shed any light on how to make a TURN server, I am ALL ears!

You'd know better in a few minutes of reading the docs, sorry. I will say, pay attention to the requirements - for instance, listening on arbitrary ports, getting the "real" port from the client, even stateful connections etc, aren't always possible on cloud services (the more "managed" the marketing, the more restricted).

> Not because I think it doesn't work, but because I haven't ripped it apart to know how to fix it if something goes wrong. As this is a side-project, I have the luxury of forcing myself to deeply learn each part of the data flow, so it doesn't make much sense to offload something I don't totally understand to someone's library

I empathize deeply with this. In fact, that's the main reason why I built rdv. WebRTC in particular is, imo, a nasty piece of over-engineering. It basically throws together a bunch of separate "protocols" into one. It has way, way too many knobs, and many things are stateful. If you do go down the route of reimplementing even a subset of WebRTC I recommend getting an insurance for your keyboard, one that covers physical violence, (but if you do, I would be very curious about your learnings).

Finally, my words of wisdom would be to avoid p2p if you have the luxury of having a small amount of messages. Just running a simple "relay" of encrypted messages is reliable and cheap. Users are still protected by e2ee.