Your devices identify each other
Each account has public identity information that can be shared to protect messages. The matching private information stays on the device.
Technical layer
How Velixnet is designed to protect private messages.
Velixnet is designed so that your device keeps its private identity information and locks message content before sending it. The delivery service handles protected message data rather than readable conversation text.
Message path
What the delivery service receives.
A sent message is packaged for delivery. The service needs enough information to send it to the right person, but the message itself is already locked before upload.
The message is locked on your device
Before upload, the app prepares protected message data using established encryption tools.
The service delivers protected message data
The delivery service checks routing information, queues the protected data, and makes it available to the intended recipient.
Under the hood
The technical design in plain language.
The design is intentionally small: encryption on the device, device identity, protected account information, and a delivery service with a limited role.
Cryptographic base
Velixnet uses established encryption tools, including Curve25519 and XChaCha20-Poly1305, rather than creating new cryptography. The implementation and test status still need checking before this is treated as independent security assurance.
Envelope format
Messages are sent as structured packages containing protected cryptographic data. The service is meant to store and forward the package, not interpret the message inside it.
Account identity
Accounts use a Velix ID rather than a phone number or email address. This keeps account identity separate from a mobile number.
Delivery layer
The delivery layer manages account state, public-key availability, protected messages, delivery confirmation, expiry, and basic abuse controls. It is not meant to become a second copy of the conversation.
Technical position
What this protects—and what it does not.
Authenticated encryption
If protected message data is changed, uses the wrong key, or is malformed, the app should reject it instead of treating it as a normal message.
Device-owned secrets
The security model depends on private identity information staying on the user's device. The service should not receive private keys or readable message content.
Recovery needs care
Encrypted recovery and deliberate key-change handling are implemented. A missing or changed identity must not silently be treated as the same trusted device.
Metadata still exists
Locked message content is not the same as invisible traffic. The service still needs limited information to authenticate, route, and deliver data.
QR identity check
QR verification lets two people compare identity information directly, reducing blind trust in whatever key the service returns.
HTTPS is transport, not E2EE
HTTPS protects the connection to the website and service. End-to-end encryption is a separate layer that locks message content before delivery.
Public implementation and release-status checklist
What is implemented, and what still needs verification.
This is the current send-to-server chain and its release status, reviewed on 26 August 2026. A checkmark means the behaviour is present in the current build or has been observed on the live service; it is not an independent audit or formal security assurance. An empty box means work or fresh operational evidence is still required.
| Implementation block | Status |
|---|---|
| 1. Device creates or loads protected identity keys. | Completed |
| 2. Client normalizes the sender and recipient IDs. | Completed |
| 3. Client fetches and validates the recipient public key and saved identity pin. | Completed |
| 4. Client creates fresh message encryption or advances the ratchet session. | Completed |
| 5. Client encrypts the plaintext locally with authenticated encryption. | Completed |
| 6. Client binds protocol, sender, recipient and client data as authenticated context. | Completed |
| 7. Client wraps the message key for recipient and sender history where required. | Completed |
| 8. Client clears temporary secret buffers after cryptographic use where the platform supports it. | Implemented |
| 9. Client validates envelope fields, sizes, encoding and UTF-8 boundaries. | Completed |
| 10. Client commits outbound ciphertext locally before network delivery. | Completed |
| Implementation block | Status |
|---|---|
| 11. Client sends the opaque envelope to the API over HTTPS. | Completed |
| 12. Public site and API are live over HTTPS. | Completed |
| 13. The public hostname has a currently valid certificate and an expiry reminder. | Implemented |
| 14. Continuous uptime monitoring for the public site and API is independently evidenced. | Not completed |
| 15. Server validates routing metadata without decrypting the message body. | Completed |
| 16. Server stores and queues the encrypted envelope for the intended recipient. | Completed |
| 17. Recipient client validates, decrypts and checks replay state locally. | Completed |
| 18. Recipient commits local plaintext/session state before acknowledging delivery. | Completed |
| 19. QR verification is available for direct contact identity checks. | Completed |
| 20. Recovery and key changes require deliberate state handling and re-verification rather than silent trust changes. | Completed |
| 21. Metadata collection, retention and logging are reduced wherever service operation allows. | Not completed |