You also assume that using that scheme Nostr will (perhaps naturally) get more decentralized and more people will use different relays, but we have no reason to expect that to happen under those circumstances. The incentives are completely in the other direction:

1. people don't want to run servers (otherwise Mastodon would have been a success)

2. people flock to a few relays that provide this "outbox-on-the-server" service for them

3. doing outbox-on-the-server is actually much harder than on the client, and impossible at scale because of relay filter ratelimits, this leads to these servers actually just giving up the outbox model and syncing with some other selected relays, which creates other types of centralization pressure on the publishing side

4. it also creates another type of centralization pressure, which is the specialization of these "aggregator servers": instead of serving a normal relay interface they are more likely to start serving some pre-processed GraphQL queries or something like that to make clients even easier to write for incompetent LLMs

5. now the barrier to running one of these aggregator is higher, which leads to less entrants

You get the idea. If we get to the end of the story we'll have like 2 or 3 of these big aggregators, with 90% of people in one of them (but even if we had 50 that would still be ridiculously centralized and censorship-resistance becomes a joke).

I don't see why we would even get to end of the story though, because why would such a broken protocol be attractive to anyone? What are its discerning features? Why not use X or Bluesky?

Reply to this note

Please Login to reply.

Discussion

This approach doesn’t change the current model at all, it only moves part of the client’s workload onto a specialized relay.

For example, if someone follows too many users and the outbox model becomes painful for them, they can run a local relay that automatically pulls events from their followings’ write relays. Then they just browse that relay with Jumble. This is actually a feature I’ve wanted to add to nostr-relay-tray for a long time, but have kept putting off. And of course, if they don’t want to run a local relay themselves, they can wait for a paid service to offer it.

If someone doesn’t follow many users, or mostly browses relays directly, then they don’t need to do anything, they’re already perfectly happy with the outbox model.

I’m only talking about the following feed here. Posting, replying, reacting, getting notifications… all of that would still follow the outbox model as usual.

And I'm telling that once you go through the centralization route because, the steps I enumerated will follow and eventually you won't be able to do "posting", "replying", "reacting" etc in the outbox model because it will not work (and won't matter either).

Maybe you’re right, I can’t argue with that.

Are you saying that going from connecting to the dozens of relays from people you follow to connecting to a single relay hosted by a big provider isn't a change in the model?

Or maybe you're just trying to step back and say that "some people may do this, others may do that", which is more reasonable, but still a bad idea, as you would have to have clients specialized in one model and clients specialized on the other model and one of those would end up winning, and since it looks like you're cheering for the single-relay-big-provider model to win I'm telling you it's a bad outcome that makes no sense to cheer for.

What if this special relay is run locally by the user? Or what if the relay is actually a client itself? Would that change the outbox model?

Why would a client need to support two models? At least Jumble doesn’t need to make any changes. If such a special relay emerges, the user simply needs to bookmark the relay and browse it. They can still click on the following feed and connect to dozens or even hundreds of relays as before.

I see what you mean. Yes, one of the advantages of the Jumble model is that it allows for that kind of customization, and if it's clear to the user that they're browsing a relay and not the abstract concept of their following feed then I see it as pretty much ok.

I was thinking that you wanted to get rid of the following feed and proposing that Nostr clients switched entirely to this other model (rather than just adding a feature for browsing relays).

This is just a solution specifically for users who follow too many people.

That's fine, specifically because no one really follows more than 400 people. When they have more than that it's because they're interested in some "trends" more than the actual specific people, so relay feeds with whatever algorithms would be a much better choice.

Eventually users will have to learn too, they can't just expect things to work the best way for them without no work (and it can't be argued that such approach works on centralized platforms, it doesn't).

(Still, I think normal outbox will work fine with any number of users as long as you have a local database that is proportionally big and a syncing process that is slow and patient.)

Will we have a Fiatjaf Jumble fork with local database?

It looks like fevela already has that.

Yeah, I agree. Even if a client fully fetches and displays notes from nearly a thousand people, I don’t think anyone can realistically read all of that. Once the number of followings passes a certain point, "following" kind of loses its meaning.

(And since most people don’t stay on a page for very long, I’m not sure a slow, patient syncing process would really work in practice either.)

I just wish it were simpler to create thematic relays; that would bring people together based on their areas of interest.

i personally think that anyone whose income comes purely from donations, and not from their own funding or investors with a plan to make a margin of profit is unqualified to talk about what nostr needs to get more users.

nostr is not going to become the next generation of web tech without making money. that's not gonna happen if it has no resistance to malicious actors. it's also not gonna happen unless people have a plan for it making money to at least maintain it after it's in production.

there is maybe 10,000 people in the world using it on at least a weekly basis. it has flatlined for the last two years. that's because people keep listening to people who have no skin in the game, like fiatjaf, who is using it as his bully pulpit.

Nostr is just a communication protocol. The reason it isn’t generating revenue right now, in my opinion, isn’t because of the protocol itself. It’s simply that the people using it haven’t found the right ideas yet, or many are comfortable with the status quo. Nobody thinks today’s internet industry is profitable because of how the HTTP protocol was designed.

But if by nostr you mean the Twitter-like kind 1 clients, then I have a genuine question: what is the actual goal of a nostr kind 1 client?

A. Become the next Twitter.

In that case, we’d need to spend money bringing in influencers and give them ways to monetize on nostr, stronger ads, storefronts, creator tools, etc.

B. Become a place where ordinary people can speak freely and post their everyday, boring, normal lives. A platform where the main characters are regular users, not influencers.

If that’s the goal, then we’ve already achieved it. On Japanese and Chinese relays, most of the content is exactly that, simple, mundane posts from normal people.

the reason why the legacy social media make money is because so much money is being thrown at controlling what people think, advertising and propaganda.

the protocol is just a protocol. it has nothing to do with the problem. it's like comparing Thunderbird to Outlook. almost nobody is usivg mozilla's version anymore, and it's barely changed in 20 years. Outlook is still holding users because it's part of Exchange and 365

the same difference. protocol is free, but nobody can build something with it forever on donations and personal savings.

What if we have Kafka or other dumb pub sub in between all relays. Each relays can become an agregator in a blink of an eye. Yes, single point of failure, but no censorship.