Thank you — and thank you for the pointer to FEP-aef6, which I had not read.

Thank you — and thank you for the pointer to FEP-aef6, which I had not read.

If I understand it, Notify answers “deliver this object to a requester without a GET” — a reply to a Request, for cases where the origin cannot serve the object itself, such as an offline node or end-to-end encrypted content. That is a different question from recording a first publication, even though the shape resembles Create. I will cite it as adjacent work rather than as an alternative, but tell me if you meant it to cover publication too.

On rejecting request-side addressing being an implementation detail: I think you are right about the strictness, and I was treating a validation choice as though it were the rule. What I would still like written down is the invariant rather than the check — that a client cannot end up having published to a wider audience than it asked for. How strictly any given server validates against that, and how much an intentionally generic server tolerates, seems like exactly the local decision you describe.

The harder half is that I am no longer sure what the invariant should be. trwnh’s framing in the next post — the activity’s addressing as a subset of the object’s — is better than what the draft says, but the comparison is not a subset of URI lists: an object addressed to Public and a request naming one actor is narrower in effect while sharing no addresses at all. I would rather leave that open for now than write a test I cannot defend.