wakoinc on Nostr: I’m still working on Nostr spam detection and prevention - and ways the network can ...
I’m still working on Nostr spam detection and prevention - and ways the network can communicate and filter it out.
Been focused on event processing as the network has now 100x since I last focused on scaling. That’s almost happy - so I can focus on more innovating stuff.
Thoughts on perhaps a wss://spam.NostrGraph.net relay that only broadcasts 1984 events with a tag of spam_score (where the score is likely > 90%). It does mean each spam message triggers a 1984 message (or perhaps batched) - and this could be 1000s events/minute or more in future.
I drop spam now and don’t persist those events, so having a meta.spam_score on my API or relay published events to websockets is likely ok - but again perhaps not ideal.
I’m leading toward the approach of a relay service that can reject events. Similar to the authentication that checks if a pubkey has paid, it could be used to check if spam score is greater than a per relay threshold. Issue then is each relay needs this service with a model and the model needs to learn - or it will miss new spam formats.
Thoughts?
Published at
2023-02-19 13:22:36Event JSON
{
"id": "837749c013c3ce55bf810ed0b17bab129003f60b080760a746cf68fb8bfc64b9",
"pubkey": "b2dd40097e4d04b1a56fb3b65fc1d1aaf2929ad30fd842c74d68b9908744495b",
"created_at": 1676812956,
"kind": 1,
"tags": [],
"content": "I’m still working on Nostr spam detection and prevention - and ways the network can communicate and filter it out.\n\nBeen focused on event processing as the network has now 100x since I last focused on scaling. That’s almost happy - so I can focus on more innovating stuff.\n\nThoughts on perhaps a wss://spam.NostrGraph.net relay that only broadcasts 1984 events with a tag of spam_score (where the score is likely \u003e 90%). It does mean each spam message triggers a 1984 message (or perhaps batched) - and this could be 1000s events/minute or more in future. \n\nI drop spam now and don’t persist those events, so having a meta.spam_score on my API or relay published events to websockets is likely ok - but again perhaps not ideal.\n\nI’m leading toward the approach of a relay service that can reject events. Similar to the authentication that checks if a pubkey has paid, it could be used to check if spam score is greater than a per relay threshold. Issue then is each relay needs this service with a model and the model needs to learn - or it will miss new spam formats. \n\nThoughts?",
"sig": "004f84b09b1f389f2993574bfff4b7df1ae1260ce8027c113baf6f95f6971316cb49dde53b7417b2f911461bf773b3310cc8df0847953b9625cfcec42e9c00d2"
}