On mobile the key comes from the platform keychain — tied to device unlock, not the app. On desktop it’s machine-derived. The decoy PIN threat model is coercion — someone watching you unlock. If an attacker already has filesystem access, you’ve got bigger problems than the PIN.
No, it’s not one file with two decryption keys — you’ve got the architecture slightly wrong. There’s one storage, encrypted with AES-256-GCM. The PIN doesn’t decrypt the file — it’s verified at the application level. If the real PIN matches, the real environment loads. If the decoy PIN matches, the decoy environment loads with its own data, stored in the same storage under separate keys. Two layers of data in one container, not two containers with different keys.
Groups are multi-member chats where everyone can send messages. Channels are one-way — only admins post, members just read.
Good points, but the architecture is a bit different. It’s not two separate encrypted files — from the outside there’s no indication there are two PINs at all. The decoy environment looks like a fully functional account: its own chats, groups, contacts, message history. The attacker doesn’t know there’s a second layer because nothing tells them the first layer is a decoy.
Your approach of generating a random DB for any wrong PIN is interesting too, but it has a different problem: there’s no “correct” result, any PIN “works”, and a paranoid attacker can figure that out. Here the decoy environment is convincing precisely because it’s a real-looking account, not a placeholder.
On encryption: AES-256-GCM, keys derived via HKDF-SHA256 with salt. The code is fully open source on GitHub — that is the documentation. Separate security docs don’t make sense for me to write right now, but if the project grows — definitely yes.
This update actually wouldn’t have happened without your suggestion — you pushed me to finally implement it. Thank you!
Just to clarify — LAN mode is an optional feature, not the only way the app works. By default ONYX works like any other messenger through a central server, with E2EE for private chats (unlike Telegram, where only Secret Chats are E2EE). LAN mode is an additional feature for people on the same local network who want to communicate without any internet or server involved at all — useful for office environments, local events, or situations where internet access isn’t available or isn’t wanted. So to answer your question: in normal mode, the server handles routing. In LAN mode, UDP broadcast handles discovery automatically — no manual IP tracking needed.
Fair question. The honest answer is: it depends on what you need. Matrix is a protocol with federation, a large ecosystem, and years of development behind it. If you need federation or interoperability with other services, Matrix is the better choice. ONYX is different in a few ways:
LAN mode — works entirely without internet via UDP broadcast, no server needed
Simpler self-hosting — one binary, runs from the command line, no complicated setup
Native Flutter client — single codebase for Android, iOS, Windows, macOS, Linux
The tradeoff is that ONYX is less mature, still in beta, and doesn’t have federation yet (it’s on the roadmap). If you’re already happy with Matrix, there’s probably no reason to switch. If you want something lighter and simpler with a focus on privacy and offline capability, it might be worth trying.
Messages are stored on the server only until the recipient comes online. Once they connect, a 30-second timer starts — after that the message is permanently deleted from the server. There’s no copy left server-side after that point. Since private chats use E2EE, the server only ever sees ciphertext anyway. After delivery, messages exist only locally on both devices. If you want no local record either, you can delete the conversation manually from within the app.
I understand it’s not for everyone. But the 16-character minimum is there for a reason — your password is the only key to your account, no fallbacks, no recovery via phone or email. That requires a strong password. There’s a built-in password generator in the app — one tap, cryptographically secure, 16 characters, done. Save it once and you won’t need to type it again. Think of it like a crypto wallet seed phrase — you store it once somewhere safe and that’s it. If the priority is speed over security, Telegram is a better fit. ONYX was built for people who actually care about privacy, and that comes with a slightly higher entry bar. That said, I’ll consider dropping the hard minimum to 8 characters with a strong recommendation to use 16 — so people have the choice but know the tradeoffs.
Yes, 16 characters minimum. Since there’s no phone number, no email, and no alternative recovery method - the password is the only thing protecting your account. A weak password with no fallback is a real risk, so I set the bar higher intentionally. It also reduces brute force viability. Passphrases are supported but currently not used for login - just the password for now.
Write to @support directly in ONYX, using the search field, and we’ll discuss this in detail.
Honestly, the main motivation was just curiosity - I wanted to see if I could build something like this, and then put it out there to see if anyone actually cares.
Fair point, I just missed adding it to .gitignore.
that’s a great idea, I’ll consider adding it in one of the upcoming updates.
Fair skepticism, but no - I used AI for the English translation of my post, since I’m not a native speaker.
Just to clarify — E2EE in ONYX is only for private chats. Groups and channels (both built-in and self-hosted) don’t have E2EE, which is actually closer to your point — for groups it’s a deliberate tradeoff for simplicity and reliable sync. So you’re right, for that use case TLS is enough.
Fair point! Yes, Claude was used as a coding assistant throughout the project. That said, every single line went through strict manual review — nothing was blindly copy-pasted into the codebase. All architectural decisions, the crypto stack choices, and the overall design are my own. Claude helped with boilerplate and speeding things up, but the project is not “vibe-coded”.
Yeah, you’re right. I’ll fix this in the next update.