Hey fellow nerds, I have an idea that Iā€™d like to discuss with you. All feedback ā€“ positive or negative ā€“ is welcome. Consider this a baby RFC (Request for Comments).

So. Iā€™ve been having a think on how to implement the right to be forgotten (one of the cornerstones of eg. the GDPR) in the context of federated services. Currently, itā€™s not possible to remove your comments, posts, etc., from the Fediverse and not just your ā€œhome instanceā€ without manually contacting every node in the network. in my opinion, this is a fairly pressing problem, and there would already be a GDPR case here if someone were to bring the ā€œeye of Sauronā€ (ie. a national data protection authority) upon us.

Please note that this is very much a draft and it does have some issues and downsides, some of which Iā€™ve outlined towards the end.

The problem

In a nutshell, the problem Iā€™m trying to solve is how to guarantee that ā€œwell-behavedā€ instances, which support this proposal, will delete user content even in the most common exceptional cases, such as changes in network topology, network errors, and server downtime. These are situations where youā€™d typically expect messages about content or user deletion to be lost. Itā€™s important to note that Iā€™ve specifically approached this from the ā€œright to be forgottenā€ perspective, so the current version of the proposal solely deals with ā€œmass deletionā€ when user accounts are deleted. It doesnā€™t currently integrate or work with the normal content deletion flow (Iā€™ll further discuss this below).

While I understand that in a federated or decentralized network itā€™s impossible to guarantee that your content will be deleted, but we canā€™t let ā€œperfect be the enemy of good enoughā€. Making a concerted effort to ensure that in most cases user content is deleted (initially this could even just be a Lemmy thing and not a wider Fediverse thing) when the user so wishes would already be a big step in the right direction.

I havenā€™t yet looked into ā€œprior artā€ except some very cursory searches and I had banged the outline of this proposal out before I even went looking, but I now know that eg. Mastodon has the ability to set TTLs on posts. This proposal is sort of adjacent and could be massaged a bit to support this on Lemmy (or whatever else service) too.

1. The proposal: TTLs on user content

  1. Every comment, post etc. (content) must have an associated TTL (eg. a live_until timestamp). This TTL can be fairly long, on the order of weeks or even a couple of months
  2. well before the contentā€™s TTL runs out (eg. even halfway through the TTL, with some random jitter to prevent ā€œthundering herdsā€), an instance asks the ā€œhome instanceā€ of the user who created the content whether the user account is still live. If it is, great, update the TTL and go on with life
    1. in cases where the ā€œhome instanceā€ of a content creator canā€™t be reached due to eg. network problems, this ā€œliveness checkā€ must be repeated at random long-ish intervals (eg. every 20 ā€“ 30h) until an answer is gotten or the TTL runs out
    2. information about user liveness should be cached, but with a much shorter TTL than content
    3. in cases where the userā€™s home instance isnā€™t in an instanceā€™s linked instance list or is in their blocked instance list, this liveness check may be skipped
  3. when content TTL runs out and a user liveness check hasnā€™t succeeded, or when a user liveness check specifically comes back as negative, the content must be deleted
    1. when a liveness check comes back as negative and the user has been removed, instances must delete the rest of that userā€™s content and not just the one whose TTL ran out
    2. when a liveness check fails (eg. the userā€™s home instance doesnā€™t respond), instances may delete the rest of that userā€™s content. Or I guess they probably should?
  4. user accounts must have a TTL, on the order of several years
    1. when a user performs any activity on the instance, this TTL must be updated
    2. when this TTL runs out, the account and all of its related content on the instance must be deleted
    3. instances may eg. ping users via email to remind them about their account expiring before the TTL runs out

2. Advantages of this proposal

  1. guarantees that user content is deleted from ā€œwell behavedā€ instances, even in the face of changing network topologies when instances defederate or disappear, hiccups in message delivery, server uptime and so on
  2. would allow supporting Mastodon-like general content TTLs with a little modification, hence why it has TTLs per content and not just per user. Maybe something like a refresh_liveness boolean field on content that says whether an instance should do user liveness checks and refresh the contentā€™s TTL based on it or not?
  3. with some modification this probably could (and should) be made to work with and support the regular content deletion flow. Something for draft v0.2 in case this gets any traction?

3. Disadvantages of this proposal

  1. more network traffic, DB activity, and CPU usage, even during ā€œnormalā€ operation and not just when something gets deleted. Not a huge amount but the impact should probably be estimated so weā€™d have at least an idea of what itā€™d mean
    1. however, considering the nature of the problem, some extra work is to be expected
  2. as noted, the current form of this proposal does not support or work with the regular deletion flow for individual comments or posts, and only addresses the more drastic scenario when a user account is deleted or disappears
  3. spurious deletions of content are theoretically possible, although with long TTLs and persistent liveness check retries they shouldnā€™t happen except in rare cases. Whether this is actually a problem requires more thinkifying
  4. requires buy-in from the rest of the Fediverse as long as itā€™s not a protocol-level feature (and thereā€™s more protocols than just ActivityPub). This same disadvantage would naturally apply to all proposals that arenā€™t protocol-level. The end goal would definitely be to have this feature be a protocol thing and not just a Lemmy thing, but one step at a time

3.1 ā€œItā€™s a feature, not a bugā€

  1. when an instance defederates or otherwise leaves the network, content from users on that instance will eventually disappear from instances no longer connected to its network. This is a feature: when you lose contact with an instance for a long time, you have to assume that itā€™s been ā€œlost at seaā€ to make sure that the usersā€™ right to forgotten is respected. As a side note, this would also help prune content from long gone instances
  2. content canā€™t be assumed to be forever. This is by design: in my opinon Lemmy shouldnā€™t try to be a permanent archive of all content, like the Wayback Machine
  • artificial_unintelligence@programming.dev
    link
    fedilink
    English
    arrow-up
    0
    Ā·
    1 year ago

    I like this idea, I think you could do some smart logic with non-responses to avoid spurious deletions. Like if any post from another instance responded recently, hold off. Iā€™m just imagining if a server had some downtime and suddenly their content in the fedi is gone

    • interolivary@beehaw.orgOP
      link
      fedilink
      English
      arrow-up
      1
      Ā·
      edit-2
      1 year ago

      Iā€™m just imagining if a server had some downtime and suddenly their content in the fedi is gone

      Yeah this is definitely a possibility, but if content TTLs that are a month or two and refreshing user account liveness starts happening much before the TTL of a content runs out (possibly even halfway through the TTL as I noted somewhere), an instance would have to be unreachable for up to a month (depending on the TTL of content / cached user account liveness info).

      But in general youā€™re definitely right that thereā€™s probably Smart Stuffā„¢ we could do regarding liveness checks to make spurious deletions as unlikely as humanly possible.

      Edit: I could also see having some sort of provision for ā€œreturning instancesā€, but no idea how this would work