Hacker News Reader

Comment by rklaehn | Hacker News Reader

We (iroh) don't do birthday paradox hole punching yet. There is some internal debate whether it is worth it.

So if you are in an extremely weird NAT you will fall back to a relay, either our public relays, your own relays rented from us via iroh services, or a self-hosted relay.

But I would argue that a p2p social application that occasionally uses a relay is very much preferable to a centralised app.

The relay is generic internet infrastructure. It just forwards end to end encrypted connections. It can not learn anything about the content.

A relay that is hosted on a non KYC server rented via ZCash would be interesting though if you are super paranoid.

View on HN

Yeah, we need "generic Internet infrastructure" for linking devices.

By 2030 we hopefully understand the mathematics-of-trust and can link all the billions of citizens together in a single overlay.

> non KYC server rented via ZCash would be interesting though if you are super paranoid.

What will happen if a decentralized Internet emerged and presented an existential threat to existing profit margins? Company lawyer would start to attack you, correct?

>What will happen if a decentralized Internet emerged and presented an existential threat to existing profit margins? Company lawyer would start to attack you, correct?

I think it's very misplaced concern. Commercially-viable internet will not be decentralized because of legal restrictions. If whatever engineering solution will be found to weaken them, governments will step in to curtail it. FWIW any moderately successful decentralization effort is more likely to be attacked from exactly this side: some countries will hate it for uncontrolled information dissemination, others for fiscal reasons.

I think this is overly bleak. Bittorrent exists and works since 20 years. And this is something that is more of a threat to commercial interests than e.g. a decentralized social network.

Also what kind of attitude is this? Government is too powerful, we might as well give up. Where's the fun in that. It is hard but also very rewarding.

Bittorrent is legally dangerous in quite a lot of countries where copyright is politically important issue, so as I see it the example supports my thesis.

>Government is too powerful, we might as well give up.

That's not what I wrote. My note is about proper understanding of real threats and obstacles.

I think you're both missing the forest for the trees. P2P connectivity is about as solved as it will get, and the last % will stay unsolved.

The final goal for decentralization is something like: no central party should become the irreplaceable master over data, community, feeds, moderation, UI and identity.

We already know the minimum pieces needed to avoid that kind of centralization: hashed, linked, signed records(/packets), so their validity and causal order don't depend on whatever connection carried them or whatever physical server received them.

Once we have that, apps 'transcend' the connection layer, and the parties that control identity, community, feeds, moderation, etc become signing keys that can operate from anywhere.

The real problem for a decentralized internet, or "local-first apps", is that writing applications at this layer, or writing the library that lets you write them, is hard and nobody has solved it.

IIRC Iroh tried this early on, then pivoted to the p2p socket library it is today.

I'm not sure where the Delft stack sits with its ambitions atm.

You're describing atproto. They solved all the problems and it's not hard to build on top of it. Maybe even easier than a traditional centralized app because your server is just a view over the network so don't need to worry about consistency or durability.

There is one last centralized part they built to avoid using a blockchain, the PLC system, but it's designed to be tamper proof and easy to replace with a new server. The only thing a malicious operator can do is censorship in the p2p sense (ignoring a user's actions) but that would break trust and make the community migrate to a new provider.

Not atproto specifically. I’m describing primitives that exist in Git, Bitcoin, and plenty of other systems.

What I’m getting at is that we haven’t nailed the right abstraction. A "sockets" or "HTTP/HTML" moment that collapses the design space, to such an extent we've collectively forgotten there were more complicated alternatives they replaced.

These links are 2 examples of the problem: https://atproto.com/guides/understanding-atproto and https://atproto.com/articles/atproto-for-distsys-engineers.

Somebody spend a lot of time and effort to make this as simple as possible. This is the best & simplest version of it.

Yet its not simple enough. Repositories, event logs, view servers, DID, ...Lexicon RPC (XRPC)? What’s the minimal version of this that still works? Not an SDK hiding the concepts; fewer concepts.

It’s hard to explain what I want precisely because I don’t think that abstraction exists yet. Maybe atproto gets us closer, but the on-ramp feels like endless links to sub-concepts. The average developer's eyes glaze over.

Reply on news.ycombinator.com