@trwnh @silverpill @technical-discussion "Servers" are the term in the spec for what implements the AP side-effects. If Alice's *server* has access to Bob's follower collection, then it can be resolved and processed for delivery. This doesn't mean that Alice's "outbox" (if that even exists internally beyond the HTTP endpoint) has access to Bob's followers collections. The spec actually doesn't say anything about that AFAICT.

@eyeinthesky @silverpill @technical-discussion sure, but the "server" can have any internal architecture it wants -- monolith, microservice, etc -- and at the level of HTTP (the most common instantiation of AP, because AP uses HTTP semantics), you are talking to outboxes. you could deliver to inboxes yourself (and there might be good reasons to do this instead of expecting outboxes to deliver for you!) but you don't get to talk to a "server" directly, just an HTTP Host/Resource

@eyeinthesky @silverpill @technical-discussion if you had some way of messaging a resource (via some other scheme's assumed protocol) then you could use that. but that's semantically equivalent to HTTP POST (send a message to a resource and it will process it with its own semantics)

@julian so, let's start from the beginning: this is already in ActivityPub, always has been, and removing it from ActivityPub would be a grossly backwards-incompatible change. So, I would fight very hard against even considering removing this valuable feature.

Second, a already covered some of the main use cases, and I won't reiterate them. One they didn't mention was making followers-only conversations actually useful. If I create a Note like this:

{
   "@context": "https://www.w3.org/ns/activitystreams",
   "type": "Note",
   "id": "https://social.example/note/1",
   "attributedTo": "https://social.example/user/100",
   "to": { 
       "id": "https://social.example/user/100/followers",
       "type": "Collection",
       "name": "Evan's followers'
   },
   "content": "Hello, followers!",
   "context": "https://social.example/note/1/thread"
}

A reply by one of my followers should address everyone who the original post was visible to:

{
   "@context": "https://www.w3.org/ns/activitystreams",
   "type": "Note",
   "id": "https://other.example/note/2",
   "attributedTo": "https://other.example/user/200",
   "inReplyTo": "https://social.example/note/1",
   "to": "https://social.example/user/100",
   "cc": "https://social.example/user/100/followers",
   "content": "Hello, back!",
   "context": "https://social.example/note/1/thread"
}

Another application is private groups. If the members of a group are represented as a Collection, then sending an activity to that collection is a private, members-only message. There's some discussion of this in in the Groups TF explainer:

https://swicg.github.io/groups/

Features in the ActivityPub spec were designed to be really flexible and useful beyond narrow applications, allowing interesting extensions and new kinds of interactions. "Mastodon doesn't do that" is a bad reason to not support a feature.

@julian

> group itself be the distributor

well, naturally, i would suggest addressing both the group and its members. just like you would address both a person and their followers. or a moderated conversation and its audience. the way inbox forwarding works is that someone has to do the forwarding from their inbox.

> list is hidden

you don't need to know the items. that's private info, and you just need the id to be understood by the forwarder (who will themselves know the secret items)