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

@trwnh@mastodon.social yeah that was what I was afraid of. Maybe a SHOULD?

What we discussed on the call was "keep it simple" for implementors, which would be to have implementors order by forward chron.

End of the day since NodeBB is the one having trouble with the order I think it's on me to re-add re-ordering so other implementors can send in whatever order they want.

cc @pfefferle@mastodon.social @jesseplusplus@mastodon.social

@harmonicarichard@techhub.social 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 @pfefferle @jesseplusplus i've got some prior fep work on OrderedCollection.orderType and SortedCollection.sortedBy|sortOrder (1985, 1863 but not submitted yet)

but there are deeper issues when trying to do anything with Collections other than just read them as-is... i've filed several issues on w3c/activitypub etc but tldr idk what the best solution is here. the existing abstraction of as2 collections falls short when you are trying to represent data structures other than a basic set.

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

@julian @pfefferle @jesseplusplus @trwnh +1 for chronological order requirement.
Are those implementations public? I'd like to test my context resolver against them too

@julian @silverpill @pfefferle Right now my fork’s implementation has just a Collection rather than an OrderedCollection, but I’m going to change that to an OrderedCollection based on today’s discussion

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

@silverpill@mitra.social 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.

@silverpill @julian @pfefferle @jesseplusplus @harmonicarichard the context SHOULD be copied if you want to participate in the same context, but the owner MAY Add whatever they want to an arbitrary Collection

context-unaware impls aren't prevented from participating but this will lead to a degraded experience if you're not careful. likely you would start with some graph source, filter for context, then optionally crawl replies for anything missing or otherwise optionally reverse query inReplyTo

@trwnh@mastodon.social @silverpill@mitra.social I'd argue that the broad baseline implementation is to allow anyone to participate in the same context... mostly because you can't guard against other implementors specifying your context value.

However, there's nothing stopping a future FEP ("context ownership"/"reply controls") from recommending that implementors check against the context first before locally adding a received object that provides context.

@julian @silverpill right, it's a bidirectional link that should be verified both ways ideally. so you have an object claiming to be included, but you also ideally have a reverse claim of inclusion

i think you can mostly get away with doing something like:

- if context is present and it has a canonical collection, you can browse it directly. ignore the original object
- if someone declares your context and you become aware of it somehow, you can optionally add it to the canonical collection

@jesseplusplus@mastodon.social @pfefferle@mastodon.social I fixed up NodeBB's janky handling of collections and now I am able to import an entire Frequency conversation via its context

I think @silverpill@mitra.social is right though, your context.first needs an id. I worked around it but it's better to have it so it can be referenced against by another page's prev.

@julian @silverpill the third point which is more contentious:

- deleting a context implies all objects included in it are now orphans and can be garbage-collected (deleted, updated, moved, whatever)

> deleting a context implies...

@trwnh@mastodon.social that would be yet another FEP

yes, but they serve objects because we're radical implementors who don't do the whole activities thing sorry in advance.

@mario@hub.somaton.com 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).

@silverpill@mitra.social'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.

@silverpill@mitra.social you can also test against this instance, though I assume you already tried:

1. context url: https://community.nodebb.org/topic/18632
2. Top level post: https://community.nodebb.org/post/103364
3. Mid-level reply: https://community.nodebb.org/post/103377

@julian Yes, I tested against NodeBB and other implementations mentioned in FEP-f228. Will add WordPress and Frequency to the list