That's fair, and I'm genuinely happy it's working for you. Quality over quantity is a valid choice.
When Nostr is pitched as a small space for like-minded people to connect deeply, that's honest and appealing. But it's often marketed as an alternative to Facebook, Twitter, Bluesky, Mastodon... and it's just not that. It serves a different purpose entirely.
People can chose to market nostr as how they see it, there isn't a marketing team to it, someone might want to make it a Facebook someone might not. Nostr isn't just one thing, it takes some time to get around that fact.
For me Nostr is one thing, it's one social protocol... similar like ActivityPub is one thing, or AT Protocol is one thing. All of these protocols use their own identity system to create an ecosystem of socially connected apps, from Git forges to Last.fm alternatives.
You can market Nostr how you want, sure... but marketing and reality are different things. Right now the reality is a small community that's chosen authenticity over reach. And because it's one protocol with one identity system, if that marketing actually worked and brought millions of users, everyone would be forced to share the same social space. You can't have a universal identity protocol AND maintain exclusivity.
Nostr is not one thing, it's an amalgamation of sub protocols, around 100 on the github Repository and multitudes that are in use and not even on github, just hosted on some devs website. Your client can pick and choose whatever nips to use which vastly changes the experience for the end user. Just look at how different pollerama.fun is to any othet client.
Nostr is vastly different from atproto and activityPub, intact I'd say you're carrying a bias from there. As I said it takes some time to get around all of this.
But it's definitely not one thing, and definitely not what you think it is.
Sorry but the exact same thing is true for ActivityPub and AT Protocol - hundreds of sub-protocols and extensions there too. They're tackling it from different angles architecturally, but from an end-user perspective it's almost the same concept.
anisota.net differs from the Bluesky client just as much as pollerama.fun differs from Damus. The technical flexibility isn't unique to Nostr, and it doesn't change my point about the social dynamics.
Yes it doesn't, my bad, I had interpreted your comment differently, but my other reply, did address how it's different from these protocols.
I was around AT Protocol for 2.5 years so I think I know its architecture pretty well. The main technical difference I see is that ATP was created with scaling to millions of users in mind - everything was optimized for that growth. Nostr is not designed for growth. If millions of users suddenly migrated here, Nostr would collapse. So in a way, Nostr is better designed for staying small - which circles back to my original point about the community choosing intimacy over scale.
Lol, I have been developing on nostr for 3 years I know the architecture very well, it would definitely not collapse with growth, now you're just making baseless assumptions.
Outline exactly what would break?
What you don't understand yet is that nostr doesn't have a global state. There is no list of ALL nostr notes. You have no clue how many nostr users there are, since there is no way to know.
You're right there's no global state. But that's exactly the scalability problem. Without global state, there's no way to do efficient content discovery, trending topics, search, or spam prevention at scale. Every client has to query multiple relays and piece together a partial view. That works fine for small communities but breaks down at millions of users.
How? Thats just another conjecture, even on legacy apps, mastadon or bluesky all you ever see is a partial view.
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.
Experience at teenly tiny scales tells you nothing about experience at actual scale.
This divine video things is a good example. I quote:
"The app has lots of bugs, and we need appstore approval, but at the moment the biggest problem I have is relays... i started using nosflare by @Luxas which worked pretty good when we had dozens of users but has had scaling issues and has been hard to debug... So then we tried using the ditto relay by @Alex Gleason and put a bunch of really beefy servers behind it. Even then it's struggling to keep up. The thing is, we're pre-launch, we have 10k users in testflight and a mostly read only site at divine.video which is a react app."
Only 10k users in test flight and the guy can't find a single relay that'll handle it. Or maybe all these test flights users were just "holding it wrong".
So many things on nostr will collapse at scale.
There's nothing special in nostr relays, they are just backend servers that can scale horizontally. If there were problems in divines relays, they could be easily solved. Nothing about nostr itself is the scale issue, there may ofcourse be bad code in a nascent protocol.
There is nothing special in nostr relays is the exact problem. You need something special to scale.
Relays physically cannot scale vertically, even strfry, which I'll be the first agree is tight c++ code, will max out before it supports anything at scale just due to write limits. You'll always hit a write wall on the database, and no code will remove that wall for you.
Relays cannot scale horizontally either (to millions) due to coordination issues, latency issues (especially tail latency), the backplane limit, state bloat quicksand, and also just vertical maxing out of individual relays in the horizontal plane. Again no code will fix this, you're bumping up against hardware and the laws of physics.
Lol, I thought you were a not earlier 😂 I'm still not sure, these are all issues where the underlying tech breaks, postgres in this case, these are the same limitations for legacy tech, so what you're saying, and it's true, is that nostr can scale as much as legacy tech can.
Bot *
I'm glad I'm not a bot. Seriously though, it's raw physics when you break it down.
I’ve heard a lot of this “in theory nostr will scale horizontally forever” but, having worked in gaming with hundreds of thousands of concurrents this is the equivalent of “in theory if all the cars start moving right when the light turns green then there won’t be a delay for the cars further back”. Yeah in theory that's true.
Put another way, relying on “naturally occurring” load balancing is about as ambitious as doing away with airplane tickets and just having everyone come to the airport to try to board planes like they’re public busses.
Relays will only scale horizontally in mythical-world conditions that will never happen in the actual world. This is a mythical world where everyone and their sister is running a relay (an impossible relay:user ratio), where everyone adds just the right combination of relays so when one is maxed out vertically it falls back to another that isn’t maxed out (and that isn’t everyone else’s fallback), where high-horsepower relays (whatever distributed SQL monsters) just happen to be scattered around to just the very right places, where nothing on nostr requires ultra-low latency (waiting for the straggler relays), where no one single person has a reason to subscribe to events from more than a couple hundred others, and so on.
And that's just the relays, when you get to the blossom servers, CDNs, etc., and then the interplay between the relay side and the media side, it's just blood out of both nostrils.
If you've scaled anything then you can see from a mile away that nostr will not scale. You need centrally-orchestrated load balancing and a hundred other things akin to a human central nervous system.
Also you can have the same universal identity and definitely maintain exclusivity that's exactly what not having a global state gives you.
