I like your ideas. BUT the reality is that zero popular Nostr clients allow mining events today to my knowledge. There’s no way to know how much PoW is required by a relay either other than mining and sending until it gets accepted. But we are connected to many relays… So now you would need PoW for every event to match the relay that requires the most PoW.

I really can’t run an experiment when there’s little support from clients.

At least public keys can be mined independently by users.

Reply to this note

Please Login to reply.

Discussion

Yes, hypothetically I guess in the future a sophisticated spammer would build their own client and wardial accepted pubkeys and use those pubkeys until they are exhausted.

I guess nobody follows spammer pubkeys, so spam is mostly a problem for General channels and discovery of new pubkeys to follow. My own feed has no spam, because I don’t follow any spammers.

Spam is also bad for new users as General channels and pubkey discovery are the main place for new users.

But you’re right, for noteID’s it would need to be the client doing the POW after the user hit send.

You’re also correct that for it to all work in a standardised way across the network it would have to be a part of the protocol.

I’ve proposed a solution for reducing spam on Global Feeds, such as Adaptive Proof of Work: https://observablehq.com/d/295d8a1c6f7b07f9

Perhaps there are simpler solutions but this one proposes using a Proportional-Integral-Derivative Controller (aka PID Controller) to tune the PoW required so that the rate of events stays under control. What it does is find the correct PoW required to maintain a reasonable rate of events (e.g. 1 event / 10 seconds).

PID Controllers are used to control robot limbs, dam gates, etc.

IMO it should only be applied to public keys that are detected to be abusing.

I was also proposing the idea of relays gossiping about spammers, once a relay considers an IP or pub key to be spamming, it sends an event including the pub key or hash of the IP and proof of the spam (merkle tree proof of event ids of the abuse) to other relays which can then be on alert. This didn’t get too much traction but I might implement something soon for Nostream relays… it will be opt-in of course.

Don’t forget aggregate PoW over time. I think it could be really useful for low hanging spam.