FEP-7888: Demystifying the context property

Standards Fediverse Enhancement Proposals
6

current use of context

I guess I can add something like that, yeah. As far as I know, the context currently goes largely unused:

  • Pleroma attaches it as a tag that is not meant to resolve, similar to ostatus:conversation, and then it gets ignored because constructing threads is largely based solely off of inReplyTo in Mastodon et al.

From Mastodon:

  "conversation": "tag:mastodon.social,2023-03-17:objectId=416298421:objectType=Conversation",

From Pleroma/Akkoma:

  "context": "https://skinnyver.se/contexts/e085588b-cc4e-4a98-8a6d-7dc015c33135",
  "conversation": "https://skinnyver.se/contexts/e085588b-cc4e-4a98-8a6d-7dc015c33135",

Failing to resolve that context:

$ curl -H 'Accept: application/activity+json' https://skinnyver.se/contexts/e085588b-cc4e-4a98-8a6d-7dc015c33135

<!DOCTYPE html><html lang=en>...<noscript>To use Akkoma, please enable JavaScript.</noscript>...</html>
  • Streams attaches it on posts and activities
"context": "https://macgirvin.com/conversation/399fba05-68ad-40c7-902b-57c0518547b1",

this actually resolves. it is an OrderedCollection with all activities as seen by the origin. abbreviated response:

  "id": "https://macgirvin.com/conversation/399fba05-68ad-40c7-902b-57c0518547b1",
  "type": "OrderedCollection",
  "totalItems": 13,
  "orderedItems": [
    {
      "type": "Update",
      "id": "https://macgirvin.com/activity/399fba05-68ad-40c7-902b-57c0518547b1",
      "context": "https://macgirvin.com/conversation/399fba05-68ad-40c7-902b-57c0518547b1"
      "object": {
        "type": "Note",
        "id": "https://macgirvin.com/item/399fba05-68ad-40c7-902b-57c0518547b1",
        "context": "https://macgirvin.com/conversation/399fba05-68ad-40c7-902b-57c0518547b1",
    },
    {
      "type": "Create",
      "id": "https://rumbly.net/activity/4f392617-57a6-4a51-90f8-9c4440640aea",
      "context": "https://macgirvin.com/item/399fba05-68ad-40c7-902b-57c0518547b1",
      "object": {
        "type": "Note",
        "id": "https://rumbly.net/item/4f392617-57a6-4a51-90f8-9c4440640aea",
        "published": "2023-03-17T21:26:33Z",
        "attributedTo": "https://rumbly.net/channel/giacelvecio",
        "inReplyTo": "https://macgirvin.com/item/399fba05-68ad-40c7-902b-57c0518547b1",
        "context": "https://macgirvin.com/item/399fba05-68ad-40c7-902b-57c0518547b1",
    },
// ...

representing “forums” with FEP-1b12

i could add a reference to other tangential FEPs within 7888, but the point of context is not just to represent “forums”. it is a general definition for representing any logical grouping. “this object is part of this collection”, if that context is a collection. or, inversely, “a collection may be created containing all objects referencing this context” would be the weaker definition.

incidentally, i consider “forums” to be currently unimplemented in activitypub, because 1b12 only loosely represents announce-bots that boost anything sent to them. it’s a model that has better compatibility with what currently exists, but it has many shortcomings that make it unsuitable for organizing and grouping information.

it also fails to account for generic activitypub servers, which might interpret audience as meaning “only the group actor can view this” and refuse to serve the objects to anyone else.

specifying Add to Collection, or inbox forwarding, as an alternative to Announce

add to collection

Add is exactly what it sounds like, and it is already defined in ActivityPub. it would look something like this:

id: ...
actor: alice
type: Add
object: <some-object>
target: <some-collection>

per ActivityPub

7.8 Add Activity

Upon receipt of an Add activity into the inbox, the server SHOULD add the object to the collection specified in the target property, unless:

  • the target is not owned by the receiving server, and thus they can’t update it.
  • the object is not allowed to be added to the target collection for some other reason, at the receiver’s discretion.

so basically the target collection should be owned by the recipient and the recipient also has the option to verify this.

basically we don’t have to be passing around exclusively Create activities. in some ways, a Create activity is actually worse, because it doesn’t represent what is really going on semantically. FEP-400e shows this by trying to use target on objects where they are only defined for activities; it does this because the primary activity is a Create, and target doesn’t really make sense on a Create either. it makes sense on Add and Remove, though, so why not actually use Add and Remove?

inbox forwarding

it’s not spelled out explicitly in the activitypub spec, but i think inbox forwarding is basically just POSTing to some other inbox exactly what you received. say you receive a Create Note and it addresses your followers. you can choose to forward that Create Note exactly as you received it, by sending it to your followers as-is.

typically, this requires some signature mechanism to prove the activity came from the original actor. but this is only really needed for private activities. public activities might reasonably be fetched from the origin if they are fetchable. say you want to forward a Like, and the Like isn’t public. you would need a signature on it (and for all participants to agree on a common signature mechanism)

where i’m going with this

i am approaching this problem from purely theoretical terms, as a shortcoming of the ActivityStreams specification, where they left the definition “intentionally vague” to the point of being useless. as a consequence, the FEP is not an implementation guide but rather a spec definition. it is of course up to Lemmy to choose whether a spec should or should not be followed, or if “real-word” compatibility is more important. my aim is to provide spec language that can be followed, and if followed, it would improve compatibility by eliminating the implementation-specific hacks that arise purely from implementation-specific abstractions.

i “plan” (hopefully!) to pave the way for generic activitypub servers that do not know and do not need to know what a “group” is. what is needed is standardized behavior around adding things to collections or logical groupings, which is what a “context” is. the “further FEP” mentioned will be to do the following:

  • prove that an object is part of a context it claims to be part of (alternative to FEP-5624’s approval or replyApproval)
  • signal who can participate in a context (similar to 5624’s canReply; i’m not yet sure if audience can do this, as there still needs to be a way to control who can see the context at all)

audience as the group actor vs audience as scoping

it is compliant, but it does not mean what you think it means. the use of audience is to scope objects to a particular audience, i.e. who is intended to see it. Activity Vocabulary

if you were to actually implement such scoping, this would mean that only the Group actor should see the activity. the Group’s followers should not be able to see it.

multiple types

type is not functional, and you should be checking for inclusion in that set, not an exact match. anything not marked “functional” in AS2-vocab can have multiple values. other examples of this include multiple actor, multiple object, multiple attributedTo, multiple inReplyTo, even multiple context. doubtless any or all of these might break existing implementations due to their (terribly incorrect) assumptions.

the advantage to having multiple types is apparent once you consider extensions. if you say type is a single value, and you actually check for type, then you are now responsible for understanding every single extension type that may ever exist, as well as all of its implications.

an example of this is OrderedCollection, which specifically guarantees that the “order” of the collection is “reverse chronological”. if you have this guarantee, you can do things like fetch only the newest pages from the start until you encounter something you’ve already seen. (there might still be gaps, but if you don’t care about gaps, you can stop there.) if you have an extension type that satisfies this requirement, you have no way of signaling this to unaware consumers. say we defined a ForumTopic/ChatRoom/SocialMediaThread type or something similar. what would this mean to us, and what would this mean to a consumer? to us, we would define the type as a Collection that contains objects and activities, and not other Collections. the ordering may or may not be reverse-chronological; it may in fact be forward-chronological. if we wanted to signal both “this collection is terminal and does not contain any other collections” as well as “this collection is ordered reverse-chronologically”, we would need to declare both types.

another example: what if an account represents both an organization and an automated application? do you declare it to be an Organization, or an Application? the former means it won’t have a “bot” indicator and the latter means it won’t have an “org”/“brand” indicator. you might reasonably want both signals. your only other option is to define an extension type like UnmonitoredBrandAccount, and good luck getting that recognized.

more generally, a “type” should be thought of as an interface that can be satisfied. in computer science terms, a type is a set containing all possible values, and satisfying the type interface means being a member of that set. the activitystreams actor types are not really “types” in this sense, but more like vcard “kinds”. you have the following “type” interfaces in activitystreams/pub:

  • Link = has href
  • Object = doesn’t have href
  • Activity = has actor and object
  • IntransitiveActivity = has actor but no object
  • “actor” = has inbox + outbox
  • Collection = has items or orderedItems
  • OrderedCollection = the orderedItems are ordered reverse-chronologically
  • CollectionPage = has partOf + has items or orderedItems
  • OrderedCollectionPage = has partOf + the orderedItems are ordered reverse-chronologically

any assumptions beyond these are incorrect and have no justification. famous examples of wrong assumptions include “an actor must be one of the five extended actor types” or “tag must contain only Mention or Hashtag or Emoji”. this kind of fragility arises mainly when an implementation thinks about its business logic more than it thinks about the spec, and so it compromises the latter in order to contort it to fit the former.

misconceptions

yes, i am aware. this behaviour is also used by Guppe, and could be used by bots implementing the mastodon api to talk to mastodon/pleroma, or could be used by bots implementing the misskey api, and so on. in all of these cases, they are reshares. reshares are not the aim of this FEP; this FEP operates on objects and collections (or objects and logical groupings, if there is no resolvable collection).

FEP-7888 does not define “forum” so much as it defines “context” which can be used to represent a forum as a collection of threads/topics. the keyword here is “collection”.

for ownership, you still use attributedTo. you can update the attributedTo on the collection just like you can on the Group actor. whoever owns the collection is in charge of distributing the Add/Remove activities to maintain that collection.

these are all implementation details – the title would be name, the description would be summary, the icon would be icon, none of these things are different than the general pattern for any other object. i’m not sure of any other limitations, but if you find any more please let me know so that i can address them or clarify the FEP language.

“switching to this federation model” doesn’t actually represent a major change, as it’s something that should be supported by plain activitypub. think of it like this: after you create an object, what do you do? you might add it to a collection, right? the only real “switch” in this case would be to maintain this collection instead of expecting everyone else to maintain it ad-hoc for themselves anyway, as we currently do. this can be done by sending out Add activities either instead of or in addition to the existing Announce flow.

hopefully i’ve shown by now that i do not wish to implement “group federation”. you might think of it as “collection federation”, where the collection is possibly being managed by some authority who gets to decide what’s in the collection. this collection might be any number of things, not limited to groups or forums but also representing chat rooms or comment threads or social media walls. it does not matter what type the owning actor is – they may be a Group actor, they may not be! it’s irrelevant – what matters is the general behavior of maintaining some authoritative collection (and signaling its moderators). it’s worth the effort to not limit ourselves to Create Note or in some cases Create Page. you should be able to browse the actual objects just like anything else on the World Wide Web.

2 Likes