FEP-8c13: Context-Authority Routing with Object Integrity Proofs for Restricted Threads

ActivityPub
1

I was writing a spec for how to handle replies in our project, and once I finished it, I realized it might be useful to others as well. There’s nothing fundamentally new here (as far as I know), it builds on existing specs, but brings them together into a single, coherent set of instructions with examples. It also makes certain logic and attributes mandatory (MUST) to reduce ambiguity and limit overly flexible interpretations :slightly_smiling_face:

Please let me know if you notice any issues. Thanks!

2

Replies are delivered only to the replier’s followers.
Other authorized participants (e.g.followers of the original author) do not see all replies.
The conversation splits into inconsistent partial views.
FEP-1b12 solves this for Groups by introducing a central routing actor, but there is no equivalent for ad-hoc, user-owned conversations.

The equivalent is FEP-171b: Conversation Containers. It is in fact very similar to the proposed mechanism, with two key differences:

- FEP-171b uses wrapper activities instead of forwarding
- Your FEP introduces context addressing

I think the "no equivalent" statement should be removed. It would also be nice to provide a list of differences between your proposal, FEP-1b12 and FEP-171b.

SHOULD include the Context Object URI in to or cc

This might cause issues because ActivityPub requires servers to expand collections:

If a recipient is a Collection or OrderedCollection, then the server MUST dereference the collection (with the user's credentials) and discover inboxes for each item in the collection.

-- https://www.w3.org/TR/activitypub/#delivery

3

Thanks for the feedback!

FEP-171b does address the same class of problem and should be referenced as a related approach rather than described as having “no equivalent”. I will adjust that wording and add an explicit comparison section.

The main distinction I am aiming to preserve is that 171b relies on owner-approved wrapper activities (Add) as the commit mechanism, while this proposal keeps native activities and uses context addressing plus integrity proofs to request routing by the Context Authority. This makes 8c13 behave more predictably in mixed-compliance environments, where some servers do not understand containers or wrapper semantics, but can safely ignore unknown to/cc targets and still interoperate.

Good point as well about collection expansion semantics, I will clarify the intent around including the context uri in to/cc and tighten the wording to avoid implying mandatory dereferencing.

I will incorporate these changes in the next revision.

1 Like
4

the mandatory dereferencing isn’t an implication, it’s a requirement of activitypub

the workaround here is to address not the collection itself but rather the collection’s audience (which may itself be a collection)

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "@base": "https://site.example/",
      "sioc": "http://rdfs.org/sioc/ns#"
    }
  ],
  "id": "conversations/foo",
  "type": ["OrderedCollection", "sioc:Thread"],
  "orderedItems": [
    "posts/1",
    "posts/2",
    "posts/3"
  ],
  "sioc:container_of": [
    {"id": "posts/1"},
    {"id": "posts/2"},
    {"id": "posts/3"}
  ],
  "audience": {
    "id": "audiences/bar",
    "type": ["Collection", "sioc:UserGroup"],
    "items": [
      {"id": "users/1"},
      {"id": "users/2"},
      {"id": "users/3"}
    ]
  },
  "sioc:has_subscriber": [
    {"id": "users/1"},
    {"id": "users/2"},
    {"id": "users/3"}
  ],
}

so in this case you wouldn’t address <conversations/foo>, you’d address <audiences/bar>

in practice, https://w3id.org/fep/7888 recommends considering context.audience and/or context.followers for additional relevant addressing. for private audiences, you should probably also address context.attributedTo so that they can forward to the private audience without leaking any info