Helios encrypts every message with ML-KEM-1024 and authenticates the sender with Ed25519. Identity is a key pair, not a phone number. Transport runs over a Tor onion service. And a shared channel lets every member read the same messages the moment they sign in.
no accounts · no phone numbers · no central cloud
Each one is a protocol or storage rule, not a setting you can forget to switch on.
Messages are sealed with ML-KEM-1024 (FIPS 203). Recordings taken today cannot be opened by a future quantum computer — the reason "harvest now, decrypt later" is a real threat rather than a slogan.
A user is a key pair generated locally. The relay pins the public bundle on first sign-in, so a substituted key is rejected with KEY_MISMATCH instead of silently taking over an account.
Messages to an absent contact are queued on the relay and released on the next sign-in. Acknowledgement — not a successful socket write — decides that a message was received.
The behaviour people remember from classic messengers: one common room, and everything that happened while you were away is waiting when you come back.
The relay is a carrier of ciphertext. Its capabilities are deliberately limited.
| Property | How it is enforced |
|---|---|
| Confidentiality | ML-KEM-1024 key encapsulation plus AES-256-GCM. The relay stores and forwards opaque envelopes. |
| Sender authenticity | Ed25519 signature over the canonical envelope, verified by the recipient against the pinned public bundle. |
| Key continuity | The bundle is pinned on first sign-in. A changed key fails with KEY_MISMATCH until an administrator resets it explicitly. |
| Network anonymity | Tor v3 onion service over SOCKS5h — no DNS lookup for the peer, no IP address in the protocol. |
| Relay blindness | Broadcasts are encrypted per member by the sender's client. The relay cannot decrypt a Home channel message, including one it relayed itself. |
| Delivery guarantee | Queued messages leave the queue only after a client acknowledgement, so a broken connection cannot silently drop a message. |
| Administrative control | Registration, bans, key resets and queue inspection sit behind an admin token. Registration can be closed to approved HL# only. |
| Local data | Identity files are written with mode 0600 under a 0700 directory. The relay stores ciphertext, not plaintext. |
A locked-down Arch-based image with Wayland, signed A/B updates and dm-verity integrity checks — in three editions.
A clean Wayland desktop with its own application store.
Central device and policy control with an audit trail.
Strict boot and application policy for regulated environments.
Each image occupies one of two slots. A failed update leaves the previous version bootable.
Updates come from the CSSLTD release server and are signed. Signature verification happens on the client.
dm-verity hash trees cover the root filesystem, so modified system files fail to mount rather than run.
The administrator approves a numeric identifier in the panel. No e-mail, no phone number, no password.
The client creates ML-KEM-1024 and Ed25519 material locally. The private key never leaves the device.
The bundle is pinned on first sign-in. Connect over the tailnet address, or over the onion service with Tor.
Direct messages, or broadcast to the Home channel. Anything missed while offline arrives on the next sign-in.
Inside the tailnet the relay is reachable directly, without Tor. Outside it, the onion address works from any host with a Tor SOCKS5 proxy.
| Route | Address |
|---|---|
| Tailnet | 100.69.54.116:8074 |
| Tor onion | ek2uqyq6fz2hvdyvtl4mrnihhkbsxaikqx4v3j5w4vwtinwl73mesuid.onion:8074 |
The web client runs the same cryptography in the page: ML-KEM-1024 key generation, AES-256-GCM envelopes and Ed25519 signatures, all in JavaScript. The private key is generated in your browser and stays in local storage. Nothing is fetched from a third-party CDN — the crypto library is served by the relay itself.
Open the address in Tor Browser, enter your HL#, and press Connect. The relay verifies the key and pins it on first sign-in, exactly as the desktop client does.
| Client | Address |
|---|---|
| Web (Tor) | ek2uqyq6fz2hvdyvtl4mrnihhkbsxaikqx4v3j5w4vwtinwl73mesuid.onion/web/ |
| Web (tailnet) | 100.69.54.116/web/ |
| Desktop package | ek2uqyq6fz2hvdyvtl4mrnihhkbsxaikqx4v3j5w4vwtinwl73mesuid.onion/download/helios-desktop.pkg.tar.zst |
No. The relay carries opaque envelopes. It holds no private key, so it cannot decrypt a message — including a Home channel broadcast, which is encrypted once per member by the sender's own client.
The relay pins the public bundle on first sign-in. A different key for the same HL# is refused with KEY_MISMATCH. An administrator has to reset the pin explicitly before a new identity can enrol.
It is queued and delivered when you next sign in. The queue is cleared only after the client acknowledges receipt, so a dropped connection never loses a message silently.
Only when you are outside the tailnet. Inside it the relay answers on the tailnet address directly. Over the onion route the client uses SOCKS5h, so the hostname is never resolved locally.
Yes. The client and relay source are published in the AegisOS repository on GitHub.
The relay, the client and the AegisOS images are available for evaluation and on-premise deployment. Scope and terms are agreed in writing.