Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

AP => AT: translate Delete actor to delete instead of deactivate #1464

Open
Tamschi opened this issue Nov 10, 2024 · 7 comments
Open

AP => AT: translate Delete actor to delete instead of deactivate #1464

Tamschi opened this issue Nov 10, 2024 · 7 comments
Labels
now parity Features supported by two or more protocols, but not yet bridged between them.

Comments

@Tamschi
Copy link
Collaborator

Tamschi commented Nov 10, 2024 •
edited
Loading

If I'm not mistaken, this regressed somewhat as part of the fix for #1130.

When Bridgy Fed receives a Delete for a currently or formerly(!) bridged account, it should mark the account as deleted towards Bluesky rather than just deactivating it, in order to fully purge content from Bluesky's cache.

This process should also disassociate the AT DID from the AP account to an extent, so that a new DID is assigned when an account with the same id is bridged later on (after a timeout of ideally several days to account for AP activity shuffling and potentially bugfix operations).

The Bluesky handle shouldn't necessary be invalidated immediately, but should be open to reassignment for the next bridged AP account with the same handle.

(Deletions have a grace period on Bluesky afaik, so destructive bugs in this function would still be fully recoverable for a few days at least. Longer deletion-durations may lose bridged posts and other activities on Bluesky.)

Related to #1462 (comment).
@Tamschi Tamschi added the parity Features supported by two or more protocols, but not yet bridged between them. label Nov 10, 2024
@snarfed
Copy link
Owner

snarfed commented Nov 10, 2024

Understood! Thanks for filing.

I don't know much about deleting your account as a user on the main PDS, but I expect much of that behavior, eg any grace period, is on the PDS, not the appview.

The only real levers we have for the relay/appview are #account (active=false, status=deleted) and #tombstone (deprecated) events: #1440. Sadly Bluesky haven't documented #account events yet, specifically which are undoable and which purge data from relay/appview. We'd need that before we could realistically do anything here. I'll ask them for that.

@snarfed snarfed added the now label Nov 10, 2024
@Tamschi
Copy link
Collaborator Author

Tamschi commented Nov 10, 2024

I'm fairly sure #account (active=false, status=deleted) is the correct one here.
I just keep forgetting in which issue someone posted an overview of all the different options and behaviour.

@Tamschi
Copy link
Collaborator Author

Tamschi commented Nov 10, 2024 •
edited
Loading

It was #1119. Seems like that was much less definitive than I thought.

@snarfed
Copy link
Owner

snarfed commented Nov 10, 2024

Hah sorry yes #1119! I like the wrong one earlier.

Sadly not official though, and doesn't confirm reversibility, data deletion, etc. I'll ask.

@snarfed
Copy link
Owner

snarfed commented Nov 11, 2024

Asked in bluesky-social/atproto#2592 (comment)

@snarfed
Copy link
Owner

snarfed commented Nov 11, 2024

Got a response: bluesky-social/atproto#2592 (reply in thread). Asked for something a bit more explicit; we'll see.

We are still debating how prescriptive to be about this. Eg, to some degree this kind of behavior isn't even observable, so compliance with the spec can't be verified externally. We also want to leave wiggle room for implementations to make their own decisions.

We probably will specify that none of the account statuses are truely permanent. They are also generally only "hop by hop": account statuses probably only apply at any specific service, they are not truely network-wide. Eg, can account can be deleted on one PDS, but pop back up (same identity/DID) on a different PDS.

As a rough guide, deactivated and suspended are more temporary and the best practice would be to not purge data on downstream services. deleted and takendown are somewhat more permanent (though reversible!), and purging data would be recommended, possibly after some time delay (eg, 24 hours; not going to be specified in the protocol).

@snarfed snarfed changed the title AP => AT: Delete bridge account on account Delete AP => AT: translate Delete actor to delete instead of deactivate Nov 11, 2024
@snarfed
Copy link
Owner

snarfed commented Nov 29, 2024

Internally, I'd probably do this with a new, non-standard deactivate AS1 verb. Tricky though because I'd need to handle it to everywhere I currently look for the delete verb, at least for actors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
now parity Features supported by two or more protocols, but not yet bridged between them.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Tamschi @snarfed