1/
I did consider that the activity ID could be the Idempotency field, but to me that has a lot of cons.
...
Discussion
1/
I did consider that the activity ID could be the Idempotency field, but to me that has a lot of cons.
...
2/
№1:
A lot of servers have a lot of constraints on what the activity ID's URL has to be (i.e., it has a format.)
If the Idempotency field was to be the activity ID, then there would need to be a way to communicate that format to the client. And then the client would need to parse it, etc.
Which makes things A LOT more complex.
...
3/
№2:
A lot of clients need the Idempotency field live on and persist, so that the client can find the data it created later.
The server cannot discard the it or replace it.
But, that is allowed with the activities ID.
...
4/
For those reasons, having a new Idempotency field, separate from the activity ID, seemed like a better idea me.
.
outboxes are supposed to ignore ids and generate their own (although this could be changed)
in HTTP you could use a header like Idempotency-Key and in fact this is something the Mastodon API uses for idempotency since the id won't be known until minted server-side. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Idempotency-Key (The I-D expired 3 weeks ago, but it's an okay approach)
even if you don't know the eventual id, you could suggest input material for it using the Slug header https://blog.cdivilly.com/2016/03/01/slug-http-header