Yet another Hacker News

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

27 points andros 1 day ago 11 comments

iamnothere 1 day ago | parent

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.

andros 1 day ago | parent

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.

iamnothere 21 hours ago | parent

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.

andros 21 hours ago | parent

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).

iamnothere 20 hours ago | parent

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.

andros 11 hours ago | parent

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

iamnothere 2 hours ago | parent

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.

tcfhgj 23 hours ago | parent

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?

andros 23 hours ago | parent

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

AAAAaccountAAAA 16 hours ago | parent

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.

andros 11 hours ago | parent

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?