Home | Notifications | New Note | Local | Federated | Search | Logout

Note Detail

Reply to @mike@macgirvin.com
silverpill@silverpill@mitra.social (2026-06-06 03:25:18)
@mike The formal definition of a 'thread' should suffice :]
---Reply---
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.

---Replies---

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.