Data and privacy

The cog splits the channel state between Red's Config and a compact append-only store on disk. Red's Config holds only the small scalar state:

• the current count,
• the author-lock limit (allow_same_before; see [p]count allowsame),
• the user id of the last accepted count,
• the id of the newest count message (the catch-up checkpoint),
• the timestamp of the last full audit rotation,
• the audit's walk position and per-section freshness timestamps,
• the pending repair notice, if one exists.

The ledger of count number to message id pairs lives outside Config in a per-channel store, ledger-<channel-id>.cg, under Red's cog data directory: a compact binary file (a 4-byte magic header, then one 16-byte little-endian (number, message id) record per count), documented in the cog's store.py. Keeping the bulk mapping out of Config means the hand-editable Config JSON stays small no matter how high the count — a million-count channel is a ~16 MB ledger file instead of a ~30 MB JSON document rewritten on every message — and Config never holds the ledger at all once an older install's in-Config ledger has been migrated. The store is not a second source of truth: the channel log is, and the checkpoint is re-derived by the audit, so the file is written append-only, fsynced only on close, and rebuilt from the log if it is ever corrupted.

No message content is stored. The user data kept is the id of the last count author, plus, only while a repair notice is pending, the ids it names: the anchor author of the last intact count and, for an edited count, the author who edited the message into a breach. Everything is scrubbed through Red's data tools: a user can run [p]mydata forgetme, and the owner can run [p]mydata ownermanagement deleteforuser or processdiscordrequest.