#activitypub thonk: delivering to a Collection is nonsensical because a Collection could be an actor. but so can a Group

basically you have implicit behavior "the Collection needs to be expanded to its items which are assumed to all be actors" just like a Group might expand to all its members (except the assumption there is a bit stronger, you can generally expect a Group's members to all be individuals?)

whereas something like WAC makes a distinction between agent, agentGroup, agentClass

i'm not actually sure how something like this could be resolved. clearly there is existing functionality that depends on expanding collections found in the audience addressing properties: specifically, the followers collection, which powers the "followers-only post" feature, which is the primary reason activitypub even got adopted by mastodon in the first place

i guess to make any transition less painful you would probably want to solve multiple problems at the same time? but part of the problem is that it’s not clear what the exact behavior of to/cc should be with respect to this other dimension of something being an actor, a group of actors (like your followers), or a class of actors (like Public). and there’s another dimension after that — splitting delivery from visibility. you can’t actually deliver to Public; it doesn’t have an inbox.

@trwnh
but there is https://codeberg.org/fediverse/fep/src/branch/main/fep/400e/fep-400e.md

@sl007 this has nothing to do with what i was talking about (addressing and delivery via to/cc)

Delivering to Collections can be ambiguous · Issue #486 · w3c/activitypub

Reference When objects are received in the outbox (for servers which support both Client to Server interactions and Server to Server Interactions), the server MUST target and deliver to: The to, bto, cc, bcc or audience fields if their v...

GitHub (github.com)

One snag I came across while modeling followable collections is that currently, you cannot address Collections without also attempting delivery to every single item in the Collection; because of this, it is impossible to Follow a Collection unless you proxy the Follow through something that is a non-Collection actor... which there isn't a clear way to do, because there isn't a clear way to follow non-actor objects in general

I am not sure how feasible it is to introduce a system of hierarchical ownership, such that a Collection owned by a Person can have its own followers collection but not its own inbox, for which you would have to crawl up the chain of attributedTo to find the first available inbox

Something like it is going to be necessary, but as currently stated it doesn't seem sound. Assuming a Person who is using their inbox like email (not automated/programmatic), this might require manual intervention.

Really, the problem is that you don't know how much you can expect the server to do automatically... like, maybe the server can maintain the followers collection automatically based on whether you Accept Follow on the Conversation/Feed/Wall/Stream/etc... but you'd have to explicitly address that followers collection and possibly rely on inbox forwarding, right?

@trwnh I've started wondering if it would make more sense for an activity addressed to a Collection to be delivered to that Collection's owning actor - which is then responsible for expanding the collection, if that's what makes sense.

My thinking was that this would allow the owner to define policies such as who's allowed to send to the collection - but it would also support your use case, by allowing the owner to treat Follow activities differently.

@FenTiger the thing is that some collections you don't want to expand, and you don't necessarily intend to address their owner either (unless there's no other way)