How to delete an account at the protocol level?

[snarfed]

Hi all! Anyone know how account deletion - eg voluntary, by the account owner, not mod takedown - is supposed to work at the AT Protocol level?

If the answer is to deactivate the DID, are AppViews expected to discover that PLC operation and stop serving the entire account, including posts etc? What's a reasonable time period?

Or is the answer to serve a #tombstone over subscribeRepos?

Are either of these non-destructive? Could the account be undeleted later and used again with the same DID? If so, how? If not, is there a different way that's non-destructive?

Thanks in advance!

(Fwiw I naively tried deleting the app.bsky.actor.profile/self record, and that just removed the profile details but kept all of the account's data visible. Obvious in hindsight. 😆)

[bnewbold]

Roughly speaking, there are two types of explicit deletion:

PDS account deletion: this is what happens if you use the Bluesky app to delete an account.
The repository and all media blobs are deleted from the PDS, and the expectation is that downstream services (relay, appviews, etc) will respect this, though the exact mechanism and semantics are not fully fleshed out yet. This does not result in the identity being deleted by default, but in practical terms it may be hard or impossible to recover the identity, unless the account had transferred PLC control to new keys/services, or was using did:web with a self-controlled domain. It is generally not possible to "undelete" or recover the PDS account, as the password and email are not retained; this is not a "de-activation" or "soft delete". The current way to check if an account exists or has been deleted is to check the "head" of the repo and inspect the returned error name. For now, the #tombstone event can go out the firehose, though that will eventually be updated.

Identity deletion: results in the DID ending up in tombstone state. In theory this is permanent, but it can be reversed for did:web, and did:plc has a recovery window (currently 72hr) in which operations, including deletion, can be reversed. The semantics are somewhat distinct from a PDS account deletion, though the effects would be similar: downstream services would be expected to no longer serve, redistribute, or display/count repository contents or media blobs. The authoritative way to check the status of an identity is to resolve the identity; most DID methods (including PLC) have an explicit way to indicate "tombstone" status. did:web is more ambiguous, unfortunately.

Something to note is the distinction between "explicit deletion" and the hosting service just not being available. In general, a DID failing to resolve or a PDS being down do not mean the account has been deleted or that the identity has been deleted, and the network expectation in these cases is that content continues to be served.

We have planned work in a couple ways to make things less ambiguous:

• we plan to consolidate some existing firehose events in to #account (for account status at PDS or Relay, including new-account, deletion, deactivation), and #identity (for DID and handle updates, including PDS host migration). This is on the 2024 protocol roadmap
• relay (or a similar service) might actively and independently scan for identity events. for example, in most cases somebody might delete their identity (DID) via the PDS, which could then emit an #identity event. but the PDS might be broken, or a did:web involved, etc. The relay would be a good service in the network to look more aggressively for identity changes and blast those out over the firehose, so that downstream services don't all feel the need to endlessly poll for identity updates.
• give folks more accessible control over their identities, for example making it more ergonomic to add additional "recovery keys" to a PLC identity, help other orgs set up "identity escrow" relationships with users, etc
• likely need to establish norms, policies, and possibly partnerships around stewardship of "memorial accounts" for folks who have passed away
• dig in to policies and expectations around accounts where, despite best efforts, identity control and PDS server control are both lost. for example, server catches fire without backups. should those accounts stay up forever? similar to the queer.af situation in fediverse. atproto has several designed layers of abstraction to prevent that specific situation, but it is still possible to lose identity control, leaving zombie accounts lingering in the network.

For bridgy fed specifically (which I assume is what motivates your question), I think you should treat somebody "removing the bridge account" as a PDS account deletion on the atproto side, and should emit a #tombstone event for now, but be ready to switch to an #account event when we get that written up. If this doesn't result in the account disappearing from the bsky appview and app, i'm happy to help debug.

[bnewbold]

There has been a bit of recent work on the firehose #account and #identity events, by the way:
#2263

[bnewbold]

Another comment about the bridgy fed situation: my initial impression is that it would not be a big user expectation violation or against the spirit of protocol if the bridge "held on to" any DID PLC identities created, even after deleting/disabling the bridge, as long as the repo was deleted. Then if the bridge is re-enabled for the remote account, reuse the DID. Any pre-existing follows would "just work" in that situation (follows are pointers to a DID, they continue to exist if the account has been deleted).

It is a bit weird? And leaves the question of what to do if the relevant account requests access/control of the identity (DID). It would be sort of nice/comfy to hand off the DID to the user if the request can be verified, but that would require extra process/workflow, and it might be simpler to consider the bridge DIDs to be ephemeral. Either way, I would definitely not keep a pool and re-use DIDs.

[snarfed]

Thanks for all this! Sounds like #tombstone is what I was looking for here specifically, but you're right, lots more to think about all around. Glad you all have all the complexities in mind, as usual.

And yes, Bridgy Fed was the motivation, especially the hope for a "soft" delete that could be undone. For better or worse, the current UX is that users turn off (and ideally delete) their bridged account by blocking the bridge bot user. That's very easy to do, and easy to undo by unblocking and re-following, so I'm hoping to find a similarly easy way to undo account deletion.

Keeping the DID (just for that user) is definitely the right idea. I may start even lighter weight and keep the repo too. You're right that user expectations will range, and some people may expect/want the data deleted entirely, but others may want to re-enable later and have their bridged content intact. If I tombstone a repo, and then later start serving the same repo again, intact, I assume the relay and appview would be ok with that?

[snarfed]

Circling back here, I shipped #tombstone and it's working great so far. Thanks @bnewbold!