Maybe. It's offering "Customized hosting and monitoring for Iroh apps".

From the same pricing page, it's all additional services: observability, relay hosting, support engineers.

As others have already mentioned, iroh the core library and protocol is fully open source. But to finance the development of it, we offer additional services to make it easier to deploy and run it, especially for larger or more specialized use caes.

The equivalent for IP addresses to what they offer would be closer to running a BGP router or ISP, or generally contracting with network engineers for your data-center's networking.

If you want to run an ISP or AS, believe me it will cost you a decent chunk of money.

tailscale syndrome.

"we want to be infrastructure for people, and a business towards professionals."

stuck between "we need cash to operate" and "we want to be a public good infrastructural system." , with the negative parts of a for-profit whisked away with "Well it's open source."

it's a business concept i'm okayish with as long as the "Well it's open source." caveat doesn't come with a total bespoke and unusable code base to figure out.

Zenoh seems interesting but can you please give me some use case where both Iroh + zenoh can be combined to achieve something more trivially (ie. without hassle) or the use-cases of this combination. I'd be curious to know more about their combined use-cases!

Thanks, we agree! We used to have bindings for while but the maintenance burden at that point was too high. Now that 1.0 guarantees everyone some stability and we feel confident in the library, we have enough room to properly support it.

how can i make it give me zen-inspired life advice?

This looks very interesting. I’m not sure I understand this, but it seems to me like it competes (or is in the same space as) both Tailscale and zeromq/nanomsg via the protocols? I think it would be nice to have a comparison page to make it easier to position it (I didn’t find one).

The secret is that iroh still uses IPs under the hood :) But with QUIC, your connections aren't bound to your four-tuple, your connection can migrate from e.g. WiFi to Cellular with only a small blip/hiccup. And with QUIC multipath, you can have multiple four-tuples "active" at the same time. iroh uses e.g. a "real" IP path mainly, with a websocket-based HTTPS path via relay servers as the backup (e.g. in case UDP is blocked).

We have an answer, but it isn't really clever. We do have both built in and pluggable address lookup services.

Our default enabled address lookup service is using DNS in a creative way, but we also have a service that is fully peer to peer and is using the mainline DHT, specifically the bep_0044 extension that allows you to store a tiny bit of arbitrary data for an Ed keypair that you control.

https://www.bittorrent.org/beps/bep_0044.html https://pkarr.org

Some custom transports such as TOR hidden services have a discovery system built in. In these cases we can just use the existing discovery system.

See for example https://github.com/n0-computer/iroh-tor-transport

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

Were interacting with IETF on a number of projects and so far it's been going well :)

Iroh is a project that combines existing IETF standards in an interesting way. For example we use raw public keys in TLS for the key exchange https://datatracker.ietf.org/doc/html/rfc7250 instead of coming up with our own key exchange scheme.

Our QUIC implementation noq is a standards compliant QUIC implementation that in addition to RFC9000 also implements the QUIC multipath draft RFC.

We try very hard not to invent new things unless absolutely necessary. In a few places we had to implement draft RFCs, QUIC multipath and QUIC NAT traversal. And there are some corners where we had to add our own extensions. But we try very hard to keep this to an absolute minimum.

As I see, it tries to explain.

But as someone who's not a network specialist, I fail to see how this is not a glorified P2P DNS.

Maybe this example helps:

https://github.com/n0-computer/iroh#rust-library

    const ALPN: &[u8] = b"iroh-example/echo/0";

    let endpoint = Endpoint::bind().await?;

    // Open a connection to the accepting endpoint
    let conn = endpoint.connect(addr, ALPN).await?;

    // Open a bidirectional QUIC stream
    let (mut send, mut recv) = conn.open_bi().await?;

    // Send some data to be echoed
    send.write_all(b"Hello, world!").await?;
    send.finish()?;

    // Receive the echo
    let response = recv.read_to_end(1000).await?;
    assert_eq!(&response, b"Hello, world!");

    // As the side receiving the last application data - say goodbye
    conn.close(0u32.into(), b"bye!");

    // Close the endpoint and all its connections
    endpoint.close().await;

Such is life when you choose to be introduced to something by a version update blogpost, instead of clicking in the top-left corner and reading the landing page.

A difference between iroh and many p2p networks is that we try to use existing IETF standards (QUIC, TLS) as much as possible instead of reinventing the wheel. An iroh connection is just a QUIC connection, using TLS and TLS ALPNs for protocol negotiation.

If you look at an iroh connection using wireshark, it is just a QUIC connection. You can use all the existing tools, and a lot of things you learn when using iroh transfers to traditional QUIC connections and vice versa.

Most iroh contributors come out of the p2p world, and you could say that we had a bit of abstraction fatigue after working on regular P2P networks for some years.

We have also so far resisted the temptation to write a DHT, opting instead to use the biggest existing DHT, bittorrent mainline, for our p2p address lookup needs. Many traditional P2P networks come with their own implementation of a DHT for discovery.

Note that there are some "regular p2p networks" that use iroh under the hood, e.g. holochain https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-... as well as various p2p chat apps.

https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-...

By far not a complete list but a starting point https://github.com/n0-computer/awesome-iroh/

Also you can join our discord and there's #showcase https://iroh.computer/discord

Establishing direct connections on the other hand is a much harder problem with the current internet infrastructure.

I'm not affiliated with Iroh or even using it, but... "IP works just fine". What!? This is _not_ a solved problem

Iroh is QUIC. We are not trying to reinvent the wheel here, just combining existing IETF RFCs in a creative way.

Here is a concrete problem we solve. You have one device in your home WLAN behind a NAT. Your other device is in a 4g network, or behind another NAT at work.

In most cases we can give you a direct connection between the two devices very quickly via hole punching, so you get the highest possible bandwidth and the lowest possible latency.

This was not a solved problem until now.

A little bit of both. Natively it relies on QUIC and leverages existing IP infrastructure, however it also works with custom transports just as fine so you can interact via bluetooth for example.

I would say it is not a replacement but an addition.

IP isn't going anywhere any time soon, but we add two capabilities on top. The ability to dial an endpoint by key, and the ability to get direct connections whenever possible.

That being said, if some other technology becomes popular that actually replaces the IP address paradigm, iroh is well positioned to make use of it. From the point of view of an iroh application developer nothing would change. You still dial by key, and iroh will just make sure under the hood to get you the best possible connection, IP or otherwise.

Their use of addressing by keys instead of by IPs seems to be the main differentiator. Also the support for custom transports (BLE, LoRa, Tor) which appears to be in progress and not yet fully implemented.

I love Tailscale, it's deployed on all my devices. But I might check this out for the transports part in particular.

My 5 second summary: Tailscale connects devices and Iroh connects applications.

Tailscale is OSS AFAIK. Not their backend of course, but if you use Headscale then I believe every part is OSS.