@stevebate are currently discussing how to behave for a Create activity in an outbox (C2S).
It might have occurred to some by now that I am not exactly a conservative interpreter of ActivityPub (or maybe a very conservative interpreter, depending on from where you look) ;). Therefore, please don’t argue based on current practices in other software, or Mastodon compatibility.
What? Why?
The scenario at hand is the following:
Alice creates ablog post on her static website https://aliceblog.example.com/. The static site generator generates ActivityStreams objects for all new posts, and places them in stable URI locations, let’s say https://aliceblog.example.com/posts/my-new-post.
Being a static site generator, Alice’s website builder can now POST this somewhere, including a ton of inboxes on the fediverse, but with some drawbacks:
- With a growing number of subscribers, the build will take very long
- Being a static site, Alice’s website cannot wait for any replies, likes, etc.
Object creation
Thus, Alice decides to use her actor on Bob’s Vocata server, let’s say https://bobsvocata.example.com/users/alice. Her static site generator adds this as attributedTo to the generated objects, resulting in something like:
{
"id": "https://aliceblog.example.com/posts/my-new-post",
"type": "Note",
"attributedTo": "https://bobsvocata.example.com/users/alice",
"content": "This is my new blog post!"
}
Now, Alice’s static site generator POSTs this object, wrapped in a Create activity, to her outbox on Bob’s Vocata server.
{
"type": "Create",
"actor": "https://bobsvocata.example.com/users/alice",
"cc": "Public",
"object": {
"id": "https://aliceblog.example.com/posts/my-new-post",
"type": "Note",
"attributedTo": "https://bobsvocata.example.com/users/alice",
"cc": "Public",
"content": "This is my new blog post!"
}
}
Vcata will remove the embedded object before processing (Alice’s SSG could have sent it as an ID only; for Vocata, this is the same – it will always pull foreign objects from their origin.)
Vocata now does the thing that is up for discussion here: It sees that the created object already has an ID, and that it is a foreign ID. It pulls the object from Alice’s website, and adds the Create activity to her outbox, without any further side effects to the object (because it is not repsonsible for the prefix of the object). It does, however, relay the activity to Alice’s followers
The following parts of the spec touch this field, but remain intact:
Section 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.
“created” here means we store a local copy. One could argue that this “is created” implies something the server has to actively do, but I see no explicit necessity for this in the wording of the spec.
A mismatch between addressing of the Create activity and its
objectis likely to lead to confusion. As such, a server SHOULD copy any recipients of the Create activity to itsobjectupon initial distribution, and likewise with copying recipients from theobjectto the wrapping Create activity.
“SHOULD”. Also, of course, Alice’s SSG can take care of that i nthe first place.
Likes, replies, etc.
Now to make real use of this, Alice wants Bob’s server to handle replies and likes of her post.
Assuming Vocata provides a way to create likes and replies collections for something (this is out of scope here), Alice changes her object from above:
{
"type": "Create",
"actor": "https://bobsvocata.example.com/users/alice",
"cc": "Public",
"object": {
"id": "https://aliceblog.example.com/posts/my-new-post",
"type": "Note",
"attributedTo": "https://bobsvocata.example.com/users/alice",
"cc": "Public",
"content": "This is my new blog post!",
"likes": "https://bobsvocata.example.com/collections/4eba371b-0e7c-4d95-a23c-34822e7bee1e",
"replies": "https://bobsvocata.example.com/colelctions/2d428460-81db-4ca0-99f8-5254a640bb98"
}
}
Now, if someone likes Alice’s blog psot, their server will send a Like activity to aatributedTo, which is Alice’s actor on Bob’s server. It receives the activity, and, being responsible for the likes collection of the object, adds the activity to the collection, and to Alice’s inbox.
Alice’s SSG now can connect to her inbox and retrieve likes, shares, etc., and blend them into the statically generated website.
Why not?
So, the “Why?” has been answered above. Now here’s the question for the rest of you: “Why not?”
Obviously, support for this on other servers might be bad, I am entirely aware of that. Other servers might refuse to process a federated Create with an object under another prefix. The question is: They might refuse, but why should they?
As noted above, please argue based on the spec and core ActivityPub mechanisms, not based on prior art.