Back

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.

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

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

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

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

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

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

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

@evan on the receiving end I was planning to just get all the inboxes from all addressed ids and collections, flatten them into a single array, and proceed.

Or actually, I'd use "new Set()". I like Sets they're automatically deduplicating!

@devnull @evan if one activity has both cc / to and bcc / bto for the same instances, I don't think it'd be inappropriate to flatten that to just the sharedInbox, since the user would get the message by their server anyway, and the bto/bcc doesn't imply that the server doesn't know the addressing.

@thisismissem @evan that's my assumption as well. It's a problem for the receiving end to parse correctly.

There are two distinct sets here, the addressees (to, cc, bto, bcc), and the inboxes. The former are basically instructions to the receiving end on how to handle remote end delivery, and the latter is just the technical route to the addressees. They're related but distinct.

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

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

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

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

@trwnh @devnull yes, true!