Hello @renchap, thanks for following up. I think the way to tackle this is a version of the following:

1. We agree on a normative approach to the use of context. <--- Discourse, NodeBB, Wordpress and others essentially agree on this already, but it would be helpful to clarify and include folks from Mastodon.
2. We develop a generalised implementation agenda. Generalised, but with the needs of different platforms in mind.
3. Individual implementers adapted the generalised implementation agenda to their specific circumstances. However that works with their individual development cycles / practices.

I suggest we start work on 1 and 2 now and discuss them both further in person at the next Threadiverse Working Group meeting at the start of March. The group was set up to address these questions.

@devnull @trwnh @pfefferle If you're on board with this, let's seize this rare opportunity of having the relevant players involved and finally settle this question so we can move forward. If so, could one of you please start a new topic in #activitypub:threadiverse-wg addressing where we're currently at with 1 as you're both better across this currently than I am.

cc @nutomic @silverpill

You're not wrong. I would make a PR to mastodon, but I fear it would languish in review for years. There has to be a better solution to this though.

@julian Say if we were to make a PR to Mastodon to address this issue what is your take on the lightest touch change we could propose?

individual objects serve a context property 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:

the context resolved to an OrderedCollection containing objects NodeBB was able to pull in the entire conversation

Just a note that I endorse @julian's suggested approach here, and this is how the Discourse plugin has implemented its backfill feature.

When I refactored my 1b12 implementation, I actually removed the second Announce(Object), but I think I will add it back.

I would gently suggest that sending both Announce(Object) and Announce(Create(Object)) to all followers for the same content is not a good solution to the problem. Yes, other implementors can come up with ways to handle that (I just deployed the Discourse solution to this duplication to SoicalHub), but it's hardly ideal.

I recently switched the Discourse plugin back to only Announcing the first Create(Note) in a topic (Collection), but not replies, or updates, as announcing everything was causing issues with Mastodon.

On the topic of federated categories – the problem with duplicated comments from other Fediverse servers persists: WordPress follow failure - #2 by pfefferle1

It's not clear to me this is a Discourse bug yet. We'll know more once we merge object JSON log viewing in the admin panel and I can see exactly what SocialHub is receiving and sending in those scenarios. If those Notes are replicated on other services with different ids Discourse would treat them as different Notes.