Following conversations across the Fediverse

calendar_today holos activitypub fediverse fep

You come across a post on the Fediverse and a discussion starts in the replies. But ActivityPub only delivers replies to the parent post author and to the replier’s followers. If you are on the same instance you may see them through the local timeline, but across instances, replies from accounts you do not follow never reach you. No Fediverse server offers a way to subscribe to a thread. Holos aims to fix this in a way that works with the protocol, not around it.

Follow-a-Note: using what ActivityPub already has

The ActivityStreams 2.0 specification defines a Follow activity. Most people think of it as following a person, but the spec does not restrict it to actors. You can send a Follow targeting any object, including a Note (a post).

The idea is simple. You want to follow a thread: your server sends a Follow activity to the server hosting the root post. If that server understands the request, it accepts and starts delivering new replies to your server. If it does not understand, nothing breaks. Your app falls back to a different method.

Here is what the activity looks like:

{
  "type": "Follow",
  "actor": "https://example.com/users/alice",
  "object": "https://example.org/users/bob/statuses/12345",
  "endTime": "2026-06-18T00:00:00Z"
}

A few things to note:

  • The object is a post URL, not a person.
  • endTime is a standard ActivityStreams property. It tells the remote server when to stop delivering replies. Threads do not live forever, so follows should not either. The default in Holos is 7 days, but the user can choose.
  • Undo Follow works the same way as unfollowing a person.

Threads are not forever

Most conversations on the Fediverse are active for a few hours or days. After that, new replies are rare. A thread follow that stays active indefinitely would just accumulate silently on the remote server, with no benefit to anyone.

That is why endTime matters. It keeps things clean on both sides: the remote server knows when to stop delivering, and the client knows when to remove the thread from its watch list. When the user follows a thread in Holos, they pick a duration (from one hour to 30 days, or permanent). The default is 7 days. If a thread gets active again, the follow can always be renewed.

A new property: threadRoot

One challenge with thread following is figuring out which thread a reply belongs to. ActivityPub only has inReplyTo, which points to the direct parent. To find the root of a thread, you have to walk the chain, fetching each parent until you reach the top.

The idea here is to introduce a new threadRoot property on replies. This is a proposed extension, not part of the current ActivityStreams vocabulary. It would be defined in a dedicated JSON-LD namespace as part of the FEP. When a server sends out a reply, it includes the URL of the root post:

{
  "type": "Note",
  "inReplyTo": "https://example.com/posts/456",
  "threadRoot": "https://example.com/posts/123",
  "content": "..."
}

This makes matching easy. When a server receives a reply with a threadRoot it knows, it can deliver it to everyone following that thread. No chain walking needed.

Servers that do not understand threadRoot will simply ignore it. JSON-LD handles unknown properties gracefully.

Respecting privacy

Not every thread should be followable. Three conditions must all be true:

  1. The post must be the root of a thread. You follow conversations, not individual replies.
  2. The post must be public. Not unlisted, not followers-only. If the author chose limited visibility, the audience should not be expanded.
  3. The author must have opted into indexing (indexable: true). This is a Mastodon extension that signals the author consents to their public posts being searchable and used by external services. If the field is missing or undefined, the thread is not followable. Consent must be explicit.

If any condition is not met, the server rejects the Follow.

For replies, the rules are slightly different. Both public and unlisted replies can be delivered to thread followers. On the Fediverse, many people reply with unlisted visibility simply to avoid noise on public timelines, not to limit who can see the reply. Excluding them would miss most of the conversation. However, the replier must also have indexable: true. If the field is missing, undefined, or false, their replies are not cross-delivered. Same rule as for the thread root: explicit consent only.

What about existing replies?

When following an actor on the Fediverse, only future posts are delivered. Past content is not sent. Follow-a-Note works the same way: after the server accepts the Follow, only new replies are pushed.

But catching up on existing replies is still possible. ActivityPub already provides a replies collection on each post. This is a standard collection that lists all known replies. The client can fetch it at subscribe time to load what was posted before the Follow.

So the two mechanisms complement each other:

  • replies collection: catch-up on existing replies (at subscribe time)
  • Follow delivery: real-time notification of new replies (after Accept)

This is consistent with how ActivityPub works today. No new mechanism is needed for the historical part.

What Holos does today (without server support)

No Fediverse server supports Follow-a-Note yet. That is expected. A new protocol feature needs time, testing, and a working implementation before anyone adopts it.

In the meantime, Holos uses what ActivityPub already provides: the replies collection. Most servers (Mastodon, Pleroma, Misskey, Friendica) expose a list of replies on each post as a standard ActivityPub collection. Holos reads that collection periodically to discover new replies.

Here is how it works in practice:

  1. You open a post’s menu and tap Follow conversation.
  2. You pick a duration (1 hour to 30 days, or permanent).
  3. Holos stores the thread root locally.
  4. At launch and during regular sync (typically every few minutes), Holos fetches the root post via ActivityPub and reads its replies collection.
  5. New replies are fetched, filtered (only public and unlisted from indexable authors), stored, and you get a notification.

This polling happens on the app side, at launch and during regular sync, with no dependency on the relay. It is not real-time, so there is a delay between a reply being posted and you seeing it. But it can work with any server, without needing any cooperation from the remote side.

The replies collection is already public. Reading it does not raise privacy concerns. And the relay proxy hides your IP, so the remote server does not know who is reading.

What comes next

When the real-time implementation is ready, Holos will send real Follow activities to remote servers. If the server accepts (because it supports Follow-a-Note), replies arrive in real time. If the server ignores or rejects, the polling fallback keeps working.

Holos will also accept incoming Follow-a-Note requests from other servers. If a remote user wants to follow a thread hosted on Holos Social, the three conditions are checked before accepting. This makes Holos a reference implementation for both sides.

A note on server sovereignty

When a reply comes from a remote instance, who delivers it to the thread followers? In the simplest model, the server hosting the thread root redistributes the reply. This is pragmatic and similar to how boosts work today, but it means one server makes delivery decisions about another server’s content.

A cleaner model would be for the replier’s server to deliver directly. The thread root could expose a followers collection (like actors do), and the replier’s server would check it and deliver on its own. Each server would only deliver its own content. This is more complex and requires broader adoption, but it respects server sovereignty better.

Both delivery approaches will be described in a FEP (Fediverse Enhancement Proposal) once the implementation is stable. In the meantime, Holos uses polling which avoids the question entirely: the client reads public collections, no server redistributes anything. The goal is not to keep this as a Holos-only feature. Thread following should work across the Fediverse, the same way following a person works across servers today.

Try it

Thread following will be available in Holos 1.10.0. The feature is accessible from the post menu and from a dedicated screen in the side menu.

Feedback is welcome on Codeberg or on the Fediverse at @HolosSocial@mastodon.social.