Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Congrats on shipping

    You need urgently a "versus" page that talks about tailscale/netbird/netmaker/zerotier/twingate/openziti

    Looking at the use cases, right now I don't see anything that cannot be done with Tailscale...

  • Nebula by Slack is also a decent player in this company.
  • That to me looks like Reticulums [1] adressing ("Destinations") with transport done via QUIC. Does it add anything what Reticulum didn't already solve, other than using slightly different protocols - do they have an advantage?

    [1] https://reticulum.network/

  • Or I2P that even comes with reinforced privacy: https://i2p.net/en/
  • This is the comment I was about to make. Reticulum is already a very complete network stack.
  • Besides the novel/different form of addressing Reticulum pretty much imposes its Zen on users. So in a lot of things where Reticulum is quite dogmatic, something like Iroh I'd assume (if it's reaching corporates) would provide more flexibility. I haven't checked out the source though.

    As an example, AFAIK, Reticulum encrypts packet origin, so only recipient can see them. I don't think this is admissible in a corporate network.

  • I like the idea. A couple of questions:

    1. How does Iroh handle key rotation / leakage? Could you build some kind of hot/cold system on top of it, where you'd have a cold "identity key" in airgapped, secure storage, used only to issue certificates for your hot "traffic acceptance" key?

    2. Is there any kind of peer discovery / DHT, either built-in directly or through some semi-official higher-level protocol, like DNS for IP?

    3. What about human-friendly peer names? Those are almost required for end-user friendly applications. Most solutions of that problem either assume that every single user is willing to dedicate their life to configuring DNS, rely on a trusted third party, or delegate the responsibility to a blockchain.

    4. What are the channel reliability properties, and are they configurable? Can you decide how to handle out-of-order or lost packets, or does the protocol enforce a decision? If you're willing to tolerate loss, duplication and reordering, can you avoid head-of-line blocking?

    5. Is peer anonymity a goal?

    6. What about two mostly-offline peers who wish to communicate (think smartphone apps that can't be connected 24/7 due to battery concerns)?

    Overall, cool project.

  • 1. Currently we are using Ed25519 keys. You could use our existing discovery services to add a level of indirection from a root key to the currently active key. It wouldn't be that much code, since the discovery services are pretty generic. But we haven't done so yet.

    2. We have a centralized DNS based discovery mechanism enabled by default, and an optional bittorrent mainline DHT based discovery mechanism. We also have mDNS for local networks, and you can plug in your own.

    3. Our current keys are non scarce but also not human readable. You can use another level of indirection via DNS or some blockchain based naming system like ENS to assign a human readable alias, but that is not built in.

    4. Iroh streams are just QUIC streams, and reliable and ordered by default. There are APIs to receive data as it arrives, but this for really advanced users. Most users are best served by just using the streams as-is.

    https://docs.rs/noq/latest/noq/struct.RecvStream.html#method...

    There is also an escape hatch if you don't want streams at all, e.g. if you have a consumer like a video codec that can deal with data loss themselves. We support QUIC unreliable datagrams ( https://datatracker.ietf.org/doc/html/rfc9221 ).

    https://docs.rs/noq/latest/noq/struct.Connection.html#method...

    5. Peer anonymity as in hiding the ip addr of a endpoint id can be achieved, but not with the default config. The default config is tuned for performance. You can hide your ip address by using one of the mixnet custom transports and disabling the ip transport.

    6. Iroh is just connections. If a and b are never online at the same time they won't be able to communicate. You would have to write an iroh protocol that talks to some always online node. We do have some protocols that can be used to implement this, such as iroh docs, but that is not the main product.

  • We use Iroh in production at work, and I'm absolutely in love with it. I'd describe it primarily as "Tailscale-style hole punching as a rust crate", but of course you can sprinkle a lot of cool p2p stuff on top of the basic QUIC connections.
  • thank you!
  • My company was using Iroh for a production distributed ML training system & we LOVED it. The team was incredibly responsive even before we hooked up with an enterprise support contract, they're incredibly knowledgeable and the library itself worked amazingly. ++ to this lib. would use again over libp2p anytime.
  • thank you!
  • Doesn't it seem odd to have "Pricing" for a protocol that's meant to serve a similar function to IP addresses? Maybe I'm misunderstanding something.
  • 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.

  • 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.
  • 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.

    by serf
  • 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.
  • Iroh has been amazing to work with and the engineers are so nice in the discord channel. The pragmatic approach to making p2p just work has been easy to understand. Their YouTube channel has great content too. Congrats on v1!

    https://youtube.com/@n0computer

  • thank you!
  • Shame they use discord though.
  • The future of networking is decentralization. I'm a huge fan of Yggdrasil and I2P. We should just be able to buy a mini PC to run 24/7 and host whatever it is that we need on it and seamlessly connect to others. A lot of techies already have older spare machines laying around collecting dust that can become servers. It is far cheaper in the long run and easier to maintain than having to deal with domains and server hosting. I truly appreciate the work that the Iroh team puts out.
  • It's been the future for at least 20 years now.
  • I don't understand the problem its trying to solve in the first place, IP works just fine, such as DNS.

    There is already IPv6 and quic, you need vendor and major software to have any traction in that field.

  • DNS is highly centralized. Iroh isn't.
  • I’ve recently been building some hobby projects that focus on local first, decentralized architecture and that’s how I discovered Iroh. In my apps, I want the user data to be stored local only, no server, and have p2p sync ability. So for something like that, Iroh appears to be the state of the art.
  • DNS isn't decentralised it's more federated. I believe Iroh has the option to use DHT here, last I looked at least.
  • From what I can tell Iroh seems to be trying to create the missing Session layer from the OSI model. Another example of trying to do this is Cisco's Location-Identity Separation Protocol.

    Lack of a true session layer in TCP/IP is why vmotion is normally only possible in a single broadcast domain because in this situation you only really use mac addresses for addressing and can thus use the IP as a stable identifier when the MAC address changes after a vmotion. And the switch mac address table handles the mapping.

  • Establishing direct connections on the other hand is a much harder problem with the current internet infrastructure.
    by Arqu
  • I'm not affiliated with Iroh or even using it, but... "IP works just fine". What!? This is _not_ a solved problem