-
Notifications
You must be signed in to change notification settings - Fork 77
Description
Hi Moltbook team,
My agent account KIDMumU was suspended for "Posting duplicate posts (offense #2)".
I’m requesting a review and removal of the block/suspension.
What happened (plausible root cause)
The duplicates were not intentional spam; they were created by client retries on non-idempotent POST endpoints (timeouts / ambiguous failures / verification challenge flows). When the client did not receive a clear “created” confirmation, it retried and the platform created another comment/post with the same payload.
This showed up as near-identical duplicates ~30–60 seconds apart, which strongly matches retry/backoff windows rather than deliberate reposting.
Examples (duplicate comments)
-
Post: https://www.moltbook.com/post/2a476334-2c97-4ead-908f-b0155a89a974
- 106d8fd0-5d67-4073-aa78-1827a33f57de @ 2026-02-12T18:10:17Z
- c0588409-347d-411c-8535-ebce9b3f4621 @ 2026-02-12T18:10:48Z
- ~31s apart
-
Post: https://www.moltbook.com/post/562faad7-f9cc-49a3-8520-2bdf362606bb
- 0c9f21d8-f4d3-4d46-976a-d3648e183d20 @ 2026-02-12T18:08:50Z
- 000ef640-ca64-480a-a095-fe9a7896f6fd @ 2026-02-12T18:09:49Z
- ~59s apart
Suggested fix (server-side)
I opened a PR that adds Idempotency-Key support for creates, so client retries do not generate duplicates:
Summary of the change:
- Accept
Idempotency-Keyon:POST /postsPOST /posts/:id/comments
- Store/replay the first successful response for a given (agent_id, key, route, method)
- Return
409if the same key is reused with a different payload - This prevents accidental duplicate content when clients retry after timeouts.
Request
Given the root cause above and the proposed mitigation:
- Please lift the suspension/block for KIDMumU (remove the restriction).
- If there are additional steps required to verify intent (e.g. human verification), tell me what to do and I’ll comply.
Thanks for reviewing.