Spec allows conflation of public and publicized without informing users

[dclements]

From section 7.1.3:

Additionally, if an object is addressed to the Public special collection, a server MAY deliver that object to all known sharedInbox endpoints on the network.

Emphasis mine.

This creates a situation where a user does not know and cannot be expected to reasonably know how their post is going to be handled ahead of time. It conflates "Public" and "Publicized" and it does it in a way that the only way for an end user to know which behavior will be employed (delivery to all known sharedInboxs or not) is to read the source code for every single version of the software that they end up using.

This problem is exacerbated by how implementations use this field. For example any 'public' post on mastodon gets something along the lines of:

"cc":["https://www.w3.org/ns/activitystreams#Public"

There are several possible resolutions to this problem.

1. Remove the line entirely. This is the least satisfying answer, but it is an answer.
2. Define different privacy classes, allowing a user to specify whether it can get pushed to sharedInbox endpoints that are not part of the address fields (target/audience/to/etc). This could either be done directly or via specifying behavior distinctions for where and how the "#Public" group is addressed.
3. Change it from a MAY to a MUST/SHOULD in the context of federated networks. If I know that "Public" means "will be sent to shared inboxes I did not specify" then I can make a determination based on which behavior I want as a user with no surprises.

[nightpool]

Although the spec is written from the perspective of completely separated clients and servers, there is no popular, currently in-use implementation that I'm aware of where users/clients participate in the authoring of activities and then hand them off to servers for delivery. While I could be led to agree that in this case the conflation of the two may be problematic for clients who might not be able to explain to their users which activities would be published where, in the current world, this requirement has basically no effect because integrated servers author the activities and then deliver them in a single breath. There is no requirement we can put on an "integrated server" like this to change their behavior, since they're authoring the activity at the exact same time as they deliver it. Changing this requirement would only introduce churn and potential backwards incompatibility (if done by adding a new "special" collection that replaces as:Public) and would provide no end-user benefit.

[cristianolongoodhl]

I suppose that Public means public, in the sense that anyone which get in touch with it can do with it whatever she want.

[evanp]

I agree that this is an important topic that balances out users' expectations against the implementation details.

I think the state of the art today is that "to": "Public" means that the activity should be delivered far and wide, and "cc": "Public" means it should be left out of feeds that aren't the home feed of followers (say, "local" or "federated" feeds). This is called "unlisted" in Mastodon. This is not well documented.

Another level of less publicness is having activities that are readable but not published into the feed -- say, not delivered. This is a behaviour that some systems like Strava have. We don't have yet have a mechanism for doing this.

Also possible to include in tag aggregations, but not to followers.

I like the idea of including other "standard" addressees, maybe with more fine-grained control of delivery. I think "Public" right now means "whatever ActivityPub says Public means", so there's not much use trying to put that genie back in the bottle. However, we can start expanding our ideas for what readability and delivery are supposed to mean.

One final usage is to separate the concepts of ''delivery'' from the concept of ''visiblity''. I think this was the original meaning of audience, but it was added as a deliverable address in ActivityPub. We could add another property like readableBy to our vocabulary, and behaviour could work like this:

{
   "@context": [ "https://www.w3.org/ns/activitystreams", "https://extension.example/ns/readable" ],
   "type": "Create",
   "id": "https://social.example/users/evanp/create/1",
   "actor": "https://social.example/users/evanp",
   "to": [ "https://social.example/users/evanp/followers" ],
   "readableBy": [ "https://www.w3.org/ns/activitystreams#Public" ],
   "object": {
      "id": "https://social.example/users/evanp/note/1",
      "type": "Note",
      "content": "hello, world"
   }
}

[trwnh]

The core of the issue is that sharedInbox isn't attached to any actor and therefore you can't as a user/client "address" an actor that doesn't exist. You would need to define clearer semantics for "to"/"cc" and to:Public vs cc:Public especially as it relates to "deliver to all sharedInbox" behavior. There's some precedent in mastodon's "unlisted" and youtube "unlisted" as well for different UX-level expectations around where posts are visible.

Tangentially, another issue is that there isn't a way to express visibility as separate from delivery. Evan describes potential extension approaches above.

Another tangential issue: there is no explicit construct of a "feed" or "profile" for expressing all posts a user has made. There is just an implicit feed based on all received Create activities. It might make sense to consider explicitly managing a feed with Add/Remove instead, have it be a Collection and check that instead of outbox or your local cache