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 
Please let me know if you notice any issues. Thanks!
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
toorcc
This might cause issues because ActivityPub requires servers to expand collections:
If a recipient is a
CollectionorOrderedCollection, then the server MUST dereference the collection (with the user's credentials) and discover inboxes for each item in the collection.
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.
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
Apologies for the long delay here, this is five months late. You’re right: dereference is a MUST, not an implication, and it applies to any collection in to/cc.
I’ve since updated the draft to drop that idea entirely. Senders now MUST NOT put the context URI in to/cc; they use ordinary addressing and deliver to the root author’s inbox, which fans out to the audience. That’s effectively your suggestion - address context.attributedTo and let the owner forward to the private audience without leaking it, plus an author-level integrity proof so the owner can rewrite addressing on forward without breaking the author’s signature.
On a related note: why propose this instead of building on FEP-171b (Conversation Containers), since they tackle the same problem? The short answer is interop with software that exists today.
8c13 forwards native activities with ordinary to/cc, so a current Mastodon server just sees a normal Create/Like in its inbox, it renders the reply and can reply back to the addressed author with no code changes. 171b requires every participant to understand the Add(Activity) wrapper and container semantics; a server that doesn’t gets activities it can’t process, so it can’t really participate.
The trade-off is that integrity-protected fan-out needs the FEP-8b32 proof, which current servers don’t produce, so Mastodon reply isn’t fan-out-eligible. But it degrades gracefully: legacy servers still receive forwarded replies and can reply into the thread; they just can’t originate protected fan-out. So adoption is incremental and the existing software keeps working instead of requiring a new contract up front.