Föderation EN Sa 04.01.2025 23:22:57 I’ve just stumbled into another annoyance in the #Fediverse architecture: thread continuity is broken when an item in the chain is broken. Suppose there is this thread of posts/replies, made by three users, and I wrote the last reply (C). A → B → C Suppose I wanted to find post A. Sadly, I don’t remember what post A contained (or A’s post is not searchable), but I do remember what I wrote in response in C. I look for my reply and find it, but much to my dismay, the poster of B has deleted their post. So now I have: A → ✵ → C Since B is missing, I can no longer find A. I was under the assumption that ActivityPub provides for a tombstone in place of B, which allows the reply chain to continue to be traversed, but I don’t think that’s the case—the tombstone contains no reference to A at all. This is particularly annoying because the longer the thread, the more likely this is to happen. I wonder if anyone is already looking at this issue? Edit: issue filed: https://github.com/mastodon/mastodon/issues/33456 |
Föderation EN Sa 04.01.2025 23:30:02 @drahardja this happens in twitter too but it may just be older threads — and yes twitter is not mastodon but possibly social media in general has common problems |
Föderation EN Sa 04.01.2025 23:31:14 @knf100 Hmm, that’s unfortunate, because there should be no reason for a monolithic social media platform like twitter to do that! |
Föderation EN Sa 04.01.2025 23:43:44 @drahardja @knf100 True, you would think it was simpler to solve with everything under one roof. Feels more complicated with fediverse, maybe C should actually have reference to A too (all in the chain above). I guess you could have a situation where all are deleted, but that’s even more edge case. |
Föderation EN Sa 04.01.2025 23:51:50 @derf @knf100 If C had a reference to A you’d have each post in the chain accumulating more and more references, which would be quite wasteful. I think keeping metadata in tombstones to allow traversal would be a good start. Sure, servers can go down and take tombstones with them, but I hope that would be a much rarer occurrence. |
Föderation EN So 05.01.2025 01:00:32 @drahardja @derf @knf100 Assign a new thread id to a non-reply. Copy it in replies. This way you'd at least have the thread somehow. In addition you could have a reference chain (possibly truncated to at most n, possibly just hashes, to save space), so in most cases you'd have structure preserved. |
Föderation EN So 05.01.2025 00:09:56 @drahardja It all starts here: |
Föderation EN So 05.01.2025 00:19:19 @dgoldsmith I think this is an ActivityPub issue and not a Mastodon one, but I will write an issue and see how it goes. |
Föderation EN So 05.01.2025 00:21:10 @drahardja @dgoldsmith Oh, I hate this so much, yes!! |
Föderation EN So 05.01.2025 00:22:12 @drahardja Mastodon works on changes to ActivityPub to support user-requested features. Right now they're working on an ActivityPub proposal to support reply controls. |
Föderation EN So 05.01.2025 10:01:16 @drahardja it's not an ActivityPub issue. In the ActivityStreams vocabulary a inReplyTo property for an object can contain the entire list for the replies in the chain. My service uses that to allow it to do easy reply threading. Mastodon however breaks when encounters a list in the property. I think the working group on threaded conversations in the fediverse has reached the same conclusion as I did, when sending a reply, you should include the links to all its parents and grandparents as their inReplyTo. |
Föderation EN So 05.01.2025 10:19:42 @mariusor @dgoldsmith Hmm, I don’t see an array as an allowable value type for inReplyTo, and I’m wary of storing a large number of references to replied posts rather than a linked list, but it would certainly be more robust to broken intermediate posts. |
Föderation EN So 05.01.2025 10:33:27 @drahardja in that documentation the properties which can receive a single value are marked as "Functional: true" (you can check the ID property for an example). The inReplyTo is not functional: https://www.w3.org/TR/activitystreams-vocabulary/#dfn-inreplyto |
Föderation · So 05.01.2025 13:32:00 @mariusor@metalhead.club @drahardja@sfba.social @dgoldsmith@mastodon.social the threaded discussions working group has settled on using resolvable contexts to get around the deficiencies of inReplyTo travertine achieve topic backfill. See FEP 7888 |
Föderation EN So 05.01.2025 04:27:31 |
Föderation EN So 05.01.2025 04:55:57 (Medien: 1) |
Föderation EN So 05.01.2025 01:04:40 @drahardja I just searched the @Mastodon |
Föderation EN So 05.01.2025 03:02:27 |
Föderation EN So 05.01.2025 01:18:00 @drahardja Pure speculation: I wonder if this was a deliberate design choice, where the developers were concerned about thwarting hostile edge cases. Imagine this reply chain (A→B→C): If B is deleted (either voluntarily or by moderation), if C's reply still appeared in the thread, it might seem like an unwarranted response to A (thus feeding the fire). I don't know if my speculation is correct, and would be curious to learn the history in any case. But that's the rationale that occurred to me. |
Föderation EN So 05.01.2025 03:05:26 @marilyn I don’t think it’s intentional, because if B were deleted there should be a tombstone in its place (i.e. “This post was deleted”), so it should be clear on clients that C was a reply to a deleted post. I think this is a blind spot in the spec. The tombstone is synced around today, but it doesn’t carry the back-pointer to the post it was referring to. |
Föderation · So 05.01.2025 09:11:36 @Dave Rahardja this is not really an activitypub issue but with how conversations are handled by mastodon, On other platforms like lemmy, hubzilla I do see a post deleted or similar tombstone while the original conversation stays intact. |
Föderation EN So 05.01.2025 10:40:07 In this case (!) ;) this might indeed be an issue of ActivityPub as Tombstone is underspecified here. See also feps @silverpill |