 Question for #ActivityPub implementors: has there been any research on how to best handle deletions (accounts and/or posts)? At the moment, the best (and only?) way to know that an account deletion has been federated everywhere is to notify any known inbox / instance, for every account deletion. This is very wasteful and not efficient, are there any alternatives? Has anyone worked on this? 14 comments
@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. @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 it’s not more wasteful than posting. Which works fine. I don’t see the problem. @pkreissel you only broadcast posts to your followers. Account deletions are broadcasted to every known instance. @renchap Yes but account deletions are incredibly rare. The alternative would be to check every time you search an account on your instance to check if the account still exists. @pkreissel they may be rare most of the time, but when you mass-delete accounts after some bad actors actions, spam attempts or other events, you call generate a lot of them in a short time. For a real example, we had to delete about 3000 accounts, which created 3000*17000 outbound notifications. And this gets worse with more users/instances.  @renchap @pkreissel Perhaps there should be a "BulkDelete" notification: signed by the instances public key listing all the accounts to be deleted in that batch. Then a single notification only needs to go out to each known server which can do a quick "do I hold any records at all from (origin server)" before processing further. To make things more efficient, servers could batch delay sending deletes for 10mins.  @renchap I think sending Deletes just to followers is a decent solution, if combined with servers refreshing an actor every time it appears in an Activity or Object. Ie, if some server wants to send a Note to a bunch of recipients the server should refresh the actors, and then notify the user that they're trying to send the Activity to invalid actors for every received Tombstone (or even removing them all together from the recipients list).  In Smithereen I send account deletions to just that account's followers. But I also handle incoming deletions differently — for me, deleting an account doesn't mean also deleting all content. I keep their comments under others' posts but I anonymize them. |
Gregory's Server
For 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.