Just wrapped up a call with @pfefferle@mastodon.social and @jesseplusplus@mastodon.social to review their implementations of FEP 7888, specifically in relation to conversational backfill.
:heavy_check_mark: individual objects serve a context property
:heavy_check_mark: that context property is a URL that resolves
One of the concerns raised was related to the OrderedCollection of items served by the context. Specifically, if the items presented in the collection were not in chronological order, NodeBB failed at importing some of the items as the inReplyTo referenced an object that did not exist.
The solution to this was to ensure that the collection items were in chronological order from oldest to newest. Once fixed:
:heavy_check_mark: the context resolved to an OrderedCollection containing objects
:heavy_check_mark: NodeBB was able to pull in the entire conversation
NodeBB used to guard against this by ordering all received items by chronological order, but I realized that while this worked 99%+ of the time, there are some fun (ahem...) individuals who send objects with timestamps way in the future.
Personally I think removing the sorting just to fix one edge case was premature. At the same time, I think specifying that the OrderedCollection be sorted in chronological order should be a requirement.
cc @trwnh@mastodon.social
@julian @pfefferle @jesseplusplus @trwnh +1 for chronological order requirement.
Are those implementations public? I'd like to test my context resolver against them too
@silverpill@mitra.social yes, but they serve objects because we're radical implementors who don't do the whole activities thing ๐ sorry in advance.
We were testing against these URLs from @pfefferle@mastodon.social's personal blog:
Article: https://notiz.blog/2025/02/11/fedidem/Note: https://notiz.blog/?c=2045174@jesseplusplus@mastodon.social had a test URL but NodeBB fell over because it encountered an Object in
nextinstead of a URL, so that's my bad:All top level or mid-level objects should report a resolvable context, resolving to an OrderedCollection (the same one if the objects are in the same conversation) containing URLs to said objects.
We normally do full activities, but after some prodding, I've begun implemented the forth-coming FEP about context vs contextHistory. So now the default context is objects for Create|Update|Delete Note|Article and activities for everything else, and contextHistory is full activities for everything associated with the opening post-of the conversation; but what a nightmare...
We do not typically provide URLs as collection members, because you may need a signed activity to access and validate third-party objects which have source access control enabled.
@mikedev
>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
contextproperty.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