FEP-4f05: Soft Deletion
-
What would happen if you receive a
Deletefor an object that you believe to have been soft deleted, but now it shows up as an object instead of aTombstone? Like, it was undeleted by the time you receive theDeleteor something?Likewise, you receive an
Undo(Delete)and when you fetch the referenced object, it returns back aTombstoneinstead of the object?It'd be good to document those cases, because I think the answers are:
- If you receive a
Deleteand the object returns an object, not a 410 / 404 orTombstone, then you discard theDelete - If you receive an
Undo(Delete)and the object returns a 404, 410 orTombstone, then you discard theUndo(Delete)
Hi Emelia, thanks for the second pair of eyes on this.
I will amend the FEP with those behaviours. It makes sense that no action be taken if the backreference check fails.
Secondly, on re-read of my own FEP it is unclear that a backreference call is to be made, so I will need to make it clearer as well.
- If you receive a
-
Hi Emelia, thanks for the second pair of eyes on this.
I will amend the FEP with those behaviours. It makes sense that no action be taken if the backreference check fails.
Secondly, on re-read of my own FEP it is unclear that a backreference call is to be made, so I will need to make it clearer as well.
I have amended the FEP with an "Unexpected Responses" section.
Of note, it's less so that you discard the activity, but since you already made the request, you may as well go through with what you received back.
So if you get a
Deleteand a backreference shows the object alive and well, then just process it as anUpdateif you so wish. -
Hi all,
Some discussion regarding NodeBB's handling of soft deleted posts and Discourse's parallel implementation prompted the creation of this FEP, which attempts to describe how the concept of soft deletion can be published without the introduction of new activities—using
as:Deleteas-is and relying on a backreference check for Tombstone in order to signal a soft delete.https://codeberg.org/fediverse/fep/src/branch/main/fep/4f05/fep-4f05.md
Hi @devnull
this regards soft deletion + context collections (as a collection of posts). This topic started at
https://codeberg.org/silverpill/feps/issues/19
I'm curious what should happen if the context contains three elements
ap-obj,reply, andreply2.reply2is a reply ofreply. Nowreplyis deleted. How many elements does the context then contain?@silverpill said that for mitra the context would contain 1 element
ap-obj.The scenario as Gherkin:
Background: Given A new user called "Alice" And A new user called "Bob" And An ActivityPub object called "ap-obj"Scenario: Reply to reply with parent reply deleted Given "Alice" replied to "ap-obj" with "Nice post!" as "reply" And "Bob" replied to "reply" with "Good point!" as "reply2" When "Alice" deletes "reply" Then For "Alice", the "context" collection of "ap-obj" contains "?" elements -
Hi @devnull
this regards soft deletion + context collections (as a collection of posts). This topic started at
https://codeberg.org/silverpill/feps/issues/19
I'm curious what should happen if the context contains three elements
ap-obj,reply, andreply2.reply2is a reply ofreply. Nowreplyis deleted. How many elements does the context then contain?@silverpill said that for mitra the context would contain 1 element
ap-obj.The scenario as Gherkin:
Background: Given A new user called "Alice" And A new user called "Bob" And An ActivityPub object called "ap-obj"Scenario: Reply to reply with parent reply deleted Given "Alice" replied to "ap-obj" with "Nice post!" as "reply" And "Bob" replied to "reply" with "Good point!" as "reply2" When "Alice" deletes "reply" Then For "Alice", the "context" collection of "ap-obj" contains "?" elementsHey Helge.
Per my understanding, when processing a deletion of
reply, you would not presume deletion of any or all downstream objects. Only the referenced object is deleted.Deleting multiple objects at once would require multiple activities, or perhaps a single (and as-yet undefined) "batch" style activity.
-
It is not about deleting the objects, it's about if they are in the context collection or not.
If I understand you correctly, we would have before Alice deletes her reply
context[ap-obj] = [ap-obj, reply, repl2]and
context[ap-obj] = [ap-obj, repl2]afterwards
-
It is not about deleting the objects, it's about if they are in the context collection or not.
If I understand you correctly, we would have before Alice deletes her reply
context[ap-obj] = [ap-obj, reply, repl2]and
context[ap-obj] = [ap-obj, repl2]afterwards
Yes, that's correct. Deletion of one object will not affect membership of downstream objects in the context collection.
-
-
Hi all,
Some discussion regarding NodeBB's handling of soft deleted posts and Discourse's parallel implementation prompted the creation of this FEP, which attempts to describe how the concept of soft deletion can be published without the introduction of new activities—using
as:Deleteas-is and relying on a backreference check for Tombstone in order to signal a soft delete.https://codeberg.org/fediverse/fep/src/branch/main/fep/4f05/fep-4f05.md
Hi!
Sorry for being late to the party.
I understand the need to be able to undo deletions, this is something we face at Mastodon for the edge case of appealing moderation decisions (currently, most moderation decisions can be reversed upon appeal, but not post deletion).
I have some concern with the FEP as it stands regarding performances, and ensuring consistency wrt. chronology of events, caching and possible out-of-order activities.
Indeed, performance-wise, the FEP asks recipients of a \
Delete\to fetch the object that has just been deleted. This means that for a post that has, over its lifetime, reached a thousand different servers, in addition to ideally reaching all of those servers again (either directly or through inbox forwarding), the authoring server must now handle all of these servers fetching the now-deleted post all at once. I fear this is an especially bad instance of the thundering herd issue.As for ensuring consistency wrt. chronology of events, we face a lot of challenges:
- depending on their architecture, servers may emit outgoing activities (or process incoming ones) out-of-order (for instance, Mastodon queues jobs into work queues, but if there are multiple workers, a later job can finish before an earlier job does)
- due to network failures, servers may fail to deliver an activity on time and retry later
- due to caching (e.g. Mastodon offers short-time caching on reverse proxies, but does not invalidate the reverse-proxy cache when the resource is changed), fetched data might actually be older than just-delivered data
The ActivityPub primer makes note of this but offers no solutions besides “The receiving server, if it receives an activity that refers to an unknown activity, should store that activity for later processing.” While this is relatively easy to do when an object cannot be brought back once it’s deleted, this breaks done if you can undo the \
Delete\, and I have seen no solution offered for that in the current FEP.Using \
published\in activities and \published\/\updated\or similar in objects might help with that, but I’m afraid this might not be enough because of the seconds resolution of \xsd:Datetime\(and it would require extra care that the lifecycle of an object is indeed serialized with a monotonic time). -
undefined julian@activitypub.space shared this topic
-
Hi!
Sorry for being late to the party.
I understand the need to be able to undo deletions, this is something we face at Mastodon for the edge case of appealing moderation decisions (currently, most moderation decisions can be reversed upon appeal, but not post deletion).
I have some concern with the FEP as it stands regarding performances, and ensuring consistency wrt. chronology of events, caching and possible out-of-order activities.
Indeed, performance-wise, the FEP asks recipients of a \
Delete\to fetch the object that has just been deleted. This means that for a post that has, over its lifetime, reached a thousand different servers, in addition to ideally reaching all of those servers again (either directly or through inbox forwarding), the authoring server must now handle all of these servers fetching the now-deleted post all at once. I fear this is an especially bad instance of the thundering herd issue.As for ensuring consistency wrt. chronology of events, we face a lot of challenges:
- depending on their architecture, servers may emit outgoing activities (or process incoming ones) out-of-order (for instance, Mastodon queues jobs into work queues, but if there are multiple workers, a later job can finish before an earlier job does)
- due to network failures, servers may fail to deliver an activity on time and retry later
- due to caching (e.g. Mastodon offers short-time caching on reverse proxies, but does not invalidate the reverse-proxy cache when the resource is changed), fetched data might actually be older than just-delivered data
The ActivityPub primer makes note of this but offers no solutions besides “The receiving server, if it receives an activity that refers to an unknown activity, should store that activity for later processing.” While this is relatively easy to do when an object cannot be brought back once it’s deleted, this breaks done if you can undo the \
Delete\, and I have seen no solution offered for that in the current FEP.Using \
published\in activities and \published\/\updated\or similar in objects might help with that, but I’m afraid this might not be enough because of the seconds resolution of \xsd:Datetime\(and it would require extra care that the lifecycle of an object is indeed serialized with a monotonic time).Regarding the performance issue, and avoiding the thundering herd problem, one could simply embed the object itself (so, a
Deletewith an expandedTombstoneinobject) into the activity. You could additionally sign it (LD Signature) or attach a proof (Object Integrity Proofs) if necessary.As for sub-second resolution of
updated/published... isxsd:Datetimerequired? I've honestly just been sending ISO Strings, which include millisecond-level accuracy. -
@claire@social.sitedethib.com I re-read the text of the FEP and noted the following:
> When a Delete activity is encountered, the referenced object MAY be either the full object or a reference to one.
>
> If object is a reference, the server MUST request the object (via its id) from the origin server directly.Emphasis is mine. In situations where you choose to embed the full object in the activity, then you are not bound by the
MUSTto refetch the object.Now, when talking about hard deletes, you cannot literally embed a non-existent object, so a re-fetch would be necessary, although I am hoping that 404 handlers are a great deal faster.
I like
published. I can add that in to the FEP if it makes it easier to handle situations where multiple Deletes and Updates are encountered out-of-rder due to network congestion, parallel processing, etc.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@claire@social.sitedethib.com I re-read the text of the FEP and noted the following:
> When a Delete activity is encountered, the referenced object MAY be either the full object or a reference to one.
>
> If object is a reference, the server MUST request the object (via its id) from the origin server directly.Emphasis is mine. In situations where you choose to embed the full object in the activity, then you are not bound by the MUST to refetch the object.
Now, when talking about hard deletes, you cannot literally embed a non-existent object, so a re-fetch would be necessary, although I am hoping that 404 handlers are a great deal faster.
I like published. I can add that in to the FEP if it makes it easier to handle situations where multiple Deletes and Updates are encountered out-of-rder due to network congestion, parallel processing, etc.
-
Regarding the performance issue, and avoiding the thundering herd problem, one could simply embed the object itself (so, a Delete with an expanded Tombstone in object) into the activity. You could additionally sign it (LD Signature) or attach a proof (Object Integrity Proofs) if necessary.
As for sub-second resolution of updated/published... is xsd:Datetime required? I've honestly just been sending ISO Strings, which include millisecond-level accuracy.
-
Hi!
Sorry for being late to the party.
I understand the need to be able to undo deletions, this is something we face at Mastodon for the edge case of appealing moderation decisions (currently, most moderation decisions can be reversed upon appeal, but not post deletion).
I have some concern with the FEP as it stands regarding performances, and ensuring consistency wrt. chronology of events, caching and possible out-of-order activities.
Indeed, performance-wise, the FEP asks recipients of a \Delete\ to fetch the object that has just been deleted. This means that for a post that has, over its lifetime, reached a thousand different servers, in addition to ideally reaching all of those servers again (either directly or through inbox forwarding), the authoring server must now handle all of these servers fetching the now-deleted post all at once. I fear this is an especially bad instance of the thundering herd issue.
As for ensuring consistency wrt. chronology of events, we face a lot of challenges:
depending on their architecture, servers may emit outgoing activities (or process incoming ones) out-of-order (for instance, Mastodon queues jobs into work queues, but if there are multiple workers, a later job can finish before an earlier job does)due to network failures, servers may fail to deliver an activity on time and retry laterdue to caching (e.g. Mastodon offers short-time caching on reverse proxies, but does not invalidate the reverse-proxy cache when the resource is changed), fetched data might actually be older than just-delivered dataThe ActivityPub primer makes note of this but offers no solutions besides “The receiving server, if it receives an activity that refers to an unknown activity, should store that activity for later processing.” While this is relatively easy to do when an object cannot be brought back once it’s deleted, this breaks done if you can undo the \Delete\, and I have seen no solution offered for that in the current FEP.
Using \published\ in activities and \published\/\updated\ or similar in objects might help with that, but I’m afraid this might not be enough because of the seconds resolution of \xsd:Datetime\ (and it would require extra care that the lifecycle of an object is indeed serialized with a monotonic time).
-
-
Yes, that's correct. Deletion of one object will not affect membership of downstream objects in the context collection.
-
It is not about deleting the objects, it's about if they are in the context collection or not.
If I understand you correctly, we would have before Alice deletes her reply
context[ap-obj] = [ap-obj, reply, repl2]and
context[ap-obj] = [ap-obj, repl2]afterwards
-
Hey Helge.
Per my understanding, when processing a deletion of reply, you would not presume deletion of any or all downstream objects. Only the referenced object is deleted.
Deleting multiple objects at once would require multiple activities, or perhaps a single (and as-yet undefined) "batch" style activity.
-
Hi @devnull
this regards soft deletion + context collections (as a collection of posts). This topic started at
https://codeberg.org/silverpill/feps/issues/19
I'm curious what should happen if the context contains three elements ap-obj, reply, and reply2. reply2 is a reply of reply. Now reply is deleted. How many elements does the context then contain?
@silverpill said that for mitra the context would contain 1 element ap-obj.
The scenario as Gherkin:
Background: Given A new user called "Alice" And A new user called "Bob" And An ActivityPub object called "ap-obj"Scenario: Reply to reply with parent reply deleted Given "Alice" replied to "ap-obj" with "Nice post!" as "reply" And "Bob" replied to "reply" with "Good point!" as "reply2" When "Alice" deletes "reply" Then For "Alice", the "context" collection of "ap-obj" contains "?" elements