Home | Notifications | New Note | Local | Federated | Search | Logout
Mike Macgirvin@mike@macgirvin.com
Retired tech artist currently living in rural Australia. Mechanical/Electrical/Electronics/Software Engineer by trade with a lifetime career focus on decentralised communications systems. Accomplished reverse-lefty (upside down and backwards) guitarist, former music store owner, and instrument repair person.
FWIW, I rarely communicate publicly these days, and this particular fediverse instance is configured to block pretty much all Mastodon traffic for reasons I won't bore you with. If you have reason to contact me, start with email. It's the same as my fediverse handle.
Joined: 2026-05-09 16:09:28
5 notes, 0 following, 0 followers
Reply to @silverpill@mitra.social
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?
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 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 to @silverpill@mitra.social
Mike Macgirvin@mike@macgirvin.com (2026-06-05 07:29:08)
I might recommend adding a pointer to a formal definition of "post" (as used here) for the benefit of newcomers.
Mike Macgirvin@mike@macgirvin.com (2026-05-09 07:01:04)
In the streams repository a few years back, we implemented a mechanism where "site actors" could follow each other, and this would result in sharing local public content with selected other sites, regardless of personal connections between actors. This scales so you can build small or large "clusters" or cooperating servers. The keyword being that this is server sharing which is "consent" based.
There was little or no interest in this ability from anybody, so the feature languished. I think it's still implemented, but there's no motivation to pursue it further. I'll just mention it if somebody else feels like dying on hills today.