Encryption
End-to-end encrypted appeals, encrypted moderation data at rest, and the keys that unlock both.
Two layers, one page
Open the Encryption section in your server dashboard. It shows both layers Nighthawk uses: end-to-end encryption, which locks ban appeals to a key only your staff hold, and encryption at rest, which stores sensitive moderation data in the database as ciphertext. The page lists exactly which data falls under each layer and which data stays readable on purpose.
Generate your appeal key
Press Generate keypair on the Encryption page. Your browser creates an RSA keypair, publishes the public half to Nighthawk and keeps the private half locally. From that moment on, a banned user’s browser encrypts their appeal to your public key before it is sent, so the appeal is unreadable to Nighthawk, to the database and to anyone who gets hold of either. Until you publish a key, appeals are stored as normal text.
Back the key up, twice
Generating asks for a backup passphrase of at least 8 characters and then downloads a backup file protected with it. A second copy, still protected by the same passphrase, is stored against your Nighthawk account so you can restore the key on another machine. Both copies are useless without the passphrase, and Nighthawk cannot reset it for you. If you lose the key and every backup, encrypted appeals stay locked forever.
Give the key to the rest of your team
The private key lives in one browser, so any other moderator who opens an encrypted appeal sees a locked placeholder instead of the text. They can restore it from their Nighthawk account, or you can hand them the backup file and passphrase and they import it under Import a key backup. Values that arrived encrypted keep a small lock marker next to them once decrypted, so it is always clear which data was protected.
Rotating the key
Rotate keypair replaces the published public key, so new appeals are locked to the new key. Old appeals still need the old private key, and rotation does not re-encrypt them. Keep the previous backup file before you rotate, or you lose access to everything submitted before it.
Encryption at rest
Separately from appeals, Nighthawk encrypts sensitive moderation data before writing it to the database: case reasons, saved and deleted message content, incident replay data, automod matched text, audit log details, username history and persisted nicknames and roles. Each server gets its own data key, and the dashboard and bot decrypt on the fly, so nothing changes in how you work. Rows written before this was switched on stay readable and are upgraded in place.
What stays readable
Watchlist report reasons are shared with other communities, so they are stored in plain text by design. IDs, timestamps and anything the bot needs for search, sorting and logging also stay readable. And none of this hides anything from Fluxer itself, which sees message content regardless of what Nighthawk does with it afterwards.
When something is wrong
If Nighthawk cannot read encrypted data, your Security page shows a warning finding saying so. It is not something you configured wrong, and there is no setting in your server that fixes it, so it costs you no points on your score. Reach out on the support server if the warning does not clear on its own.
Watchlist disputes
Disputes filed on the public watchlist page are end-to-end encrypted too, but to the Nighthawk network administrators’ key rather than to your server’s, since the network team reviews them. Your server key plays no part there, and disputes are never readable from a server dashboard.