ActivityPub Server’s Custom Reply‑Control Extensions Undermine Federation

It seems like Activitbypub developers are extending ActivityPub with optional metadata to fix a lot of its issues, but that is still problematic. Trying to add moderation tools and user control to threads seems to be the ongoing battle. I am fascinated by dumpster fires, so I’ve started looking at the ActivityPub protocol in detail. I tend to become fascinated with things that are going down in flames.

As a brief recap of the problem:

So, one of the very popular features on Bluesky—also popular on Twitter—is the ability to select who can reply to a post. A major issue in the Fediverse is the inability to decide who can reply, and once you block someone, their harassing reply is still there. I honestly thought it was simply a case of them choosing not to add or address it for cultural reasons. What is clear from that thread is that they were always aware that the ActivityPub protocol and most Fediverse implementations don’t provide a universal way to control reply visibility or enforce blocks across instances.

An ActivityPub server that has reply control is GoToSocial. ActivityPub, as defined by the W3C specification, standardizes how servers federate activities. It defines actors, inboxes, outboxes, and activity types (Create, Follow, Like, Announce, etc.) expressed using ActivityStreams 2.0. It also specifies delivery mechanics (including how a Create activity reaches another server’s inbox) and how collections behave.

The specification does not include interaction policy semantics such as “only followers may reply” or “replies require manual approval.” There is no field in the normative vocabulary requiring conforming servers to enforce reply permissions. That category of rule is outside the protocol’s defined contract.

GoToSocial implements reply controls through what it calls interaction policies. These appear as additional properties on ActivityStreams objects using a custom JSON-LD namespace controlled by the GoToSocial project.

JSON-LD permits additional namespaced terms. This means the document remains structurally valid ActivityStreams and federates normally. The meaning of those custom fields, however, comes from GoToSocial’s own documentation and implementation. Other servers can ignore them without violating ActivityPub because they are not part of the interoperable core vocabulary.

Enforcement occurs locally. When a remote server sends a reply—a Create activity whose object references another via inReplyTo—ActivityPub governs delivery, not acceptance criteria. Whether the receiving server checks a reply policy, rejects the activity, queues it, or displays it is determined in the server’s inbox-processing code. The decision to accept, display, or require approval happens after successful protocol-level delivery. This behavior belongs to the application layer.

These are server-side features layered on top of ActivityPub’s transport and data model that are not actually part of ActivityPub. The protocol ensures standardized delivery of activities; however, the server implementation defines additional constraints and user-facing behavior. Two GoToSocial instances may both recognize and act on the same extension fields. However, a different implementation, such as Mastodon, has no obligation under the specification to interpret or enforce GoToSocial’s interactionPolicy properties. These fields function as extension metadata rather than protocol requirements.

The semantics of GoToSocial are not part of the specification’s defined vocabulary and processing rules for ActivityPub. They no longer operate purely at the protocol layer; it has become an application-layer contract implemented by specific servers.

Let’s use the AT Protocol as an example. Bluesky’s direct messages (DMs) are not currently part of the AT Protocol (ATProto). The AT Protocol has nothing that specifies anything for DMs, so DMs are not part of the AT Protocol. The AT Protocol was designed to handle public social interactions, but it does not define private or encrypted messaging. Bluesky implemented DMs at the application level, outside of the core protocol. DMs are centralized and stored on Bluesky’s servers. What is happening with servers like GoToSocial is sort of like that. The difference is that the AT Protocol was designed for different app views; ActivityPub was not.

The issue is the divergence in semantic interpretation that emerges at the interpretation layer. ActivityPub standardizes message delivery and defines common activity types. However, it leaves extension semantics and application-layer policy decisions to individual implementations. Servers may introduce custom JSON-LD namespaces and enforce local behaviors, such as reply restrictions, while remaining protocol-compliant. But, the noise created by divergences are problematic, because it creates unexpected, unintended, and unpredictable behavior.

Divergence appears when implementations rely on non-normative metadata and assume reciprocal handling to preserve a consistent user experience. Behavioral alignment then varies. Syntactic exchange succeeds, but behavioral consistency is not guaranteed. Though instances continue to federate at the transport level, policy semantics and processing logic differ across deployments. Those differences produce inconsistent experiences and results between implementations.

That leads to fragmentation, specifically semantic or behavioral fragmentation and an inconsistent user experiences. ActivityPub ensures syntactic interoperability, but semantic interoperability (everyone interprets and enforces rules the same way) varies. This creates a system that is federated at the transport level yet fragmented in behavior and expectations across implementations. It is funny how the thing that the fediverse touted has made the entire thing very brittle. ActivityPub technically federates correctly, but semantically falls apart once servers start adding their own behavioral rules.

LOS HERMANOS DE HELIÓPOLIS

“Our task is not to indiscreetly disclose the secrets of the Art, but rather to guard them faithfully, that the Brethren of Heliopolis may at some future hour receive this synthesis and, in due course, carry on the doctrine.”

#AIart + #collage

#Emblematica #Egypt #Symbolism #occult #Occulture #Illuminati #surrealism #future #newage #Pataphysics #Alchemy #Kabbalah #Magick #Chaosmagick #Fnord

FEP-171b: Conversation Containers Won’t Work

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!