Discussion threads with Tombstones

[mnd]

Suppose we have one discussion thread:

{"type": "Note",
 "id": "https://chatty.example/alice/1",
 "attributedTo": "https://chatty.example/alice/",
 "to": ["https://www.w3.org/ns/activitystreams#Public"],
 "content": "Note Txt"}

{"type": "Note",
 "id": "https://chatty.example/bob/2",
 "inReplyTo": "https://chatty.example/alice/1",
 "attributedTo": "https://chatty.example/bob/",
 "to": ["https://www.w3.org/ns/activitystreams#Public", "https://chatty.example/alice/"],
 "content": "Comment 1"}

{"type": "Note",
 "id": "https://chatty.example/alice/3",
 "inReplyTo": "https://chatty.example/bob/2",
 "attributedTo": "https://chatty.example/alice/",
 "to": ["https://www.w3.org/ns/activitystreams#Public", "https://chatty.example/bob/"],
 "content": "Reply to the comment"}

Now if Bob decides to "Delete" his https://chatty.example/bob/2 activity then it will be impossible for Alice to connect her https://chatty.example/alice/1 and https://chatty.example/alice/3 Notes in a single thread.

As a side effect all replies to "https://chatty.example/alice/3" will be separated from original post and original readers will be lost for https://www.w3.org/TR/activitypub/#inbox-forwarding mechanism.

As far as I understand only solution for the described issue is to add "to", "cc", and "inReplyTo" to list of mandatory fields that Tombstone activity should inherit from Deleted Note.

[trwnh]

it could be done with only inReplyTo (which is the most widely supported way to handle threading), or with context (which isn't as widely supported for threading). of course, there's also the caveat that most implementations currently do not use Tombstone and instead just break the thread (unless threading is done with context instead of inReplyTo).

[mnd]

@trwnh thank you for a comment. Looks like that either ActivityPub should recommend context for threading and use this field for inbox-forwarding mechanism as well or it should add recommendation about inReplyTo inheritance for Tombstone objects.

[evanp]

We have a few mechanisms for retaining this information. One is the replies collection on Alice's original post, which may retain the Tombstone object's ID, or may remove it automatically on receipt of the Delete activity.

As mentioned above, the context for conversations would keep Alice's reply to the comment as part of the conversation, but might still disconnect it from the root.

I would say that it's a good idea to maintain a Tombstone object in the tree if it has replies, and possibly even if it doesn't have replies -- they may come in later.

This has to be balanced with the privacy of the creator of the Tombstone object. They deleted it for a reason, and probably want more of the metadata removed (publish date, inReplyTo, ...). So, time limits, or just being tolerant of holes in the tree may lean more towards the privacy of the deleter.

Mastodon's handling of replies and conversations might actually have some helpful patterns for this problem. Because it uses a search-style data storage (it shows only the posts visible from the current server, and doesn't fetch the replies or context collection from the original server), it has to deal with this kind of gap in the conversation tree all the time. UI and processing patterns may be useful.

[evanp]

I'm labelling this Needs FEP because it is greatly helped by https://w3id.org/fep/7888 .