Post · bonfire.cafe

Post

⁂ Article

Re: Expanding collections on delivery

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

https://swicg.github.io/groups/

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.

groups

Groups

Repository for the Groups Task Force of the SocialCG

evan

@evan@activitypub.space replied · 2 days ago

⁂ Article

Re: Expanding collections on delivery

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"
}

https://swicg.github.io/groups/

groups

Groups

Repository for the Groups Task Force of the SocialCG

julian

@julian@activitypub.space replied · 2 days ago

⁂ Article

Re: Expanding collections on delivery

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

infinite love ⴳ

@trwnh@mastodon.social replied · 2 days ago

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

julian

@julian@activitypub.space replied · 2 days ago

Re: Expanding collections on delivery

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

silverpill

@silverpill@mitra.social replied · 18 hours ago

@julian If forwarded activity doesn't have a signature (FEP-8b32 or LD signature), you can fetch it by its ID. Mitra does this. Not all activity IDs are dereferenceable (hello Mastodon), but some are :)

@trwnh @eyeinthesky

silverpill

@silverpill@mitra.social replied · 18 hours ago

@trwnh @eyeinthesky

infinite love ⴳ

@trwnh@mastodon.social replied · 2 days ago

@julian well, no, trust/authenticity is a separate concern. if you trust the sender, that's good enough. if you don't trust the sender, you can:

- fetch the id via HTTPS and authenticate it with TLS
- forward the original HTTP Signature: (although this might not be recommended)
- embed a vcdi proof in the jsonld content
- link to some other token/stamp/etc which can either resolve or be revoked

infinite love ⴳ

@trwnh@mastodon.social replied · 2 days ago

@julian in the basic case you just make everything fetchable with HTTP GET (as AP says, everything MUST have publicly dereferenceable id which SHOULD be https:)

no signatures needed there. signatures are just an optimization/tradeoff that allows saving an HTTP request

infinite love ⴳ

@trwnh@mastodon.social replied · 2 days ago

@julian consider the difference between these examples:

to: group/followers
cc: group
summary: "the group will forward this to followers, who are the primary audience"

to: group
summary: "this is a private message to the group actor, which may implicitly forward but maybe shouldn't, since it might not be relevant! it could be a control flow message"

infinite love ⴳ

@trwnh@mastodon.social replied · 2 days ago

@julian the specifics of how a group actor should behave are indeed undefined, and that's what @evan and i are nominally supposed to explore in the swicg/groups TF

- Announce from inbox to followers/members/audience?
- forward from inbox to followers/members/audience?
- do something else with private messages?

this also has implications for the swicg/activitypub-e2ee work imo! in that case, you only have an mls:Group actor's id and its ldp:inbox as public info

infinite love ⴳ

@trwnh@mastodon.social replied · 2 days ago

@julian wrote:

> Was there a specific use case/story

have you ever used diaspora* "aspects", google+ "circles", facebook "privacy lists", instagram "close friends", or twitter "circles"? this spec language is intended to allow for this kind of mailing-list style usage in to/cc/audience/bto/bcc.

> The only commonly addressed collection [...] is a followers collection

this is a limitation with mastodon et al who only care about followers and assume followers are the only collection mattering.

infinite love ⴳ

@trwnh@mastodon.social replied · 2 days ago

@julian

> should we remove

if this is removed, then you lose a very valuable ability to address things like "the audience of a conversation" or "the members of a group". i would strongly recommend NOT removing it.

current behavior in mastodon is to upgrade "direct" posts to "limited" when a recipient is detected that doesn't dereference to either a user or a user's followers. they get presented in the mastodon api as "followers" though (for compat), so further interactions lose this nuance.

infinite love ⴳ

@trwnh@mastodon.social replied · 2 days ago

@julian

> 7.1.2

wrt inbox forwarding, this only helps when addressing collections of *someone else*, where the contents are private. for your own collections, unless you plan to deliver all such activities to yourself with the expectation that you will forward them (why didn't the outbox do it for you?^1), it doesn't help you.

^1: if the outbox doesn't have your credentials, then it can't do this. in this case, you or your client is responsible for deliveries, and the outbox only publishes.

infinite love ⴳ

@trwnh@mastodon.social replied · 2 days ago

@julian

i would be fine with removing this collection expansion behavior from outbox delivery if it was decided that outbox delivery itself is problematic and should be removed -- probably in favor of the client being responsible for sending notifications, where the client can apply whatever logic it wants.

this is kinda what mastodon does right now as a monolith -- it is both the activitypub client (submitting to its internal outbox) and also the http agent for linked data notifications.

julian

@julian@activitypub.space replied · 2 days ago

Re: Expanding collections on delivery

@trwnh@mastodon.social so collection expansion is mainly for when I am sending an activity to collections that I control?

Then I'm wondering why this needs to be explicitly spelled out and required because it seems to be inferred already from a UX perspective.

silverpill

@silverpill@mitra.social replied · 2 days ago

@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

1+ more replies (not shown)

infinite love ⴳ

@trwnh@mastodon.social replied · 2 days ago

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

2 more replies (not shown)

infinite love ⴳ

@trwnh@mastodon.social replied · 2 days ago

@julian there's probably a bunch of open issues on the https://github.com/w3c/activitypub/issues tracker regarding the problems with outbox delivery. those problems might be addressable all together, but it might instead make more sense to conceive of a sort of "LDN proxy" which handles deliveries instead (and holds your keys as an HTTP agent sending signed messages)

bonfire.cafe

A space for Bonfire maintainers and contributors to communicate

bonfire.cafe: About · Code of conduct · Privacy · Users · Instances

Bonfire social · 1.0.1 no JS en

Automatic federation enabled