@julian I'm not using context, but I think FEP-7888 is great and I want to implement it in the future. Haven't decided yet on what exactly this collection should contain. Slightly in favor of collection of activities (as in Streams / Conversation Containers).

@trwnh @mikedev

I have created a spreadsheet with open editing permissions (for now) and invite implementors to add their implementations if applicable.

One thing I am noticing now (and should've expected) is that not every software has the concept of a discrete context, nor can you expect one from remote activities. In those scenarios, the fallback seems to be to point to the root-node Object and iterate via replies collection.

For example:

• @mariusor@metalhead.club's FedBOX defines context as the root-node Object.
• @mikedev@fediversity.site's (streams) has a concept of conversation containers, and if context is received, inherits it, but otherwise, context becomes the root-node Object.

@trwnh@mastodon.social does FEP-7888 account for this use-case?

Hi, I've been working on something a little similar to FEP-7888 which uses the context field as a grouping of a subjective context but more for discovery purposes than anything. For example, followers of a Service (I called it Topic in my doc, which I realize could be a little confusing now) used as the context field can use that to discover other instances that create content with the same context. Optionally, this can be decentralized by appending a nonauthoritative ID to the context, so the authoritative ID would be used for discovery only, and as a way to bootstrap federation.

Having context be completely authoritative (and thus, forcing an authoritative Collection as its representation) could be useful too, but it'd be great to have solution that allows it to be more ephemeral as well.

@Julian yeah that's a good point - I think tag would work but I always got the impression that they were more of a micro-level part of a specific piece of content vs. macro-level (being the place they're being discussed in). context would be set at the forum level (whatever the forum's owner specified) whereas tags might be decided by the user. So in that sense, context would more about origination of a post.

Example might be something like this -

{
  id: "https://yuforium.com/forums/cars",
  type: "Service",
  name: "Example Forum About Cars",
  context: "https://another-instance.org/topic/cars"
}

Where a POST to that forum's outbox with a Note would result in that note's context defaulting to the one set to the forum. Posting with another context would result in an error. This makes things a little different than a tag which is what would be user specified. In that sense, context is more about where the post was created, vs. what it was created about. In a federated system, where could be an authoritative entity that encompasses multiple instances and is dereferenceable, or where could be defined as a UUID and be completely unauthoritative and ephemeral.

Given that it's more about the origination of the post, I would agree that the term "Community" is better in this case to define what context relates (instead of "Topic") so in the example, context could be switched to https://another-instance.org/community/cars.

It's been a while since I wrote that up, and at the time I was considering using "Community" as the terminology for a context so I might update that soon (especially with "Topic" being a frequently used convention in forums meaning something totally different).

In the Activity Streams docs, the one part about context that got my attention was this - "An example could be all activities relating to a common project or event", meaning that context exists outside of the scope of what a thread would be, and is more indicative of a forum level or federation setting vs. the contents (objects, activities, etc.) of a single thread.

One context-related issue I've encountered which hasn't been canvased yet, is that context could be used to set the canonical url of a forum topic. When I say I've encountered this issue, it's some feedback we've received on the plugin. See further

https://meta.discourse.org/t/activitypub-plugin/266794/213?u=angus

And the subsequent discussion.

What I'm currently thinking is the following:

1. When working with a topic (thread etc)
2. If a Note in that topic has a resolvable context
3. If the context resolves to a Collection.
4. Use a resolvable URL for the Collection as the canonical url
   • My current candidate for a "resolvable url" is the url property of the Collection as the Discourse plugin already serializes the topic url as the url of Topic Collections.

Interested in thoughts on any of the above.