I got tired of every messenger asking for a phone number before letting you talk to anyone. Most privacy-focused messengers make you choose between convenience and privacy — either you get a polished experience with questionable data practices, or you get strong privacy with a painful setup. I tried to find the balance between the two. The result is ONYX. I want to be upfront about what it does and doesn't do privacy-wise — because "private messenger" is a claim that deserves scrutiny.

---

What the server actually knows about you

• Your username (not tied to phone, email, or anything real-world)
• That your devices exist (but not their private keys)
• Your IP address when connected (unavoidable)
• Message content in groups and channels — these are not E2EE encrypted, that's a real limitation

What it doesn't know:

• Your phone number or email — never collected
• Content of private chats — server only sees ciphertext
• Your favorites — stored locally only, server has no knowledge of them

---

How the E2EE actually works

Private chats use X25519 ECDH for key exchange (ephemeral per session) and HKDF-SHA256 for key derivation. I chose XChaCha20-Poly1305 over AES-GCM because it runs in constant time without AES-NI hardware acceleration — relevant for mobile devices — and has a 192-bit nonce vs 96-bit in GCM, which reduces collision risk in long sessions. LAN mode uses AES-GCM-256 — sessions are short-lived and never leave the local network.

Packet format (internet):

E2EEv1:[base64 JSON envelope: {eph pubkey 32B, nonce 24B, ciphertext, mac 16B}]

Packet format (LAN):

[pubkey 32B] [nonce 12B] [ciphertext] [mac 16B]

Multi-device works without the server touching your keys — new device sends an auth request to an existing trusted device, which must explicitly approve it before any key exchange happens.

---

The honest limitations

• Groups and channels have no E2EE — the only way to get full control over group communication is to self-host your own instance, so at least no third party has access to the data.
• Only incoming messages sync across devices — outgoing stay on the sending device only
• The server knows your IP when you're connected

---

LAN mode

There's a mode that works with no server and no internet at all — devices discover each other via UDP broadcast on the local network, exchange X25519 public keys in the broadcast packet itself, and communicate directly encrypted. Just hold the "Send" button in a private chat to choose this mode. Useful if you don't want any data leaving your network.

---

Self-hosted groups and channels

If you don't want to rely on the central ONYX server at all, you can run your own. There's a separate server software written in Rust — you download it, run it, and host your own groups or channels for your community or just a small group of friends. No web interface, runs entirely from the command line. Available for both Windows and Linux.

https://github.com/wardcore-dev/onyx-server/releases

---

Registration and account deletion

Username and password only. No phone, no email. Accounts can be deleted at any time and take all server-side data and media with them.

---

The project is still in early beta — rough edges are expected. If you run into any bugs or weird behavior, feel free to reach out directly to @support in ONYX. Just write your issue there and I'll look into it.

Available for Windows, Linux, macOS, and Android: https://github.com/wardcore-dev/onyx/releases

When you look at existing self-hosted messengers, you usually see one of two things: either complex infrastructure that's hard to deploy (Matrix/Synapse), or minimalism with no encryption. ONYX is an attempt to find the middle ground: easy to deploy, real E2E encryption, and the ability to work entirely in a local network without internet at all.

---

Project architecture

Component	Technology
Client	Flutter (Android, Windows, macOS, Linux)
Server	Node.js — Express + express-ws + ws
Database	MariaDB + Redis (sessions, cache)
File storage	S3-compatible (AWS SDK v3)
Transport	WebSocket (wss://) + HTTP/REST
Encryption	X25519 + XChaCha20-Poly1305 + AES-256-GCM

---

LAN mode: works without internet

One of the key features of ONYX is the ability to communicate in a local network without internet at all. A custom device auto-discovery mechanism handles this entirely.

Discovery protocol via UDP broadcast

Every client broadcasts a JSON packet to 255.255.255.255:45678 every 5 seconds:

{
  "username": "alice",
  "timestamp": 1710000000000,
  "pubkey": "<X25519 public key, base64>"
}

All other clients listen on that port and update two local tables:

• username → source IP address
• username → X25519 public key

No mDNS, no manual IP entry — just pure UDP broadcast. The public key is included directly in the broadcast packet, so encrypted communication can start immediately without an additional handshake.

Media transfer in LAN

Media files go through a separate channel on port 45679, split into ~32 KB chunks. Each chunk is encrypted independently with AES-256-GCM, which allows decryption and rendering to begin before the full file is received.

---

Encryption: two layers on elliptic curves

No RSA anywhere in the project — only a modern elliptic curve stack.

E2EE scheme for private chats

1. Key exchange: X25519 ECDH with an ephemeral key pair per session
2. Key derivation: HKDF-SHA256 with a context label (onyx-lan-v2 for LAN, separate labels for E2EE chats)
3. Encryption: XChaCha20-Poly1305 AEAD

Packet format:

[pubkey 32B] [nonce 12B] [ciphertext] [mac 16B]

Why XChaCha20-Poly1305 and not AES-GCM?

AES-GCM requires hardware acceleration (AES-NI) for decent performance. XChaCha20-Poly1305 runs in constant time on any hardware — important for mobile devices without AES-NI. It also has a wider nonce (192 bits vs 96 for GCM), which reduces collision risk in long sessions.

AES-256-GCM is used for LAN media transfers — chunked delivery, and hardware acceleration is available on most desktops.

---

Multi-device and E2EE

When a new device connects to an account, it sends an authorization request to a trusted device. The trusted device must explicitly approve the new one — only then does the key exchange happen. The server never has access to decrypted content, even when adding a new device.

Multi-device sync

When a message arrives, the server sends it to each of your devices separately — encrypted with that device's specific public key. Technically these are different encrypted messages for each device, just with the same plaintext inside.

One honest limitation: only incoming messages sync across devices. Outgoing messages are visible only on the device they were sent from. Full bidirectional sync with E2EE requires either a "copy to self" encryption mechanism or server-side plaintext storage — both are worse tradeoffs.

---

Why Flutter and not Electron or native development

The requirement from day one: one codebase for Windows, macOS, Linux and Android. Three options were considered:

Option	Problem
Native development	3–5 separate codebases, constant desync
Electron	+150–200 MB RAM, DOM rendering
Flutter	Single codebase, Skia/Impeller, real 60fps

Flutter Desktop required writing 10+ separate optimization modules (fps_booster, fps_optimizer, fps_stimulator, message_load_optimizer, chat_preloader) — Flutter on desktop lags noticeably without tuning. But the result is smooth UI across all four platforms from one repo.

---

Desktop-specific integrations

• System tray — app minimizes to tray instead of closing.
• Single-instance — prevents multiple copies via IPC. A second launch focuses the existing window.
• Custom titlebar — system titlebar hidden, custom header with drag zone
• Windows-native notifications — separate module, not Flutter overlay
• Autostart on system boot

---

Security beyond E2EE

• PIN + biometrics — Face ID / fingerprint via Flutter Secure Storage
• Proxy support — proxy_manager.dart, routing through any proxy
• Secure storage — all sensitive data through OS secure storage (Keychain / Android Keystore)
• Active session management — all connected devices visible, any session can be terminated remotely — but only from a trusted device

---

Self-hosted groups and channels

Two types of groups and channels in ONYX — fundamentally different models.

Built-in (via ONYX server)

Standard groups and channels work through the central ONYX server and are not encrypted — a deliberate tradeoff for reliable sync. Suitable for open communities where E2EE is not a requirement.

External (self-hosted)

Anyone can run their own instance — on a VPS, home server, or local network:

Use case	Description
Local network	File sharing and chat within office/home network, no internet
Private community	Closed group on your VPS, join by invite
Public channel	You host it, subscribers read posts

• Group — two-way, all participants can write
• Channel — one-way broadcast, only admins publish

Connect to any external server directly from the app — enter the instance address and join.

Deploying your own instance

Server software — ONYX Server: github.com/wardcore-dev/onyx-server

---

Favorites: local notes and storage

ONYX has a dedicated Favorites tab — not a "Saved Messages" clone, but a proper local notebook. Create any number of favorite chats, each with its own avatar and name, as separate categories: passwords, ideas, saved media, links.

Everything is stored locally on the device — nothing sent to the server, nothing synced. The server knows nothing about your favorites.

---

Accounts: anonymity, multi-account and deletion

• Registration — username and password only. No phone number, no email.
• Username — chosen once, permanent. Can never be changed. You can change your display name, but not the username itself.
• Multi-account — register and hold any number of accounts, switch freely.
• Account deletion — delete at any time with all media and server-side data. No traces left.

---

Current state

Project is in working beta. Development is ongoing. Happy to answer questions in the comments.

Try it out

ONYX: self-hosted messenger with LAN mode — an indie project story

When you look at existing self-hosted messengers, you usually see one of two things: either complex infrastructure that's hard to deploy (Matrix/Synapse), or minimalism with no encryption. ONYX is an attempt to find the middle ground: easy to deploy, real E2E encryption, and the ability to work entirely in a local network without internet at all.

---

Project architecture

Component	Technology
Client	Flutter (Android, Windows, macOS, Linux)
Server	Node.js — Express + express-ws + ws
Database	MariaDB + Redis (sessions, cache)
File storage	S3-compatible (AWS SDK v3)
Transport	WebSocket (wss://) + HTTP/REST
Encryption	X25519 + XChaCha20-Poly1305 + AES-256-GCM

---

LAN mode: works without internet

One of the key features of ONYX is the ability to communicate in a local network without internet at all. For this, a custom device auto-discovery mechanism was implemented.

Discovery protocol via UDP broadcast

Every client broadcasts a JSON packet to 255.255.255.255:45678 every 5 seconds:

{
  "username": "alice",
  "timestamp": 1710000000000,
  "pubkey": "<X25519 public key, base64>"
}

All other clients listen on that port and upon receiving a packet update two tables:

• username → source IP address
• username → X25519 public key

No mDNS, no manual IP entry — just pure UDP broadcast. The public key is included directly in the broadcast packet, which allows encrypted communication to start immediately without an additional handshake.

Media transfer in LAN

Media files go through a separate channel on port 45679, in chunks of ~32 KB. Each chunk is encrypted independently with AES-256-GCM, which allows decryption and rendering to begin before the full file is received.

---

Encryption: two layers on elliptic curves

No RSA anywhere in the project — only a modern elliptic curve stack.

E2EE scheme for private chats

1. Key exchange: X25519 ECDH with an ephemeral key pair per session
2. Key derivation: HKDF-SHA256 with a context label (onyx-lan-v2 for LAN, separate labels for E2EE chats)
3. Encryption: XChaCha20-Poly1305 AEAD

Packet format:

[pubkey 32B] [nonce 12B] [ciphertext] [mac 16B]

Why XChaCha20-Poly1305 and not AES-GCM?

AES-GCM requires hardware acceleration (AES-NI) for decent performance. XChaCha20-Poly1305 runs in constant time on any hardware — important for mobile devices without AES-NI. An additional bonus is the wider nonce (192 bits vs 96 for GCM), which reduces collision risk with a large number of messages in a single session.

AES-256-GCM is used for LAN media — chunked delivery, and hardware acceleration is available on most desktops.

---

Multi-device and E2EE

One of the trickiest cases — a user with multiple devices while keeping E2E encryption intact.

When a new device connects to an account, it sends an authorization request to a trusted device. The trusted device must explicitly approve the new one — only then does the key exchange happen. This means the server never has access to decrypted content, even when adding a new device.

---

Private messages and multi-device sync

Private chats work through the central ONYX server with E2EE. Technically, multi-device works like this: when a new message arrives, the server sends it to each of your devices separately — encrypted with that device's specific public key. Technically these are different encrypted messages for each device, just with the same plaintext inside.

One honest limitation: only incoming messages sync across devices. Outgoing messages are visible only on the device they were sent from. This is a deliberate tradeoff — full bidirectional sync with E2EE requires either a separate "copy to self" encryption mechanism or server-side plaintext storage. Both options are either more complex or less secure.

---

Why Flutter and not Electron or native development

The requirement from day one: one codebase for Windows, macOS, Linux and Android. Three options:

• Native development: 3–5 separate codebases, much more work and constant desync between platforms
• Electron: cross-platform yes, but Chromium in-process means +150–200 MB RAM on startup and DOM rendering instead of native
• Flutter: single codebase, Skia/Impeller rendering without DOM, real 60fps on animations

For a messenger with active animations, media and chats the rendering difference is significant. Flutter Desktop required writing 10+ separate optimization modules (fps_booster, fps_optimizer, fps_stimulator, message_load_optimizer, chat_preloader) — Flutter on desktop lags noticeably without tuning. But the result is smooth UI across all four platforms from one repo.

---

Desktop-specific integrations

• System tray — app minimizes to tray instead of closing. Online status is preserved.
• Single-instance — prevents multiple copies via IPC. A second launch focuses the existing window.
• Custom titlebar — system titlebar hidden, custom header with drag zone
• Windows-native notifications — separate module, not Flutter overlay

---

Security beyond E2EE

• PIN + biometrics — Face ID / fingerprint via Flutter Secure Storage
• Proxy support — proxy_manager.dart, routing through any proxy
• Secure storage — all sensitive data through OS secure storage (Keychain / Android Keystore)
• Active session management — all connected devices are visible, any session can be terminated remotely — but only from a trusted device

---

Self-hosted groups and channels

Two types of groups and channels in ONYX — fundamentally different models.

Built-in groups and channels (via ONYX server)

Standard groups and channels work through the central ONYX server and are not encrypted — a deliberate tradeoff for reliable sync. Suitable for open communities where end-to-end encryption is not a requirement.

External groups and channels (self-hosted)

Anyone can run their own instance — on a VPS, home server, or directly in a local network. Use cases:

• Local network — file sharing and communication within an office or home network without internet
• Private community — closed group on your own VPS, join by invite
• Public channel — you host it, subscribers join and read posts, also by invite

A group is two-way communication — all participants can write. A channel is one-way broadcast — only admins publish, others read.

Connect to an external server directly from the app — enter the instance address and join the group or channel.

Deploying your own instance

There's a dedicated server software — ONYX Server, available at github.com/wardcore-dev/onyx-server:

git clone https://github.com/wardcore-dev/onyx-server
cd onyx-server
npm install
cp .env.example .env
node server.js

Dependencies: MariaDB + Redis + any S3-compatible storage (MinIO works for a fully local stack). Runs on a $5/month VPS.

---

Favorites: local notes and storage

ONYX has a dedicated Favorites tab — not a "Saved Messages" clone, but a proper local notebook. You can create any number of favorite chats, each with its own avatar and name, and use them as categories: passwords, ideas, saved media, links.

Everything is stored locally on the device — nothing is sent to the server, nothing is synced. The server knows nothing about your favorites.

---

Accounts: anonymity, multi-account and deletion

Registration requires only a username and password. No phone number, no email — a deliberate decision to keep minimal data on the server.

Your username is chosen once and forever — it cannot be changed. It's your permanent identifier in the system. You can change your display name, but not the username itself.

Multi-account: register and hold any number of accounts in the app, switch between them freely.

Account deletion: delete your account at any time along with all media and server-side data. No traces left.

---

Current state

The project is in working beta. Development is ongoing. Happy to answer questions in the comments — especially about the crypto implementation or Flutter Desktop specifics.

Try it out — github.com/wardcore-dev/onyx-server

---

Tags: #flutter #node #encryption #selfhosted #privacy #opensource #security #webdev