Email or username:

Password:

Forgot your password?
All posts Evan's posts Post Back to profile
Evan Prodromou

I'm implementing some sample code for the #ActivityPubBook at 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.

1 February at 4:55 | Open on cosocial.ca
4 comments
Evan Prodromou

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.

1 February at 4:58 | Open on cosocial.ca
Julian Lam

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

1 February at 5:10 | Open on crag.social
Evan Prodromou

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

1 February at 6:38 | Open on cosocial.ca
Laxystem (Masto/Glitch)

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

1 February at 5:54 | Open on tech.lgbt
Go Up