search

n0-computer / iroh

peer-2-peer that just works
https://iroh.computer
Apache License 2.0
2.6k stars 164 forks source link

Pluggable transports for iroh-net #2228

Open rklaehn opened 7 months ago

rklaehn commented 7 months ago

This would be a major enhancement, but it would be very nice if you could have a way to plug in additional transports into iroh-net.

Examples include local transports like BLE, or something like unix datagram sockets or even something like shared memory for communication between local processes.

link2xt commented 2 months ago

Is this about connections to the relay or P2P connections?

For relay connections I really want to have a way to provide my own dialer ("connector") so I have full control over connection establishment. E.g. if user configures the application to use proxy I want to proxy all non-P2P connections the same way and don't expect iroh-net to support exactly the same set of proxy protocols and same authentication methods and have same TLS certificate store for HTTPS proxies.

For P2P I think iroh-net better focuses on supporting any kinds of IP LANs. Then if someone wants to use BLE or unix socket they only need to turn it into a virtual IP interface. Pluggable transport API can then be something like TUN API.

dignifiedquire commented 2 months ago

this is issue is about p2p transports

matheus23 commented 2 months ago

For P2P I think iroh-net better focuses on supporting any kinds of IP LANs. Then if someone wants to use BLE or unix socket they only need to turn it into a virtual IP interface. Pluggable transport API can then be something like TUN API.

I disagree. As an end-user application developer, I don't want to force my users to make changes to their ip interfaces to be able to have features like a local BLE-based transport.

link2xt commented 2 months ago

For P2P I think iroh-net better focuses on supporting any kinds of IP LANs. Then if someone wants to use BLE or unix socket they only need to turn it into a virtual IP interface. Pluggable transport API can then be something like TUN API.

I disagree. As an end-user application developer, I don't want to force my users to make changes to their ip interfaces to be able to have features like a local BLE-based transport.

TUN API can be entirely in the application layer, I don't mean that you need to actually create tun0 interface. If iroh can speak real interfaces as well as pluggable TUN interfaces, then any software that knows how to speak TUN can be adapted to speak directly to iroh instead of the kernel.