I wanted to investigate about onion routing when using WebRTC.

Im using PeerJS in my app. It allows peers to use any crypto-random string to connect to the peerjs-server (the connection broker). To improve NAT traversal, im using metered.ca TURN servers, which also helps to reduce IP leaking, you can use your own api key which can enable a relay-mode for a fully proxied connection.

For onion routing, i guess i need more nodes, which is tricky given in a p2p connection, messages cant be sent when the peer is offline.

I came across Trystero and it supports multiple strategies. In particular i see the default strategy is Nostr… This could be better for secure signalling, but in the end, the webrtc connection is working correctly by aiming for fewer nodes between peers - so that isnt onion routing.

SimpleX-chat seems to have something it calls 2-hop-onion-message-routing. This seems to rely on some managed SMP servers. This is different to my current architecture, but this could ba a reasonable approach.

In a WebRTC connection, would there be a benefit to onion routing?

It seems to require more infrastructure and network traffic… and can no longer be considered a P2P connection. The tradeoff might be anonymity. Maybe “anonymity” cannot be possible in a WebRTC connection.

Can the general advice here be to “use a trusted VPN”?

  • Consti@lemmy.world
    1·
    16 days ago

    I don’t think you need to do anything special here. So long as the client enables TOR on their device (or just the browser), all traffic including WebRTC will be routed through the onion network, like with a VPN. Your server will only see the IP of the exit node.