Delivery to a collection page

[evanp]

In section 7.1, we describe delivery to a collection:

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.

I think with the expressed class hierarchy in AS2 Core you could make an argument that a CollectionPage "is-a" Collection, and that an OrderedCollectionPage "is a" Collection and an OrderedCollection.

I don't know if that's a desired behaviour or not; I can't see a lot of use to it. I can't see a lot of value in addressing a collection page; I think it might also be reasonable for receiving servers to accept AP actors, Collections, OrderedCollections, the Public object, and nothing else as addresses.

[trwnh]

I think it might also be reasonable for receiving servers to accept AP actors, Collections, OrderedCollections, the Public object, and nothing else as addresses.

even under this definition we definitely do say a collection page is a collection, since it subclasses from as:Collection.

we are probably rehashing #486 at this point, though -- this issue #530 is a subset of that issue.

to reiterate: the solution other specs have arrived at is to clearly separate concepts of addressing individual agents, group members, or a class. WAC uses agent, agentGroup, and agentClass with very distinct algorithms for each property defined in the processing model. every value of a acl:agentGroup is expected to be a foaf:Group with each foaf:member being implied to have the level of access granted by the acl:Authorization resource.

what we have in activitypub is an ambiguity from not separating addressing from delivery. this separation exists in basically every other messaging protocol as far as i'm aware -- decades ago, SMTP has an envelope using RCPT TO: that doesn't need to match the content headers To: or Cc: or Bcc:. the separate envelope allows delivering to an inbox without addressing the inbox, which is how Bcc: works in the first place (and also why as:bto and as:bcc are kind of broken right now, as #495 gets into).

[evanp]

I think it might also be reasonable for receiving servers to accept AP actors, Collections, OrderedCollections, the Public object, and nothing else as addresses.

even under this definition we definitely do say a collection page is a collection, since it subclasses from as:Collection.

Thanks, that was my point above. How about "AP actors, Collections only without subclasses, OrderedCollections only without subclasses, the Public object, and nothing else"?

we are probably rehashing #486 at this point, though -- this issue #530 is a subset of that issue.

It has the benefit of specificity, which can be useful.

[trwnh]

"is-a" without subclassing wouldn't be "is-a" anymore. you are now talking about owl:sameAs or strict id equivalence, which would probably break a lot of existing software/libraries/toolkits/etc in how they deal with rdf:type and subclassing.

and nothing else

the problem here is that it unnecessarily breaks addressing anything else that might have an ldp:inbox, or any other value that carries semantic importance in the activity even if no delivery occurs. i would advocate that the range of the addressing properties is in fact "anything", not "nothing else". otherwise, the as:outbox becomes a LOT less useful.

also, if the outbox doesn't have access to the thing and doesn't get any info when it dereferences the id, you have no idea what its type may be:

"to": "https://foo.example/"

is foo.example a as:Person, as:Collection, or something else?

you could argue that the delivery algorithm might skip values it can't do anything with, but "you can't do anything with as:CollectionPage" isn't really justifiable. if something is a CollectionPage and also multityped with other types, then you'd skip over something even if it had an ldp:inbox? you'd skip over it even if it had as:items? why?

more concretely:

</contacts/m> a as:CollectionPage;
  as:name "Contacts starting with M";
  as:items </contacts/#maia>, </contacts/#mallory>, </contacts/#meg>;
  as:next </contacts/n>.

</activity/#foo> a as:Activity;
  as:to </contacts/m>;
  as:content "Shouts-out to all my friends whose names start with M!".

because you can page a collection in arbitrary ways, the publisher is free to use those collection pages in arbitrary ways. it doesn't cause any issues and it would be unreasonable to forbid it. forbidding it causes issues by making perfectly normal things suddenly invalid.