Besides muting individual accounts/a pubkey list, I don’t have an obvious client side solution. We plan to address this with note classification + filter “focus” modes with user configure global views. Not quite there yet but soon!
You can add ?global=all to filter.nostr.wine today and break out of the follows+follows network, but you’re right - it’s filled with bots. My dream is global all -bots. Coming soon™️…
Maybe we need bot tagging services. Anyone can help tag them as bots or humans.
And I’m sure it was mentioned, I know I’ve said it a bunch. Would be nice if there was a protocol way for the “good actor” bots to self label as bots too.
I think it’s something that needs to be addressed from both sides - publisher and client filtering. Perhaps a kind 0 flag? Unsure about best bottom up approaches.
I think a “bot” is perhaps too specific phrasing. Is a bot something that posts my twitter posts to Nostr as well (extremely hypothetical.. I don’t dead bird). Not really.. but it is automated or assisted? But does that matter.. not really, it’s mimicking a human. Does a bot reply to DMs? Etc.
Verification events read like a bot, but are ideally once per account/service combo. This is a ‘service-like’ event/message example - in contrast to a dedicated bot/machine account.
My interest in identifying machine posts is to remove them from certain summarisation data - like hashtags or words or url frequencies. I want to represent human contributions instead of the most frequent repetitive bot terms.
I think we need a better name too. Bots, automated, machine… maybe hybrid accounts exist too… naming is hard.
Maybe “service” accounts? Maybe there are event a few standard types that could be chosen from?
Why not a new NIP that requires some POW to generate a valid npub/nsec pair? Anything that doesn’t put in enough work auto seen by clients as spam. Just need a loading bar on account creation as phone does some computing, like trying to get a custom looking npub but actually useful. #[5] does this for contacting him via website form. Has to upgrade difficulty occasionally but works I think
Can start computing right from first app screen while user configures account, agrees to terms, writes profile bio/name etc, chooses UI theme etc
A significant issue I realised recently with POW pubkeys, is when you use HD identities that derive from a seed key - even if your initial seed or first derived key has high POW, any children using incremental counters won’t. It will be a random POW.. most likely 0.
This means POW for HD identities is likely incompatible with many of the simpler key management and rotation approaches.
The issue in this case is the target problem isn’t directly flood spam. It’s largely repetitive or generic generated events that aren’t from a direct human source. It’s like metadata events or piggy back events that don’t provide value to most users.
Can relays not just require some POW attached to notes to accept them? As long as there is a real cost somewhere along the line, spam is disincentivized
POW has a fair chunk of pushback - however it does offer unique properties. The general preferred approach is pay-to-relay.
It’s a good point that perhaps generic messages shouldn’t be posted to dedicated public human consumption relays to begin with - but again, you can’t really control this. However, pay-to-relay could assist - but people will just pay for their bot pubkeys to relay, as it’s cheap per event in general.
A counter point is, just like advertising and tagging, as soon as it’s used for discovery, people will do whatever they get to boost/maximise their discovery for the lowest cost. Bot dedicated relays for example likely wouldn’t get as much attention or engagement.
I see kind 1 as a forever dumping ground of random events, as it will be the most supported kind by apps and get the most eyes. Our engineering challenge is to best manage that.
