The client builds the envelope
It generates a fresh 32-byte session key and 24-byte XChaCha nonce, then encrypts UTF-8 message bytes with XChaCha20-Poly1305.
Technology
How Velixnet messages are protected.
Velixnet’s message layer uses libsodium with Curve25519 identity keys and XChaCha20-Poly1305 authenticated encryption. Each message gets a fresh session key, then travels as a Base64URL envelope that the PHP server stores unchanged and cannot read as plaintext.
Message path
What happens when a message is sent.
The important part is not mystery. The client creates a real cryptographic envelope, the server validates public routing fields, and only the intended devices can open the wrapped session key.
The session key is wrapped twice
Curve25519 crypto_box wraps one copy for the recipient and one copy for the sender, so sent history can decrypt after restart.
PHP stores only the sealed payload
The server checks session identity and public envelope fields, then stores the original Base64URL payload unchanged.
Technical position
Advantages and honest tradeoffs.
Advantage: authenticated encryption
XChaCha20-Poly1305 means altered ciphertext, wrong keys, changed identities, or malformed envelopes fail instead of displaying random text.
Advantage: device-owned identity
The long-term private key is generated on the client and protected by Android Keystore or macOS Keychain-backed storage.
Tradeoff: recovery is harder
If the device key is lost, secure recovery cannot be guessed into existence. It needs a deliberately designed recovery or key-rotation protocol.
Tradeoff: metadata is the server weak point
Encryption protects content, but every delivery server still sees some routing facts. Velixnet minimises those facts, separate them from message content, and keep retention narrow.
Advantage: QR identity verification
QR verification lets two real devices compare identity keys directly, reducing reliance on the server as the only source of contact-key truth.
Operational fact: HTTPS is active
velixnet.com is served with a trusted Let's Encrypt certificate, valid TLS protects transport; it does not replace end-to-end encryption.
Production honesty
What has to stay true as this goes wider.
Velixnet is not a pile of random GitHub pieces. It has a defined protocol and test coverage around the message envelope, sender binding, spoof rejection, malformed payload rejection, sent-history decryption, and QR identity verification. The next standard is operational discipline: keep the server honest, keep certificate renewal monitored, and keep metadata retention narrow.
- Keep HTTPS active, monitored, renewed, and enforced for the site and API.
- Keep QR identity verification as the human trust check for contact keys.
- Design signed key rotation and account recovery instead of silent replacement.
- Reduce server metadata: collect less, log less, separate it from content, retain less, and document what remains.