It was a poorly implemented feature that was never communicated and when said feature failed to function outside of the specific instance it was designed for, people threw shit. That’s not a bug. If anything its an integration failure. A failure that is entirely the fault of the mastodon instance team. Calling it a vulnerability is fuckin wild.

They’re really not.

Here’s the relevant docs, and a little summary of how they relate to private posts and Mastodon’s specific implementation of them.

Specs: https://www.w3.org/TR/activitypub/#delivery

Mastodon code where you can verify that this is how they are handled: https://github.com/mastodon/mastodon/blob/main/app/lib/activitypub/tag_manager.rb (look at the cc() and to() functions)

Overall summary in detail:

---

ActivityPub Specification

What ActivityPub Explicitly Mandates

1. Audience Targeting (Section 5.1):

   • Activities must include audience targeting fields (to, cc, etc.)
   • Servers must deliver activities to the specified audiences

2. Public Posts (Section 7.1.2 and 7.1.3):

   • Activities addressed to the Public collection must be delivered to all followers
   • Servers MAY deliver Public activities to all known sharedInbox endpoints

3. Filtering (Sections 5.2 and 7.1.2):

   • Servers SHOULD filter inbox content according to the requester’s permissions
   • Servers MAY filter delivery targets according to implementation-specific rules

4. Privacy of Non-Addressed Content (Section 7.1 Note on “Silent and private activities”):

   • For activities with no recipients, it’s “recommended” (not required) that objects remain private
   • An activity sent only to the “public” collection should be viewable in the actor’s outbox but not delivered to any actors

What ActivityPub Leaves Undefined

1. Visibility Levels:

   • No explicit definitions for “public,” “unlisted,” “private,” or “direct” as formal visibility modes
   • No mandatory behavioral requirements for different audience targeting patterns

2. Privacy Enforcement:

   • No explicit requirements for how receiving servers should restrict visibility based on audience fields
   • No requirements that servers must hide content from non-addressed users

3. Timeline Placement:

   • No specification about which posts should appear in public timelines vs. home timelines

Mastodon’s Implementation

Visibility Levels in Mastodon

Mastodon implements four primary visibility levels:

1. Public

   • UI Name: “Public”
   • ActivityPub Implementation:
     • to: [“https://www.w3.org/ns/activitystreams#Public”]
     • cc: [“https://example.com/users/username/followers”]
   • Behavior: Visible to everyone, appears in public timelines

2. Unlisted

   • UI Name: “Unlisted” or “Quiet public” (newer versions)
   • ActivityPub Implementation:
     • to: [“https://example.com/users/username/followers”]
     • cc: [“https://www.w3.org/ns/activitystreams#Public”]
   • Behavior: Visible to everyone but doesn’t appear in public timelines

3. Private

   • UI Name: “Followers-only”
   • ActivityPub Implementation:
     • to: [“https://example.com/users/username/followers”]
     • cc: [] (empty)
   • Behavior: Only visible to followers

4. Direct

   • UI Name: “Mentioned people only”
   • ActivityPub Implementation:
     • to: [array of mentioned user URLs]
     • cc: [] (empty)
   • Behavior: Only visible to mentioned users

Key Implementation Details

1. Visibility Through Addressing:

   • Mastodon uses the to and cc fields to indicate intended visibility
   • The presence and position of the Public collection determines visibility level
   • No explicit “visibility” property is included in ActivityPub messages

2. Convention-Based Visibility:

   • The difference between “public” and “unlisted” is determined by whether the Public collection is in to (public) or cc (unlisted)
   • This is a convention defined by Mastodon, not explicitly required by the spec

---

I also sent a user-targeted explanation of how Mastodon’s privacy settings work, that might be helpful for you to read. You can probably find it in my profile.