Gregory's ServerFor Mastodon @Claire had a go at using a bloom filter to restrict the list of instances we broadcast to (https://github.com/mastodon/mastodon/pull/22273), but this requires authenticated fetches for accounts, which prevents HTTP caching of those and might cause performance / scalability issues, and this is not ideal.
|
4 comments
 @JasonPunyon @Claire I am not sure how this would solve the issue of needing to broadcast it to every known server? There is not really a privacy problem here, as you reference a no-longer-existing account @renchap @Claire It's pointed out as a "minor" privacy concern that servers who've never seen the account before the delete now know about its previous existence. This fixes that. I don't know how you get around having to broadcast to every instance you know. That's kind of the way fedi is shaped. You can make it cheaper to do a lot of deletes (batch 'n' bloom, as i lay out in my other post), but a single delete is always gonna cost you a trip 'round the verse. @renchap @Claire I think good use of bloom filters would be when you want to batch those deletes. Now instead of sending a single SHA to delete, you put all the SHAs in an appropriately sized bloom filter and send that. 1000 deletes with a 1-in-a-trillion false positive rate is a 7KB filter. Instance2 receiving such a bloom filter delete from Instance1 would SHA all its local Instance1 actor ids and check them against the filter. If it gets a match it does the delete. |
@renchap @Claire What if instead of sending the raw actor id in a delete activity you send SHA256(actor id)? The deleted actor id would never be broadcast in the open, mitigating the privacy concern. Instance2 receiving a delete from Instance1 would SHA all its local Instance1 actor ids and if one of them matches, that's the one to delete.