Live data from Hacker News

Iroh 1.0

iroh.computer

311–320 of 488 posts

Re: Iroh 1.0

#311

I am happy to see that Iroh says they'll support the 1.0 protocol for the entire life of the project even if they make a new version. If they can stay true to this it'll be a useful alternative domain system. But using QUIC means it's CA TLS only. As we've seen with the US government pressure on Lets Encrypt recently this CA TLS requirement allows the US (or other nation's) feds to shut down your 'key' no matter wher…

We are using QUIC, but using a QUIC/TLS extension called raw public keys in TLS. The DNS is not involved in any way, and there is no way anybody can shut down your usage of iroh.

https://datatracker.ietf.org/doc/html/rfc7250

In the beginning of the project we did use self-signed certs, but due to raw public keys that is no longer necessary. And in any case scary build flags aren't an issue since we control our own rust QUIC implementation, noq.

Re: Iroh 1.0

#312
post #271

Earlier quoted context omitted.

the closest comparison is openziti: + iroh and openziti can both be app-embedded + so the app developer embedding in their service is a good use case for both + openziti is used for services in which scale and security are critical + whereas iroh allows participation from parties which don't have any prior relationships - which can be very convenient

> the closest comparison is openziti: Except without all the ceremony about setting up daemons, servers, controllers, "networks" and what not that openziti seems to have. Iroh is more "define protocol and hook two clients together" with everything in one binary. Unless I understand https://github.com/openziti/sdk-golang/blob/a6e5f1697a9dc34a... wrong, it seems to require a "controller-url", is that controller embedda…

yes, openziti includes a full mesh, programmable overlay. agree not all apps need that.

Re: Iroh 1.0

#313
post #62
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…

"This was not a solved problem until now."

Re: Iroh 1.0

#314

If you're new to Iroh, my mental model is roughly "Tailscale at the application layer instead of the network layer". If your question is, "why not just use Tailscale?", look at it from an app developer's perspective. If you want to release an app and have instances of your app be able to easily connect to each other, you could theoretically embeded Tailscale functionality into your app, but then the users of your app…

[deleted]

Re: Iroh 1.0

#315
post #16

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

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.

Re: Iroh 1.0

#316
post #16

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

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

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?

Re: Iroh 1.0

#317
post #41

Earlier quoted context omitted.

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.

I've been running my own AS for years. You can get an ASN and IPv6 from a RIPE LIR for $200/year or less. Then you need a couple of VPSes that are BGP capable. You can get those for $20 month. Then you can tunnel traffic back to your location with a Wireguard tunnel or whatever you prefer. It's relatively cheap! I also have a legacy IPv4 block I'm routing, which doesn't cost me anything.

Is there no annual fee on all IPv4 blocks, or just legacy ones, which I'm assuming means blocks that haven't changed hands in a very long time?

Re: Iroh 1.0

#318

If you're new to Iroh, my mental model is roughly "Tailscale at the application layer instead of the network layer". If your question is, "why not just use Tailscale?", look at it from an app developer's perspective. If you want to release an app and have instances of your app be able to easily connect to each other, you could theoretically embeded Tailscale functionality into your app, but then the users of your app…

Ok, stupid question, but what applications is something like tailscale/iroh used for? I've never worked with this type of tech so curious where it is valuable.

Re: Iroh 1.0

#319

To me this sounds like tailscale - does anyone have any insight into how what this is doing is similar or different?

I work on iroh.

On the technical level, the biggest difference is probably that we build on QUIC whereas tailscale builds on wireguard. Iroh is a library that is made to embed into your application, whereas the tailscale offering started as a daemon. It allows embedding, but you are still carrying the baggage of a go runtime. Iroh is written in rust. Rust compiles to a native library and is therefore easier and more lightweight to embed in compiled programs (C, C++) and languages such as js and python.

Another big internal difference is that we use relay URLs whereas tailscale is using relay IDs. The consequence is that every iroh endpoint, no matter if using self-hosted relays, the n0 public relays, or the n0 paid relays, can reach any other. In tailscale two nodes will only be able to talk if they use the same mapping from relay id to relay ip address, which usually means that they use the same coordination server.

Last but not least, while we do have a commercial offering, everything you need to run iroh is open source, licensed MIT and Apache2. With tailscale the coordination server is closed source and operated by tailscale, and the only way to run your own tailnet is to use the headscale community project.

Re: Iroh 1.0

#320

> Dial keys Maybe it's in the video I didn't watch, but I really think paragraph one should make clear what kind of keys and why. Cryptographic? Asymmetric? How do they do the job, at even the most basic level? It never explains, just dives into abstract claims of superiority and usage stats. I gather relays are involved; this would be a good thing to mention right away instead of making me sift it from the HN discus…

> Dial keys. Not IPs. > It's a simple idea really, and it's the right abstraction for the future of the internet. IP addresses can break, without warning, and it's outside of your device's control. Keys, however, are created & controlled by you. They stay the same as your device moves, and are yours to throw away, or not. IP addresses can be private and inaccessible behind firewalls, but with iroh your device can be…

DNS doesn't work with constantly changing IPs, like you have on mobile networks. DNS also doesn't help when the IP is behind a NAT. So I really don't see how the two are similar at all.
Post reply on HN