Question for #ActivityPub implementors: has there been any research on how to best handle deletions (accounts and/or posts)?
-
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?
-
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.
-
Hi @[email protected]! Discussion regarding this resurfaces from time to time, and it mostly centres around how noisy the deletion process is, as you've alluded to in your post.
I wrote up a small update regarding how NodeBB handles deletes via ActivityPub, perhaps it may help.
End of the day ensuring that a deletion is fully propagated is probably futile. I personally believe that all instances should handle remote actor data like a cache, and clear it regularly. That means if account data is stale and a re-fetch results in a
Tombstoneor410 Gone, then the account should be scrubbed. -
@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.
-
mariusreplied to Renaud Chaput on last edited by [email protected]
@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).
-
@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
-
@[email protected] @[email protected]
Agreed with Julian. In case you haven't noticed, the number of instances in the fediverse is growing. Sending any message to all of them doesn't scale or slowly eats at the minimum requirements for a node to participate. Most of our members use pocket servers or shared hosting for friends and family -- or just personal sites. We certainly don't want them sending something to every known instance in the fediverse, but we also don't want them to be on the receiving end of these posts. Having the elephant in the room trample our little communities with hundreds/thousands of deletions per hour for accounts they've never seen before is a contentious issue on our side of the fediverse -- and we currently have tools to turn off ActivityPub completely so they can still function.
Since I'm moving everything to ActivityPub and phasing out Nomad and Zot - this means that I will need to provide a way to block traffic from Mastodon instead. This is in fact what I'm currently doing; so that their little personal and family servers have a chance to survive and do what we've always done - which is sharing stuff amongst family and a few close friends. -
Renaud Chaputreplied to Mike Macgirvin 🖥️ on last edited by
@mikedev @julian Yes, I am well aware of this and this is the goal of this message: trying to see how things can be improved in ActivityPub. And to be clear, this is not a Mastodon-specific problem.
An issue with not federating deletes to non-follower instances is that your profile might have been cached there, and if you request deletion of your account, you want it to disappear from anywhere in a timely manner (for example, GDPR might be involved). -
@mikedev @julian This is why it works this way right now. Followers are immediately notified, and other servers are notified with a low priority, over time. You could rely on remote servers periodically refetching accounts, but then:
- not every ActivityPub implementation does it
- those refreshes create a lot of useless messages as well
At the moment, Mastodon refreshes accounts weekly *if we receive activity from them*, but that does not solve federating the deletion of inactive accounts -
@[email protected] in terms of GDPR it would be really helpful if we could get a subject matter expert's view on whether all copies everywhere must be deleted to satisfy GDPR's right to be forgotten.
That's kind of an impossible ask, even with federating deletes to all known instances. Not to mention @[email protected]'s concern re: small servers.
I would wager that if the account and it's content were deleted from the origin account, and a best effort attempt to federate that delete were made, then that's the most you can reasonably expect.
-
@julian @renchap @mikedev not a GDPR expert but does GDPR have anything to say about what any given agent caches locally? it seems ridiculous to say that GDPR reaches that far. if i visit your website and my browser caches it and i never clear my cache... surely that's not your fault. i would assume that any "right to be forgotten" would have to be lobbied at *me* if I republished that webpage (and you could prove ownership of it, legally speaking)
