The people actually shipping slop hide the AI usage - I don’t. Make of that what you will.

Yeah, you’re right. I’ll fix this in the next update.

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.

GitHub: https://github.com/wardcore-dev/onyx/releases/tag/v1.5-beta

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.

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.

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.

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.