No. There is no signup, no email address, no phone number and no password reset. The client makes its own keys the first time it runs. The server knows it by the public key, so a name and a key are the whole of an account. The only things a new member needs are the server address and the join password the host set. That password is never sent: the client proves it knows the password without revealing it.

Messages, voice and screen share stay locked, because the channel keys never reach the server and it has nothing to unlock them with. What a dishonest host gets is the details around the messages: addresses, display names, channel names, membership, who spoke and for how long, and the volume and timing of traffic. A dishonest host can also serve an edited web client to anyone using a browser. Building the client locally avoids that risk. The privacy page has the full list rather than a slogan.

Not yet. The published downloads are a Linux server build, the web client files and the container files, all listed on the download page. Windows and ARM64 server builds come from the release workflow and will be listed there once they exist. Anyone with the Rust toolchain can build from source today, and the hosting guide covers running the server as a service.

The defaults are 500 users, 200 channels and 5000 stored messages per channel, with per-connection limits of 30 control messages a second and 256 KB/s. Bandwidth is what really decides. Each block of voice goes once to every other listener. A listener receives about 40 kB/s, and a five person call has the host sending about 160 kB/s. A small rented server carries a few dozen people talking comfortably; a busy server with large calls wants a real uplink.

The web side lives on port 8443 over an encrypted connection, so anything in front of it that passes that kind of connection through carries it without special handling. Voice and video use port 8444, which ordinary web forwarding cannot carry. Browser voice then falls back to travelling inside the same connection as the chat. That works through the forwarding, at slightly higher latency. Desktop clients pointed straight at the address use the faster path. Ready-made nginx and Caddy samples, with the settings that keep the connection open, ship in the deploy folder that comes with the container files.

No, and it is worth being precise about why. The database stores a locked bundle, a signature, a message id, a sender id, a channel id and a time. It stores no keys and no readable text, so every message column is unreadable. What can be read is which channel each bundle belongs to, who sent it and when. There is no message content in the file to find. The hosting guide has a section on inspecting and backing up the database, so that can be seen first hand.

No. A phone browser can join a server, read channels and take part in voice. It uses the same connection as the chat, which is slower than the direct path a desktop client uses. Native Android and iOS clients are planned for a later phase and are not in this release. If a browser is enough for a group, that is the whole phone story today.