The only solution to Nostr spam

By spam I mean any undesired, automated or subjectively low-value content. You can also include harassment and other bad things in this category, it doesn't matter.

The main feed

Nostr doesn't have a problem with spam in your main feed, as you only read notes from people you follow or from relay feeds chosen manually that are likely to not have spam (of course you can also read from relays full of spam, but that would be your choice).

So this problem is solved.

The "inbox" spam

Currently it's possible, in some clients and depending on some user configuration, to spam someone by mentioning them or replying to their notes, which causes spam to show up for them in their "notifications" tab or analogous place.

The solution to this is for clients to only read mentions or replies (["REQ", "inbox", {"#p": ["<user-pubkey>"]}]) from relays marked as "read" in the user's kind:10002. These relays are also the relays other well-behaving clients will pick when mentioning someone, so by reading only from these "read" relays no one will lose any notifications.

That, per se, doesn't fix anything. The fix comes when users start to set as their "read" relays relays that filter out spam by excluding low-value throwaway pubkeys or low-value content.

What relays do this? relay.mostr.pub, for example, has this nip05 requirement that will prevent most types of spam; pyramid.fiatjaf.com/inbox, (and any other self-hosted instance) will compute an aggregated 2-level WoT filter for all relay members and only accept incoming notes from such people (it will also block hellthreads); pow.relays.land or paid relays like nostr.wine can be used as fallbacks for when people really want to reach out to someone but they can't fulfill the initial requirements.

I'm just listing some examples, but the space needs more relays that do this filtering. Specifically, it would be nice if some well-intentioned relay provider (there are many people with good hearts out there already hosting relays for free) set up some "inbox" relay (I can imagine inbox.nostr.wine or inbox.yakihonne.com or read.nos.lol) that did some basic antispam filtering by content or by excluding keys using a broader definition of high-value pubkey based on some global algorithm.

Assuming such infrastructure exists, clients should start setting up these public specialized inbox relays as the default for users that do not care, so they won't see spam as their first Nostr experience.

The reply spam

The "inbox" spam is trivial to fix, but now we move to the third and hardest of spam avenues: other people's threads.

When browsing their own threads in an ideal client a user will only be seeing replies that can be found in their own "read" relays (say, pyramid.bob.com/inbox and inbox.yakihonne.com), because that's where everybody sent their replies to and that's the only relevant place to read replies from, so they won't see any spam there.

But, when going to read someone else's thread, he will also fetch replies from their "read" relays, and these may be full of spam, like public.nostr.at, and the thread will have spam in it. How do we solve that?

If the practices outlined above become widespread, it will also become evident that, if you're seeing spam at someone else's thread that is their fault. It's their fault for not picking "read" relays correctly.

And maybe they did it on purpose, they like some specific kind of spam, so if that bothers you you shouldn't go on their threads anymore. But maybe they are just unaware of the issue, so anyone can easily inform them and they can find a better set of "read" relays.

Again, this is not to say every single user must have an ardent desire for tweaking their own relay configurations, all clients should set up sensible defaults for users, but that doesn't mean that relay configurations are meaningless and that users should have no responsibility whatsoever for their configurations and still assume everything will be great. If they misconfigure things once or if their current configuration stops working they'll have to fix it, with or without a nice client-provided AI-generated friendly advisor bot. Eventually people should stop going to someone else's house if the house is always dirty.

Local filtering

Many people will read this and complain that these relay settings are not necessary and that all filtering must be done locally, using mutes, shared mutelists or client-side WoT. To these people I must say: yes, but also no.

Yes because such client-side techniques can complement the relay filtering and catch some lucky spam content that was able to pass through the well-configured relay barrier.

Mutes and mutelists can be very good when dealing with some specific real user that is harassing or bothering others, but it obviously does not work against spambots as these will use an infinite number of public keys.

Client-side WoTs can address spambots, but they can't be the only thing a client relies on, for the simple reason that content must first be downloaded before it can be filtered. This means that in a future in which Nostr is big with no relay-based spam filtering clients would be downloading gigabytes of spam all day everyday just to filter everything locally, and that is a horrible situation. Even now a spammer can just flood a thread with >500 spam replies and that will cause the naïve relay to serve only the top 500 replies to such note, which means all the real replies will not be shown (assuming most relays are configured to hard-limit queries at 500 and no pagination is done).

Another issue with client-side WoTs is that it is a monolithic solution: while the relay-based filtering allows users to choose what kind of replies they want to see by simply picking the relays that have the desired configurations, on the client side they would probably have to change clients in order to use a different technique, not to mention the fact that many of the antispam techniques available to relays wouldn't be possible to do on a client, so the options would be much more limited.

Maybe there are other techniques for filtering spam on the client side and they should be explored, but again these would be useful only for catching last-mile spam, they can't ever be a generalized solution.

The final argument against doing everything locally is that it doesn't create the overarching incentive structured outlined in the previous section: i.e., if I'm filtering everything locally that means I do not care for the fact that other people visiting my threads will see a ton of spam, and these people are left to fend for themselves and that spirals into a tragedy of the commons situation in which every Nostr user suffers.