Non-addressable collections?

[ThisIsMissEm]

Currently all collections of actors are addressable by default, which means you can't expose a collection of actors without that being able to be used for addressing.

If a recipient is a Collection or OrderedCollection, then the server MUST dereference the collection (with the user's credentials) and discover inboxes for each item in the collection. Servers MUST limit the number of layers of indirections through collections which will be performed, which MAY be one.

However, I think there are cases where we want a collection to not be able to be used for addressing, but it'd be tricky / best-effort now to say something like addressable: false on the collection.

[trwnh]

This is what inbox forwarding is supposed to solve.

If a collection is owned by someone else, you send your activity to that someone else, and they choose whether to forward it or not to the collection that they own.

However, there is indeed a concern that if the items are public, a delivery agent (outbox endpoint, etc) might attempt to discover inboxes directly without relying on inbox forwarding.

There are some workarounds we could apply here:

1. Do not use Collection / OrderedCollection for this use case. Use a different type to represent the "collection" so that the quoted requirements are bypassed. This is perhaps the least disruptive for delivery, but more disruptive overall since you have something that is "basically a Collection but don't call it a Collection". And it may in fact be inferred to be a Collection if you're not careful -- i.e., you cannot reuse as:items as a property.

2. Rework the delivery algorithm to make certain collections not addressable, or to use a different expansion mechanism (e.g. something to do with a Group or Group's members, or using vocabulary terms/classes instead of collection ids, or something else that frees up Collection/OrderedCollection). This is a breaking change, and there is more exploration in Delivering to Collections can be ambiguous #486 regarding this. It could be done with different properties, or by splitting delivery from addressing a la SMTP's RCPT TO being separate from the headers within the actual message (To:, Cc:, Bcc:), which is enveloped rather than processed directly for delivery. (Some tangential discussion in Potential issue with private delivery when an inbox is associated with more than one resource #492 (comment) as well.)

3. Define an addressable: false flag that can be trivially ignored if the collection's items are exposed.

4. Advise against exposing the items of collections intended for addressing?

[github-actions]

This issue has been labelled as potentially needing a FEP, and contributors are welcome to submit a FEP on the topic.
Note that issues may be closed without the FEP being created; that does not mean that the FEP is no longer needed.

[evanp]

I think there are some interesting use cases here. My main concern with adding a flag is backwards compatibility, since the undesired behaviour is the current default. I think this deserves some more thought, and might use it for future enhancement.