How? Thats just another conjecture, even on legacy apps, mastadon or bluesky all you ever see is a partial view.

Reply to this note

Please Login to reply.

Discussion

The difference is HOW they achieve the partial view. Mastodon has federated timelines and instance-level aggregation - there's coordination and state within instances. Bluesky has the AppView/BGS that maintains a global index and serves it efficiently. Both can optimize queries and content discovery because they have (centralized) components handling that layer.

Nostr clients query individual relays directly with no coordination or optimization layer. At small scale, the difference doesn't matter. At millions of users, it absolutely does.

At millions of users, you either need massive relays (centralization) or clients querying dozens or hundreds of relays simultaneously (terrible UX and bandwidth). There's no efficient way to do content discovery or search at scale without building centralized indexes on top.

Have you even looked at amethyst? It's not terrible UX just a ux that were learning to improve. I'm not going to get into "convince me" arguments because your mind is already made up.

But some of us have chosen to fix these issues when we see them, instead of declaring it won't work, and they are being solved, there are clients and NIPs that already address them. See gossip and amethyst if you wish to learn, or chose to ignore if you just want people to move to your shitcoin space.

> I'm not going to get into "convince me" arguments because your mind is already made up.

This seems be projecting. I'm not a Bitcoin maxi with fixed views. My journey has taken me from leftist to Bitcoin maximalist to anarchist over the past 25 years - I'm constantly learning and adapting my views based on new information.

I'm using Amethyst on Android but I don't understand how it relates to the architectural components needed for the scaling we're talking about.

See the number of relays it connects to. And how many you added. As long as your "following" is fixed, your client only needs to query their relays, not millions or billions of other users that exist on the network, that already exists, as for discovery, seperste completely privately owned indexers could exist and do exist (primal) specifically for this purpose, they will never be able to index all of nostr as well, because that's not possible.

Nostr private keys are locally generated, relays are discovered through peer interactions. It's a bottom up model thats literally built to work with infinite scale because it doesn't waste its time in building a global state.

The global state problem is supposed to be centralizing and is fine if it centralizes because that's not a problem that the protocol attempts to solves.

So you're actually confirming my point? If I follow 1k users scattered across the network, my client either needs to:

a) connect to hundreds of different relays (massive overhead for the client)

b) hope those users consolidate onto a few large relays (centralization)

The "bottom up model" works fine at current scale, but saying "the global state problem is supposed to be centralizing" is admitting the architectural limitation I'm talking about. Its not possible to handle millions of users without either client-side complexity exploding or relying on centralized infrastructure.

My Amethyst is currently connected to 200+ relays without effects on performance or battery - it just works - check how many relays you are actually connected to.

If it's 200+ relays now when Nostr has a few tens of thousands of users, how many will there be when it has millions users? Thousands? Tens of thousands connected relays? LOL

This is related to the number of people you follow, not the whole network.

I follow 264 people and it shows 170/281 relays. I think I'm connected to that many relays because the "global" feed

I don't think Amethyst connects to global by default, I think that's only when you view global. nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgswaehxw309ahx7um5wghx6mmd9u2mk7fe, is that correct?

Correct

Ok, I think I understand, I follow 264 people and it wants to connect to 284 relays because those are the relays that have the people I follow set up (not global). So if I follow 2k+ people, it can easily connect to 2k+ relays.

It's on demand (afaik) as you scroll through your feed... so it connects and disconnects very rapidly based on what needs to be displayed. My number of relays sometimes jumps to 1500 and then down under 200 again.

So essentially this is leveraging the fact that you usually follow only at most thousands of people and also the fact that you can only view a small number of pieces of content at the same time on your screen. And then finally, some relays are actually shared / used by multiple people, so the number of relays that you practically need to pull from stays similar no matter how many people you follow.

Are you going to follow millions of users? Are you dumb or are you just acting malicious?

I never mentioned "following" a million people.

I don't know how you use social media, but for me it's about information discovery. On Bluesky/X, I follow around 2-3k accounts, but I consume far more content through thematic feeds, easily reading posts from tens or hundreds of thousands of users I don't follow.

I'm unsubscribing to this thread, it's probably a waste of time for the both of us.

a) is not as huge an overhead as you make it out to be. It's already done.

B) no, this is the part you get wrong, indexers(seperate infra only for discovery) is going to centralize, that has nothing to do with users and their relays, users can host their own relays and write only to them, and the protocol still works.