@julian do you approve?

@silverpill@mitra.social looks fine to me, thanks <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f44d.png?v=0e52d811655" title="" /> would be great to see it finalized.

@silverpill Generally, if (streams) has something implemented, ActivityPub-wise, then so does Forte. And vice versa.

This means that Forte should be mentioned under Hubzilla and (streams).

#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Streams #(streams) #Forte

I might recommend adding a pointer to a formal definition of "post" (as used here) for the benefit of newcomers.

@mike The formal definition of a 'thread' should suffice :]

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.

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.

@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.

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?

@mike@macgirvin.com collection of objects, if that makes sense.

Just a collection of Notes, Articles, Pages, whatnot

So no likes/reactions, geolocation activities, invites, etc.. No audience restrictions beyond "public" and "unlisted". And lots of new code with issues that can never be resolved, but that our software needs to implement in order to comply with these new requirements -- and that nobody will ever use.  

Got it.  Don't know how that qualifies as conversation completion in even an abstract sense, but it's not my circus and those certainly aren't my monkeys.

> @mike@macgirvin.com said:
>
> but that our software needs to implement in order to comply with these new requirements -- and that nobody will ever use.

The wonderful thing about FEPs is you don't have to implement them, but you also don't get to decide who does.

Certainly not. But all good. Thanks. Sorry for interrupting last call. Cheers.

@mike

Which is it? If it's both, how does that work?

Yes, it's both. The backfilling algorithm described in the FEP should be used on a top-level post. When this post has a contextHistory property, it will resolve to a collection of activities. When it has a context property, it will resolve to a collection of posts.

wtf is a "collection of posts"

Alright, I will add a definition to the FEP.

"post" is any kind of attributed object. Usually it's a Note or an Article, but it could be an Event too, or something else entirely. What's important is that "post" is not an activity.

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.

It shouldn't be a problem because with the proposed backfilling algorithm the collection item type is always known beforehand.

If it's a problem, you can use duck typing on collection items. That's what I do when I fetch an object whose class is not known.

@mike@macgirvin.com for what it's worth (and I say this not knowing how streams and forte work), processing activities and objects can be done in a way where code paths are reused. However I think that's easier when you're object-first (as NodeBB is), and if you rely on activities to provide context around the object, then a collection of objects makes little sense.

In that case, not supporting the collection of objects is probably also okay.

Nah, we'll implement a posts context collection. Then everybody (including threadiverse apps and also including Mastodon) will be able to see with their own eyes that it's a broken concept.

It looks like others can expect an overall backfill effectiveness of about 8-12% from our software using objects.

Wahoo!

It's certainly better than the 0.0% we get trying to backfill from the same objects, because by definition these objects all belong to the un-moderated cesspool. Using contextHistory and object signatures, both apps should be able to successfully backfill 100% of the moderated conversation, minus anything they rejected due to their own content policies.

#Works for me.

I believe you can put forte in the implementation list now. Should tick all the boxes. I've updated the Conversations document to compare target and context without fragments or query params. Conversation Containers may require a similar update to make sure that's still valid; as the identifier and presentation format now needs to change depending on the placement of the context attribute.

@mike Forte is already listed as an implementer of "collection of activities". Does it also provide "collection of posts"?

@julian