beta · guide · 0.1.0
Remove comments into tombstones
Before removal, the Project Backend verifies its own session, Project Membership, exact resource visibility, and that the current user still controls platform_account_id. MiniCenter requires a server-side Project Credential with comments:write and matches the Comment's Project Client, author, resource_type, and resource_id. A mismatch returns 422 without revealing which boundary failed.
: "${MINICENTER_URL:?set the Sandbox URL}"
: "${MINICENTER_PROJECT_CREDENTIAL:?set a Project Credential}"
: "${MINICENTER_COMMENT_ID:?set a Comment ID}"
curl --fail-with-body -X DELETE "${MINICENTER_URL}/api/v1/community/comments/${MINICENTER_COMMENT_ID}" \
-H "Authorization: Bearer ${MINICENTER_PROJECT_CREDENTIAL}" \
-H 'Content-Type: application/json' \
--data '{"platform_account_id":"30000000-0000-4000-8000-000000000003","resource_type":"article","resource_id":"article-42","idempotency_key":"article-42-comment-remove-1"}'
Removal is a terminal tombstone, not hard deletion. List APIs retain the Comment's position, ID, author, resource, revision, moderation state, and removed_at, but return body: null. Reaction summaries return zero counts and new reactions or edits fail closed. Stored content, body revisions, reactions, reports, and moderation decisions remain available for dispute handling for 30 days after removal. The hourly community:retain job then erases the body and revision/edit history and deletes reactions and reports. The minimal tombstone remains to preserve reply structure and prevent replay from recreating removed content. An active, audited, expiring Privacy Legal Hold on an affected author or participant defers this purge until the hold expires.
Reuse an idempotency_key only for the identical Comment, author, and resource. An identical replay returns the original tombstone; changed input returns 422. A second removal under another key does not create another transition. Removing a parent does not cascade to existing replies, but a removed parent accepts no new replies.
The first removal atomically publishes one client-scoped community.comment.removed event containing Comment, nullable parent, resource, and time only—never author identity or body. If the outcome is uncertain, retry with the original key. Tombstone state, idempotency proof, and durable event commit together or all roll back.
Account privacy lifecycle
Privacy Exports include the account's own comments, revision bodies, reactions, reports and browser-grant metadata. They exclude other reporters' identities, unrelated authors' content and grant token hashes.
When Account Deletion is ready to finalize, authored comments become terminal tombstones and publish the normal removal event. Their content and revision/edit history, and the account's reactions, reports and browser grants, are erased immediately. Other authors' replies remain intact. An active Privacy Legal Hold hides the authored comments immediately and defers final erasure; the deletion scheduler retries pending requests after holds expire. The existing project acknowledgement/deadline rules still apply.
Expired browser grants are purged hourly, unless their account has an active Privacy Legal Hold. Token expiry is always enforced independently of storage cleanup. Active comments are retained while published; their revisions support the published comment's edit history until removal or Account Deletion.