Navigation
1. Welcome2. Administration2.1. Installation2.2. Running2.3. Configuration2.4. Services2.4.1. CDN2.4.2. Voice2.4.3. Long-poll API2.5. Bots2.5.1. Botfather2.5.2. Mgmt App2.5.3. Telegram bridge2.6. Nginx examples2.7. Metrics2.8. Sing-box2.9. FAQ3. Developing3.1. Build from source3.2. Feature flags3.3. CDN3.4. How old guild settings (aks json settings) are implemented3.5. Mdbook3.6. Server overview3.7. How to patch a certain android client3.8. How to patch a certain web client3.9. Known resources3.10. How to test in manual mode3.11. Tg stickers mapping3.12. "tokio-rs / console" tool3.13. Typegen4. Help wanted5. Research5.1. Brief Discord API changes history5.2. CDN architecture draft5.3. Encryption5.4. Message Acknowledge5.5. 2026-Feb-035.6. Permission sync5.7. Vanilla bugs5.8. Voice region switch procedure5.9. Webrtc6. Setup guide7. DC features implementation status8. Vocabulary
DCAS handbook
https://xmpp.org/extensions/xep-0384.html
Client might be malicious;
Client device is assumed to be secure;
Communication channel is assumed to be secure;
Server might be insecure;
All data is stored in a plain text;
Absolutely fine for guilds with public invite (anyone can access guild data
anyways) and guild with a large number of participants (such guild is
insecure in a practical sense);
What is encrypted: guild name, channel name, channel topic, message text,
role name, nickname, image data;
How it is encrypted:
DM: DH/ECDH;
GDM/guild: pre-shared key;
Model/api changes:
Guilds/DMs/GDMs now have “security mode” property:
server: implement this filed for guilds and channels;
server and client: reject plaintext-looking msgs in secure channels;
client: show guild/channel security mode (and explain what is it);
Users have asymmetric key pairs, possibly time-limited;
client: store private keys secure;
client: allow user to generate, view and manage keys;
client: notify user on their or others’ key expiration;
Users can share their public keys manually;
there should be message type / embed to show pubkey to the user;
client: allow user to easily add and auto-verify others’ pubkeys;
Server stores public keys and provides em w/ user profile;
server: store and send pubkeys;
client: show something like “emoji hash” to make it easier to
manually validate peers pubkeys;
Text and image data is transmitted and stored encrypted:
cdn: do not attempt to transform encrypted images;
Users/channels/guilds may have multiple keys associated with it:
client: choose decryption key depending on message edit time;
client: if have sufficient rights, allow guild key re-issue and
automatic key transmission to all/chosen members via encrypted DM;
Notes:
server now has no access to message data, but meta-data is still public;
almost no forward secrecy and post-compromise security;