How do you use `context` (if at all)?
-
angus: Could you elaborate specifically on why you think Like activities shouldn’t be included? Mainly because this information is available via likes "already". I'm not adamantly opposed to including e.g. Like and Announce in a representation of the conversation, but this needs to be considered more carefully as to whether it's appropriate or not. angus: I’m not saying that Activities are primary over Objects, just that both may be relevant depending on the context. I don’t particularly see the benefit in preferencing one over the other in a normative sense. That said, I do think that Objects are necessary as a baseline, as not all implementations will have the same feature set That point was less about "feature set" or "relevance", and more about e.g. "should the object always be wrapped in a Create or not?" -- this was discussed in an earlier topic about "Implicit Creates": https://socialhub.activitypub.rocks/t/implicit-creates/4104 -- and the answer is "it depends on the convention you're following". A practical example would be how Streams includes the Create activity, while NodeBB includes the object. It's not like either of these usages is more "correct" than the other. It's just a difference in opinion. Put another way: You can have a collection of Creates and Likes, or Notes and Likes, or just Notes, or Creates/Likes/Announces, or so on and so forth. There's only so much you can actually constrain here; constraining too much would end up being detrimental to certain use cases.
-
If
context
contains ordered activities, servers can easily sync their copies ofcontext
by fetching the collection until they encounter activity with a certain timestamp. That could be useful for backfilling in federated groups.Ifcontext
contains objects, backfilling would be limited to comments (no reaction backfilling, which can be important for Reddit-like services). -
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:
- @[email protected]'s FedBOX defines
context
as the root-node Object. - @[email protected]'s (streams) has a concept of conversation containers, and if
context
is received, inherits it, but otherwise,context
becomes the root-node Object.
@[email protected] does FEP-7888 account for this use-case?
- @[email protected]'s FedBOX defines
-
Option 3:
context
is heterogeneous and can contain both objects and activities.Or, rather, I should jump to the end of the reasoning chain and just go ahead and say it: if the
context
is an actor, you can put the "post" objects incontext
and stuff the full activities inoutbox
instead. You could even makecontext
be forward-chronological andoutbox
be reverse-chronological. Fetchingcontext
means fetching the "posts" of the thread; fetchingoutbox
means fetching the "activity log" of the thread.The way you make that work is inbox forwarding. The reason FEP-7888 makes mention of
context.followers
"if the context is an actor" is entirely due to this possibility. Your participatory activity looks something like this:id: actor: type: Createobject: - id: content: "Hello to the everyone" context: to/cc/audience: , ,
This indicates that the object should be
Add
ed to the . You could also/instead attachcontext
to the activity, but you don't need to do that if you instead rely on inbox forwarding:id: actor: type: Likeobject: to: # this notifies you directly/activelycc: , # this means it will be delivered to the context actor to be forwarded to its followers
You wouldn't need to
Add
the to the if you instead forward it and also make it available via .Again, adding to context collections is a bit of a negotiation between the sender and receiver. The sender adds the
context
property in the hopes that the receiver will Add that object (which may be an activity) to the context collection. The receiver is free to not Add the object/activity. Just like the receiver is free to not forward the activity to its followers, if it is deemed spam. But assuming all goes well, the ideal situation is that the post object gets labeled with the context property and added to the context collection, while the activity is inbox-forwarded to the context's followers and/or audience. -
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 hasattributedTo
, you can assume thatattributedTo
will be maintaining the collection; in such a case, you can opt into the rest of FEP-7888 by sending your participatory activity to theattributedTo
actor and alsoaudience
/followers
if present.
- if it is a
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 anattributedTo
that can moderate the conversation, but there isn't an explicit representation of the conversation viaitems
/orderedItems
/outbox
. The authority of theattributedTo
to moderate downstream replies is not clearly established anywhere, hence it not being a great idea to do this. -
@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.
-
-