-
Notifications
You must be signed in to change notification settings - Fork 78
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
Comments
Mastodon's |
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 --
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 |
I think in terms of fallback-behaviour, it comes down to either Non-destructive I think another useful way to look at it is that |
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 My first note is as you point out the 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. |
This issue has been labelled as potentially needing a FEP, and contributors are welcome to submit a FEP on the topic. |
I want to capture a couple of ideas from issue triage so they don't get lost:
|
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. |
Right now, in practice,
Delete
ing 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.Delete
ing aNote
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 aDeactivate
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 anUndo
of theDeactivate
, 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 destructiveDelete
.) I don't particularly care about the nameDeactivate
. 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!
The text was updated successfully, but these errors were encountered: