Re: Expanding collections on delivery
Technical Discussion
3
Posts
2
Posters
0
Views
-
@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
/memberscollection 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)
-
> 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)
-
> 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.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@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.
-
> 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)
-
@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)
-
@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)
-
@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
-
@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")
-
@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.
-
@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.
