Gregory's ServerI'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.
 4 comments
 @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 according to activitypub spec, if one sends to a shared inbox, they mustn't also send to specific inboxes (or at least, that's how we understood it?) There's also something about making sure the system works with BTO and BCC. |
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.