The two most abused relays in terms of spam are Damus and Nostr.bg. I’m finding perhaps 30%+ of total DB events can be purged. And the current load of inserts drops by 75% with spam filtering.

It’s a moving target, but relays need to protect themselves from malicious actors. My DB is already 40Gb including indexes.

I’ll keep sharing any spam preventing approaches I find that work. ML is currently the best approach.

BlueWallet doesn’t support lightning addresses, which allow repeated payments. Works fine for single use invoices.

Any idea how to combat zap cycling where two parties agree to zap each other’s content continually, effectively boosting each other at near zero transaction cost?

I had the same issue. Said some back in 11 days and has since stopped replying.

I’m not claiming serial numbers as unique identifiers have no value. Nostr event ids are a useful example. Database indexes another.

It’s more around in day to day life, when did you ever check the serial number on your fiat bank note when someone paid you? Never.

Sure, perhaps that’s hard to look up and easier with a Bitcoin system - however you don’t need to check an ordinal sat number to check if you now hold newly transferred Bitcoin. No Bitcoin wallet has to check the ordinal to verify payment success.

The issue is basically digital goods are fungible (copy + paste, now which is the original? Do you care?). Serial numbers are there to make goods non-fungible (you can’t swap two things and not be able to detect that).

Outcome, Ordinals are just some arbitrary mapping using some statistical uniqueness to apply potential perceived value, which will only ever be intangible, and unless you collect postal stamps, you likely shouldn’t care.

Side note: unless you have a centralised authority that signs the authenticity of an inscribed ordinal, in a decentralised world, inscriptions are lacklustre.

Ordinal theory is actually interesting (not to be confused with being valuable). The issue is effectively “so what?.. you hold some print number of sat since the genesis block”.

Any inscription is not unique, or won’t be for long. Same basic issue as NFTs.

And serial numbers are useful for physical goods (counterfeiting or contractual identification/warranty) or in centralised systems (phone home software licensing, or order tracking)… otherwise they hold no real value.

When do you last remember ever checking a serial number in real life (outside of a business relationship) for any reason? Never.

Two things that hold no real value joined together doesn’t create value. Doesn’t mean a bull rush and burst cycle won’t happen… and “opportunists” won’t fill the mempool hoping to cash out on a craze.

It Bitcoin didn’t have a free market mechanism for transaction fees we would be in far more trouble. This is just part of a cycle.

You’ll have to read the embedded inscription Lore. May grant +10 to magic, or may BTC > /dev/null.

True, however if there was any actual value it wouldn’t be the inscription, it would be the effective sat serial number.

Luckily in either case it’s marketing bottled air.

You still have issues around public wifi and being more identifiable. You also may not be talking to the relay you think you are.

We don’t know yet how best to deal with spam across the protocol. At present it’s easiest for relays to do something as they have the most data. However clients could use a pre-built model to detect spam themselves.

So yeah, todays it’s relay specific and clients can only really modify their relays to ones that have some protection.

DMs disappearing seems to be happening more. I know it’s based on sender broadcast relays and receiver connected relays - however it’s not quite that simple.

With the relay auth NIP, only you connecting to each relay (with auth enabled) will get content for your DMs. This means relay syncing and aggregation won’t work - clients will need to query all relays for their DMs (basically a distributed inbox model). Obviously this doesn’t scale.

Clients can and should become better when broadcasting DMs to ensure it’s a relay the recipient uses (e.g NIP-05 relays) - and not just their own relay set. Clients can also cache which relay they have received DMs from and use it again for future lookups too.

I like the concept. The 1984 events could have a known pubkey that could be trusted by relays or others to label events as spam.

One issue is you would lose the spam score component. At what score would an event be created? Is that something clients should instead decide? The score could be inside a 1984 tag perhaps - but scores also could change or improve over time if an event was re-evaluated (perhaps a bug, or new data now correctly identifies something as spam).

Yeah, the issue is they often use a new pubkey per event.

I don’t have the specific data, however your relay volume in general reduced significantly from two days ago. I’d guess it’s likely related to your efforts. And your relay didn’t change after I applied my spam filtering today.

It’s proof of concept, but I’ve added meta.spam_score to my event API. I still need to decide how to roll out the ML classifier at scale (it’s a bit slow atm without a GPU). I’ve only classified 40k events thus far to review.

I’m not sure publishing 1984 events is the best approach. Each spam message then would need another 1984 kind event. And just one spam message alone I have 360k+. But alas, it’s not too dissimilar to likes and how one post could have 10MM+ like events in the future.

https://api.nostrgraph.net/beta/events/note1da798nu47zk363rjddg37wlsgy0xw8y0w48yx0vrzfw6652tam3szpzre9.json?pretty=true

Or just stats

https://api.nostrgraph.net/beta/events/note1da798nu47zk363rjddg37wlsgy0xw8y0w48yx0vrzfw6652tam3szpzre9.json?pretty=true&stats_only=true

And here is Nostr global feed before and after spam filtering.

Fixed image link for previous.

A few more examples. Including the Damus relay, which had a 52% total volume reduction.

Basically all spam detected was with 99% confidence or more only.

This stuff all adds up too. I found one specific spam event (duped, unique event_ids) I had stored 360,000 times on my relay 😟

Interesting there are a fair few relays where the traffic didn’t change at all - basically not being used by spammers (or syncing from a relay that is).

https://i.ibb.co/QbpRCRB/image.page

Here is a real example of how spam detection can help reduce noise on the Nostr network.

First image as I was enabling it. Semi-staggered in two phases.

Second two images are examples of relays (not finger pointing.. just examples) where their event traffic dropped 80-90% by volume (when I dropped the spam).