Status: implemented metadata audit, pre-alpha
Successful account creation/status, invitation issue/revocation, channel-access initialization, global-capability, channel-role, initial-owner, owner-transfer, channel-ban, channel-limit, channel-key, and channel-retention changes create typed audit records in the same SQLite transaction as the authority mutation. A failed, stale, or idempotent request creates no record. An ownership transfer writes one record for each affected account at the same timestamp and policy revision.
Capability changes made through /operator/ use the authenticated configured
operator's stable account ID as the actor. The panel does not expose the audit
log or alter its 30-day retention.
The audit fields are deliberately narrow:
- local sequence and Unix-millisecond timestamp;
- infrastructure or stable account actor ID;
- typed action;
- optional target account ID, immutable account kind, or invitation ID;
- optional conversation ID, channel access mode, capability, previous/current role, previous/current member limit, previous/current typed retention override, and policy revision.
It never stores account or channel display names, IP addresses, host masks, device IDs, credentials, invite secrets, message bodies, or attachment data. Channel-key records contain only the conversation ID, action, actor, timestamp, and resulting policy revision; neither the raw key nor its Argon2id verifier is an audit value. Retention records contain policy metadata but never message content or a channel name. Failed, stale, out-of-range, disabled-indefinite, and idempotent requests create no retention record. Invitation redemption does not create a link-bearing audit action: issuance and revocation carry the invite ID, while the resulting human account has neither that ID nor the issuer ID. The CLI prints the stored IDs directly and does not resolve them into a more convenient social graph:
IRC_DATABASE=data/irc.db cargo run --locked -- authority audit list 100Records expire after 30 days. Expired rows are excluded from reads and deleted
on database open and on each successful audited mutation. SQLite secure_delete
is enabled, but this is ordinary bounded retention, not a forensic-erasure
promise: copied databases, filesystem snapshots, backups, and prior WAL frames
may outlive the primary row.
This is an operator diagnostic trail, not a tamper-proof transparency log. An operator with filesystem access can edit the database and binary. We do not add hash-chain theater that would imply protection from the same principal who controls both the data and verification code.
Channel access is recorded once, when the channel is created public or invite-only. It is deliberately not mutable: relabeling a room cannot retract history clients already retained or safely publish previously private history. Content reset removes prior channel- and invitation-scoped audit rows while retaining account and global-capability records inside this ordinary bounded window. The newly created public room receives fresh access and optional owner records. This metadata policy makes no claim to erase backups or remote copies; see content epochs and reset.