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

Did @silverpill@mitra.social or @trwnh@mastodon.social put together a draft FEP that successfully merges 7888, 400e, and @mikedev@fediversity.site's conversation containers? I remember reading it last week, and wonder if it's the one true FEP that will render the others obsolete.

@thisismissem@hachyderm.io in a post yesterday brought back the idea that better post controls could be achieved if the reply were sent to the target only, and the target then forwards it if applicable.

It reminded me of @trwnh@mastodon.social's https://w3id.org/fep/7888, which attempts to govern a similar flow where a reply is sent to the context owner (instead of inReplyTo, which I think was Em's intent), and the context owner (and/or originating server) federates out an Add if approved.

Which got me thinking about whether that federated server could actually send out a Remove too!

Let's say a reply is made but later on, a mod decides that it is to be deleted. A Remove would be a way to signal to other instances that the content actually be removed/deleted!

We could even take it one step further; servers will always exist who don't adhere to the philosophy of the context owner approving replies. If they federate their own replies out, the context owner could actually proactively send a Reject and limit the spread of those replies...