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

Note Detail

Reply to @mike@macgirvin.com
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---
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.

---Replies---

Mike Macgirvin@mike@macgirvin.com (2026-06-07 07:22:29)
When context property is present on a post, it MUST resolve to a collection of posts.
...
When context property is present on an activity, it MUST resolve to a collection of activities.

In one place, we are asked to distinguish what type of thing we are fetching based on the name (context vs. contextHistory), and in another we are asked to distinguish based on the subclass of the element which contains "context".

Which is it? If it's both, how does that work? And since this is a MUST, once again, wtf is a "collection of posts"? I can't implement something if everybody refuses to define it.

And if "contextHistory" is an equal player with "context", every.single.fediverse.project now has to examine every context they copy to their own objects and activities, just to ensure they  get the right one in each case. And if both are present, copy both - after checking that "context" is or isn't the one they really want.  

And nobody is pushing back on this but me?