C2S Create activity has unspecified behavior wrt assigning an ID to the inner object

[trwnh]

From 6.2 "Client to Server Interactions" > "Create Activity"

The Create activity is used when posting a new object. This has the side effect that the object embedded within the Activity (in the object property) is created.

When a Create activity is posted, the actor of the activity SHOULD be copied onto the object's attributedTo field.

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. Note that it is acceptable for the object's addressing to be changed later without changing the Create's addressing (for example via an Update activity).

so we have the following behaviors:

• the object "is created"
• copy actor onto object.attributedTo
• merge and copy recipients with object

this doesn't actually say anything about generating an id for the inner object

the only mention of generating an id for the object is in 6.2.1 "Object creation without a Create activity":

The server MUST accept a valid [ActivityStreams] object that isn't a subtype of Activity in the POST request to the outbox. The server then MUST attach this object as the object of a Create Activity. For non-transient objects, the server MUST attach an id to both the wrapping Create and its wrapped Object. Note

The Location value returned by the server should be the URL of the new Create activity (rather than the object).

Any to, bto, cc, bcc, and audience properties specified on the object MUST be copied over to the new Create activity by the server.

[emphasis mine]

there's also this for activities in section 6:

If an Activity is submitted with a value in the id property, servers MUST ignore this and generate a new id for the Activity. Servers MUST return a 201 Created HTTP code, and unless the activity is transient, MUST include the new id in the Location header.

so this logically implies the following possibilities:

• for activities,
  • if there is no id, it will be assigned one
  • if there is an id, it will be ignored and assigned a new one
• for objects without a wrapping Create,
  • if there is no id, it will be assigned one
  • if there is an id, ...? [unspecified behavior, but it is implied that the server will generate and attach a new id]
• for objects with a wrapping Create,
  • if there is no id, ...? [unspecified behavior]
  • if there is an id, ...? [unspecified behavior]

this could really go one of a few different ways:

• the id generation behavior could apply in all cases
• the id generation could apply only if there is no id
• the id generation could apply only to bare objects
• the id generation could apply never

depending on the answer here, it has some implications for certain use-cases:

• Create an object that already has its own id (already been "created" elsewhere, Create is just a notification here)
• Create an object that explicitly has no id (anonymous object, part of the parent activity's context)

[evanp]

So, I think the best outcome for this problem is as follows:

1. A primer page describing how to best handle Create with and without an object id. It can also cover implicit create, although that's more of a sub-category of Create. The primer page should also mention that this behaviour is underspecified and not all implementations will support it correctly -- perhaps with some fallback recommendations.
2. In a future version of the spec, include some guidance about how to use id when specified or not in the object property.
3. I think that this is a problem of omission, not commission . There's not actually an error in the text, so I don't think this needs an erratum.

[ap-socialhub]

This issue has been mentioned on SocialHub. There might be relevant details there:

https://socialhub.activitypub.rocks/t/fep-c7d3-ownership/4292/36

[ap-socialhub]

This issue has been mentioned on SocialHub. There might be relevant details there:

https://socialhub.activitypub.rocks/t/fep-c7d3-ownership/4292/38