How do you use `context` (if at all)?

a

There's three possibilities laid out in FEP-7888 regarding the use of context:

It's missing. Fall back to other heuristics (inReplyTo, etc) to do implicit grouping.
It's a non-dereferenceable URI. Do explicit grouping against this URI.
It's a dereferenceable object. Do explicit grouping against the ID, and also:
- if it is a Collection/OrderedCollection and has attributedTo, you can assume that attributedTo will be maintaining the collection; in such a case, you can opt into the rest of FEP-7888 by sending your participatory activity to the attributedTo actor and also audience/followers if present.

With that said, the use of the "root-node Object" as context is supported, but not recommended. It represents a sort of halfway-point where you probably have an attributedTo that can moderate the conversation, but there isn't an explicit representation of the conversation via items/orderedItems/outbox. The authority of the attributedTo to moderate downstream replies is not clearly established anywhere, hence it not being a great idea to do this.

Evan Prodromou

@trwnh I really like this. Very clean.

julian

@Chris-Moser Thanks for sharing your implementation of context in Yuforium!

That's definitely an interest use-case, although I am curious why you did not consider using the as:tag property instead, given that it seems to be a rough parallel to your Topics.

In that scenario, then you could limit context to what you would call Communities, though depending on how it is used, maybe audience could be a better fit (as per FEP-1b12)

Mike Macgirvin 🖥️

I would expect that if there's a Delete/Note, the corresponding Create would instantly become a Tombstone, and cease to exist completely after some initial notification period.

Rimu

@julian @mariusor @mikedev @trwnh At first I thought you were talking about the "@context", used for JSON-LD...

Chris Moser

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

Angus McLeod

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

ActivityPub Plugin

:discourse2: Summary Discourse ActivityPub allows you to publish Discourse posts via ActivityPub so they can be read on services that support ActivityPub such as Mastodon. :hammer_and_wrench: Repository Link …

Discourse Meta (meta.discourse.org)

And the subsequent discussion.

What I'm currently thinking is the following:

When working with a topic (thread etc)
If a Note in that topic has a resolvable context
If the context resolves to a Collection.
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.

a

Sounds reasonable to me

julian

re:

Use a resolvable URL for the Collection as the canonical url

Angus, it's a little more complicated than that I think. Two concerns:

It depends on where the topic first started. If a topic started on i.e. SocialHub then it makes sense that the canonical URL should be SocialHub. If it started on the NodeBB community it should be that. This might've been implied in your post, but I wanted to make sure!
Secondly, it would not be correct to set a resolvable context as the canonical URL if that context resolves to an AP implementer following FEP 400e, unless you also keep track of whether all items in that context were Add'd and can confirm that all items are in that collection.
- Short of that it's easier to just maintain your own context and canonical URL. That's this line in 7888:
  - You MAY set your own context, if you wish for your object to be in a separate context owned by you.

cc @[email protected]

Also sorry for the delay, it turns out I introduced a regression that caused replies to not make it into NodeBB for the past 12 days. Yikes.

julian

So until that second point is considered — maybe we should discuss at next ForumWG meeting... — I might just maintain my own set of known contexts local context, and send additional <link rel="alternate" type="application/activity+json" href="..."> instead

In AP, I was considering sending an Array in context if applicable, with my context first, and all others afterwards.

Happy to do it your way, but would need to resolve that 400e problem first.

a

julian:

Short of that it's easier to just maintain your own context and canonical URL. That's this line in 7888:
You MAY set your own context, if you wish for your object to be in a separate context owned by you.
cc @[email protected]

I might have not phrased that clearly enough -- there is a soft assumption in 7888 that there is only one context set, especially when reading those bullet points. In other words, you would be overwriting the one context with another. This is the same as "starting a new thread" or "forking the topic".

At the same time, it should be possible for context collections to have multiple identifiers -- id being "canonical" and aliases being present in alsoKnownAs. I feel like having multiple collections for the same topic is not a good way forward; it's better to look at it as a state synchronization problem instead, with one collection at the origin being the source of truth. You maintain a local cache of that collection.

julian

@[email protected] said in How do you use `context` (if at all)?:

I feel like having multiple collections for the same topic is not a good way forward; it's better to look at it as a state synchronization problem instead

That's a good point. I'm okay with that sort of assignment of context in theory, although I have concerns about how to handle that "local cache" situation where replies sent to a remote context aren't considered part of the context until an Add is received. Might be a sensible default to set the context for those items to the local context until confirmation is received...

a

julian:

although I have concerns about how to handle that "local cache" situation where replies sent to a remote context aren't considered part of the context until an Add is received

If you haven't received an Add yet, then either:

there was a network failure, and you might receive it later, or you can manually fetch the collection later to synchronize state.
more likely: your post wasn't "approved" by the moderator of that collection, and it is intended that others won't see it, unless you send it to your followers/etc as well. consider it in a pending state.

julian

@[email protected] said in How do you use "context" (if at all)?:

consider it in a pending state.

Ah, but given that there's no such thing in NodeBB (besides the post queue which is... not quite the same thing), I'd be hesitant to build a system just for handling the potential for receipt of an Add, especially given that there are few (if any?) implementations that contain a resolvable context, with an attributedTo, tied to an as:Note, that may or may not respond with an Add.

Again, all this is still in flux, so this may change.

a

If "pending" is something you feel uneasy with, would it be better to look at it as "approved" or "verified" once you get the Add? The idea is that in some future where more implementations do this, it can become a policy decision whether to show "unverified" posts. In the meantime, you can show a checkmark or other icon to indicate it's been stamped by the authority.

Angus McLeod

julian:

It depends on where the topic first started. If a topic started on i.e. SocialHub then it makes sense that the canonical URL should be SocialHub. If it started on the NodeBB community it should be that. This might've been implied in your post, but I wanted to make sure!

Yes, that is my understanding. For example, the canonical url of this topic would be

https://community.nodebb.org/topic/18050/how-do-you-use-context-if-at-all julian:

Secondly, it would not be correct to set a resolvable context as the canonical URL if that context resolves to an AP implementer following FEP 400e, unless you also keep track of whether all items in that context were Add'd and can confirm that all items are in that collection.

I'm not sure I quite agree here, albeit I may be misunderstanding your meaning. I don't think the "canonical" nature of the context should be dependent on the fidelity of the context's object (e.g. the context's collection) to all activities made with respect to it, or dependent on the context owner following a particular approach (beyond the necessities I've laid out below).

I feel like requiring activity fidelity makes the use of the context a bit too circumspect as there will always be a possibility that some actor interacting with it does not consider the context to have treated its activities appropriately.

Consider the following

Discourse and NodeBB both consider the context of this topic (i.e. the one we're in right now) to be the canonical context, as represented in the canonical url
https://community.nodebb.org/topic/18050/how-do-you-use-context-if-at-all
Another platform, let's call it "SEOmaster" has also published some activities in this context, however for whatever reason they are not winding up in the context's collection, and not appearing in the topic representations on nodebb and socialhub. There could be many reasons for this, ranging from an issue with their activity formatting, to connection issues, to an issue with the actor etc.
NodeBB has implemented FEP 400e compatibility, in addition to 1b12 support, in some form.
SEOmaster, as its name implies, has amazing SEO. Because it doesn't consider its rejected activities to be treated appropriately. It feels justified in setting the canonical URL as a URL with its domain and points out that NodeBB is compatible with FEP 400e.

Now, the above could well happen anyway, without any justification, if SEOmaster were to ignore any convention we devise here. However I think the convention we set should be as robust as possible. Making it subject to the specific implementation of the context feels like a hostage to fortune to me.

That said, I do think that, to be considered a "canonical" context for the purposes of a forum the following needs to be true:

context is resolvable.
It resolves to a Collection.
The Collection has a resolvable url.

For a forum I think we need to at least require the context to be a Collection, otherwise it can't be a canonical context for a topic.

julian

@[email protected] said in How do you use `context` (if at all)?:

That said, I do think that, to be considered a "canonical" context for the purposes of a forum the following needs to be true:

context is resolvable.

It resolves to a Collection.

The Collection has a resolvable url.

Agreed on that. I think I am over-complicating things by thinking that individual objects in a forum topic could have different contexts when queried via ActivityPub.

However, what if after iterating through the resolved context, the top-level item identifies itself as having a context that differs from the one you queried? Do you start over with the new context (if resolvable? lol.)

Angus McLeod

I think the answer to that has to be that you have to take whatever context is associated with the object you're sent as canonical. Otherwise we'll always be second-guessing. The context on the object of the first object in whatever collection you resolve could also be "wrong". Yes, practically speaking, this may lead to errors in certain cases, however I think that's better than making the context overly relative.

**edit I guess in this case, practically speaking, you'd follow up with the implementer of whatever platform is being used to resolve the context you initially got and ask them to fix their issue