How do you use `context` (if at all)?
-
@trwnh I really like this. Very clean.
-
@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, maybeaudience
could be a better fit (as per FEP-1b12) -
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.
-
-
@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 aNote
would result in that note'scontext
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 tohttps://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 furtherActivityPub 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 theurl
of Topic Collections.
- My current candidate for a "resolvable url" is the
Interested in thoughts on any of the above.
-
Sounds reasonable to me
-
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.
- Short of that it's easier to just maintain your own context and canonical URL. That's this line in 7888:
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.
-
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="...">
insteadIn 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.
-
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.
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 inalsoKnownAs
. 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. -
@[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... -
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 receivedIf 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.
-
@[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 anattributedTo
, tied to anas:Note
, that may or may not respond with anAdd
.Again, all this is still in flux, so this may change.
-
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 McLeodreplied to julian on last edited by [email protected]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 resolvableurl
.
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. -
@[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 McLeodreplied to julian on last edited by [email protected]
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
-