Home | Notifications | New Note | Local | Federated | Search | Logout
Note Detail
Reply to @silverpill@mitra.social
Mike Macgirvin@mike@macgirvin.com (2026-06-06 07:35:07)
OK, I need to push back this time. If your context collection contains enough information to rebuild a conversation from scratch, I don't care about the presentation. My context collection is legal ActivityStreams, as is a "posts" collection. It differs from a "posts" collection only in that it provides enough information to rebuild a restricted access conversation from scratch. A "posts" collection doesn't work well in that environment. In my experience it doesn't work at all, but I'll take any improvement in backfilling it might provide. If restricted access conversations matter to you, you might prefer to use signed activities in your presentation. If they don't, use any presentation that works for you.
I believe that a "posts" collection has a limitation that backfilling contains no "likes" and not sure how you might rebuild the conversation accurately without them. This is why I'm looking for a clarification. I just want clarification that if I load your context that I still need to go out and hunt down reaction activities, or if you're going to provide them somehow (how?).
Otherwise, the precise presentation of the context element shouldn't be a deal-breaker issue for anybody at all.
---Reply---
Mike Macgirvin@mike@macgirvin.com (2026-06-06 09:07:35)
A secondary issue is consistency. It manifests itself as the same cache problem we discussed recently with partial objects. Now we have two identifiers of the same name which provide different content depending on their "containing object instanceOf".
Please repeat after me: the context is the primary source of truth.
I really don't want multiple primary sources of truth that differ from each other. I doubt anybody else does either. If you can't parse my version of the truth, you probably won't be federating with me, and vice versa. That doesn't make my presentation invalid. If I can't parse and verify your version of the truth, I won't be federating with you either. I really don't like "contextHistory" and propose that we simply let you display your version of the true conversation in a manner which allows participants to reconstruct it. Nothing more. When you involve restricted audiences, the requirements might be different than for public conversations. However, the "activities" presentation works well for both public and private content. The "posts" presentation is more suited to public content and doesn't work well with restricted audience communications. Again, this is an implementation concern -- I really don't think we need a formal protocol divide between such trivial implementation concerns. It kind of goes against everything I believe in.
Reply
---Replies---
silverpill@silverpill@mitra.social (2026-06-06 17:03:41)
@mike I agree that collection of activities is a better representation, because it is more complete, but this is not the subject of this FEP. The FEP is about backfilling, and its purpose is to document the current practices.
Implementers of this FEP are not required to publish any collections. However, they are advised to use a backfilling algorithm that supports all three conversation models (containers, threads and reply trees): https://fediverse.codeberg.page/fep/fep/f228/#reading-collections. The algorithm gives precedence to contextHistory, so collection of activities is used as a primary source when it is present.