This proposal introduces an ActivityPub extension to improve reply distribution.
It allows a reply (comment) to be addressed directly to the original post author’s followers collection,
so that followers of the original author can receive the reply.
This behavior aligns with how networks like Diaspora and Friendica distribute comments,
and aims to enhance conversation visibility across federated servers.
A new flag in NodeInfo metadata advertises support for this extension.
Servers implementing this FEP can thus coordinate reply delivery:
if both servers support it, a reply will be forwarded to the original author’s followers automatically; otherwise, the sender can fallback to standard distribution.
Hi Dima, as I understand it, you can put OP's followers collection in the recipients list, and as per protocol the originating server should forward along the replies.
Yes - ActivityPub §7.1.2 does define “forwarding from inbox” so that a reply addressed to OP/followers should be fanned-out by the OP’s server.
Why the FEP is still useful
Poor real-world support
In practice many servers (notably most Mastodon forks) don’t add OP/followers to the audience and don’t forward such activities when they arrive. If I’m wrong and there’s broad support, please point me to examples.
Capability signalling
The FEP adds a simple NodeInfo flag ("repliesTargetAuthorFollowers": true) so a sender can know in advance whether the OP’s server will forward the reply; if the flag is missing, the sender can fall back to manual fan-out.
Safer forwarding rules
§7.1.2 can be abused for spam because its conditions are easy to satisfy:
activity is new to the inbox
activity addresses a local collection (e.g. any followers list)
activity references some local object in inReplyTo
A spammer can fake those three and force delivery to thousands of followers.
The FEP suggests tightening this by forwarding only if
the replied-to object was itself addressed to that followers collection, and
the replier is in the original post’s audience (or is the OP).
Those stricter checks could be folded into the spec or a future revision of the FEP.
So while §7.1.2 has the right idea, the FEP provides (a) a way to tell who actually supports it, (b) a sender-side fallback, and (c) a pathway to stricter, spam-resistant forwarding.
That FEP describes a similar mechanism, where audience is preserved throughout the thread, but Add activity is used instead of inbox forwarding. Conversation containers are used by Hubzilla and Streams (Friendica's successors).
I know 171b - it’s aiming for the same end goal (preserve audience across a thread), but it takes a very different route.
As you said 171b works in Hubzilla/Streams, but AFAIK Mastodon doesn’t implement it at all.
c313 is much lighter weight and Mastodon-compatible: it just uses the existing inbox forwarding in §7.1.2, explicitly puts OP/followers in the audience, adds a NodeInfo flag so the sender can detect support, and defines stricter spam checks. It can be adopted incrementally without changing Mastodon’s conversation model.
So, overlap in goal but not in mechanism. 171b is more comprehensive, c313 is a pragmatic step that works for the current Mastodon ecosystem. There’s room for both - servers could support either or both - but c313 solves the problem for Mastodon today, while 171b would need bigger changes.
I know 171b - it’s aiming for the same end goal (preserve audience across a thread), but it takes a very different route.
@skavish Is it really that different? The only substantive difference I see is the use of inbox forwarding instead of an Add activity.
FEP-171b has a DRAFT status, we're still working on it and may add inbox forwarding as an alternative distribution method.
It can also be implemented incrementally, for example in my project I implemented it without fully switching to contained conversations and without publishing the activity collection.
adds a NodeInfo flag so the sender can detect support
I don't recommend doing this, by the way. NodeInfo is optional protocol used to publish instance statistics, it is not related to ActivityPub.
Appreciate the clarification, I hadn’t looked closely at 844e but it does seem like a more appropriate fit than NodeInfo for capability signalling. Thanks for pointing that out.
As for the difference between 171b and c313: I agree the mechanisms aren’t wildly far apart, and it’s great to hear you’re exploring inbox forwarding as an option for 171b. That said, my main motivation for c313 was Mastodon compatibility - something that could work today without requiring changes to conversation structure. I see 171b as more powerful long-term, and I’d likely use it where full audience continuity is needed. For now, I’m planning to support both: c313 for interoperability with Mastodon, and 171b where conversation containers make sense.
If Mastodon doesn't support forwarding delivery to local collections, then you're still facing an uphill battle getting Mastodon to support your FEP, no?
In which case wouldn't it be roughly equivalent to get Mastodon to support 7.1.2 of the AP spec?
Good question - honestly, my immediate goal wasn’t to get Mastodon itself to adopt this, but to have it work reliably at least between our own servers, while still being compatible with popular software like Mastodon if they ever did support it.
I’m not counting on Mastodon implementing it, and I’m not trying to “fix” 7.1.2 in Mastodon. I just wanted something that works now for the environments I control, but doesn’t break federation with the wider network.
As far as I’m aware, addressing someone else’s followers collection should be something you can just do always in every case. If it’s understood and allowed, it can be forwarded. If it’s not, then that one addressee usually gets ignored and other recipients will still receive the activity. The only question is if you want your own followers to receive it as well (or not).
Yes, you can address someone else’s followers collection, but in practice it doesn’t work with Mastodon, it ignores that audience. I don’t want to send that reply to my own followers instead, it just doesn’t make sense: I’m replying to a post addressed to the OP’s followers, so my reply should have exactly the same audience.
Right, so the fallback would be that Mastodon thinks it’s a “limited” post (which is somewhere between “direct” and “followers”). If/when Mastodon updates to support forwarding, it should be made available to other people.
The fallback seems very tricky to me, it’s not directly comparable to any of the existing Mastodon levels. How do friendica / Hubzilla / etc represent this, and how does it interact with Mastodon?
It’s also important to think about how it chains. If a reply falls back to “Limited” (aka “quiet public”), it would be very unfortunate if the original poster’s reply (in a thread originally limited to their followers) somehow became more visible.
You’re thinking of “unlisted”, not “limited”. Mastodon has supported limited audiences since about 2018, but they get rendered in the API as followers-only posts and behave like direct posts.
To be clear, Mastodon has 5 visibilities currently:
public (aka Public)
unlisted (aka Quiet Public)
followers (aka Followers-Only)
limited (not used in the API)
direct (aka Specific People)
Notably, while Mastodon supports receiving and storing limited audience posts, they don’t support forwarding or publishing those posts… yet
It still seems like adopting 7.1.2 as written is a more viable path forward. skavish noted that they're not intending to rely on Mastodon to support 7.1.2 or this FEP, but rather to improve instance to instance communication on their platform.
Although to be fair I haven't thought through the potential implications they mentioned re: spam controls. Could be this FEP could build upon the protocol as is and supply security best practices instead.
a, Mastodon supporting limited audiences is new to me, perhaps we can discuss it separately from this topic!