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”.