My new antispam thesis is this:

1. Reject events unless we already have a kind 0 (profile event) for the pubkey.

2. Restrict making a kind 0.

By requiring profile events, you force the attacker to create a profile. By restricting the creation of profiles, you slow them down.

Real users should still be able to get in because they won't hit the same limits.

We just recreated web 2.0 security on Nostr. "You need a profile to post?" -Nostr Zoomer

Reply to this note

Please Login to reply.

Discussion

This breaks giftwrapps and other important ephemeral key use cases...

Hmm, not sure about this. Restricting profiles could make it harder for new users and might even create a FOMO effect for bad actors. A spam assassin-style approach seems better as a baseline. I use Ditto regularly to make 'good' profiles, and if that gets blocked, newer versions will be trickier for me to use.

https://en.wikipedia.org/wiki/Apache_SpamAssassin

This would kill anon posts. Maybe require pow for pubkeys without profile.

Not the ultimate solution at all

How would you restrict an event? Maybe on a relay that you control, but then anything not on your relay will subvert this control.

How do you globally restrict creation of a kind 0, or do you require it has to be created on your relay? Don't see this being a good strategy.