Pluggable transports

[RangerMauve]

TCP and UTP are great, but it should be easy to add more transport types. This will be really useful for seamlessly adding the ability to route your traffic through mixnets like Tor or I2P.

• Support an API for adding transports
• Tor?
• I2P?
• libp2p?

What should a transport be able to do?

• connect(port, host)
• listen(port)
• get data to announce on the DHT?

[pfrazee]

I think before committing work to pluggability, we should think through how many transports could really be added this way. If the answer is less than, like, five, then we may be better off just building in those transports and making them option flags. Pluggability adds interface complexity by being more abstract, and is harder to implement overall.

[RangerMauve]

I haven't used this yet, but node-i2p has a very similar API surface to net. Maybe just shoving that in and seeing if it works would be a good start?

[m-onz]

• 1 vote for WebRTC

[noaho]

Some clients are also likely to be behind public wifi that has a firewall that only allows local DNS traffic, http, https. It would be great if some of the discovery servers / DHT could work over http/https, so these clients can still discover other http/https endpoints.

Supporting HTTPS connections could also allow hyperswarm traffic to blend in and work across even the most restrictive corporate firewalls, because corporates can’t ban public cloud traffic eg AWS/Azure without breaking their own systems.

[RangerMauve]

@Karissa, @pvh and I were thinking it'd be cool if we could eventually integrate discovery-swarm-stream servers into the discovery layer for cases when you need a proxy to the p2p network. But that's probably a ways away and likely won't be within hyperswarm directly.