-
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
Clarify 'Delete' activity re unwinding side effects #472
Comments
So, I think this is a really good issue. I have a few thoughts on the topic. First, I don't think the concern about side effects is quite as severe for content types like The second issue is that I don't think deleting the activity is the preferred way to undo its side effects; they would normally be handled with an |
I'll take the rest in order, but I think these should probably go to the Primer.
Nothing. It remains how it is.
Great question! I think a best practice by the server that hosts the actor object is to send out undos for all the relevant actions (Undo Follow, Undo Like, ...). It could even send out Delete's for created object, Undo's for Announce activities, etc. That said, it's a real big lift, and I don't think anyone does this right now.
With the API, your server should reject it.
Yeah, I don't think it's even meaningful to talk about deleting a hashtag. It's kind of a global numinous object that nobody owns; it's like deleting an idea or a category.
It works the same as deleting any other actor. I'm going to try capturing some of these ideas to the Primer. |
We think that at least the question of deleting an actor should be addressed in the main spec. |
Bob Wyman points out that for many applications, deleting an actor is overkill, and would be really deleterious to the fabric network. For example, in a marketplace application, it would be a real big problem if the seller in a transaction deleted their account. |
(Big thanks to
@hrefna
for raising this issue). To quote/paraphrase:Many Activities in AP have complicated (and sometimes recursive) side effects. The specs (and Best Practices docs) on the Delete activity need to address how Delete interacts with unwinding side effects. For example:
Delete{Create{object}}
? Does the object go away?Delete{Create{object}}
if someone has acted on the object other than the entity who has Created it? Especially if there are multiple creators or if the attributedTo is different from the actor?Delete{Object}
what happens to Create for that object?Create{Note{attributedTo: user1}, actor: user1}
Update{Note}
(indicating that the attributedTo has been changed to user2, which I don't think is forbidden by the spec)Delete{Create{Note{attributedTo: user2}, actor: user1}, actor: user1}
.The text was updated successfully, but these errors were encountered: