The problem: when a brand new pubkey starts sending events, it can be difficult to tell immediately whether they are a legitimate user or spam.
Our solution: accept all new user notes temporarily in a separate database. As they send events, we continually evaluate their behavior based on several rules (and eventually by a trained model) and approve/block the pubkey.
If approved, all of their old events get added to our aggregator relay and the user is immediately discoverable. Their future notes will also go directly to the relay. If blocked, the events are sent to a purged database (for transparency and evaluation) and never reach our relay.
Still an early WIP but coming along! It doesn’t solve all the issues but it is a massive improvement on our current rules. nostr:note19kp6d4lmdjr8r0hn0uyx62jdreu5xcyxz7zm2pxwsrd6hcferdtqyx6nxp
This does not have anything to do with nostr.wine as it requires a payment to write and has yet to have any real spam issues!
This is all about our free relay aggregator and filter.nostr.wine.
Sounds like a new user would be invisible in the beginning. Sounds like a poor experience. Imagine coming to Nostr for the first time, putting out your initial #introduction, and getting ghosted by the platform.
First, this is just our aggregator and filter.nostr.wine - not anyone else’s relay. Nobody is forced to use our aggregator but keeping spam off of it long term is more important to us than a slight delay in brand new pubkey discoverability.
If that #introductions hashtag is filled with infinite spam, you also will never discover the new user.
The advantage of this over WoT based relays is as soon as the user reveals themselves to be legitimate (could be after just a few minutes of their original event) none of their old content is lost.
There is going to be some cost to being discovered as a brand new pubkey on an open protocol where there are no account creation limits. We think this solution is the least harmful.
That would only be in a scenario where some client onboards you to the wine filter relay? Thats not a thing. This would have to be something a user does purposefully to filter their view.
good idea. are you doing this in write policy or strfry c++ coding?
i was thinking of something similar with write policy but then Doug said async acceptance of notes is not possible.
We are using a write policy to send the notes to a separate application/db that handles the “purgatory” state. Then that application inserts events back to the relay as needed.
Would not be able to do it all within a write plugin.
so you first reject the notes. then accept in the second processing.
Yes, but the initial write plugin checks if that user was previously approved and if so auto accepts the note. So only “unknown” pubkey events are sent for secondary processing.
Oddbean new post about login | logout