[erichanson]

Hadn't seen STOMP before, cool. I think making Tor a core part of the architecture is a little over-engineered in our case. The Internet is already a p2p network damnit! I like WebRTC because they seem to solve just the NAT-piercing problem specifically without a whole additional network layer.

[rancor]

I've worked with WebRTC NAT punching pretty extensively, and it is not the solution to your problem. STUN and TURN both require details like proxies with fixed IP addresses, specific DNS and SSL configuration, and so on. So for the nodes to be independent, most users will need to set those services up.

So while the added network layer of Tor (or any overlay network really) certainly adds a level of complexity, from the application standpoint it actually simplifies matters for the following reason: Your application doesn't need any longer to think about the topology of the underlying IP network, as this implicit detail dragged in by direct IP connectivity use is abstracted by the overlay network. Instead, your application is able to interface with any peer via (in the case of Tor) an HTTP proxy and a set of opaque base URLs.

IOW, you're going to need one or more additional daemons to make the P2P part go, and Tor is legitimately the simplest thing available today that accomplishes this without ruling out other styles of overlay network from an architectural point of view.

[erichanson]

Interesting.

I don't mind adding additional daemons to the system if it's essential. But, Tor also (as I understand it, given that this is a ways outside my core competency) adds a whole encryption and anonymization layer, which would be undesirable overhead in at least some scenarios, which is why it seems too heavy to be part of core. Maybe WebRTC isn't going to work reliably which would be very disappointing. I'd like to hear more about your experiences and could really use some help making a good decision here. Ping my email if you're available!