iroh 0.32.0 - Browsers Alpha, QAD, and n0-future

Welcome to a new release of iroh, a p2p library that just works, putting more control in the hands of your users. This release brings you some cool new features that we can't wait to get into your dependency tree.

To start: join us in testing out iroh that compiles to WASM and can work in the browser! Next, iroh can work in higher latency environments with larger packet loss due to QUIC address discovery. Finally, take a look at the n0-future crate for a single, sane, curated crate for working with a smattering of futures-* crates, as well tokio::{spawn,task,time} alternatives that can compile to WASM.

🖥️ iroh in the browser alpha release!

We've got preliminary iroh support for browsers via WebAssembly! During this preliminary support phase, you'll need to depend on a branch to be able to use it, but we'll release it properly soon.

To try it out, add this git dependency to your Crates.toml:

iroh = { git = "https://github.com/n0-computer/iroh.git", branch = "matheus23/iroh-browser", default-features = false }

Running cargo build --target=wasm32-unknown-unknown should just work, if the rest of your project can also build to Wasm.

Some caveats:

• WebAssembly support won't be compatible with any additional iroh features. Namely metrics, test-utils, discovery-local-network, nor discovery-pkarr-dht.
• Browser support specifically needs wasm-bindgen's bindings generation, so that needs to be set up. We also leverage wasm-bindgen-futures, so async iroh code will use javascript promises on the main browser thread. So if you’re spawning tasks that should run iroh functions, make sure to use wasm-bindgen-futures.
• Using iroh from browsers will be similar to using iroh in a "relay only" mode. When you connect to another node, the traffic will be end-to-end encrypted for the node you connect to in particular, however, it won't try to hole-punch or try to establish a direct connection, as that's not possible in browsers without deeply integrating with WebRTC. Instead, traffic is relayed via a WebSocket connections to relays.

Remember, this is specifically support for iroh in browsers, which we expect to be the biggest use case for compiling iroh to WebAssembly. We don't support other related things such as running wasm32-unknown-unknown Wasm files without wasm-bindgen nor compiling to wasm32-wasi or similar.

Check out PR #2799 for more details.

🌍 Quic Address Discovery (QAD) on the iroh-relays

Finding out your node’s public address is one of the big steps necessary for hold punching. Without knowing your public IP address, you have no way to let anyone else know what it is either. It’d be like wanting a friend to mail you a package, but not being able to tell them what your address is. We use a few different protocols speak to the iroh relay servers to learn about your public IP address (and a few other pieces of information).

Previously, we relied solely protocols that communicated over UDP. UDP is great when you want to fire and forget, but if you need reliability or the ability to retransmit data, to ensure the other side of the connection definitely received the data, you can’t rely on UDP.

In high latency, noise-y areas across the world, where traffic and packet loss might get too overwhelming for UDP, we were unable to always relay on STUN and ICMP. One solution we had to deal with the quirks of UDP, was to ensure we had relays all over the world, so that a user’s node has a better chance of reaching and getting a response from a relay server.

The other way we could solve this was by using a protocol for learning your public IP address, that was based on a reliable transport. QUIC is already an enormous part of our codebase, we thought we could use QUIC to solve this problem for us.

We implemented the Quic Address Discovery RFC to do just that.

Now, in iroh-net-report, we race STUN and QUIC address discovery probes to see which will get us our public IP address as soon as possible.

Our relays are all equipped with a QUIC endpoint that has QUIC Address Discovery enabled. Now, in our worst case scenario, very high latency and packet loss may result in a probe that takes a bit to respond, but this change takes us from no response at all to a response that is just delayed.

Check out PR #3049 for more details.

💫 n0-future

Another future crate?! Aren’t there enough of them?

First, none of them have as a dramatic name as our new crate: n0-future 😎.

Second, this crate acts as a single place where we expose the most useful futures-* and tokio traits and structs that work well with iroh, and that, in our experience, have the fewest “footguns”. If you want to have the same codebase compile to Wasm and native simultaneously, n0-future is for you.

Third, this does the major lift of co-locating a large amount of code that is very common in async programming, but does not work in the browser. n0-future takes care of the ugly cfgs for you. But with that said you should not need to import n0-future yourself if you are using iroh as a dependency. n0-future is an implementation detail of iroh, unless you start running into async headaches, especially if you're targeting WASM.

The major goal here is to make our (and your) coding lives easier. Rather than having to import multiple crates that all cover slightly different futures-like topics or stress about what can and cannot compile to WASM, just import n0-future and be good to go.

Check out PR #3156 for more details.

⚠️ Breaking Changes

• iroh
  • removed
    • iroh::endpoint::get_remote_node_id has been removed. Use iroh::endpoint::Connection::remote_node_id instead.
    • iroh::endpoint::Connecting::local_ip is removed.
    • iroh::endpoint::Connecting::remote_address is removed.
    • iroh::endpoint::Connection::local_ip is removed.
    • iroh::endpoint::Connection::remote_address is removed.
    • discovery-pkarr-dht feature became non-default (moved from opt-out to opt-in).
  • changed
    • iroh::Endpoint::connect returns an iroh::endpoint::Connecting
    • iroh::endpoint::Connecting resolves to an iroh::endpoint::Connection
• iroh-net-report
  • changed
    • iroh_net_report::Client::new now takes additional parameter mapped_addrs: Option
• iroh-test
  • whole crate is removed:
    • iroh_test::parse_hexdump is replaced with data_encoding::HEXLOWER.decode
    • iroh_test::CallOnDrop is replaced with tokio_util::task::AbortOnDropHandle
    • iroh-test::logging is replaced with tracing-test

But wait, there's more!

Many bugs were squashed, and smaller features were added. For all those details, check out the full changelog: https://github.com/n0-computer/iroh/releases/tag/v0.32.0.

If you want to know what is coming up, check out the v0.33.0 milestone, and if you have any wishes, let us know about the issues! If you need help using iroh or just want to chat, please join us on discord! And to keep up with all things iroh, check out our bluesky.