Docs/Trust and data flow
Reference

Trust and data flow

A plain description of how the dashboard authenticates you, what it stores, and how it stays in sync with the bot — for anyone who wants to know before connecting a Discord account.

01

Signing in

Signing in uses Discord's own OAuth flow — you authorize on Discord's website, not ours, and we never see your Discord password. Discord returns an access token scoped to what the login screen showed you: your identity and your guild list.

02

What the session actually stores

The OAuth tokens Discord issues are encrypted (AES-256-GCM) before they're stored, and the browser only ever holds a session identifier in a cookie — not the tokens themselves. If your access token expires while you're active, it's refreshed automatically using the encrypted refresh token; you're not silently logged out mid-session.

03

Every action is re-verified live

The dashboard does not trust the permissions it saw at login. Every page load and every save re-fetches your current guild list and Manage Server permission directly from Discord before deciding what you're allowed to do. That's a deliberate choice: a 14-day session should never grant access you no longer actually have, because your roles or membership can change at any point during it.

04

The bot and dashboard never talk directly

The website and the bot process are separate deployments that can run on entirely different servers. They coordinate only through a shared MongoDB database — the dashboard writes configuration and the bot reads it, and for real-time features like music, the bot publishes state that the dashboard polls. Neither side opens a direct connection to the other, and the dashboard talks to Discord exclusively over its REST API, not the realtime gateway a running bot uses.

RelatedFor the specific mechanics behind the music player's real-time sync, idle handling, and reconnection behavior, see the music system deep dive.