So, I took a look at this:
This document specifies a model for managing conversations in ActivityPub network. It is based on the implementation of Conversation Containers in Streams.
In this model conversations are represented as collections controlled by a single actor. Such conversations take place within a specific audience and may be moderated.
FEP-171b: Conversation Containers
https://fediverse.codeberg.page/fep/fep/171b/
TL;DR: It won’t work.
The proposal introduces authoritative conversation control to ActivityPub by modeling threads as owner-managed OrderedCollection containers. The conversation owner curates replies and redistributes approved activities via Add. Participants are expected to reject unapproved content. The abstraction is internally coherent. The friction appears when this model is placed inside ActivityPub’s federated design.
Here is the problem. ActivityPub does not define enforcement semantics. Servers operate autonomously and apply local policy. A specification can say that implementations “SHOULD reject” unapproved replies. Yet nothing in the protocol requires that outcome. A server that declines to participate can still accept Create(Note) activities directly. It can reconstruct threads from inReplyTo and ignore the container model. In that environment, thread authority exists only where it is voluntarily recognized.
The delivery path changes as well. Under typical federation, actors deliver activities directly to recipients’ inboxes. Here, replies flow to the conversation owner first. Only approved entries are redistributed. Each thread effectively runs through a single coordinating node. Availability now depends on the owner’s server. If it is offline or slow to redistribute, the conversation stalls. Different redistribution behavior across instances can also produce divergent views of the same thread. This is a structural shift in how information propagates.
Ordering and consistency are less defined than the container model implies. ActivityPub does not specify global ordering or conflict resolution rules. An OrderedCollection provides sequencing, but not append-only guarantees or convergence constraints. Order might reflect author timestamps, owner receipt time, or redistribution time. The owner can reorder, omit, or later insert activities. Other servers may cache earlier states. Without cryptographic sequencing or a log structure that constrains mutation, synchronization relies on local policy rather than shared verification.
Moderation authority also changes. The conversation owner decides which activities become part of the visible thread. That may reduce unwanted replies in cooperative environments. It also concentrates control over inclusion and historical presentation. Because the container remains mutable, integrity depends on trust in the owner. It also depends on how other servers interpret updates.
The harassment issue is not actually solved. A non-adopting instance can continue storing and rendering replies it receives directly. Some servers will display only curated entries. Others will not. Over time, different thread views can coexist without converging.
Compatibility with existing implementations raises practical concerns. Most current systems build conversation views from inReplyTo chains and local storage. Introducing container-centric validation, authenticated Add wrapping, and modified inbox handling would require substantial changes. Partial adoption would produce mixed behavior across the network.
The proposal acknowledges risks such as forged or poisoned embedded updates. It also suggests validation steps. Even with those measures, the container remains mutable shared state interpreted by independent systems. ActivityPub standardizes vocabulary and delivery, but not global state enforcement. This design can improve reply gating among cooperating servers. It does not, by itself, establish authoritative thread state across a federation built on autonomous peers.
The issue with the fediverse is that they want their cake and they want to eat it, too. They like to emphasize that they are truly decentralized and use that as a way to sweep any critiques against them in relation to the AT protocol away. But being truly decentralized is the issue.
The core issue is the federated and decentralized nature of ActivityPub. The problem is that the protocol is built around autonomous servers that don’t have to obey a central authority. Each server applies its own rules and policies. Even if a specification says servers “should” reject unapproved replies, they can still accept and display them. The authority is voluntary and not enforceable. The major limitation is that state is not globally enforced. There is no mechanism to ensure that all servers see the same thread order or content. A container can sequence posts. Other servers can reorder, omit, or cache different versions. Without cryptographic or append-only logs that every node verifies, synchronization relies entirely on local trust rather than any shared enforcement.
Partial adoption makes it even more of a clusterfuck. Some servers might implement the new authoritative-thread model, while others won’t. So threads will diverge across the network, and harassment or unwanted content can still appear on servers that do not participate. The decentralized and federated design fundamentally limits any attempt to impose global authority.
No, I am not joining in on the thread, because ActivityPub devs are especially nasty. That is why no one wants to fucking work with them. That is why it’s so fucking underdeveloped.
I was going to put this into this post, but I realized it would get too long:
https://neon-blue-demon-wyrm.x10.network/archives/16790
This is a really bad situation. I have been working with the AT protocol for roughly a year, so I haven’t been keeping track of what’s been going on here. Basically, the only way to fix it is to pretty much change the expected behavior so much it is no longer recognizable. Yikes!
Fediverse Reactions
