Fundamental principle
Solo2 creates a private tunnel between two people. Direct. No middlemen.
Our server does one single thing: it introduces the two ends of the tunnel so they can find each other. For that it needs the bare minimum — the identifiers of the two peers — which it holds in RAM for the milliseconds it takes to make the introduction. The instant the two devices have found each other, that data is erased from memory. It is never, at any point, written to disk.
Once connected, the server vanishes. It doesn't take part in the conversation. It doesn't see it. It doesn't store it. It doesn't know how long it lasts, how often you talk, or what you talk about.
We're not asking you to believe us. We're asking you to verify it:
Test 1 — The server is unnecessary.
Once the direct tunnel is established, our server is no longer involved. If it went down at that moment, your conversation would continue without interruption. As long as your devices are on and connected to the internet, the tunnel is yours. We're no longer there.
Test 2 — Send a 10-gigabyte file.
Not only will it be fast — our server couldn't care less. Try sending files of 10 gigabytes or more continuously for 24 hours straight. Our server won't even notice, because it's not involved. Try that with any other messaging service.
Test 3 — Talk about telescopes.
Spend an afternoon talking to someone about telescopes, or fishing rods, or anything you've never searched for online. Wait a few days. No telescope ads will appear anywhere. Your words never left your tunnel.
Your data, your responsibility.
This is our greatest virtue and, honestly, the thing you'll find hardest to get used to. Your messages, files, and contacts live in an encrypted vault on your device. There's no copy on any server. They're protected with 24 words — the same security level as Bitcoin. But they're in one place only, unless you install Solo2 on a second device — both vaults will sync automatically when connected at the same time. You can also export an encrypted backup — or a readable copy in standard formats to take your data wherever you want. There's no cloud to save you if you lose your only device. Your data is yours, with all the consequences.
In detail
Solo2's server is completely blind. It doesn't know who you're talking to, what you say, or what files you share. Even the technical signals that establish the connection between devices cannot be read by the server — they travel end-to-end encrypted.
Your messages travel directly between devices, end-to-end encrypted. Your history lives encrypted in your browser, never on our server.
Encryption keys rotate automatically with every message. Each message is encrypted with a unique key that is discarded immediately after use. This is technically known as Double Ratchet, and it means that even if someone obtained a key, they could only read a single message — not the conversation. Moreover, security is automatically restored after each communication round: a compromised key becomes useless as soon as the next message is exchanged.
When a direct connection between devices is not possible (for example, due to network restrictions), a mirror server (technically called TURN) is used: data is reflected from one device to another, but the mirror is unaware of what it reflects — everything travels end-to-end encrypted and the server cannot read it. Additionally, all packets are padded to a uniform size to prevent an observer from deducing information by analyzing traffic size or frequency.
You can always see in the app what type of connection you are using — direct or through the mirror server — and act accordingly.
Your master key is randomly generated with 256 bits of real entropy — the same level as Bitcoin. When creating your account, Solo2 generates a unique key that is represented as 24 words. Your password protects access to the service. Your 24 words are the key to your data. They are two different keys for two different doors.
Even if our server disappears, your data survives. With your 24 words you can access your local vault without a server connection. Your data is yours — for real.
1. Data we DO have on the server
1.1 Your user account
These are all the fields that exist in your record. There are no others.
| Data | Why | Protection | Duration |
|---|---|---|---|
| Username | So you can log in | Plain text (public by design) | Until you delete your account |
| Password | Authentication | Protected with Argon2id (recommended by OWASP, resistant to attacks with specialized hardware). We never store your actual password | Until you delete your account |
| Wrapped master key | So you can open your vault by logging in with your password, without typing the 24 words every time. If you lose your words, this wrapper is your recovery | Opaque blob (80 bytes) encrypted with a key derived from your password — the server cannot open it | Until you delete your account |
| Recovery fingerprint | To verify that your 24 words are the correct ones when you recover access to your account — without the server ever seeing them | Irreversible fingerprint (SHA-256, 64 characters). It reveals nothing about your words or your key | Until you delete your account |
| Display name | So your contacts can recognize you | Plain text (you choose it) | Until you change it or delete your account |
| Pairing code | Your address within Solo2 — like a phone number. It's what you share with someone so they can find you and send you a connection request | Plain text, unique (~10 characters) | Until you delete your account |
| Account balance | Money you have added to your account | Number (in cents) | Until you delete your account |
| Bonus balance | Bonuses received (promotions). Consumed before the account balance | Number (in cents) | Until you delete your account |
| Account type | Your plan: standard, founder or platinum (admin exists only for administration accounts) | 1 byte (integer) | Until it changes or you delete your account |
| Account state | The situation of your account: active, in trial, paused by you, or in a grace period. If you pause your account, this field is what remembers it | 1 byte (integer) | Until it changes or you delete your account |
| Service cut-off mark | Records when service was cut off: an administrator sets it when suspending an account, or the system does when your balance reaches zero (it's the start of the grace period). On an account in good standing it's 0 | Numeric timestamp (0 = no cut-off) | Until the account is reactivated — top-up or lifting — or deleted |
| Registration date and time | When you created your account | Full date and time (timestamp) | Permanent |
| Internal identifiers | The system needs two internal codes to refer to you without using your username. One is your primary ID and the other a reference code. Both are opaque — they mean nothing outside the system | Two random codes of 24 characters each (e.g.: u_7kX9mP2...). They contain no name, date, or personal data — they are purely random | Until you delete your account |
| Security version | Which version of the password protection algorithm was used | Internal number | Until you delete your account |
| Status flags | Technical flags (whether your balance has changed, whether you have maximum security mode active) | 1 byte — the equivalent of a single letter. Nothing more fits | Until you delete your account |
To give you an idea of the volume: your complete record takes up about 400 bytes — less than this paragraph. It's your names (made up if you like), a fingerprint of your password (fixed size, 128 characters), your encrypted master key (an opaque 80-byte blob that we can't read), a recovery fingerprint (64 characters that reveal nothing), two numbers for your balance, a few dates and four configuration bytes. That's everything you are on our server.
1.2 Active sessions
| Data | Why | Protection | Duration |
|---|---|---|---|
| Session token hash | Keep your login active | Irreversible fingerprint (SHA-256). The original token is never stored on the server | 24 hours — then completely deleted |
| Creation date | So the system knows when it was created — useful for automatic cleanup | Numeric timestamp (unix seconds) | Deleted with the session |
| Expiry date | The session expires 24 hours after creation. It is not renewed by use — it has a fixed expiry date | Numeric timestamp (creation + 24 hours) | 24 hours — then completely deleted |
When logging out or upon expiry, the row is completely deleted from the database. No trace remains that the session existed.
1.3 Pairing requests
| Data | Why | Protection | Duration |
|---|---|---|---|
| Requester ID | To know who sent the request | Internal code of 24 random characters | 3 days — then automatically deleted |
| Recipient ID | To know who it is addressed to | Internal code of 24 random characters | 3 days — then automatically deleted |
| Status | Pending / accepted / rejected | 1 byte (integer: 0=pending, 1=accepted, 2=rejected) | Deleted when resolved or when expired (3 days) |
| Creation date | Know when the request was created in order to auto-delete it | Numeric timestamp (unix seconds) — 4 to 8 bytes | 3 days — then automatically deleted |
Important note: While the request is pending (maximum 3 days), the server does know that user A asked to connect with user B. After 3 days, the request is automatically deleted. Once the link is accepted, the server does not store the relationship. Your contact list exists only in your browser, encrypted.
1.4 Connection code
| Data | Why | Protection | Duration |
|---|---|---|---|
| Connection code (alias) | Short identifier so another user can find you and request to create a tunnel | Random 8-character code derived from your internal ID | Permanent (it is your public connection identifier) |
1.5 Push subscriptions (notifications)
| Data | Why | Protection | Duration |
|---|---|---|---|
| Notification address | Send notifications to your browser | URL from the browser provider (Google, Mozilla, or Apple) | Until you disable notifications or delete your account |
| Push encryption keys | Encrypt the notification so only your browser can read it | Web Push standard | Same as the address |
1.6 Feedback (support)
| Data | Why | Protection | Duration |
|---|---|---|---|
| Your message | So we can help you | Plain text | Until we process it |
| Your user ID | To know who needs help | Internal ID | Same as the message |
1.7 Connection signaling (ephemeral)
For two devices to connect directly, they need to exchange technical connection establishment signals (WebRTC protocol). The only moment our server holds your user code and your contact's in memory is during the milliseconds it takes to process this connection request. It lasts an instant, exists only in RAM and is never written to disk. The signals themselves are end-to-end encrypted
| Data | Why | Protection | Duration |
|---|---|---|---|
| Connection signals | Establish the direct connection between devices | End-to-end encrypted with the recipient's public key. The server cannot read or modify them | 60 seconds |
1.8 Mirror server (TURN relay)
If a direct connection is not possible, a mirror server is used: data passes through it like light through a mirror — it is reflected from one side to the other, but the mirror is unaware of what it reflects. All packets are padded to a uniform size so that an observer cannot distinguish a message from a simple connection heartbeat.
| Data | Why | Protection | Duration |
|---|---|---|---|
| Access credential | Authenticate you on the mirror server | Your identity is transformed into an irreversible fingerprint — the mirror server does not know who you are | 24 hours |
1.9 Processed payments
Payments are the only point where there is real friction with anonymity. Let's be honest about it.
When you register on Solo2, you choose a username (it can be made up), a password, and a display name (also made up if you wish). No data links you to a real person. But if you make a payment by card, your financial institution does know who you are.
What we receive from the payment gateway is only a confirmation and an amount. We do not receive or store the cardholder's name, card number, national ID, or any personal data of the payer. These are small amounts — legally equivalent to a cash receipt, like buying a lollipop at a newsstand: the shopkeeper doesn't record the buyer's ID.
Additionally, the payment record is deliberately unlinked from your user account. There is no field in our database that links a payment receipt to a specific account.
| Data | Why | Protection | Duration |
|---|---|---|---|
| Payment record | Accounting and tax obligations | Confirmation + amount. No personal data of the payer. No link to any user account | Permanent (legal obligation) |
Regarding the worst-case scenario: Even with a court order, the traceability chain would be: your card → your bank → the payment gateway → our payment receipt. However, our receipt does not contain any user identifier. This is not an oversight: it is a design decision. There is no field or index in our database that links a payment to an account. The only theoretical path would be a temporal correlation — if you were the sole payment in a given period — but even in that extreme case, the account does not contain information that identifies the real person: the username and public name can be entirely fabricated.
All our revenue is legal and accounted for through the payment gateway. We pay the corresponding taxes. But client anonymity is total from our side.
2. Data we do NOT have on the server
This is what defines us. The Solo2 server does not store or have access to:
- Your messages — Travel directly between devices, end-to-end encrypted. The server never sees them.
- Your files — Same as messages: direct and encrypted.
- Your contact list — Exists only in your browser, encrypted in The Vault.
- Your chat history — Only in your browser, encrypted.
- Your location — GeoStamps are calculated on your device and sent directly to the recipient. The server never processes them.
- Usage analytics — The Solo2 application has no analytics system, tracking cookies, or third-party scripts.
- Device data — We do not collect model, resolution, operating system, or any characteristics of your device.
- Communication metadata — We do not know who you talk to, when, how often, or for how long.
About your IP address
Your IP address is not stored in any database. In the server's technical logs, IP addresses are transformed into irreversible fingerprints (hashes) — useful for detecting abuse patterns, but impossible to reverse to the original IP. These logs are automatically deleted every 7 days. Connection signals, which could contain your IP, are end-to-end encrypted — the server cannot read them.
3. Data in your browser (The Vault)
All of the following resides exclusively in your browser, encrypted with AES-256-GCM (a military-grade encryption standard used by governments and financial institutions). The key is generated from your password using Argon2id (the most resistant algorithm available against specialized hardware attacks), and this process occurs entirely within your browser. Your password is never sent to the server.
Your data is encrypted at rest — even if someone accessed your browser's storage, they would only find unreadable encrypted blocks without your password.
When you export a backup, it is encrypted with the same protection (Argon2id + AES-256-GCM). Only someone who knows your password can decrypt it. The one exception is deliberate: the readable copy — a standard ZIP designed so you can read your data without the app — is created unencrypted; the app warns you and asks for your password before generating it.
| Data | Encryption | Control |
|---|---|---|
| Messages | AES-256-GCM | You decide when to delete them |
| Files | AES-256-GCM | You decide when to delete them |
| Contacts (pairs) | AES-256-GCM | You decide who to pair with |
| Verification status | AES-256-GCM | You verify each contact's identity |
| Search index | Encrypted with irreversible tokens (HMAC) | Rebuilt from your messages |
| Delivery status | AES-256-GCM | Which messages were delivered |
| Pending messages | AES-256-GCM | Send queue when there is no connection |
Temporary browser storage
| Data | Type | Duration | Why |
|---|---|---|---|
| User session | Browser local memory (localStorage) | Until you log out | Keep your login |
| App version | Browser local memory (localStorage) | Permanent | Detect updates |
| Theme preference | Browser local memory (localStorage) | Permanent | Remember your visual theme |
| Language preference | Browser local memory (localStorage) | Permanent | Remember your language |
| Password (maximum security mode) | Tab memory (sessionStorage) | Disappears when you close the tab | Reinitialize encryption if you reload the page |
Note on browser security
Solo2 runs inside your web browser. Your encrypted data is protected at rest, but when the app is open and showing you your decrypted messages on screen, security also depends on your environment:
- Browser Extensions: A malicious extension with access to the pages you visit could, in theory, read what is displayed on the screen. We recommend using as few extensions as possible and only from trusted sources.
- Clean browser: An updated browser without unnecessary extensions is your best ally.
- Native App: In the future, we will offer a desktop application (Windows, Mac, Linux) that will provide an additional level of isolation by not relying on the browser environment.
4. Network connections
The Solo2 app
| Domain | Reason | Data sent |
|---|---|---|
| solo2.net | Application API | Authentication, signaling, presence |
| pay.menzuri.com | Payment gateway | Only if you make a payment |
No other domain. No external script. No tracking CDN. The server's content security policy (CSP) technically enforces this: any attempt to load resources from other domains is blocked by the browser .
Even to discover the public IP address of your device (necessary to establish direct connections between users), we use our own server (technically called STUN). We do not delegate to external services. We manage it ourselves.
The landing page
The landing page (solo2.net) — which is independent from the app — uses an anonymous measurement system hosted on our own servers in Germany:
| Domain | Reason | Data sent |
|---|---|---|
| stats.menzuri.com | Anonymous visit measurement | Page visited (no cookies, no IP, no identification) |
This system does not install cookies, does not log your IP address, does not identify you, does not track you between visits, and does not share data with third parties. The Solo2 app does not have this system or any other type of analytics.
5. Deleting your data
There are two different actions, and it is important that you know the difference:
Delete local data
From the app settings you have two local deletion options:
- Clear my data — Delete only your data (identity, vault, session) without affecting other users using the same browser.
- Emergency Reset — Erase absolutely everything: data of all users, Service Worker, cache and cryptographic keys. Requires double confirmation.
In both cases, your account on the server still exists. You can log in again, but your local data will be irreversibly lost. Doing so creates a completely new cryptographic identity: whoever had your previous public key can no longer encrypt anything for you. If a previous contact wants to reconnect, they will have to ask you to link again, and you decide whether to accept it or not.
Automatic recovery between devices
If you lose your data on one device and have another one connected, Solo2 detects the situation and offers to restore your identity and vault automatically. The restoration travels encrypted (Argon2id) over a direct connection between your devices — without going through the server.
Delete your account from the server
- all rows in the database associated with your ID are deleted: account, sessions, requests, invitations, push subscriptions, feedback.
- The deletion is atomic (all or nothing): either everything is deleted or nothing is deleted.
- Payment records are deliberately unlinked from your identity — they exist by legal obligation, but a payment cannot be traced to you.
- The identifiers in server logs are irreversible fingerprints: a log cannot be linked to your account once deleted.
- The Vault in your browser is not automatically deleted with this action (we do not have access to your browser). To delete it, first run the nuclear wipe or clear the site data in your browser.
5b. Your master key and your 24 words
When creating your Solo2 account, a master key is generated with 256 bits of real entropy (the same used by Bitcoin). This key is represented as 24 words that only you know. Your password wraps this key to store it encrypted on the server — the server cannot read it.
This means you have two independent keys
Exact algorithms (verifiable)
Generation: CSPRNG from the operating system (crypto.getRandomValues, 256 bits). Master key encryption: Argon2id (OWASP) to derive the wrapper key + AES-256-GCM (authenticated encryption) to protect it. Identity: Ed25519 (signature) + X25519 (exchange). Messages: Double Ratchet with ChaCha20-Poly1305 . When you close the browser tab, all sensitive data disappears from memory.
How your master key is protected
| Layer | What it is | Where it lives |
|---|---|---|
| Password | Server access. Wraps your master key | In your memory + hash on server |
| Device secret | Invisible second factor, generated automatically on install | On your device (non-extractable) |
| Master key (24 words) | 256 bits of real entropy, randomly generated. Bitcoin level (BIP39) | On a paper you keep + wrapped on the server |
| Key rotation | Each message uses a unique key that is destroyed after (Double Ratchet) | Automatic, transparent |
If you change your password
Changing your password is instant. Your master key is simply re-wrapped with the new password — your identity doesn't change, your vault isn't re-encrypted, your contacts aren't affected, and your 24 words remain the same. It's a millisecond operation.
Recovery
If you lose your password, you can access your vault with your 24 words — without needing a server. If you lose your 24 words, you can log in with your password and the server returns your wrapped key. If you lose both, your data is unrecoverable. Like in Bitcoin, that's security by design.
6. What happens if someone accesses the server without authorization
If an attacker gained full access to Solo2's server, they would obtain:
- Usernames and display names
- Pairing codes
- Public keys (useless without the private key, which is in your browser)
- Password fingerprints (useless without an extremely costly brute-force attack thanks to Argon2id)
- Session token fingerprints (useless without the original token)
- Pending pairing requests (internal IDs, expire in 3 days)
- Account type, balances, and registration dates
- Payment records (with no way to link them to a specific user)
What they would NOT obtain:
- No messages (they were never on the server)
- No files (they were never on the server)
- No contact list (it was never on the server)
- No chat history (it was never on the server)
- No private encryption keys (they live in your browser)
- No IP addresses (they are not logged)
7. Our commitment
This manifesto will be updated with every relevant change in data management. If we add a new field to the database, it will appear here. If we remove something, it will too.
The current version is always this page.