@julian Mitra can backfill from Streams and Hubzilla, but it doesn't publish any collections yet.
Streams and Hubzilla have interoperable FEP-171b implementations, but I don't know about pulling the collection. They are more focused on private conversations where backfilling is not needed.
Streams and Hubzilla also implement context collection. They attach context to activities, it is an OrderedCollection, and its items are activities.
The problem with duplicated remote comments seems to be gone (I am writing this comment from my own server).
However, I discovered another issue with remote comments like this one: https://socialhub.activitypub.rocks/t/1b12-vs-guppe-groups/5032/13.
Its ActivityPub ID is
https://socialhub.activitypub.rocks/ap/object/07746fd71af9af4f0789f9e4798f33ec
and its attributedTo property has the value of
https://oisaur.com/users/renchap
meaning "actor from oisaur.com created object on socialhub.activitypub.rocks", which generally shouldn't be allowed (unless this actor is explicitly authorized to do so).
I think Discourse should show the original ActivityPub ID of the remote comment when user clicks on the "ActivityPub" button. This probably affects federated activities as well.
>So now the default context is objects for Create|Update|Delete Note|Article and activities for everything else
Shouldn't Create|Update|Delete also have activities in context?
My understanding is that context collection is supposed to contain things that have collection ID as their context property.
If entity is an activity, its context is a collection of activities.
If entity is a post, its context is a collection of posts.
@julian @pfefferle @jesseplusplus @trwnh @mario @harmonicarichard @reiver @aslakr @Fitik
@julian Yes, I tested against NodeBB and other implementations mentioned in FEP-f228. Will add WordPress and Frequency to the list
@julian @pfefferle @jesseplusplus @harmonicarichard @trwnh
>yes, but they serve objects because we're radical implementors who don't do the whole activities thing 
sorry in advance.
My server can retrieve both kinds of collections :) I had concerns about diverging / conflicting implementations in the past, but the solution was found...
>We were testing against these URLs from @pfefferle@mastodon.social's personal blog
This context is working 
>@jesseplusplus@mastodon.social had a test URL but NodeBB fell over because it encountered an Object in next instead of a URL
I have a problem with this one because the first page doesn't have an id. I can adjust my code but the absence of id is unusual. For example, there is a next page (currently 404), and if we navigate to it, how prev would look like if the first page is anonymous?
>All top level or mid-level objects should report a resolvable context
Do you mean replies made by the context owner specifically? I think remote mid-level replies should not be required to have context (that would prevent non-implementing servers from participating).
@julian @pfefferle @jesseplusplus @trwnh +1 for chronological order requirement.
Are those implementations public? I'd like to test my context resolver against them too
How to subscribe to a thread?
Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.
So here is an alternative: FEP-f06f: Object observers.
Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.
@julian FEP-1b12 only works with activities,
but Lemmy also announces Page objects for (micro)blogs.
https://socialhub.activitypub.rocks/ap/object/443fb143373ebc5a4df190cddcd2da1f
@julian Take a look at this document: https://codeberg.org/silverpill/feps/src/branch/main/f228/fep-f228.md
I wrote it for Conversation Container implementers, but maybe others will find it useful too.
>Contexts can provide a thorough, comprehensive way to backfill an entire conversation. This is the biggest step we can take towards tackling the “fediverse is quiet” problem.
Sure, context is useful for backfilling, but is it the biggest step? I don't think so.
With FEP-1b12 or Containers, conversations are synced by default, so there is no need for backfilling. This is more efficient too: you don't need to retrieve context periodically to get an up-to-date view.
@scott @trwnh @julian I am also in favor of thread but other implementers have settled on context. Can easily support both if you want to use thread in your project
@pfefferle You may want to read the previous version of FEP-7888, which says that context should resolve to a collection:
fep - Fediverse Enhancement Proposals
Codeberg.org (codeberg.org)
This is what various projects have implemented so far.
The FEP was changed several days ago and now it is a very different document. The recommendation to use collection is no longer present, so I don't see any reason to refer to this FEP anymore.