Moderation Command Center

[salmad3]

Overview:

Moderation is a top operational gap. Today the API can ban or hide content, but there is no interface, no on-chain authority mapping, and no traceable visibility. We will work towards a production-ready "command center" that trusted stewards can use without touching raw endpoints.

Based on the team’s and Jae’s insights, GovDAO appears to be a viable path forward.

However, this also relates to another broader focus, governance business logic on AtomOne. There’s no DAO-creation module (no x/group, no factory). The only extension is x/coredaos, which assigns two addresses (Steering, Oversight) limited to proposal controls: AnnotateProposal, EndorseProposal, ExtendVotingPeriod, VetoProposal. That leaves application‑layer governance open—Dither’s GovDAO initiative can fill that gap.

Also the need for a testnet.

Here’s the direction we’ve outlined:

Objectives:

• Ground moderator privileges in GovDAO roles instead of ad hoc tables
• Serve the admin surface from an isolated domain with hardened auth
• Provide clear tooling for post/account actions with full audit trails
• Add guardrails, rate limits, and monitoring so mistakes are caught early

Requirements:

Role & Permission Model

• Sync role assignments (super_admin, admin, moderator, future voice_chat_sheriff) from GovDAO; start on testnet, move to mainnet once proven
• Cache the role snapshot with TTL and invalidation when chain events arrive
• Allow super admins to delegate/ revoke moderators via on-chain workflow (link back to wallet flow)

Admin Surface & Authentication

• Host UI at https://admin.dither.chat with dedicated session store and restrictive CSP
• Enforce WebAuthn or hardware-key MFA for super admins; TOTP fallback for moderators
• Fail closed: unauthorized access redirects with an auditable event, no data leak

Moderation Toolkit

• Dashboard summarizing flagged items, active bans, and open escalations with filtering
• Post-level actions: hide, delete, shadow-ban, restore (capture reason, optional expiry)
• Account actions: temporary mute (duration picker), permanent ban, reinstate
• Bulk tooling for coordinated spam runs; include confirmation screens
• Evidence viewer showing the content, reporter history, and prior actions
• Inline audit log showing actor, action, timestamp, and rationale

Safety Rails

• Configurable thresholds (e.g., bans/hour per moderator) with override path for super admins
• Default to soft-delete; hard delete requires dual approval or elevated role
• Push critical events (mass ban, guardrail breach) to communications channel (Slack/Matrix)

Current State:

• /mod/* endpoints operate on a local moderators table with manual inserts; no GovDAO integration
• JWT login only proves wallet ownership; no role enforcement, session management, or MFA
• No frontend screens consume these APIs; moderators would have to rely on scripts and cannot see history
• audits table records actions but lacks any visualization or export path
• Admin experience shares the main domain; no isolated origin or hardened CSP
• No rate limits or guardrails; moderators can execute unlimited destructive actions without alerts

Dependencies

1. GovDAO role registry exposed on AtomOne
2. Infrastructure for admin.dither.chat (DNS, TLS, session store, auth provider)
3. Design system components and UX flows for moderation dashboards
4. Logging/metrics pipeline capable of ingesting moderation events