@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

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

@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

Yes,  whenever the context element is referenced from a naked object per the current FEP-f228. The definition of "posts" was very useful, as this is about the 4th time I've done this - but trying to still provide reactions since our software considers them to be an integral part of the conversation.

No reactions.

Got it.

Don't worry that's it's completely flawed as a conversation filling mechanism and won't work well for anybody in the current fediverse until they implement this FEP fully ---  a situation which I tried so hard to avoid.

Got it.  

So it'll work like shit for the next five years, or maybe forever in the case of Mastodon, but it should be fully compliant with FEP-f228

@mike

Yes, whenever the context element is referenced from a naked object per the current FEP-f228.

I tried to fetch context from one of your (private) posts, but the collection contains activities:

https://macgirvin.com/.well-known/apgateway/did:key:z6MkhPXNfiHDh2qSNjFzZ9yY27C1iHnHVbb1eaxuoiEe4tjk/conversation/bf59f105-711d-4c71-96a3-923e90f76e18?posts=true

but trying to still provide reactions since our software considers them to be an integral part of the conversation

One way to provide reactions when only "collection of posts" is available is to use likes and emojiReactions collections, but I doubt that any implementation would actually resolve them.