Semantic Coherence: Nostr – Signal Evidence & AI Readability

What is a "protocol"?

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.

How does Nostr handle spam and unwanted content?

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.

Will Nostr scale effectively with massive user adoption?

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.

What protections does Nostr offer against online harassment?

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.

Why not just use Mastodon/Fediverse?

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.

Why not just use Bluesky/ATProto?

Bluesky has many problems, the two most pronounced are:

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;

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.

Are economic incentives aligned to keep relays operational?

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.

If content is spread across multiple relays how can I be sure I'm seeing everything?

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

How does search work?

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

How can I discover new content from people I don't already follow if there are no
algorithms?

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.

Is Nostr related to Bitcoin?

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.