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

261–270 of 488 posts

Re: Iroh 1.0

#261

Post by dotancohen »

andrewflnr wrote: post #222

> 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 securely addressable no matter where it is.
To me that just sounds like a reimplementation of DNS. Maybe decentralised and maybe free and maybe not monomeric, but broadly the same.

Re: Iroh 1.0

#262

Post by szmarczak »

apitman wrote: post #257
kkapelon wrote: post #99

Earlier quoted context omitted.

Like https://tailscale.com/docs/features/tsnet ?

Similar on the technical level (though QUIC vs WireGuard), but that would make your app dependent on Tailscale, and require your users to have Tailscale accounts. You'd also be limited to Golang currently. In theory you could run Headscale, but you're really working against Tailscale's intended design at that point, and Iroh was built for this from the ground up, so what is Tailscale buying you?

You don't need tailscale accounts to access tsnet (via funnel).

Re: Iroh 1.0

#263

Post by apitman »

overgard wrote: post #173

This sounds useful, but isn't this the problem that ipv6 is supposed to solve with 128bit addresses? (I'm not really familiar with why IPv6 never really seemed to take off -- does NAT block incoming IPv6 traffic? (I guess that's the other thing -- even though my devices all seem to have IPv6 addresses I can't recall ever using them))

IPv6 solves a lot of it, and maybe in another 20 years we can rely on it.

Re: Iroh 1.0

#264

Post by Folcon »

dotancohen wrote: post #261
andrewflnr wrote: post #222

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

The biggest difference that I can see is that keys are not making any claims about ownership, there's no global registry and it's p2p, which is a big upside

Re: Iroh 1.0

#265

Post by forkerenok »

jhbruhn wrote: post #88

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/

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.

Re: Iroh 1.0

#267

Post by nemothekid »

kkapelon wrote: post #146
nemothekid wrote: post #130

Earlier quoted context omitted.

This isn't the same functionality - if I'm shipping a video conferencing application, tsnet would require all my customers be in my tailnet.

but if I am shipping a video conferencing application (where I control both the client and the server) I don't need nat traversal anymore. My clients will have outgoing connections to whichever co-ordination server I choose. Tailscale is great for bringing devices/apps into a secure network when I cannot modify them in any way. If I have full access to the source code for everything, the story changes completely.

>My clients will have outgoing connections to whichever co-ordination server I choose.

Then it's no longer p2p? If I wanted to avoid paying cloud egress costs, then I would need a p2p solution.

>Tailscale is great for bringing devices/apps into a secure network when I cannot modify them in any way. If I have full access to the source code for everything, the story changes completely.

Naturally, but this thread isn't about Tailscale, its about Iroh. You were the one that claimed Tailscale can already do what Iroh can. But I've pointed out a usecase where Tailscale wouldn't suffice that Iroh can accomplish.

Re: Iroh 1.0

#268

Post by bicepjai »

So each app can be its own tailnet, and let devices talk to each other on its network using api keys. Like home appliances in HomeKit network ?

Re: Iroh 1.0

#270

Post by asdfaoeu »

sva_ wrote: post #244
morphism wrote: post #240

Earlier quoted context omitted.

While the frontpage doesn't go in depth, the docs quickly do: First with https://docs.iroh.computer/what-is-iroh and then following up with the how it works section. The docs are actually good from what I can see so far. From what questions you brought up so for it seems to answer them pretty quickly.

The doc still doesn't show what such a 'key' looks like? Why can't there be a simple infographic that goes like 127.0.0.1 -> 'key'

It seems to use DHT under the hood whether directly or through a relay. https://pkdns.net/ .
Post reply on HN