Server accounts
Local accounts are usernames and passwords stored by one server, for people who don’t want to use a Rotur account. The protocol calls them cracked accounts, and their user IDs start with USR:local_. Both names are current, not deprecated.
Enable local accounts
Section titled “Enable local accounts”Merge this into config.json to allow both Rotur and local accounts:
{ "auth_mode": "cracked", "cracked": { "allow_registration": true }}auth_mode takes one of three values:
| Value | Rotur login | Local login |
|---|---|---|
rotur (default) |
Yes | No |
cracked |
Yes | Yes |
cracked-only |
No | Yes |
Set cracked.allow_registration to false to stop new sign-ups while existing local accounts keep working.
You can also change these with config_update. Only the owner can change auth_mode and cracked. The change applies to new logins right away, but connected clients learn about it only from the handshake, so they need to reconnect.
Rules for local accounts
Section titled “Rules for local accounts”- Usernames are 2 to 32 characters of lowercase letters, digits,
-, and_. Uppercase input is lowercased. - Passwords are 4 to 72 characters.
- Registration counts toward
limits.max_members. - New local accounts get the roles in
DB.users.default.rolesas read at startup.
Local accounts are stored in users.json alongside Rotur accounts. Passwords are stored as bcrypt hashes. There’s no password reset, so a member who forgets their password needs a new account.
Local and Rotur accounts share roles, channel permissions, bans, timeouts, and presence. Local accounts aren’t included in the hourly Rotur ban check.
Implementing another server
Section titled “Implementing another server”The rest of this page is for people writing their own OriginChats server. See the server account protocol for the wire format.
Registration must:
- Validate the username and password.
- Check that the username is free and the member limit isn’t reached, while holding the lock that guards account changes, so two sign-ups at once can’t both pass.
- Save the account before reporting success. If the save fails, don’t keep the account in memory.
A successful login follows the same auth_success and ready sequence as a Rotur login. Issue a fresh local upload token for HTTP uploads, and invalidate the old one when the member logs in again or disconnects.
For HTTP uploads, resolve the token to an existing local account, and apply ban and timeout checks. An avatar upload must target the token’s own account. The client account guide covers avatar formats and responses.
Never include password hashes in public user objects.
Local accounts have no Rotur signing keys. Take message authorship from the logged-in session, and ignore any Rotur proof fields a local account sends.
Moving data from the legacy Python server is a separate job from turning on local accounts. Sharing a protocol name doesn’t make the two database layouts interchangeable.
