ActivityPub specifications don't seem to provide a way to do Idempotent POSTs to your outbox.
That seems like a problem for C2S to me.
Networks are unreliable. You cannot tell the difference between an unreceived request vs an unreceived response. You'll get unwanted identical duplicate activities.
Although it isn't difficult to solve — a convention just needs to be picked.
For example, a new Idempotency field could be added to the JSON-LD payload.
Yes. I think you are asking exactly the right question:"What does it mean in this context?"
Many replies to the #poll ponder related questions, or state an "it depends". It is clear there's a lot of nuance and edge cases.
Reformulated, how delete should work is solution-specific, depends on domain, use cases, and stakeholders in SX terms.
And Delete activity in #ActivityStreams is not the well-understood part of #ActivityPub it is treated as today. See also:
There is a comparison that can be made between ActivityPub and Event-Sourcing.
3/
With ActivityPub, Activities are often applied to an object. That object gets assigned an ID in the form of a URL.
(And, by URL I mean URL, URI, IRI, etc.)
One doesn't have to read through all the Activities in an inbox, outbox, etc to get the final state of an object.
One can just get the JSON-LD document from the object's ID URL to get the final state.
There is a comparison that can be made between ActivityPub and Event-Sourcing.
2/
With Event-Sourcing, you can "project" the events to get another (often more peformant) view of the data in the events.
Without having to incur the cost of having to read all the events to figure out the final state.
...
There is a comparison that can be made between ActivityPub and Event-Sourcing.
1/
With Event-Sourcing, your source-of-truth is an append-only series of events.
Ex: USER_REGISTERED, EMAIL_ADDRESS_VERIFIED, PASSWORD_CHANGED, etc.
In ActivityPub, this is similar to the inbox, outbox, etc being an append-only series of Activity.
Ex: Create, Like, Undo, etc.
...
Just thinking out loud —
If we wanted to support resumable uploads in C2S API, then — we probably need some URL to upload the file chunks to.
…
When a user POST to their own outbox, the HTTP "201 Created" response will have a "Location" header that provides a URL.
Maybe that could be used as the upload URL.
Or, maybe the JSON-LD document at that URL might contain a URL under the "object" field that could be used as the upload URL.
Other options too
I can think of different ways to support resumable uploads with ActivityPub, but — just to see what others are doing —
PeerTube seems to have resumable uploads already.
PeerTube seems to use this protocol for it:
https://github.com/kukhariev/node-uploadx/blob/master/proto.md
I like that it uses Content-Range in the protocol. I would have done the similar.
It seems as if the uploadMedia ActivityPub extension does not provide a way to resume an upload that didn't previously compete.
https://www.w3.org/wiki/SocialCG/ActivityPub/MediaUpload
If, for example, you are working with large files (such as video files) this would matter.
Because if you uploaded 1GB, and the upload stopped, you would want to resume at where it stopped, and not have to upload from the beginning again.
This would be important for ActivityPub C2S adoption.
What do you think about JSON-LD language maps for "preferredUsername"?
I.e., preferredUsernameMap.
"preferredUsernameMap": {
"en": "hello",
"fa": "درود",
"ko": "안녕하세요"
}
@reiver ⊼ (Charles) 
🫧 socialcoding..