Requirement of id in Create activity

[jaywink]

I started implementing ActivityPub in federation yesterday and noticed something I had not (embarrassingly) given too much thought before.

Federated (server to server) Create is supposed to have an id attached to it, as is obviously the object that was created as well. The intro (editorial draft) example for example is as follows:

{"@context": "https://www.w3.org/ns/activitystreams",
 "type": "Create",
 "id": "https://social.example/alyssa/posts/a29a6843-9feb-4c74-a7f7-081b9c9201d3",
 "to": ["https://chatty.example/ben/"],
 "author": "https://social.example/alyssa/",
 "object": {"type": "Note",
            "id": "https://social.example/alyssa/posts/49e2d03d-b53a-4c4c-a95c-94a6abf45a19",
            "attributedTo": "https://social.example/alyssa/",
            "to": ["https://chatty.example/ben/"],
            "content": "Say, did you finish reading that book I lent you?"}}

While in some use cases tracking the Create separately might make sense, for my social networking server it is a completely unnecessary extra thing. Storing the create separately not only requires the database objects but also mapping an endpoint to show the object, in case someone requests it. My server is multi-protocol, so I want to avoid protocol specific code/objects as much as possible. So I would like to do my implementation without specifying an id for the Create object.

Questions:

• What would this likely cause in interoperability with other implementations?
• How should the object look without an ID - should it be null or just left out? This section hints both are valid cases?
• Can the Note id be placed as the Create id? (as suggested below)

---

Edit: Clarification, I would write the library with the activity id but make it optional so the server I am working on doesn't have to create and track them.

[nightpool]

An ID explicitly specified as the JSON null object, which implies an anonymous object (a part of its parent context)

this seems to imply that you could maybe put the post id on the "Create" activity, and then inherit it to the post object? Not sure if that's what this is intended for though

[strugee]

This feels like a question that might belong in the AS2 issue tracker? https://github.com/w3c/activitystreams/issues

¯_(ツ)_/¯

[jaywink]

Actually it is ActivityPub that extends the requirement for a globally unique identifier from should to must. ActivityStreams2 vocab examples don't even have id's for activities.

ActivityPub says:

All Objects in [ActivityStreams] should have unique global identifiers. ActivityPub extends this requirement; all objects distributed by the ActivityPub protocol MUST have unique global identifiers, unless they are intentionally transient (short lived activities that are not intended to be able to be looked up, such as some kinds of chat messages or game notifications).

And then ActivityPub says:

These identifiers must fall into one of the following groups:

• Publicly dereferencable URIs, such as HTTPS URIs, with their authority belonging to that of their originating server. (Publicly facing content SHOULD use HTTPS URIs.)
• An ID explicitly specified as the JSON null object, which implies an anonymous object (a part of its parent context)

So I guess the options are:

• ID as HTTPS URI
• null ID
• No ID at all (conflicts with the MUST in spec)
• Reuse the ID from the object (not in spec , but as an idea by @nightpool above)

I'm kinda assuming that null would be the right way to go here. But I'm interested in thoughts how will that effect delivery when my server pushes a Create that has id null?

[nightpool]

sorry, to clarify: I was suggesting you use the null id. (and on the Note object, not the create—note the "parent context" language in the spec)

[jaywink]

Sorry, misunderstood, corrected. Still, it could be a valid option, maybe?

Kinda stuck here, don't want to start implementing before this is cleared since it directly affects the library design and also whether I can directly use ActiviPy or change it to match. @cwebber do you have any opinions as editor about this?

[cwebber]

@jaywink So another option is, maybe, to use fragment identifiers. Here's an example:

{"@context": "https://www.w3.org/ns/activitystreams",
 "type": "Create",
 "id": "https://social.example/alyssa/posts/49e2d03d-b53a-4c4c-a95c-94a6abf45a19#create",
 "to": ["https://chatty.example/ben/"],
 "author": "https://social.example/alyssa/",
 "object": {"type": "Note",
            "id": "https://social.example/alyssa/posts/49e2d03d-b53a-4c4c-a95c-94a6abf45a19",
            "attributedTo": "https://social.example/alyssa/",
            "to": ["https://chatty.example/ben/"],
            "content": "Say, did you finish reading that book I lent you?"}}

This has a unique id, but is not expected to be retrievable as an independent document.

This will probably work for federation, but it will be awkward for the client to server protocol, which requires a Location header to point to the activity. Note that in such a scenario you definitely need a signature solution if you're going to be passing the object around, since it won't be possible to retrieve it independently.

[jaywink]

Personally I would say there always needs to be a signature when federating, but well :) I'm not personally so interested in client-to-server. Maybe I'll wait and see how Mastodon will do the federation part, would love to be compatible with them. Or will implement the fragment identifier, let's see.

Thanks!

[cwebber]

@jaywink Do you think the fragment identifier route + signatures satisfies this issue for you?

[jaywink]

I .. don't know :) I opened this partly for discussion and hoping to get comments from other implementers. I feel interop is the most important here. What is unclear to me if a non-functional Create ID will have any effect on server-to-server federation. I guess will just have to wait and see some implementations.

I guess this can be closed since it doesn't really require any actions to spec?

[cwebber]

Let's close it but leave open the possibility of reopening if need be based on feedback during exploration, since it seems like we have an answer (for those using signatures that is!)

@jaywink, I'm happy to test interoperability on this one. It seems interesting and worth exploring.