Is your feature request related to a problem ?

As a user on a phone with a bad connection, I want to avoid both losing my post if my network connection drops, and double-posting if it's not clear if my post went through.

As a mobile client dev, I want to be able to retry creating a status if I get an error indicating that it might have failed.

Describe the solution you'd like.

Implement the Idempotency-Key header for the POST /api/v1/statuses endpoint. This header can be optionally set by clients to a UUID, ULID, or other short random string, and is used to de-duplicate operations requested with the same idempotency key in a given time window, an hour in Mastodon's case.

For complete Mastodon API compatibility, if we ever implement scheduled statuses, this would also involve adding an idempotency field to the ScheduledStatus type returned from scheduled status APIs.

Describe alternatives you've considered.

Storing the status text, CW, poll, media attachment IDs, etc. client-side, retrieving the user's recent statuses after a potentially failed POST (and possibly a short delay), and checking for duplicates. This requires extra network traffic and extra work for the client, but doesn't require any server-side changes.

Additional context.

Mastodon only implements it for creating statuses, but the same mechanism could be used to make any API call idempotent.

It could be implemented as an in-memory per-user set of idempotency keys, as an extra column on the statuses table, or as a separate table. Some databases have performance issues with tables that are frequently appended to and deleted from; partitioning such a table and dropping old partitions perodically can mitigate that problem, removing the need to vacuum in PG.