3 ms·

I am one of the iroh developers. A question that frequently comes up: when will iroh support webrtc, or BLE, or LoRa, or ... Iroh as of now supports only IPv4

by rklaehn 4mo ago

I am one of the iroh developers. A question that frequently comes up: when will iroh support webrtc, or BLE, or LoRa, or ... Iroh as of now supports only IPv4, IPv6 and relay transports out of the box. There is such a large variety of potentially interesting transports out there that we can't support all of them without turning the codebase into an unmaintainable maze of feature flags. But we have added the ability to implement custom transports. That way your transport implementation can live in a completely separate crate. Existing experimental custom transports include Tor, Nym and BLE. https://github.com/mcginty/iroh-ble-transport https://github.com/mcginty/iroh-ble-transport Here is how custom transports work under the hood: https://www.iroh.computer/blog/iroh-0-97-0-custom-transports-and-noq https://www.iroh.computer/blog/iroh-0-97-0-custom-transports...

Bender 4mo ago
What are the risks if any of running public relays? Is this similar in concept to running Tor Guard Nodes / Relays?
- Arqu 4mo ago
  All the data is e2e encrypted and nothing is stored. The usual self hosting public things rules apply.
- rklaehn 4mo ago
  If you run a public unauthenticated relay you act as a home relay for whoever has your relay configured in their relay map and is close in terms of latency. So you might get a lot of traffic. You can configure rate limiting, as we do on our public relays. The traffic is fully encrypted and can not be decrypted by the relay. The only information the relay has is what is necessary for it to function - the endpoint id and ip addresses of the endpoints that are connected to it at any given time, as well as endpoint pairings. You relay encrypted traffic with no egress to the open internet. So if you want to compare it with Tor, it would be like a tor guard/middle relay, not an exit node.
  - Bender 4mo ago
    So if you want to compare it with Tor, it would be like a tor guard/middle relay, not an exit node. Nice. I already do rate limiting, traffic balancing using sch cake. This looks like an interesting project. I could envision open source NVR's implementing this. I also like the name of the project.
refulgentis 4mo ago
FWIW I think for “new user” audiences you’re better off describing why we’d use this instead of IP, than why you haven’t gotten it everywhere yet: there’s a certain sort of “complaint I see the most from current users” myopia that sets in, at least for me, over the years. :)
ascii0eks84 4mo ago
If you don't mind, what are other low-effort but high signal forums other than HN, Perplexity and X for accurate news that skip the annoying part?
larodi 4mo ago
Lora is a must
- rklaehn 4mo ago
  There are already some crates providing a bridge between LoRa using iroh. See for example https://crates.io/crates/donglora-bridge https://crates.io/crates/donglora-bridge I am not aware of a LoRa custom transport yet, but that is not unexpected given that the custom transport API is relatively new, and our main focus has been on getting iroh 1.0 out of the door.
  - larodi 4mo ago
    Definitely interesting in having lots of things running lora AND meshes. Thanks.
mhluongo 4mo ago
Hi! As someone who has historically built on libp2p, I'd love to see an updated comparison focused on app developers! Last year, I was trying to choose between the two and went with that I know... but it feels like there's real momentum on Iroh's side.
Folcon 4mo ago
Hey, just reading through the docs, this looks like a pretty cool project and I found your p2p chat example[0] I'm trying to understand it's limitations, if I used this to build a p2p client / server setup or even two peer machines, what else do I need to setup to be able to have connections between the two applications? For example, could I create an application that runs on my phone and another that runs on my laptop and finally get a direct secured working connection between the two of them? Or is this solving a different problem? =) -[0]: p2p chat, in rust, from scratch: https://www.youtube.com/watch?v=ogN_mBkWu7o https://www.youtube.com/watch?v=ogN_mBkWu7o
- rklaehn 4mo ago
  Yes, you will get secure direct connections. This matters for privacy in case of an encrypted chat, but also has a lot of benefits for more demanding use cases such as video streaming. Here is a video of frando from our team demoing media over QUIC: https://www.youtube.com/watch?v=K3qqyu1mmGQ https://www.youtube.com/watch?v=K3qqyu1mmGQ If you use the default setup you are still depending on a tiny bit of cloud infrastructure such as our public relays to faciliate the hole punching. However, we also have optional local discovery using e.g. mDNS.
- apitman 4mo ago
  You'll get a direct connection in most cases, but sometimes it will need to fall back to relays. n0 provides free relays, but ultimately that can get rather expensive. You can also run your own relays for your app.
SillyUsername 4mo ago
You may want to consider using a feature flag API if you think it will be unmaintainable. Strategy patterns and code-centralised feature management ftw :)
teravor 4mo ago
> Tor https://github.com/n0-computer/iroh-tor-transport https://github.com/n0-computer/iroh-tor-transport you are using a Tor daemon in it. tor has a rust implementation and when used with rust has stream objects etc. an example of how it's used can be found in https://gitlab.torproject.org/tpo/core/oniux https://gitlab.torproject.org/tpo/core/oniux
- rklaehn 4mo ago
  Yes, I wrote the current tor transport as a quick demo/testground for custom transports. Arguably directly embedding the rust tor implementation would be more useful for the typical iroh user that wants an embeddable library. I just did not get to it yet. But thanks for the link.
  - teravor 4mo ago
    turns out someone made an issue about it, and they referenced a more relevant example: https://github.com/uncognic/circuitchat https://github.com/uncognic/circuitchat
opem 4mo ago
Can the relay servers, when used as fallback, read the data between two parties by providing its own public key to both of the peers?
- rklaehn 4mo ago
  No. The data in each direction is encrypted by TLS, using ephemeral keys. Only the owner of the corresponding private key can initiate a connection from their public key, or receive a connection attempt to their public key. Let's say you have alice and bob talking via a relay. Even if you have the private key of alice, you can impersonate alice to bob, but not vice versa. So you can't initiate a connection between the two. To really intercept data you would need the private keys of both participants.
- khowells 4mo ago
  As I understand it the “peer ID” you dial acts like the public key, of the public/private key pair. So the public key doesn’t come from the relay. You need to do the initial public key/ID exchange out of band, and then dial the connection to each other via the relay. So the relay is never in a position to send you the wrong public key, because it doesn’t give it to you in the first place.
- flub 4mo ago
  Iroh uses QUIC connections and uses the EndpointId, the public ed25519 key, in the TLS handshake for authentication. This makes it impossible for a server to try and machine-in-the-middle the connection.
- matheus23 4mo ago
  You need to know the public key you communicate with ahead of connecting to the correct relay. It needs to be shared securely out-of-band, relays don't help with that.
hathawsh 4mo ago
Iroh looks very interesting! How current is the PyPI package? https://pypi.org/project/iroh/ https://pypi.org/project/iroh/
- Arqu 4mo ago
  We bumped to 1.0 an hour ago https://pypi.org/project/iroh/#history https://pypi.org/project/iroh/#history
syllogistic 4mo ago
> when will iroh support webrtc... This would give you a native iroh node that also speaks webrtc but I find that what folks want is for browsers to participate as peers. I build p2claw, p2p for self-hosted web apps, and ended up doing both halves separately. Box to box is iroh, although I use my own coordinator service and run my own iroh relay. Browser to box is webrtc with a service worker that makes the browser act like a peer. The worker grabs fetches and sends them as HTTP frames over the data channel, the box answers on localhost. The browser bit has to be webrtc because it's the only browser api does ICE. Wiring up the iroh half went smoothly, very much enjoying working with the library. Congrats on 1.0!
- samantp 4mo ago
  Yes, seems that browser support for services running on P2P boxes behind NATs cannot leverage iroh. Need the service worker hijacking the browser’s fetches as well as monkey patching the browser’s websocket SDK and sending all that traffic over webrtc data channels.
- apitman 4mo ago
  I discovered p2claw the other day and it's really cool. I'm a little surprised you're running Iroh as well. Why not just use WebRTC for everything once you're forced to for the browser anyway?
  - syllogistic 4mo ago
    [dead]
jhancock 4mo ago
Nice. How easily is the protocol categorized by an external observer? I'm noticing protocols like wireguard more commonly hitting problems as websites rely on third party systems to protect them from non-human interactions.
- matheus23 4mo ago
  Somewhat easy, unfortunately. If you look at Wireguard traffic, you'll see a <EndpointID>.iroh.invalid SNI in the QUIC Initial packet. Encrypted ClientHello can fix that, but support hasn't shipped into rustls yet. So it's definitely fixable. The interesting thing is that the ClientHello is undetectable when it's sent via the relay transport (sent inside a WSS connection). And in that case, any traffic that happens on IP is fully encrypted and can't be categorized.
mkl 4mo ago
Please consider putting the first paragraph of [1], "iroh is a modular networking stack written in Rust. It provides the building blocks to create applications that can communicate using fast, cheap, and reliable connections.", at the top of the blog post and the main website. The middle two lines of [2] are good as a follow-up. The current stuff about dialling is pretty incomprehensible, as shown by the many confused comments here. No one "dials" IP addresses (or keys), and no one wants to, so the word "dial" shouldn't be part of the title or description. The word "key" would be better not mentioned until you start talking about implementation, and the brief high level "what it is" and "what it is for" stuff should come before implementation. Iroh seems quite relevant to some projects of mine, but after reading the blog post and the main page, I still had no idea of that relevance until I had read over a hundred comments here (many of them confused about what Iroh was). [1] https://docs.iroh.computer/what-is-iroh https://docs.iroh.computer/what-is-iroh [2] https://news.ycombinator.com/item?id=48543554 https://news.ycombinator.com/item?id=48543554
- munksbeer 4mo ago
  > "iroh is a modular networking stack written in Rust. You can omit the "written in Rust" part, but then you'd lose street cred.
  - mkl 4mo ago
    It's not for street cred, it's what makes it usable everywhere: Rust, JavaScript (server or browser), Python, Kotlin, Swift, C. Written in JavaScript or Python means limited use, Kotlin or Swift means it could be tricky outside their main platforms, C means worrying about potential vulnerabilities and core dumps. I.e. "written in Rust" is definitely relevant here.
    - quibono 4mo ago
      > C means worrying about potential vulnerabilities and core dumps Rust guarantees no vulnerabilities?
      - 4mo ago

by rklaehn 4mo ago

Bender 4mo ago

What are the risks if any of running public relays? Is this similar in concept to running Tor Guard Nodes / Relays?

Arqu 4mo ago
All the data is e2e encrypted and nothing is stored. The usual self hosting public things rules apply.
rklaehn 4mo ago
If you run a public unauthenticated relay you act as a home relay for whoever has your relay configured in their relay map and is close in terms of latency. So you might get a lot of traffic. You can configure rate limiting, as we do on our public relays. The traffic is fully encrypted and can not be decrypted by the relay. The only information the relay has is what is necessary for it to function - the endpoint id and ip addresses of the endpoints that are connected to it at any given time, as well as endpoint pairings. You relay encrypted traffic with no egress to the open internet. So if you want to compare it with Tor, it would be like a tor guard/middle relay, not an exit node.
- Bender 4mo ago
  So if you want to compare it with Tor, it would be like a tor guard/middle relay, not an exit node. Nice. I already do rate limiting, traffic balancing using sch cake. This looks like an interesting project. I could envision open source NVR's implementing this. I also like the name of the project.

refulgentis 4mo ago

FWIW I think for “new user” audiences you’re better off describing why we’d use this instead of IP, than why you haven’t gotten it everywhere yet: there’s a certain sort of “complaint I see the most from current users” myopia that sets in, at least for me, over the years. :)

ascii0eks84 4mo ago

If you don't mind, what are other low-effort but high signal forums other than HN, Perplexity and X for accurate news that skip the annoying part?

larodi 4mo ago

Lora is a must

rklaehn 4mo ago
There are already some crates providing a bridge between LoRa using iroh. See for example https://crates.io/crates/donglora-bridge https://crates.io/crates/donglora-bridge I am not aware of a LoRa custom transport yet, but that is not unexpected given that the custom transport API is relatively new, and our main focus has been on getting iroh 1.0 out of the door.
- larodi 4mo ago
  Definitely interesting in having lots of things running lora AND meshes. Thanks.

mhluongo 4mo ago

Hi! As someone who has historically built on libp2p, I'd love to see an updated comparison focused on app developers! Last year, I was trying to choose between the two and went with that I know... but it feels like there's real momentum on Iroh's side.

Folcon 4mo ago

Hey, just reading through the docs, this looks like a pretty cool project and I found your p2p chat example[0] I'm trying to understand it's limitations, if I used this to build a p2p client / server setup or even two peer machines, what else do I need to setup to be able to have connections between the two applications? For example, could I create an application that runs on my phone and another that runs on my laptop and finally get a direct secured working connection between the two of them? Or is this solving a different problem? =) -[0]: p2p chat, in rust, from scratch: https://www.youtube.com/watch?v=ogN_mBkWu7o https://www.youtube.com/watch?v=ogN_mBkWu7o

rklaehn 4mo ago
Yes, you will get secure direct connections. This matters for privacy in case of an encrypted chat, but also has a lot of benefits for more demanding use cases such as video streaming. Here is a video of frando from our team demoing media over QUIC: https://www.youtube.com/watch?v=K3qqyu1mmGQ https://www.youtube.com/watch?v=K3qqyu1mmGQ If you use the default setup you are still depending on a tiny bit of cloud infrastructure such as our public relays to faciliate the hole punching. However, we also have optional local discovery using e.g. mDNS.
apitman 4mo ago
You'll get a direct connection in most cases, but sometimes it will need to fall back to relays. n0 provides free relays, but ultimately that can get rather expensive. You can also run your own relays for your app.

SillyUsername 4mo ago

You may want to consider using a feature flag API if you think it will be unmaintainable. Strategy patterns and code-centralised feature management ftw :)

teravor 4mo ago

> Tor https://github.com/n0-computer/iroh-tor-transport https://github.com/n0-computer/iroh-tor-transport you are using a Tor daemon in it. tor has a rust implementation and when used with rust has stream objects etc. an example of how it's used can be found in https://gitlab.torproject.org/tpo/core/oniux https://gitlab.torproject.org/tpo/core/oniux

rklaehn 4mo ago
Yes, I wrote the current tor transport as a quick demo/testground for custom transports. Arguably directly embedding the rust tor implementation would be more useful for the typical iroh user that wants an embeddable library. I just did not get to it yet. But thanks for the link.
- teravor 4mo ago
  turns out someone made an issue about it, and they referenced a more relevant example: https://github.com/uncognic/circuitchat https://github.com/uncognic/circuitchat

opem 4mo ago

Can the relay servers, when used as fallback, read the data between two parties by providing its own public key to both of the peers?

rklaehn 4mo ago
No. The data in each direction is encrypted by TLS, using ephemeral keys. Only the owner of the corresponding private key can initiate a connection from their public key, or receive a connection attempt to their public key. Let's say you have alice and bob talking via a relay. Even if you have the private key of alice, you can impersonate alice to bob, but not vice versa. So you can't initiate a connection between the two. To really intercept data you would need the private keys of both participants.
khowells 4mo ago
As I understand it the “peer ID” you dial acts like the public key, of the public/private key pair. So the public key doesn’t come from the relay. You need to do the initial public key/ID exchange out of band, and then dial the connection to each other via the relay. So the relay is never in a position to send you the wrong public key, because it doesn’t give it to you in the first place.
flub 4mo ago
Iroh uses QUIC connections and uses the EndpointId, the public ed25519 key, in the TLS handshake for authentication. This makes it impossible for a server to try and machine-in-the-middle the connection.
matheus23 4mo ago
You need to know the public key you communicate with ahead of connecting to the correct relay. It needs to be shared securely out-of-band, relays don't help with that.

hathawsh 4mo ago

Iroh looks very interesting! How current is the PyPI package? https://pypi.org/project/iroh/ https://pypi.org/project/iroh/

Arqu 4mo ago
We bumped to 1.0 an hour ago https://pypi.org/project/iroh/#history https://pypi.org/project/iroh/#history

syllogistic 4mo ago

> when will iroh support webrtc... This would give you a native iroh node that also speaks webrtc but I find that what folks want is for browsers to participate as peers. I build p2claw, p2p for self-hosted web apps, and ended up doing both halves separately. Box to box is iroh, although I use my own coordinator service and run my own iroh relay. Browser to box is webrtc with a service worker that makes the browser act like a peer. The worker grabs fetches and sends them as HTTP frames over the data channel, the box answers on localhost. The browser bit has to be webrtc because it's the only browser api does ICE. Wiring up the iroh half went smoothly, very much enjoying working with the library. Congrats on 1.0!

samantp 4mo ago
Yes, seems that browser support for services running on P2P boxes behind NATs cannot leverage iroh. Need the service worker hijacking the browser’s fetches as well as monkey patching the browser’s websocket SDK and sending all that traffic over webrtc data channels.
apitman 4mo ago
I discovered p2claw the other day and it's really cool. I'm a little surprised you're running Iroh as well. Why not just use WebRTC for everything once you're forced to for the browser anyway?
- syllogistic 4mo ago
  [dead]

jhancock 4mo ago

Nice. How easily is the protocol categorized by an external observer? I'm noticing protocols like wireguard more commonly hitting problems as websites rely on third party systems to protect them from non-human interactions.

matheus23 4mo ago
Somewhat easy, unfortunately. If you look at Wireguard traffic, you'll see a <EndpointID>.iroh.invalid SNI in the QUIC Initial packet. Encrypted ClientHello can fix that, but support hasn't shipped into rustls yet. So it's definitely fixable. The interesting thing is that the ClientHello is undetectable when it's sent via the relay transport (sent inside a WSS connection). And in that case, any traffic that happens on IP is fully encrypted and can't be categorized.

mkl 4mo ago

Please consider putting the first paragraph of [1], "iroh is a modular networking stack written in Rust. It provides the building blocks to create applications that can communicate using fast, cheap, and reliable connections.", at the top of the blog post and the main website. The middle two lines of [2] are good as a follow-up. The current stuff about dialling is pretty incomprehensible, as shown by the many confused comments here. No one "dials" IP addresses (or keys), and no one wants to, so the word "dial" shouldn't be part of the title or description. The word "key" would be better not mentioned until you start talking about implementation, and the brief high level "what it is" and "what it is for" stuff should come before implementation. Iroh seems quite relevant to some projects of mine, but after reading the blog post and the main page, I still had no idea of that relevance until I had read over a hundred comments here (many of them confused about what Iroh was). [1] https://docs.iroh.computer/what-is-iroh https://docs.iroh.computer/what-is-iroh [2] https://news.ycombinator.com/item?id=48543554 https://news.ycombinator.com/item?id=48543554

munksbeer 4mo ago
> "iroh is a modular networking stack written in Rust. You can omit the "written in Rust" part, but then you'd lose street cred.
- mkl 4mo ago
  It's not for street cred, it's what makes it usable everywhere: Rust, JavaScript (server or browser), Python, Kotlin, Swift, C. Written in JavaScript or Python means limited use, Kotlin or Swift means it could be tricky outside their main platforms, C means worrying about potential vulnerabilities and core dumps. I.e. "written in Rust" is definitely relevant here.
  - quibono 4mo ago
    > C means worrying about potential vulnerabilities and core dumps Rust guarantees no vulnerabilities?
    - 4mo ago