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