Comment on FEP-c3ab: Referencing existing objects in client-to-server Create

trwnh@socialhub.activitypub.rocks ⁨20⁩ ⁨hours⁩ ago

• jiwoon@socialhub.activitypub.rocks ⁨4⁩ ⁨hours⁩ ago

  Thank you — this is more useful than I expected, and two of the points change the draft.

  On 201. Agreed, and I should have been clearer: 201 refers to the activity being published, not to the object being created. A Delete makes it sharpest — the 201 there says a Delete activity was recorded, and says nothing about whether the object now answers with a Tombstone, a 404 or a 410. Running that sequence out:

  POST Delete        → 201, Location: .../activities/1
  POST Delete again  → no new activity recorded
  Undo(Delete)       → 201, Location: .../activities/2
  POST Delete again  → 201, a new transition, Location: .../activities/3
  

  The second line is the only one I am asking about. The first submission records an activity and gets 201; the question is what to return for a POST the server has recognised as a retry, where it recorded nothing.

  Section 6 requires 201 Created for a submission without qualification, which reads naturally as long as an accepted submission records an activity. RFC 9110 defines 201 as meaning the request “has resulted in one or more new resources being created”, and defines the content of a 200 for a POST as “the status of, or results obtained from, the action”. So where a server accepted the submission and recorded nothing, reading Section 6 as covering that case obliges it to say something about its own request that is not true, while the honest answer is a status Section 6 does not mention. That is less a deviation than a case the requirement was not written for, and leaving it undocumented means every server that needs it invents its own answer quietly.

  It is also not special to a referenced Create, now that I look at it. Whenever an outbox recognises a submission as a retry and records no new activity, it can answer 200 and identify the existing one — Follow, Like and Block are the familiar cases. Which submissions count as retries is a separate question, and a contested one, as w3c/activitypub#381 and #485 show; the draft proposes the response for a referenced Create without defining deduplication rules for anything else.

  There is a practical reason to identify the existing activity rather than say nothing about it: that id is what a client needs later to address an Undo, which is close to what #485 describes senders losing. A C2S response obviously cannot settle how a remote server deduplicates on its side, but it can at least tell its own client which activity is the authoritative one.

  So: do you mean replaying the original 201 and Location for that second POST, or something else? I would rather understand the proposal before revising.

  On Announce. You are right that the draft never says why not, which is a gap rather than a disagreement — and @steve_bate, this is the answer to your /cc as well. Announce is a reasonable choice when the goal is to draw attention to an object. The goal here is narrower: to record that an actor published this object to the fediverse for the first time. That record is what establishes attributedTo and what later Update and Delete activities refer back to — which is also why Update cannot be treated the same way, since the same actor may legitimately update the same object many times.

  Your own observation supports the shape, incidentally: an object may be created beforehand and the Create sent later, with its own published date. That is exactly the case the draft is about. I will add a section on why Create here, and on when Announce is the better fit.

  On addressing, I was too strict. “The addressing of the activity controls where the activity will be delivered; the addressing of the object might control who can fetch the object; the former should probably be a subset of the latter” states it better than the draft does. What I meant to prevent is a client supplying a narrower audience and the server publishing to the object’s wider one, so the client believes it published narrowly when it did not. Refusing every addressing property also forbids delivering more narrowly, which I did not intend.

  What I am less sure of is how a server should check it, because the comparison is not a subset of URI lists. If the object is addressed to Public and the request names a single actor, the delivery is narrower in effect even though that actor may appear nowhere in the object’s to. So I would like to allow narrowing and work out the test, rather than write one into the draft today.

  Lastly, w3c/activitypub#662 looks closely related from the other direction: it asks what a server must do for an object that “is created”. The referenced case may be a useful data point there, because what the server owes the object is nothing — no identifier is assigned and it is already persisted — while it still checks authorisation and records a new activity. Separating those two is what makes the response question appear at all.

  original