Context vs conversation

ActivityPub Server to Server
1

I’ve noticed that some servers send “context” along with activities (Create/Note, etc.), while others also use a “conversation” attribute. In the spec, I don’t see the conversation attribute, although I may just not be seeing it. Can anyone shed some light on how to use inReplyTo, context, and conversation to handle threading and replies correctly and effectively?

Friendica direct message has context set, inReplyTo null (first message in a conversation), and no conversation.

{
  "id": "https://friendica.feneas.org/objects/76158462-185e-74d5-0709-2a3993136982",
  "to": [
    "https://tavern.ngrok.io/users/nick"
  ],
  "url": "https://friendica.feneas.org/objects/76158462-185e-74d5-0709-2a3993136982",
  "type": "Note",
  "content": "Whats up!",
  "context": "nick@tavern.ngrok.io:76158462-905e-74d5-0709-2d0876673840#context",
  "summary": "Testing",
  "inReplyTo": null,
  "published": "2020-03-20T14:36:55Z",
  "attributedTo": "https://friendica.feneas.org/profile/ngerakines",
}

Pixelfed sets inReplyTo to null, but includes neither context nor conversation.

{
  "cc": [
    "https://pixelfed.social/users/NHonigdachs/followers"
  ],
  "id": "https://pixelfed.social/p/NHonigdachs/145603388422361088",
  "to": [
    "https://www.w3.org/ns/activitystreams#Public"
  ],
  "url": "https://pixelfed.social/p/NHonigdachs/145603388422361088",
  "type": "Note",
  "content": "",
  "summary": null,
  "inReplyTo": null,
  "published": "2020-03-17T18:55:52+00:00",
  "attributedTo": "https://pixelfed.social/users/NHonigdachs",
}

Mastodon sets inReplyTo to null, includes conversation, but doesn’t include context.

{
  "cc": [
    "https://mastodon.social/users/ngerakines/followers"
  ],
  "id": "https://mastodon.social/users/ngerakines/statuses/103841255374530007",
  "to": [
    "https://www.w3.org/ns/activitystreams#Public"
  ],
  "type": "Note",
  "content": "<p>Hedgehogs are super cute.</p>",
  "summary": null,
  "inReplyTo": null,
  "published": "2020-03-18T00:36:51Z",
  "attributedTo": "https://mastodon.social/users/ngerakines",
  "conversation": "tag:mastodon.social,2020-03-18:objectId=160438886:objectType=Conversation",
}
2

ostatus:conversation is an OStatus property, and Mastodon used it only due to the OStatus -> ActvityPub transition. New implementations should use context. (You removed the @context property from the document, where conversation is defined, which may have led to some of the confusion)

3

Ah, that makes sense. So the correct thing to do would be to use the context attribute, but for compatibility with ostatus (existing Mastodon instances using it), set both context and conversation and give context preference if they are different?

4

[2020-03-20 22:23:06+0000] Nick Gerakines via SocialHub:

Ah, that makes sense. So the correct thing to do would be to use the context attribute, but for compatibility with ostatus (existing Mastodon instances using it), set both context and conversation and give context preference if they are different?

Not sure if it’s needed for compatibility (probably not), but that’s what pleroma is doing anyway (we put the conversation declaration is in the litepub schema):

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://queer.hacktivis.me/schemas/litepub-0.1.jsonld",
    {
      "@language": "und"
    }
  ],
  "actor": "https://queer.hacktivis.me/users/lanodan",
  "attachment": [],
  "attributedTo": "https://queer.hacktivis.me/users/lanodan",
  "cc": [
    "https://www.w3.org/ns/activitystreams#Public"
  ],
  "content": "plz tell me Master Boot Record do live concerts",
  "context": "https://queer.hacktivis.me/contexts/01ac5949-e12e-4179-bcab-cce80f6e8341",
  "conversation": "https://queer.hacktivis.me/contexts/01ac5949-e12e-4179-bcab-cce80f6e8341",
  "id": "https://queer.hacktivis.me/objects/89d7d12b-4827-4c5a-b672-e3f441490708",
  "published": "2020-03-21T13:49:28.312398Z",
  "sensitive": false,
  "summary": "",
  "tag": [],
  "to": [
    "https://queer.hacktivis.me/users/lanodan/followers"
  ],
  "type": "Note"
}
5

I don’t store neither context nor conversation anywhere and so don’t include them in my replies/comments, but Mastodon displays them in appropriate threads just fine anyway :thinking:

6

https://www.w3.org/TR/activitystreams-vocabulary/#dfn-context

Identifies the context within which the object exists or an activity was performed.

The notion of “context” used is intentionally vague. The intended function is to serve as a means of grouping objects and activities that share a common originating context or purpose. An example could be all activities relating to a common project or event.

In practical terms, it could be understood to be either the root Object in the tree (so that the tree can be crawled downward via replies), or it could be a Collection, or it could be something else entirely (e.g. a pseudo-object meant to identify a conversation and nothing more). I would personally say that it would be better to at least make sure that context can be something resolvable instead of a pseudo-object, and I have a weak preference to using the root object insofar as the current fediverse relies on replies for threading rather than having a discrete “thread” as in forums. Although, the root Object could be a Page that is part of a forum, were there to be such a forum software implementing ActivityPub…

7

Hello everyone,
just wanted to mention that the use of the context field is what we talked about in the last 2 meetings. There is a small text by @cpmoser in

and we will go on with Groups / Relationship and Context on TUE 12th

8

On the original topic:

Zap derivatives set context ; and fetching the context id from one of our servers returns a collection containing the entire (referenced) conversation tree from its root. I don’t know of any other projects currently doing this; which is unfortunate because conversation completion from fragmented comments was not given the importance under ActivityPub that it deserves.

Using it to perform fetches of other contextually related information is fine with me, so long as it doesn’t break this usage model.

‘ostatus:conversation’ is also currently supported, but deprecated; as usage of that protocol continues to wane.

1 Like
9

There is some discussion currently around whether context is the appropriate property for this, as there does seem to be a need to differentiate “authoritative context in which this object exists” and “collection of all activities surrounding some common origin”.

Perhaps the former is more appropriate for context and the latter should be provided via an extension property? Something like conversation or thread would be more explicit.

For example, consider a somewhat tangential issue of having authorized replies or interactions. An immediate obvious question would be, “on whose authority”? Do you defer to the immediately-replied-to actor’s authority, or do you defer to the root post / originating actor’s authority? This concept of an “authoritative context” is necessary to properly model the concept of “comments” as opposed to “replies”.

It seems like context is the most natural way to express, well, the “context”. Having the collection of related activities be served via conversation would mean less ambiguity in what is already an “intentionally vague” property definition. Heck, maybe even the former sense of “authoritative context” could be better expressed by some other property name, although I am drawing a blank right now.

10

brainstorming: there are 3 different meanings of “context”

  1. existing in “context” of another object (authoritativity)
  2. grouping together activities related to a common originating “context” (commonality)
  3. grouping together objects within a conversational “context” (topicality)

2 and 3 are similar but i can see value in having either/both a collection of interactions and/or a collection of just the objects. it is 1, however, that i’m interested in, and it is a pressing and relevant issue for the proposed “reply controls” feature that mastodon is interested in: Enable Twitter-style Reply Controls on a Per-Toot Basis · Issue #14762 · mastodon/mastodon · GitHub

incidentally, the difference between this proposal and the existing way things are done currently, is that currently the only implementations caring about reply control are explicitly using the “comment” conceptual model, where replies are child objects existing in the authoritative context of some parent, but they don’t signal this “context” because context is instead used in the sense of commonality (type 2 above). this proposal uses an explicit Accept Note and is currently lacking a way to determine authority; authority is assumed to belong to the object you are immediately replying to, and not the root post. ideally there would be a way to model both; context seems best to me but i’m not sure.

EDIT: maybe the following?

  1. parent = if set, denotes ownership by this object in an authoritative “context”
  2. history = a Collection of activities with the same target or originating “context”
  3. conversation = a Collection of objects within the same thread or conversational “context”