We don't want decentralized systems, we want small ones | Hacker News Reader

We don't want decentralized systems, we want small ones

en.andros.dev

28 pointsandros12 comments

The problem with small systems is that they go away when the maintainer gets bored, dies, moves to a new country, gets too busy with life, etc. And they give the owner an immense amount of control, which isn’t always good in a time of declining trust and increasing hostility. At some point you get tired of migrating or rebuilding.

These days I don’t really like hosting anything that isn’t either under my own control or on a decentralized system.

This can happen, even in open-source projects. The key is that not everyone has the knowledge or the money to maintain them. These mini-federations make the Internet much richer and more accessible.

How is decentralization not better than this type of system? In a well decentralized system, nodes are coming and going all the time. Nostr presents a successful example of this: there are tons of relays, and even if one disappears then your content doesn’t.

I have lost count of the times that I invested time into a platform or small community hub, only to lose everything when it later closed up shop. Many times the community wasn’t dying, either, it was just forcibly evicted. This usually kills the community, especially if it’s very small.

The problem with Nostr lies in its cost and replication; the traffic is redundant (98% of it). The result is a fragile infrastructure; a "ticking time bomb" in terms of costs. Added to this are the typical headaches associated with any decentralized network (spam, moderation without a central authority, Sybil attacks, a constantly growing volume of data, etc.). Furthermore, it is dependent on relays (which is not the case for other networks).

Relays can be selective about the type of content they host, or even limit their hosting to specific enumerated identities. Most don’t do this at present (except for spam mitigation) because the network is too small to worry about it. There’s also no rule against expiring and deleting “old” content.

As for data volume, incoming relay data comes from users who choose where they publish, not from federated relays (as with Fediverse servers), so the traffic growth should be somewhat different from how things have played out with Mastodon hosts. I’d like to see a citation for that 98% number if you have it! Worst case, individual relays can limit themselves to registered identities or hold content for only a brief period.

I think that this flexibility will lead to a more robust network than the Fediverse, with some relay operators curating the type of content they host, with others going for a wide but shallow approach. Meanwhile users will be able to cross-publish to whatever relays allow them. If a node drops off the network, the content is not lost, and the original events can always be republished if that’s ever needed.

Sure, it's Wei & Tyson, "An Empirical Analysis of the Nostr Social Network": https://arxiv.org/abs/2402.05709 The 98.2% is download traffic, not relay-to-relay sync. Across 17.8M posts and 712 relays (second half of 2023), the average post sat on 34.6 relays, and since clients subscribe to every relay in their list, they pull the same event over and over.

On curation, expiry and registered identities: I agree, and that's more or less my point in the article. A relay that only accepts its members and drops old content is a small community with a gatekeeper and someone paying the bill. That's fine, it's what I'm arguing for. But "the content survives when a node drops" comes precisely from the replication that costs money. The more relays curate and expire, the more survival depends on someone (often just your own client) keeping a copy to republish.

I also wonder: if each administrator has their own rules and configurations for their respective relay, is it a decentralized or a federated network?

I wrote about where each protocol puts its single point of failure (identity, discovery, cost) here: https://en.andros.dev/blog/603e4e90/there-is-no-such-thing-a...

Thanks, not sure who would have flagged your comment but I vouched it. Redundancy in download traffic makes sense, although NIP 77 should help with this: https://github.com/nostr-protocol/nips/blob/master/77.md

I think I see Nostr as having some of the best points of both decentralization and your “small community” concept. As a user I can be as decentralized as I want to be (or totally centralized!) by publishing to as few or as many relays as I want. I can also hoard my events and republish if relays go offline. And followers can find my content through multiple channels: I don’t necessarily know or care what relay they use.

I don’t necessarily think that the small community approach is bad for everyone. Some people may even prefer the ephemerality of it. I just get tired of building on sand.

Thanks for the action! Perhaps my comments make me seem anti-Nostr, but if anyone reads my articles, they'll find several where I praise some of its design ideas and even implement them from scratch as an exercise in understanding. Therefore, I can venture to say that it has some scalability issues inherent to its architecture, but not due to poor design. It seeks a design somewhere between total decentralization (like P2P) and federation (like ActivityPub/Mastodon), with its advantages and disadvantages. It's not perfect, nor are any of the other solutions. Perhaps the NIP-77 extension mitigates some of the replication, but architecturally, it can't avoid it.

Is it suitable for small communities? I don't think so; it's over-engineering. A small decentralized or federated system is sufficient; successful examples like Tilde or FriendCamp reinforce my point. But everyone has their own perspective; I prefer simple systems without third-party dependencies. Small and sufficient is better than large and complete.

I don't buy it.

First of all, I don't use GMail or Outlook for E-Mail.

What would E-Mail/messengers/telco look like in small without federation?

What is your goal? To talk with other users via private messages, in the style of XMPP or IRC?

This is getting really absurd. Speak for yourself. I do not want those "small" things. Small means no one is using them. I want big, decentralized and reliable systems, built to deal with heavy load, system failures and malicious attackers.

Is it better to have something small with a certain level of usage, or a network of millions of users where only a negligible percentage actually interact?

Reply on news.ycombinator.com