Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Iroh 1.0

iroh.computer

Post reply on HN
Print view View original

101–110 of 488 posts

Re: Iroh 1.0

#101

Post by system2 »

rklaehn wrote: post #62
Thaxll wrote: post #46

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.

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 a…

Is bypassing the router a good idea?

Re: Iroh 1.0

#102

Post by moritzruth »

noworriesnate wrote: post #86
dignifiedquire wrote: post #9

Earlier quoted context omitted.

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.

I don't mind paying for a subscription, as long as I'm not also paying for the privilege of being locked in to a specific vendor. If I pay for a subscription and then your prices quadruple or something, what are my options? Can I self-host a relay? Do I lose features if I do so?

I'm not affiliated. From what I understand, they provide an open-source implementation of the relay server: https://github.com/n0-computer/iroh/tree/main/iroh-relay (which may or may not be what they actually run as part of their hosted offering).

If you use their offering, you probably get some kind of web interface for metrics that isn't open-source.

Re: Iroh 1.0

#103

Post by ben-schaaf »

tumdum_ wrote: post #37

How is that different from https://yggdrasil-network.github.io ?

Not an expert but this is how I understand it. Yggdrasil is a P2P mesh network. You configure peers to join the network and your computer becomes a relay node for everyone else to use. It doesn't work behind a NAT without port forwarding.

Iroh is kinda just a connection protocol. If you get given a public key for another computer, you can establish a connection. Like you would an IP address. The magic is in being able to establish that connection regardless of where either device is, and keeping that connection alive through changing network conditions.

Re: Iroh 1.0

#104

Post by pkulak »

handoflixue wrote: post #70
rklaehn wrote: post #62

Earlier quoted context omitted.

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 a…

Excuse my ignorance on the subject, but what does this solve that VPNs didn't already address?

From my VERY brief understanding: this is like if you want the hole-punching of a VPN, but your stuff is public, so not only do you not want all the security of a VPN, but it works against you. But I'm happy to be corrected!

Re: Iroh 1.0

#105

Post by [deleted] »

colinmarc wrote: post #92

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.

[deleted]

Re: Iroh 1.0

#106

Post by rklaehn »

suwapat wrote: post #69

Missing a native go version

Iroh is just a clever combination of existing standards such as QUIC with some draft RFCs and a tiny bit of clever custom logic added via TLS extensions.

So in theory a go implementation is possible using a go QUIC implementation that supports the multipath extension.

Our focus is the rust implementation, since it is very easy to use from compiled languages such as rust, C and C++ and to embed into languages such as js and python.

But there are some other projects that attempt to provide a native go implementation: https://github.com/tmc/go-iroh

Edit: since iroh is just a library, it is also possible to link iroh into a go program. Linking a go program from other native languages is a bit of a pain, but linking a C or rust library into a go program is relatively straightforward and high performance.

Re: Iroh 1.0

#108

Post by rklaehn »

gamegod wrote: post #72

Sounds good, but the first step in your quickstart is getting an API key, and I'm oh, so I guess your sales pitch was a lie and this is really just another Cloudflare-like play to build another intermediary in the internet. If that's not the case, then I shouldn't need an API key for hello world...

If you are a rust developer, you can just take a look at the examples in the iroh repo itself or in our iroh-examples repo.

None of them require an API key.

https://github.com/n0-computer/iroh/tree/main/iroh/examples

https://github.com/n0-computer/iroh-examples

Re: Iroh 1.0

#109

Post by dignifiedquire »

orthecreedence wrote: post #98
aliasxneo wrote: post #85

Earlier quoted context omitted.

Is that not what libp2p already offers? Not sure if it has QUIC out of the box, but hole-punching to UDP connectivity and then running QUIC over it isn't that hard.

Libp2p does have quic, at least the rust implementation.

Yes, but libp2p was mainly designed around the limitations of tcp, as quic simply wasn't there yet when the design started. Iroh gets the benefit of having been designed and built from the ground up, based on quic.

Re: Iroh 1.0

#110

Post by geoctl »

Honestly I am happy that more remote access products are using QUIC, not WireGuard, for tunneling and realizing its technical benefits (e.g. AES hardware acceleration, dynamic endpoints, custom auth with JWT or mTLS, FIPS compliance, traffic masquerading as HTTP/3, etc.). I am a big fan of QUIC myself and I implemented it long ago in Octelium, which is a similar remote access product that's more centered around access control and zero trust rather than P2P connectivity. I believe QUIC should be the future of tunneling, especially when it comes to business and enterprise remote access use cases. Congrats on launching an I wish you the best of luck.
Post reply on HN