An open protocol with a chance of working

A protocol is like a common language that multiple different software can use to talk to each other, it's like e-mail, HTML or HTTP.

When we say "protocol" we mean that there is no need to use a specific app in order to be in Nostr: there are many apps that talk the same language and can be used (mostly) interchangeably — and each has its own take on how to do and display things.

In the default feed you never see any spam, because clients will only fetch information from people that you follow. In that sense no one can "push" spam into you.

It's trickier when you want to see, for example, replies to your posts, in that case a client might be programmed to fetch anything that claims to be a reply from anyone, which might include spam.

The way we can deal with it on Nostr is by restricting our area of contact with the spam: for example, some clients may easily decide to only display replies that come from people followed by people you follow. More refined strategies involve announcing and then only reading notes from relays known to be "safe" according to your criteria (could be relays that require payment, relays that do screening for humans, relays that only accept members of certain communities or political affiliations etc).

There are no perfect solutions. But these do not exist anywhere, centralized platforms are also full of spam. Nostr at least isn't naïve and tries to build resiliency from the start.

Yes, Nostr is just a basic client-server architecture. And the fact that users can naturally spread among hundreds of different relays while clients can query dozens of relays that they're interested in at the same time means the network has a natural load balancer (which doesn't prevent a single relay from having its own internal load balancer either).

Another (almost the opposite) concern that may be raised is with problems arising from clients having to connect to too many relays if the profiles being followed for whatever reason decide to spread way too much, but this shouldn't be a problem either because people tend to follow many accounts with similar content and these will tend to share relays. Still, if it happens, it's cheap for native apps to open many hundreds of WebSocket connections simultaneously (as they will be getting very few data in each of those). For web apps that isn't so hard, but we can still go up to a few hundreds without big problems. Regardless of any of that, in any complete enough app that wants to display a "following feed" it's already necessary to store events in a local database, and that will make all these issues easy to deal with as you can do the event requests in batches instead of all at once.

Harassment is similar to spam in the sense that anyone can still create the undesired content and publish to the relays that accept them. All the techniques mentioned in avoiding spam can also be applied in this case, but if we're talking about specific individuals with a permanent identity and not only an army of bots in this case the problem becomes easier, as those individuals can just be blocked by their target and their content will vanish. Presumably friends of such target will also block, and creative solutions involving shared blocklists can be created such that some people don't even have to click the block button directly.

Other approaches involving, for example, relays with restricted read (that can emulate "protected account"/"only friends" features seen in centralized platforms) can further improve this.

There are many problems with Mastodon, mostly due to the fact that it doesn't rely on any cryptography. Because it cannot do the multi-master approach of Nostr due to lack of cryptography, identities are assumed to be "owned" by the server, which is fully trusted by its tenants. Mastodon server owners can do all the harm centralized platforms can do to their underlings, which are completely helpless in case of misbehavior or even in the normal case where a server owner loses their server or decides to shut down for whatever reason.

Worse than that, for many of its purported features, such as blocking or direct messages, users have to also trust owners of the other servers.

There are also problems with reliance on the DNS system, but we don't have to talk about those.

The most interesting feature of Mastodon is that by its nature it creates communities with shared values that grow in each of its servers. Or, should I say, that should be a feature if it actually worked like that. In fact these are not really communities, but a mashup of users that may share some interests among each other, but also have other interests and those other interests end up polluting the supposed "community" with things that do not interest the other users.

Nostr, on the other hand, can create real communities around relays, specifically because users don't have to fully belong to those relays, but can go to them only for some of their needs and go to other relays for other needs.

Bluesky has many problems, the two most pronounced are:

1. Identity centralization: all accounts belong to PLC, a database ran by a central entity that can censor at will — or, alternatively, they can belong to a DNS domain, which is cumbersome, also censorable, risky and is not expected to be used by many anyway;
2. Data centralization: because the Relay-AppView-Client flow assumes only one canonical source of data at each step (unlike Nostr multi-master architecture) that source is always a server that has power to censor, shadowban, reorder data and so on.

Clients are assumed to be dumb and trust the AppView, and here you have room for all sorts of undesired shenanigans. Then AppViews also assume to source their data from a single Relay, and here you have room for the same effect.

You could argue that Bluesky Clients could become smart and start sourcing data from multiple AppViews, or from multiple Relays, or that the AppViews could rely on multiple Relays, or that the Clients could talk directly to the PDSes — and all of that is possible and would indeed bring solutions, but notice that if those things started happening Bluesky would end up becoming Nostr, except with more steps.

Yes, this clip answers it well.

But basically the answer is the same as the question about scale: if users can go to whatever relay they want we'll see relays ran by all sorts of people and entities. Running servers is very cheap, and a relay can run on a $5/mo server and house at least a few thousand users. It's not hard to imagine relays ran by communities, individuals who just want to be useful to others, big organizations wanting to gain good will with some parts of the public, but also companies, client makers, and, of course, dedicated entities who sell relay hosting for very cheap.

It's not a feature of the world at large to be able to see or hear everything that is happening everywhere at all times. Nostr inherits that property from the world, making it so that you can only see what you focus your attention on (and you're allowed to see by the relay that hosts that information).

It's only possible to search on what you have seen, so search engines will always have to crawl some parts of the network they chose to and index those to enable public search. The word "chose" is employed because, as we know, there can't be a "global" view of the network (and no one would want such a thing anyway as it would be full of spam), so indexers have to choose. This is not different from Google deciding what websites to index.

On the other hand, it's surprisingly doable for clients to store all the posts from people you follow, or all the posts you have seen or interacted with over time (since it's just text, a huge amount of notes can fit in the same space that would otherwise be required to store a single photo, for example) then provide local search over that. That kind of search will be sufficient for most of the cases you would reach out for a search bar in a centralized platform (which is to search for things that you have seen before), and perhaps even more useful since it would naturally filter out all the unrelated garbage.

Last, niche or community-oriented relays can also provide very useful search capabilities by just indexing the notes they have stored locally, already filtered and scoped to that relay's topic or cohort (imagine searching over a Discord, Slack or Telegram group, for example).

The most basic way to do that is by following the natural habits used by most centralized social platforms users since a long time ago: by looking at the people you follow and whom they're interacting with.

But also it's not true that Nostr doesn't have algorithms. Nostr can have algorithms of all kinds: manual, automatic, AI-powered or rule-based. Some of these algorithms can be run entirely locally on clients (for example, surfacing posts from the times when you were not online, or from people that make fewer posts), while other algorithms can be provided by all sorts of relays, either by naturally surfacing posts from a community of people you don't follow or by dedicated relays that have the stated purpose of curating content desirable for a target audience or even by targeting specific users.

Nostr uses the same cryptographic principles of Bitcoin and was kickstarted mostly by a community of Bitcoiners, so it has disproportionately attracted the attention of Bitcoiners at the start, but aside from that it doesn't have any relationship with Bitcoin. It doesn't depend on Bitcoin for anything and you don't have to know or have or care about any Bitcoin in order to use Nostr.

What about "zaps"? Zaps are a standard for tipping Nostr content using Bitcoin that is implemented by some Nostr clients, but it's fully and completely optional and if you don't care about Bitcoin you don't have to bother about it.