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. 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 |
| 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 current plan (trial, standard, gold, platinum) | 1 byte (integer: 0=trial, 1=standard, 2=gold, 3=platinum, 4=paused, 5=suspended) | Until it changes or you delete your account |
| 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, 60 bytes), your encrypted master key (an opaque blob of ~128 bytes that we can't read), two numbers for your balance, a few dates and a configuration byte. 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.
Furthermore, the payment record is deliberately unlinked
| 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) |
About the worst-case scenario:
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. Solo2's server does not store or have access to
- Your messages
- Your files
- Your contact list
- Your chat history
- Your location
- Usage analytics
- Device data
- Communication metadata
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)
Everything below lives exclusively in your browser
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.
| 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:
- Clean browser:
- Native application:
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.
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:
- Delete my data
- Emergency reset
In both cases, your account on the server still exists.
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
- The deletion is atomic
- Payment records remain deliberately unlinked
- 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
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.