You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently in both OStatus and ActivityPub, there is a "hole" in the deletion mechanism. The user story is something like:
User A posts a status to their followers (User B)
User B, who follows user A, "boosts" or "repeats" the status to their followers (User C)
User A deletes the original status and publishes a "delete" notification to their followers
User C, who follows User B but doesn't follow User A, does not see the delete activity.
(for simplicity, all users in this example live on different servers. "User A" could be used equivalently to refer to the class of users that share a server with User A)
What are possible solutions to this problem? After typing this up, I think one solution for ActivityPub is to say that, after receiving a Delete activity in an inbox, servers should either publish a delete for, or publish an Update with a Tombstone for, any activities in the corresponding outbox that reference that activity (or, in the case of the shared inbox, any activities the server knows about). But this doesn't solve the problem of passing along the original Delete activity.
The text was updated successfully, but these errors were encountered:
I'm not even sure there's user agreement (consensus?) on whether people want their reposts/boosts auto-deleted if the original is deleted. Nevermind holes in the protocol, it's not clear that the set of desirable user-behaviors have been explored / defined.
I definitely agree that people's boosts shouldn't be automatically deleted—especially in a system like e.g. a hypothetically federated Tumblr, where reblogs can contain original content. I tried to reflect that in the ticket by talking about "deleting or replacing with a Tombstone", which mirrors the spec's language in this area.
Currently in both OStatus and ActivityPub, there is a "hole" in the deletion mechanism. The user story is something like:
(for simplicity, all users in this example live on different servers. "User A" could be used equivalently to refer to the class of users that share a server with User A)
What are possible solutions to this problem? After typing this up, I think one solution for ActivityPub is to say that, after receiving a Delete activity in an inbox, servers should either publish a delete for, or publish an Update with a Tombstone for, any activities in the corresponding outbox that reference that activity (or, in the case of the shared inbox, any activities the server knows about). But this doesn't solve the problem of passing along the original Delete activity.
The text was updated successfully, but these errors were encountered: