Conversation

Notices

1. Embed this notice
   Evan Prodromou (evan@cosocial.ca)'s status on Thursday, 01-Feb-2024 13:56:11 JST Evan Prodromou

   I'm implementing some sample code for the #ActivityPubBook at https://github.com/evanp/bots-rodeo . I'm realizing that we can really get wedged on delivery between using `sharedInbox` and `bto` or `bcc`. Preventing double delivery is kind of a chore, here.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Thursday, 01-Feb-2024 13:59:07 JST Evan Prodromou

     in reply to

     Basically, if `userA@domain1` has followers `userB@domain2`, `userC@domain2`, and `userD@domain2`, and they have an activity that has `to`: `followers` and `bcc`: `userD@domain2`, and domain2 has a shared inbox, you can't deliver to the shared inbox without double-delivery to userD. domain2 can do double-delivery-detection, but that kind of sucks.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Thursday, 01-Feb-2024 15:39:06 JST Evan Prodromou

     in reply to

     • Julian Lam

     @devnull that's how it would work, but there are problems with BCC and bto.

   • Embed this notice
     Julian Lam (devnull@crag.social)'s status on Thursday, 01-Feb-2024 15:39:08 JST Julian Lam

     in reply to

     @evan you can't? I thought that was explicitly how shared inboxes worked.

     In your example my understanding is domain2 would receive a single activity, and parcel out the activity to the other users internally as appropriate. How that's actually handled by domain2 is out of scope of the spec.

     A potential complication could arise if you're saving a serialzied representation of that object for validation, in which case it wouldn't pass as you have to remove bcc from the object...

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Friday, 02-Feb-2024 01:09:32 JST Evan Prodromou

     in reply to

     • Julian Lam

     @devnull https://cosocial.ca/@evan/111854454446258555

   • Embed this notice
     Julian Lam (devnull@crag.social)'s status on Friday, 02-Feb-2024 01:09:33 JST Julian Lam

     in reply to

     @evan morning! Did you figure it out overnight?

     My implementation hasn't gotten as far as handling audience delivery yet (it all just goes into a single public bucket, yay proof-of-concept software!), but what problems re: bcc and bto were you referring to?

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Friday, 02-Feb-2024 01:10:57 JST Evan Prodromou

     in reply to

     • Julian Lam

     @devnull I think the standard resolution is to just not support bcc and bto on the authoring side. Which is probably fine.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Friday, 02-Feb-2024 01:18:14 JST Evan Prodromou

     in reply to

     • Julian Lam

     @devnull My code does something like this:

     ```
     const publicRecipients = await getPublicRecipients(activity) // to, cc, audience
     const privateRecipients = await getPrivateRecipients(activity) // bto, bcc

     const publicInboxes = await getSharedOrDirectInboxes(publicRecipients)
     const privateInboxes = await getDirectInboxesOnly(privateRecipients)

     await Promise.all(deliverToAll(publicInboxes, activity), deliverToAll(privateInboxes, activity))
     ```

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Friday, 02-Feb-2024 01:21:09 JST Evan Prodromou

     in reply to

     • Julian Lam

     @devnull I think to prevent delivery to a shared inbox that's also the shared inbox of someone on bto or bcc, I'd need this:

     ```
     // get shared inboxes of private recipients
     const excluded = await getSharedInboxes(privateRecipients)

     // get shared inboxes unless the same as private recipients, otherwise get direct

     const publicInboxes = await getSharedOrDirectInboxes(publicRecipients, { exclude: excluded })
     ```

     HTH.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Friday, 02-Feb-2024 01:56:04 JST Evan Prodromou

     in reply to

     • Julian Lam

     @devnull because the `bcc` and `bto` properties are stripped before sending, there's no way for the receiving server to know how to deliver the activity if it comes to the shared inbox. So, you have to deliver it directly to the user's inbox.

   • Embed this notice
     Julian Lam (devnull@crag.social)'s status on Friday, 02-Feb-2024 01:56:06 JST Julian Lam

     in reply to

     @evan was this on the sending end or receiving end?

     On the sending end, I wasn't aware that "bcc" and"bto" needed special handling that required delivery to their individual inboxes.

     I was planning to send activities addressed in "bcc" and "bto" to the shared inbox, same as "to" and "cc".

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Friday, 02-Feb-2024 02:24:15 JST Evan Prodromou

     in reply to

     • Julian Lam

     @devnull No offense taken; I get reminded of parts of the spec that I misremember all the time. But I'm pretty sure they are stripped before delivery. "The server MUST remove the bto and/or bcc properties, if they exist, from the ActivityStreams object before delivery, but MUST utilize the addressing originally stored on the bto / bcc properties for determining recipients in delivery."

   • Embed this notice
     Julian Lam (devnull@crag.social)'s status on Friday, 02-Feb-2024 02:24:18 JST Julian Lam

     in reply to

     @evan my understanding is that those properties are stripped if forwarded along in another activity, but not on the original send.

     Please please please I mean no offense by quoting the AP spec to you 😅

     https://www.w3.org/TR/activitypub/#server-to-server-interactions

     It's not explicitly mentioned but that paragraph talks as though bto/bcc are present.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Friday, 02-Feb-2024 04:52:13 JST Evan Prodromou

     in reply to

     • infinite love ⴳ
     • Julian Lam

     @trwnh @devnull yes, true!

   • Embed this notice
     infinite love ⴳ (trwnh@mastodon.social)'s status on Friday, 02-Feb-2024 04:52:14 JST infinite love ⴳ

     in reply to

     • Julian Lam

     @devnull @evan my understanding is that sharedInbox and bto/bcc are incompatible. but there’s actually another issue with signatures that is even bigger — mutating the activity before delivery is going to invalidate any client-generated signatures.

   • Embed this notice
     Julian Lam (devnull@crag.social)'s status on Friday, 02-Feb-2024 04:52:18 JST Julian Lam

     in reply to

     • infinite love ⴳ

     @evan this open issue raises similar questions and @trwnh advocated for sending a separate activity for the bto/bcc'd user

     https://github.com/w3c/activitypub/issues/326

     For simplicity's sake, disallowing bto/bcc in S2S seems wise.

     If blind recipients are omitted then it presents a real problem in S2S communications, and sending the activity to those users' inboxes directly ASSUMES behaviour on the other server's part, which is unwise.