Clarification about "bcc/bto" in server -> server communication needed

[annando]

The specification says:

bto and bcc already must be removed for delivery, but servers are free to decide how to represent the object in their own storage systems. However, since bto and bcc are only intended to be known/seen by the original author of the object/activity, servers should omit these properties during display as well.

And:

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.

So this tells me, that in a S2S situation there can never be a "bto/bcc", am I right? This can be read out of the specification but hadn't been explicitly told. I'm creating the issue since there had been different opinions about this between the different implementers.

[kaniini]

the specification is talking about delivery to end-users, meaning that side effects of the bto/bcc should not be observable

[annando]

I see a problem with BCC in S2S situations and public posts. You could create a note to the public audience and in parallel you deliver it via BCC to someone. Since on signed activities you must not change any element, you wouldn't be able to dereference it upon relaying or when displaying it in the outbox.

[kaniini]

well, the relevance of LDS signatures are really debatable, hince litepub

[annando]

LDS is the present, Litepub is possibly the future, but currently not even documented. We have to respect the present.

[trwnh]

You could generate a separate Activity and deliver that instead, as far as bto/bcc is concerned. The important thing is not leaking the original audience to people outside of to/cc.

[clacke]

bcc is a signal from the client to the server, and is not part of the object sent out. It's pretty clear. There isn't really any "delivery" event from the server to the client.

[annando]

I guess that the best way is to possibly generate the "bcc/bto" internally, but upon delivery to the other server, we remove these fields. And we deliver the object in theses cases to the personal inbox and not the shared one. In this case the receiving server should know that the post was meant for this user.

Does this sound okay?

[cjslep]

That sounds very similar to what go-fed does.

[annando]

Question is if this behaviour could be written down somewhere, as some "best practices".

[clacke]

As AP doesn't even have minor and major inboxes, I don't understand what the difference between bto and bcc is supposed to be. There is no way to distinguish them. They are probably a remnant from pump.io that wasn't detected in the standardization process.

[clacke]

Audience targeting information included within an Object only describes the intent of the object creator. With clear exception given to the appropriate handling of bto and bcc, this specification leaves it up to implementations to determine how the audience targeting information is used.

https://www.w3.org/TR/activitystreams-vocabulary/#audienceTargeting

Or rather, left out, I guess.

[annando]

I'm not sure about the difference of "bto" and "bcc" as well. Both should be removed upon the delivery to the personal inbox.

[cjslep]

I assumed it would be used by the sending application to be able to render the bto and bcc recipients differently (and have different reply vs reply all behaviors) when viewing the sent message.

But yes no effect for the recipient server.

[evanp]

I think @annando has it correct. However, as with most things on the Internet, you can't really count on your correspondent server to always do the right thing. I would say, that if bcc or bto are seen by the receiving server, they should be ignored and preferably stripped out at that point.

We have a page on addressing here:

https://www.w3.org/wiki/ActivityPub/Primer/Addressing

I will add some more information about when bto/bcc should be stripped versus hidden. Ideally, these should still be available to the actor or creator when fetching via GET, or in collections, but should not be visible to others. And shouldn't be send.

@trwnh notes that this has implications for shared inbox delivery; in particular, because the remote server has to figure out delivery based on the addressing properties, sharedInbox can't be used for bcc/bto addressees. That means the sending server should deliver to all bcc/bto recipients via the inbox instead, which can be a performance hit!