@julian i don't think it's "inferred", and leaving ambiguous cases up to inference in specification is typically called "unspecified behavior"

say you are an outbox and you get an activity to: some id. you deref the id and get some info. what do you do?

- in all cases, if it has an `inbox`, you send an LDN to that id if you can.
- in case it's an as:Collection, you iterate over its items in theory and repeat step 1 recursively. (this is also problematic because it can be both paged+unpaged)

@julian now remove the requirement. what do you do instead?

- if it has ldp:inbox, send an LDN

...and that's it. at no point were you ever told or required to do anything else, so your followers/audience/members/etc will never get the activity even if addressed, because the collection was never expanded.

@trwnh@mastodon.social said in Expanding collections on delivery:
> say you are an outbox and you get an activity to: some id. you deref the id and get some info. what do you do?

Simple. My outboxes send a "not supported" HTTP tag

But I'm being facetious.

From a C2S standpoint I suppose that makes sense. Thanks.

@julian well, sure, with a monolithic implementation, the client and the outbox and the delivery agent are all the same app. but they don't have to be. the model is that the client submits to the outbox, and the outbox could also talk to a separate delivery agent internally. it's all opaque from outside the outbox. your internal "outbox" is the code that serializes activities and sends them to the delivery workers.

@julian Yes, I think in practice expansion should be performed only for local collections.

the server MUST dereference the collection (with the user's credentials) is confusing, because it sounds like we're talking about remote collections here.

@trwnh

@silverpill @julian @technical-discussion

a "local collection" might still have access control on it.

(the interface being assumed throughout the AP spec is HTTP, or at least HTTP semantics; "with the user's credentials" in this case means using an Authorization header that lets the outbox access the collection. it's only confusing if you have a monolith with no boundaries between the outbox and anything else; in that case it'd be "lookup the collection in your db/store/etc")

@silverpill @julian @technical-discussion

example: alice and bob on site.example each have followers collections, but alice can't see bob's followers. if alice addresses bob's followers collection, then alice's outbox can't deliver to bob's followers. alice must address bob, and bob can choose to forward to bob's followers (inbox forwarding)

if site.example has a collection of "local users" that alice can see, then alice can address it and alice's outbox can deliver to items

@trwnh The statement is in "Server to Server Interactions" part of the spec, so it's either a database lookup or a remote collection.

@silverpill @technical-discussion it's part of the outbox delivery algorithm, which bridges between c2s and s2s. the intention is that the outbox publishes activities via c2s, but then optionally delivers based on addressing properties via s2s

(this ends up having other issues in practice due to the lack of an envelope, but at least the intent of "relevant activities should trigger notifications for relevant entities" makes sense, per 6.1 clients "look at" some relevant props)

@trwnh @silverpill @technical-discussion I'd claim that *outboxes* don't publish or deliver anything. Servers do. In all but one place, the spec wording is consistent with this claim. But... there is one place (out of many mentioning the outbox) that is phrased "the receiving outbox can then perform delivery". Although I believe this is just poor writing (very common in the spec), I suppose one could use this exception to claim outboxes deliver activities instead of servers.

@eyeinthesky @silverpill @technical-discussion outboxes are HTTP resources (commonly), and we use that HTTP resource's internal semantics (via HTTP POST, which is specified to mean exactly this) to publish and deliver.

the idea of a "server" is actually a lot less real than most would think. you have an application listening on TCP port 443 that you can talk to with TLS and HTTP, but after you send it the HTTP POST, everything else is completely opaque internally.

@eyeinthesky @silverpill @technical-discussion i would say the most consistent answer is that deliveries are done by an HTTP agent which delivers a constrained LDN (AS2 document with exactly 1 activity). this role *might* be played by the same software handling the outbox, but it doesn't have to be.

sending http agent -> POST -> ap outbox -> [internal interfaces] -> delivering http agent -> POST -> inbox

the [internal interfaces] can be anything, including HTTP POST

@eyeinthesky @silverpill @technical-discussion in most cases right now the [internal interfaces] are probably hardcoded function calls in the codebase between e.g. outbox controller and delivery workers. the outbox controller could do synchronous delivery inline if it wanted to, but async is more advantageous usually

@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

@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:

Groups

Repository for the Groups Task Force of the SocialCG

groups (swicg.github.io)

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.

@evan The groups (private groups, specifically) aspect is the reason why I brought up this topic at all — it was mostly for my understanding of the spec because to my knowledge, there weren't many collections being passed around in recipient fields; the only one being /follower, which isn't always resolvable.

The same issues would occur around private groups... a public group publishing something a /members collection would be addressable, but not a private group or one whose membership list is hidden.

All threadiverse softwares work around this by having the group itself be the distributor, and so you needn't address a members collection, you just need to ensure the group itself is addressed. The rest is implied (which HA! I bet @trwnh@mastodon.social has much to say about implied behaviour)

@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)

@trwnh@mastodon.social I thought inbox forwarding between instances was a non-starter per the AP spec because you cannot guarantee that the activity hasn't been tampered with.

I thought it must be paired with a signature of some sort.