OPERATOR are
facts only the operator can supply: a security contact for the
instance, and the disclosure terms the operator commits to. Fill
them in, and have a qualified lawyer read the result, before
presenting this document as binding.
The contact points in these documents are the project's own. If you run your own
instance, replace them with yours before you publish them.
Version: 1.0 ·
Template last revised: 2026-09-20 ·
Effective on this instance:
OPERATOR: the date this page takes effect on this instance
1. Sign-in
Passwords are hashed before they are stored, and are never kept in a form the server could hand back. The work factor is 12 by default and can be raised per instance. Sessions use signed tokens with an individual identifier, so one session can be revoked and all of them can be revoked at once, and revoking them also disconnects any live connection opened by the old session. Optional two-step authentication adds a second factor for an account that wants one.
Email verification and password recovery are supported. A self-hosted instance with no mail configured sends no mail at all, which means it also cannot verify addresses or reset passwords by email; the operator has to handle those by hand.
2. Permissions
Community roles and administrative powers are checked on the server for every request. The client never decides for itself what you may do; it draws the answer the server gives. A permission that was misspelled in configuration is a startup error rather than a silent grant or a silent refusal.
3. Uploads
Avatars and file attachments are served through routes that check who is asking, not from a public folder anyone can browse. Uploads are identified by their contents rather than by the name the sender supplied, and a file the server cannot place is served as a download, so a browser is never asked to interpret bytes the server did not recognise. Avatars, banners and community icons must be images. The size limit is a per-instance setting, and uploads can be switched off entirely.
4. Rate limits and abuse controls
Registration, email verification, direct messages and other abuse-prone endpoints are rate limited per account and per address, with the limits configurable per instance. The limits are a speed bump, not a defence: they make casual abuse inconvenient and they do nothing about a determined attacker.
5. Moderation and records
Reports, appeals and administrative actions are written to a server-side log that only people permitted to see it can read. An action records who took it and when, and an appeal creates a record an administrator can act on rather than a message in a private inbox.
6. Federation
Federation is off unless an operator turns it on. Where it is on, a remote instance is not trusted: it cannot read a private channel, cannot see a local ban, and cannot grant itself local administrative rights. Material that arrives over federation is still content on this instance, and the rules in the acceptable use rules apply to it in full, including the prohibition on child sexual abuse material. The Federation Policy describes what an operator takes on when enabling it.
7. Transport security
Trycord speaks plain HTTP and expects to sit behind a proxy that terminates TLS, except in local development. Transport encryption is therefore the operator's responsibility. No method of transmission is perfect, and no operator can promise absolute security.
8. Supported versions
Trycord is developed continuously on main. Security
fixes land on the current codebase and are included in later
releases. There is no long-term-support branch.
| Component | Supported |
|---|---|
Server (main) | Yes |
Web client (main) | Yes |
| Latest desktop release | Yes |
| Older desktop releases | No |
| Unmaintained forks or modified builds | No |
If you self-host Trycord, keep your server updated with the latest supported code and apply fixes promptly. The changelog is where releases are described.
9. Reporting a vulnerability
Report privately, and only when it could allow unauthorized access, data exposure, privilege escalation, or other harm to users or self-hosted instances.
Preferred route: use GitHub's private vulnerability reporting on the repository. Do not open a public issue for a security vulnerability.
A useful report says what you found, where, how to reproduce it, and what the impact could be. If you can, include the version or commit, the configuration that matters, and a minimal reproduction.
Please do not test against instances that have not agreed to it, and do not access, change, or keep other people's data while demonstrating an issue. Do not send material that is itself illegal to possess, and do not include other people's personal data in a report; a description is enough.
A security contact for this instance, if you want one besides the project: the project's Discord, discord.gg/dSF7eqsJuP. The terms the operator commits to on disclosure are OPERATOR: how long the operator takes to release a fix, and what it will tell the reporter.
10. If you run an instance
Your users' security is your responsibility, because their data is
yours. Keep the server updated, set a unique
JWT_SECRET, put the service behind TLS, keep the
database and the upload directory off the public internet, and
review the settings that widen access before you turn them on. The
documentation covers the options that have
security consequences.
A secret that is shared between two instances is a secret that neither of them can rotate on its own. A default value left in place is not a secret at all.