A mismatch between addressing of the Create activity and its object is likely to lead to confusion. As such, a server SHOULD copy any recipients of the Create activity to its object upon initial distribution, and likewise with copying recipients from the object to the wrapping Create activity.
So as I understand it, a Create activity has addressing fields both on itself but also on its object, i.e. it has both the fields to, cc, bto, bcc but also the nested fields object.to, object.cc, object.bto and object.bcc. The snippet above suggest that these fields should be equal but this is not guaranteed. I suppose this also applies to other activities than Create.
Is there any guidance on what the behavior should be in the situation when the fields are not equal? I can think of a few possibilities:
The addressing on the activity is used and the addressing on the object is ignored.
The addressing on the object is used and the addressing on the activity is ignored.
The addressing of the activity and object are combined, deduplicated and the resulting fields are used.
Option 3 is flexible but I’m worried it might introduce some weird edge cases, could be confusing and it also sounds more complicated to implement. My initial thought is that option 2 sounds most reasonable.
Any idea what approach some established implementations take, if they deal with this problem at all?
EDIT: A related question which probably has the same answer as the original question: What should happen if the actor of the Create is different than the attributedTo field of the object?
I’m not talking specifically about C2S, this happens for S2S as well (notice I posted this in the S2S category). My server receives a Create from another server with addressing both on the Create and on the object: which one to use?
It looks to me that option 3 is the closest match to the spec recommendation you quoted (two-way copy). That’s the C2S spec guidance.
No guidance for S2S. It could be a good topic for an FEP.
I think this topic is one of the many problem areas in the specification. What do “delivery addresses” mean for a created object? Those objects aren’t directly delivered. Activities are delivered. For S2S, one could argue that Create object-level addresses shouldn’t be allowed. The C2S case where it’s needed is when an object, posted to the outbox endpoint, is automatically wrapped in a Create activity (Section 6.2.1). In that case, I think it would be better to move (not copy) the addresses to the automatic activity before delivering it.
Another aspect of the S2S answer may be that the spec implicitly conflates delivery addressing with access authorization. The object’s “delivery addresses” are often used as a loose and ill-defined form of access control.
AFAIK, the AP spec doesn’t define this behavior either. I’m guessing a common response is to reject the activity as invalid. However, it would just as valid to ignore the object addresses in an S2S context (and derive authorization constraints from the activity addressing).
A more sophisticated authorization implementation might use “also known as” relationships to authorize the activity.
I think the answer depends on what type of application you’re building. The addressing on the activity matters when it is POSTed to outbox and you decide where to deliver it. The addressing on the object matters when you decide who can view it and interact with it.
If application only implements S2S, I’d go with option 2.
In origin-based security model, actor and attributedTo must be on the same server. They still can be different actors, but that doesn’t make any sense, so I’d just treat such activities as invalid.