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.

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

new Deactivate activity as an alternative to Delete #475

Closed
snarfed opened this issue Nov 1, 2024 · 7 comments
Closed

new Deactivate activity as an alternative to Delete #475

snarfed opened this issue Nov 1, 2024 · 7 comments

Comments

@snarfed
Copy link

snarfed commented Nov 1, 2024

Right now, in practice, Deleteing an actor has destructive side effects that can't be easily undone, notably severing all follower relationships. I dealt with this recently in snarfed/bridgy-fed#1379 ; not fun. Deleteing a Note or other object may have similarly destructive side effects; not sure.

These side effects are mostly unspecified in ActivityPub or ActivityStreams afaik; background in #472. Ideally, we should specify them. But also, I wonder if we want a different activity that's less destructive and/or easy to undo. For actors at least, maybe call it Deactivate. If a server receives a Deactivate for a remote actor, it could hide (aka tombstone) that actor and their posts and other activities, but not delete their local copy or take any other destructive actions like irreversibly removing follow relationships. If it later gets an Undo of the Deactivate, it could easily remove the tombstone and show the actor and their posts and activities again, and re-activate the existing follow relationships.

I'm flexible on most of the details here. If we instead choose to specify Delete to be non-destructive, that obviates the need for this. (But we may still want a destructive Delete.) I don't particularly care about the name Deactivate. I'm open to how it would be undone, which specific things could be undoable or not. (But ideally as many as possible.)

Thanks for reading!

@snarfed
Copy link
Author

snarfed commented Nov 1, 2024

Mastodon's suspended flag is related.

@trwnh
Copy link

trwnh commented Nov 2, 2024

I think that in an alternate universe, we could have said from the start that Delete is always nondestructive, i.e. the side effect of issuing a Delete ought to have been the conversion of the object to a Tombstone. To destructively drop all information, you could issue a Delete Tombstone.

In a different alternate universe, we could have said that there is a flag on the Delete activity indicating whether the Delete should leave behind a Tombstone or not.

Failing that, in our current universe, it might make sense to define a FEP for an activity that explicitly leaves behind a Tombstone while preserving the original data. I don't know what to call such an activity -- ConvertToTombstone? or do we retool Delete as you mention? -- but we definitely need to have two classes with different behaviors here:

  • a "soft delete".
    • Side effect: Convert the resource to a Tombstone.
    • Side effect: Keep the original data around (where?) so that you can Undo it later.
  • a "hard delete".
    • Side effect: Irreversibly drop the data associated with the resource.

There's actually a separate consideration here, which is: what is the behavior of a Tombstone? Some implementations might make use of Tombstone to prevent re-use of identifiers, which seems to conflict with the use of Tombstone as a marker for a "soft delete".

Taking a step back, there's also another angle -- do we need to be looking at this use-case from the perspective of Delete at all? As you point out, Mastodon actually uses an Update activity to set or unset the suspended flag. Could this not be used as-is? Have the actor Update their own actor (or profile or whatever) to set or unset the flag, instead of making it a dedicated activity. Perhaps a FEP might define a different flag such as active instead, since "suspended" carries negative connotation.

@Tamschi
Copy link

Tamschi commented Nov 2, 2024

I think in terms of fallback-behaviour, it comes down to either Delete with a flag to be non-destructive or Update-Actor with "…#active": false, depending on which is preferable on non-supporting instances.
Stand-alone Deactivate would essentially be a no-op on non-supporting instances and combining Update+Deactivate (to adjust baseline profile fields to indicate deactivation) would be prone to implementation differences regarding message ordering.

Non-destructive Delete would be useful if hiding content is more important than non-destructiveness, but personally I'd prefer if my instance just responded to most fetches with a status 403 (Forbidden) and edited my display name to say "(deactivated)" on non-supporting instances. Since that text should never show up on supporting instances, de-/activation would have to be atomic with Update-Actor. The latter works better with an "…#active": false flag and that also lends itself well to lookups (indicating that the account exists but ).

I think another useful way to look at it is that "…#active": false could fall back to "…#suspended": true on non-supporting instances if both are published on an Actor. The FEP would have to say that "…#active": false ꜱʜᴏᴜʟᴅ take precedence over "…#suspended": true when encountered externally. It would be the publishing instance's choice which it prefers between still-visible content and the negative connotation of "suspended".

@evanp
Copy link
Collaborator

evanp commented Nov 8, 2024

So, the first response I have to this is that I really appreciate the structuring of this issue. Adding a new activity type to define the changed behaviour is a good way for us to gradually make changes to the Fediverse in a backwards-compatible way. After this new activity is defined and widely implemented, we can find ways to deprecate (if needed) the use of Delete with an actor.

My first note is as you point out the suspended property already exists. I believe that Mastodon uses and Update activity with the suspended property as a boolean true value. If we were to define a new activity, Suspend might be a good verb to use, for parallelism.

Regardless, I believe the next steps for this process are creating and debating a FEP for the extension term. Once it is defined and in use, we can use the extension policy to add it to the Activity Streams 2.0 context.

Copy link

github-actions bot commented Nov 8, 2024

This issue has been labelled as potentially needing a FEP, and contributors are welcome to submit a FEP on the topic.
Note that issues may be closed without the FEP being created; that does not mean that the FEP is no longer needed.

@evanp
Copy link
Collaborator

evanp commented Nov 8, 2024

I want to capture a couple of ideas from issue triage so they don't get lost:

  • Properties on the actor, like suspended, are more useful than an activity that goes past and is later is forgotten. Consumers can still get the suspended status without having received the activity.
  • We can also use dual-typed activities.

@evanp
Copy link
Collaborator

evanp commented Nov 29, 2024

So, this has been labelled need-fep for a few weeks; the next step is to create a FEP for the new syntax. I'm going to close this issue, but it is still wanted and needed as a FEP.

@evanp evanp closed this as completed Nov 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants