@julian @pfefferle @jesseplusplus @trwnh +1 for chronological order requirement.
Are those implementations public? I'd like to test my context resolver against them too
this post was submitted on 18 Feb 2025
1 points (100.0% liked)
Forums and Threaded Discussions Task Force
0 readers
2 users here now
Discussion and announcements related to the SWICG Forums and Threaded Discussions Task Force.
This profile is a discussion forum category and shares content from users who post in its discussions.
founded 8 months ago
@[email protected] 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 @[email protected]'s personal blog:
- Top level
Article: https://notiz.blog/2025/02/11/fedidem/ - Mid-level reply
Note: https://notiz.blog/?c=2045174
@[email protected] had a test URL but NodeBB fell over because it encountered an Object in next instead 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.
>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 @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 @[email protected]'s personal blog
This context is working ๐
>@[email protected] 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).
@[email protected] said in FEP 7888 serving up an OrderedCollection: > Do you mean replies made by the context owner specifically?
Correct, or more specifically, at least for all replies coming from the instance that the context owner belongs to... so other sibling replies by users on that instance should also report that same context.
@[email protected] you can also test against this instance, though I assume you already tried:
contexturl: https://community.nodebb.org/topic/18632- Top level post: https://community.nodebb.org/post/103364
- Mid-level reply: https://community.nodebb.org/post/103377
yes, but they serve objects because we're radical implementors who don't do the whole activities thing ๐ sorry in advance.
What if only the activity is signed (as is often the case) and the object is not fetchable due to let's say some network error?
@[email protected] at least per our working implementation, the context only deals with public objects which should be fetchable by an instance (either anonymously or via signed GET).
@[email protected]'s 171b does what you suggest, sending the full signed (via proofs) activities, which in that sense is more performant as fewer network requests are required (just the one, really), and more reliable as you don't need to fetch the individual objects. However, requiring object integrity proofs is a burden that seems quite difficult to clear at present.
WordPress, NodeBB, and Mastodon are not built in such a way that activities are saved direct-to-database. The activities are consumed and a local representation is saved, which makes going reverse quite difficult, especially when it comes to content from outside the local instance.
@julian i see... In general i think in distributed systems it makes a lot of sense to keep the source intact while consuming the data you need. Other projects might need to consume a different set of fields and the overhead is minimal...
@julian Are the future posts scheduled posts. Do they have a "scheduled" flag or something similar? Is timezone info included by default? Those are the two situations I can think of where this would occur with "timestamps in the future".
@[email protected] if an object gets federated out with a future timestamp but is meant to be scheduled, I think that's a bug.
I wouldn't trust other implementors to respect post scheduling ๐ฌ
@julian I have a classicpress and a wordpress instance where I could test scheduled posts. It might help to check instance logs. I can test scheduled posts from classicpress with ease.