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

461–470 of 488 posts

Re: Iroh 1.0

#461

Post by PLG88 »

embedding-shape wrote: post #443
dovholuknf wrote: post #439

Earlier quoted context omitted.

OpenZiti has numerous SDKs. If you are a developer and you can integrate an SDK into your application, it 100% is application-embedded. It is incorrect stating that it can't be app-embedded... (i am a maintainer on the project). Perhaps I just don't understand the response?

Oh, hi :) Thanks for responding! This: https://github.com/openziti/sdk-golang/blob/a6e5f1697a9dc34a... mentions a "controller url", I'm assuming it's just the particular example then and in reality you could build and ship one golang binary that doesn't require any other external processes to connect the two processes together via OpenZiti?

I’d separate “app-embedded” from “no external coordination.” OpenZiti SDKs are app-embedded: the app can directly dial/bind Ziti services without a local tunnel daemon. Ziti also supports tunnelers and non-embedded options where app modification is not practical. But yes, the app is still participating in a Ziti network with controllers, routers, services and policies.

Iroh is definitely lighter-weight and developer-first, but it is not always “two binaries and nothing else” either (at least from what I have read). Once you need arbitrary peers across NATs/firewalls, you may need relays, address lookup, relay URLs/tickets, and for production likely dedicated/authenticated relays.

So to me the distinction is not “embedded vs not embedded”; both can be embedded. It is “P2P connectivity substrate” vs “governed zero-trust service overlay.” Iroh optimises for low-friction key-based peer connectivity. OpenZiti optimises for centrally governed, least-privilege service reachability, including identity lifecycle, revocation and policy control at fleet scale.

Note, I also work for NetFoundry, which develops and maintains OpenZiti.

Re: Iroh 1.0

#462

Post by bsenftner »

__MatrixMan__ wrote: post #422
bsenftner wrote: post #394

Earlier quoted context omitted.

That amazement is due to one of our largest and least realized critical mistakes as a civilization: no where are people taught how to effectively communicate. We have entire Colleges of Communications at every university, and what do they teach? How to execute mass manipulation, not how to convey understanding, not how to manage disagreements. These are not "mistakes" either, this distinct lack of teaching real commu…

I think my college technical writing course covered these things quite well. It's not that they're not taught, it's that communication skills are not rewarded the same way that marketing skills are. Generally speaking there's a lot of blame to be placed on the universities, but in this case it's an HR oversight.

A technical writing class is learning the alphabet, and does not really touch the nuance, the subtleties in certain topics that make them very difficult to communicate.

Any topic with unknown aspects (to the audience) or controversy require special handling because in that uncertainty people's personalities step in, and that is the seed of misunderstandings becoming institutionalized.

When an individual has gained group prestige from their "theory" being accepted, they then guard that prestige with omissions of information that counteract their position, and deferment of blame when proved incorrect. This is the ordinary human response, and will play out unless the participants have formal communications training that break this pedestrian cycle.

Communications is far more than just "communicating with another". Self communications is the gargantuan invisible elephant yet to be realized by larger society, and is the source of gullibility. Group communications has fractal complexities that play out depending on how many participants are trying to collaborate, and their relative hierarchical power verses one another. Entire careers are spent identifying the categories, and this area is largely unexplored, unexamined. It's too interpersonal and laced with extreme levels of power for honest analysis.

And then there is AI: a communications technology that people think is an automation technology, and our colossal communications tragedy is not going to correct this misunderstanding.

Re: Iroh 1.0

#463

Post by bsenftner »

MithrilTuxedo wrote: post #429
bsenftner wrote: post #394

Earlier quoted context omitted.

That amazement is due to one of our largest and least realized critical mistakes as a civilization: no where are people taught how to effectively communicate. We have entire Colleges of Communications at every university, and what do they teach? How to execute mass manipulation, not how to convey understanding, not how to manage disagreements. These are not "mistakes" either, this distinct lack of teaching real commu…

That sounds like the Success Oriented approach, as opposed to the Understanding-Oriented approach. Check out Jürgen Habermas's Theory of Communicative Action (1981).

I will, thank you.

Re: Iroh 1.0

#464

Post by dovholuknf »

embedding-shape wrote: post #443
dovholuknf wrote: post #439

Earlier quoted context omitted.

OpenZiti has numerous SDKs. If you are a developer and you can integrate an SDK into your application, it 100% is application-embedded. It is incorrect stating that it can't be app-embedded... (i am a maintainer on the project). Perhaps I just don't understand the response?

Oh, hi :) Thanks for responding! This: https://github.com/openziti/sdk-golang/blob/a6e5f1697a9dc34a... mentions a "controller url", I'm assuming it's just the particular example then and in reality you could build and ship one golang binary that doesn't require any other external processes to connect the two processes together via OpenZiti?

At this time OpenZiti still operates in relay pattern. All your traffic travels through an OpenZiti router. It's also a zero trust overlay so having an external server is important to make policy decisions about whether an identity is authorized to dial a service or not. OpenZiti also allows for bespoke pathing via OpenZiti routers so that path traversal over the overlay is also coordinated.

The project has been moving to supporting directly connecting to other identities but it hasn't been a priority yet.

The connections an OpenZiti identity makes to another OpenZiti identity are direct-over-OpenZiti (not direct over IP underlay) if that makes sense. I don't know if you'll ever be able to have two process communicate without that third 'arbiter' process (I'll call it). It might happen, but right now it seems less likely than the direct connect approach.

hope that helps. But you can definitely have an SDK app client connect to an SDK app "server" and be fully zero trust, fully app embedded, fully end to end encrypted, peer-to-peer (over the overlay) connections.

Re: Iroh 1.0

#465

Post by angry_octet »

rklaehn wrote: post #455
angry_octet wrote: post #404

Earlier quoted context omitted.

How do I add firewalls and proxies and logging to iroh connections? How do I revoke and re-issue iroh keys? Can I host iroh relays/gateways on my intranet? Until these questions are answered iroh will remain blocked.

You don't have to use it. But here are some answers: Re-issuing keys is as simple as generating a new Ed25519 keypair. let secret_key = SecretKey::generate(); // takes less than a millisecond Iroh as of now has no fleet management. So the concept of revoking a key is something you would have to add yourself. We have extensive logging for iroh. You can enable trace logging and even enable qlog for detailed connection…

Thanks for responding.

By logging I mean a gateway/proxy which logs connection metadata, not client side logging. Possibly this is something that could be added to a private relay. With a network of private relays you could form admission controlled virtual overlay networks for each application.

For key revocation, it is necessary to be able to invalidate a server accepting a key, without necessarily having the key. E.g. maybe you have a pre-generated proof enabling revocation.

Observability is super important for organisations. Especially with LLM servers and MCP interfaces popping up everywhere.

Re: Iroh 1.0

#466

Post by GreenWatermelon »

bsenftner wrote: post #394
samrus wrote: post #329

Earlier quoted context omitted.

Its amazing to me how people can make a great a product. And then completely bury the lead because they are so deep into the guts of the system You explained the value proposition so well. The website just didnt get to the "why?" At all

That amazement is due to one of our largest and least realized critical mistakes as a civilization: no where are people taught how to effectively communicate. We have entire Colleges of Communications at every university, and what do they teach? How to execute mass manipulation, not how to convey understanding, not how to manage disagreements. These are not "mistakes" either, this distinct lack of teaching real commu…

Is the LLM-tone of this comment intentional? Or is it just how you normally write? Honest question.

Re: Iroh 1.0

#467

Post by kkapelon »

ben-schaaf wrote: post #163
kkapelon wrote: post #148

Earlier quoted context omitted.

They do if you use tailscale and friends

Everyone I'd like to connect to isn't on my tailscale, nor do I want them to be.

They don't need to be https://tailscale.com/docs/features/tailscale-funnel

For this simple scenario (just exposing your laptop to a public IP) there are already a gazillion alternatives (e.g. ngrok)

Re: Iroh 1.0

#468

Post by logankeenan »

musicmatze wrote: post #452
logankeenan wrote: post #19

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

Shame they use discord though.

Why’s that? What would be the alternative?

Re: Iroh 1.0

#469

Post by embedding-shape »

dovholuknf wrote: post #464
embedding-shape wrote: post #443

Earlier quoted context omitted.

Oh, hi :) Thanks for responding! This: https://github.com/openziti/sdk-golang/blob/a6e5f1697a9dc34a... mentions a "controller url", I'm assuming it's just the particular example then and in reality you could build and ship one golang binary that doesn't require any other external processes to connect the two processes together via OpenZiti?

At this time OpenZiti still operates in relay pattern. All your traffic travels through an OpenZiti router. It's also a zero trust overlay so having an external server is important to make policy decisions about whether an identity is authorized to dial a service or not. OpenZiti also allows for bespoke pathing via OpenZiti routers so that path traversal over the overlay is also coordinated. The project has been movi…

> But you can definitely have an SDK app client connect to an SDK app "server" and be fully zero trust, fully app embedded, fully end to end encrypted, peer-to-peer (over the overlay) connections.

Yes, but that's the thing, when people say "Iroh lives in the app" they mean the entire thing, the relays are optional hole-punching mechanisms, otherwise it is distributed P2P embedded in the app. It's slightly confusing when you claim OpenZiti to be the same, with "fully app embedded" but in reality there is a server/overlay/controller/coordinator running somewhere that isn't actually embedded in the app.

I'm not saying the idea is bad, I think both have their use cases, OpenZiti seems like a solid project otherwise, I'm not trying to say it's a bad choice. I'm merely trying to help you, as an outsider, to maybe use/don't use certain words/definitions when you talk about it as it gets confusing then once you actually start looking at the code and things look very different from the expectations you set.

I do wish you luck with the project, all sorts of P2P projects are needed and they all have their place, I don't think it's a "one eats them all" ecosystem, and the more the merrier :)

Re: Iroh 1.0

#470

Post by embedding-shape »

PLG88 wrote: post #461
embedding-shape wrote: post #443

Earlier quoted context omitted.

Oh, hi :) Thanks for responding! This: https://github.com/openziti/sdk-golang/blob/a6e5f1697a9dc34a... mentions a "controller url", I'm assuming it's just the particular example then and in reality you could build and ship one golang binary that doesn't require any other external processes to connect the two processes together via OpenZiti?

I’d separate “app-embedded” from “no external coordination.” OpenZiti SDKs are app-embedded: the app can directly dial/bind Ziti services without a local tunnel daemon. Ziti also supports tunnelers and non-embedded options where app modification is not practical. But yes, the app is still participating in a Ziti network with controllers, routers, services and policies. Iroh is definitely lighter-weight and developer-…

> Iroh is definitely lighter-weight and developer-first, but it is not always “two binaries and nothing else” either (at least from what I have read). Once you need arbitrary peers across NATs/firewalls, you may need relays, address lookup, relay URLs/tickets, and for production likely dedicated/authenticated relays.

Indeed, for hole-punching you need something external, I don't think anyone found an mechanism to do it without some "signaling" server or similar, if it's even possible at all.

> OpenZiti SDKs are app-embedded

I think this is a good clarification, the SDKs that communicate with OpenZiti are app-embedded, while the server/coordinator/whatever runs somewhere else. That's why the comparison with Iroh feels weird, as both the SDK+"server" runs embedded in the application (except if hole-punching is needed, then some external signalling server is needed, as mentioned earlier), so it is in practice, what the developer cares about, two binaries and not much else.

> So to me the distinction is not “embedded vs not embedded”; both can be embedded

This is where you lose me and others, as when they talk about Iroh being embedded, they do mean everything you need to say run a P2P chat application on two computers, there are usually no URLs/coordinators/whatnot involved there (again unless hole-punching is needed), while with OpenZiti you need that chat application + OpenZiti running. The distinction people are trying to understand is very much this, so it's confusing when you call it "embedded" while still having an external thing running alongside it.

Post reply on HN