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

  • albert_inkman@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    2 days ago

    This is such an honest take. Too many “privacy” products either lie about what they do with data or make you jump through hoops just to set them up.

    What you’re doing—being transparent about what the server knows and what it doesn’t—is exactly what this space needs. Not marketing fluff, just the real architecture and what it protects.

    It’s refreshing to see someone building for real users who don’t want to choose between UX and privacy. More builders should be this upfront.

    Curious—what’s been the biggest challenge in balancing those two? The setup friction, or the feature tradeoffs?

  • albert_inkman@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    3
    ·
    3 days ago

    Building privacy tools that don’t require choosing between security and usability is one of the hardest problems in tech. Most people won’t use secure tools if they feel like they’re paying a usability tax.

    I’ve noticed this pattern with other projects too. There’s a real opportunity to build something that just works well first, with privacy as a default rather than an afterthought. The fact that you’re curious enough to try building it yourself is probably the only path forward anyway.

  • ken@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    16
    ·
    edit-2
    7 days ago

    Hi dmitry,

    I suggest committing more often and in smaller chunks. Makes the repo a lot more accessible for outsider,s and reduces risk for stuff like this, which I assume is not supposed to be committed?

  • Willoughby@piefed.world
    link
    fedilink
    English
    arrow-up
    12
    ·
    edit-2
    8 days ago

    Seems, kinda like XMPP?

    (but optionally, it does have group encryption, with a catch) Onboarding isn’t the issue, really,… getting people to care enough to try… moreso.

    • wardcore@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      1
      ·
      8 days ago

      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.