Anzen
Download

Features

Everything the app does today

Anzen is a community chat client: workspaces, text and voice channels, direct messages, and a member list. The difference is that the conversation is sealed before it reaches the server.

Rooms that feel familiar Direct messages and invites Voice channels Pictures and files Link previews, on your device Roles and permissions Sign-in without a password

Rooms that feel familiar

Anzen uses the community-chat layout: a workspace rail, a channel list, a message thread, and a member list.

  • Every new workspace starts with a
  • Messages support a small Markdown set: bold, italic, strikethrough, code, and @mentions.
  • Replies, edits, and reactions are encrypted the same way as text, so the server cannot tell them apart.
  • Typing indicators name who is typing. They do not include the draft.
  • Push notifications, when a build includes them, name the sender and the place. They never include the message.

Direct messages and invites

A direct message exists only between two people who already share a workspace.

  • Unknown, self, and unshared usernames all look the same to the requester, so the app does not reveal who has an account.
  • Workspace invites are short codes. The server stores a hash of the code, not the code itself.
  • An invite can also be sent as an ordinary encrypted message, which the app shows as a join card.
  • Codes expire within 7 days and have a use limit.

Voice channels

Voice is a peer-to-peer WebRTC mesh. The server relays offers, answers, and network candidates. It never carries audio.

  • Call audio between the two devices is encrypted (DTLS-SRTP).
  • Speaking indicators come from WebRTC audio levels and draw a green ring around whoever is talking. Mute closes the microphone. Deafen also stops playback.
  • Each pair of people can compare a 30-digit voice privacy code. Matching codes mean nothing is sitting between them.
  • Echo cancellation, noise suppression, and gain control can be changed without rebuilding the call.
  • Per-person volume and “Mute for me” stay on your device.
  • “Always relay calls” forces a TURN relay so other people see only the relay’s address. Without a relay configured, the app refuses to join rather than connect directly.
  • Owners and admins, or anyone granted the moderate-voice permission, can server-mute, server-deafen, or disconnect someone.
  • Free rooms allow up to 5 people at once. Anzen Plus allows up to 25. The mesh sends each speaker’s audio to every other device, which is the size it is built for.

Pictures and files

Attachments use the same envelope model, with the file kept out of the message body.

  • Before upload, JPEG, PNG, and WebP pictures have location, camera, and editing details removed on the device. Color and pixels stay. GIF metadata is not removed.
  • The composer attaches from Photos, Camera, or Files.
  • Each file is encrypted with its own key (AES-256-GCM). The name, type, and size travel inside the encrypted message.
  • The server learns the conversation, the uploader, and the encrypted size. It does not learn the name, the type, or the contents.
  • A picture is shown in the thread only when the decrypted bytes are PNG, JPEG, GIF, or WebP. Anything else, including SVG, is offered as a file to save.
  • Decrypted files stay in memory for the session and are dropped when the vault locks. Nothing decrypted is written to disk unless you save it.
  • Free accounts can send up to 5 MB. Plus accounts can send up to 8 MB. The cap is the file before encryption, and the encrypted message for text.

Roles and permissions

Workspaces start on a simple ladder: owner, admin, manager, and member.

  • Managers and above can rename the workspace and create, rename, and delete channels.
  • Invites, removal, and role changes stay with admins and the owner.
  • Only the owner can make admins, and nobody can change their own role or the owner’s.
  • The owner can turn on custom roles. Each role has a color, a position, a hoist flag, and a permission bitfield. Permissions stack.
  • Switching back to the simple ladder keeps the custom roles for later and folds people onto admin, manager, or member from the bits they hold.

Sign-in without a password

The first contact is a short-lived email code. The account then enrolls an authenticator app or a hardware passkey before a full session exists.

  • A new device always needs two factors. A passkey alone on a new device is refused until the email code is confirmed.
  • Device trust starts at 14 days. That device can change it to 1, 7, 30, or 90 days, or to never. Choosing never warns you and emails the account.
  • Inside the window, one factor is enough only together with a proof that the device still holds its quantum-proof secret key (ML-KEM).
  • When that window has ended, verification is authenticator-first: the app asks for the authenticator code if one is enrolled, and sends an email code only if you choose that instead.
  • Change device PIN uses the same authenticator-first check.
  • Unlocking the app with the device PIN, Face ID, or a fingerprint can renew an expired session from that key proof.
  • The PIN seals the keys with a password hash (PBKDF2-HMAC-SHA256) and authenticated encryption (AES-256-GCM). The PIN is not stored. Face ID or fingerprint unlock releases the key from the phone’s secure storage and is unavailable in the browser build.
  • The vault locks after the app spends 5 minutes in the background, unless a call is in progress.
  • Android backups and device transfers exclude app data. iOS excludes the vault from backup.

How the encryption fits together