- The receiving server can't use the HTTP signature because it can't check Key.owner == Activity.actor when there is no actor.
- The receiving server can't verify activity by fetching it from the origin, because there is no id

Maybe this batch-Add activity is a special activity that differs from all other activities and should be unwrapped without authentication? In my opinion, the case for such "special activity" is not sufficiently strong.

@technical-discussion

I left `id`, `actor`, and `to` out because multibox also omits them. Additionally, batches don't have much use outside their POST request, so giving them a resolvable ID isn't super useful, and deduplication can be done per activity instead. Since the activities could be addressed to anyone and be created by anyone, `to` and `actor` dont have singular values either. Although I do realise now that omitting `actor` makes it incompatible with FEP-2277...

Good point on startTime/endTime. I'll clarify that tomorrow.

No, receiving servers should not add `Add` activities to their inboxes.

The object of the Add is a Collection, which would usually mean to add the collection obviously

You can introduce a new activity type, which will have different semantics.

e.g. DeliverBatch

-----

startTime: The creation time of the chronologically first activity in this batch.

I suggest clarifying what "creation time" means. Is it the value of the published property of an activity?

Delivery

The Add activity in the example does not have the id, actor and to properties, which are usually required.

Processing

Should receiving servers add Add activities to inbox collections?

@technical-discussion