How it works, and what we don't promise.
This page is for people who want to check for themselves. For each component we say what it protects and what it doesn't.
The architecture in one line
A client on every device, one hub per community (the Outpost) reachable only as a Tor v3 onion service, MLS end-to-end encryption between clients. The hub orders, temporarily stores and forwards messages it cannot read. No central server, no GiBSeS component in the data path.
Tor onion v3 with Arti
The Outpost and the clients talk only through Tor. The Outpost publishes a v3 onion service: the address is derived from the service key, so it stays the same if the PC changes network or IP, and there's no need to open ports on the router. We use Arti, the Tor Project's Rust implementation of Tor, built into the binary: no external Tor process to install.
- Latency is Tor's. In our tests the round-trip time of a message via the hub was between 168 and 627 ms (median per scenario). Large attachments take longer than on a direct connection.
- Where the Tor network is blocked, Naisho doesn't connect. We don't include bridges or anti-censorship tools.
Web version
The web version is the interface, opened in the browser, of a small local program that speaks Tor. There is no remote web server: the browser only talks to the program on your computer, which carries the messages to the Outpost through Tor.
MLS (RFC 9420) with OpenMLS
Every conversation, even a one-to-one, is an MLS group per RFC 9420, implemented with OpenMLS. Suite: X25519 for key exchange, ChaCha20-Poly1305 for encryption, Ed25519 for signatures. Text, photos, voice notes, files and even attachment names and types are encrypted on the device.
- No post-quantum, for now Hybrid suites for MLS are still in draft. We won't promise them until they're stable.
- Messages are not deniable Every message is signed by the sender: whoever receives it can prove to third parties that you wrote it. It's the same signature that lets you report a message to the operator with proof that it's authentic.
MLS provides forward secrecy and post-compromise security: a key stolen today doesn't decrypt yesterday's traffic and, after a key update, doesn't decrypt tomorrow's. It protects messages in transit, not the history already saved on the phone: that is protected by the local database encryption and the app lock (PIN or biometrics).
We verified this with sentinel strings inserted into test messages: zero occurrences in the hub's data.
Whoever joins a group doesn't read the history. Whoever leaves or is removed doesn't read what is written afterwards. In a 100-member test, removing a member produces an 8.7 KB commit in 6.5 ms.
Identity and keys
The Outpost's keys are pinned on joining, from the invite. Every personal ID (QR or 32-character code) contains the key fingerprint: if anyone, the hub included, tries to replace it, the app blocks sending and shows a full-page warning. Two people can compare a 60-digit safety code or a QR. Each community has a separate identity, with different keys.
- On first joining, the client trusts the operator's certificate. A malicious operator can present you with a fake new member: the countermeasure is comparing codes, which we recommend for important contacts.
- Separate identities across communities reduce linking, they don't make it impossible. Two operators comparing connection times over a long period can link the same person.
- An intercepted invite link can be used by whoever intercepts it before the recipient. A QR shown in person doesn't have this problem.
The hub is blind to content. Not to metadata.
Read this table in full. It applies to the Outpost, and therefore to whoever runs it.
| Data | Does the hub see it? |
|---|---|
| Text, photos, voice notes, files, attachment names and types | No |
| Meeting audio and video (both modes) | Yes |
| Client IPs | No (Tor), except participants in High quality meetings |
| Hub IP, for clients | No (onion), except participants in High quality meetings |
| Member list, with keys and labels, including hidden members | Yes |
| Visibility chosen by each member | Yes |
| Who is in which room, room names | Yes |
| Who writes to whom in one-to-one chats | Yes |
| Who uploads content to a room | Yes |
| When and how often each person connects | Yes |
| Message size | Yes |
| Who opens a private chat with whom from a room | Yes |
GiBSeS sees none of these things: it has no servers, accounts, telemetry, crash reports or online activation. Anyone set to “visible only to those who have my ID” remains visible to the members of the rooms they join.
Store-and-forward
If the recipient is offline, the encrypted envelope stays on the Outpost for up to 30 days (adjustable), then expires. As soon as it's delivered it's deleted: the Outpost works in transit-only mode and keeps no message archive. What stays on disk is the list of members and rooms and the queue of uncollected messages, in a folder encrypted at rest with the operator's password (Argon2id). In one-to-one chats you see “queued”, “delivered” or “expired”. Attachments travel in chunks, resuming after an interruption, up to 100 MB per item.
No push
No notification goes through the Android and iOS push services. Two modes: no background checks (default) or a periodic check via Tor every 15, 30, 60 or 240 minutes, with a content-free local notification. On Android, battery saving can delay checks; on iOS the system limits background activity, so reception is only complete while the app is open.
Audio calls
Calls, 1:1 and group calls of up to about 10 people, travel over Tor and pass through the hub, which forwards them in memory only, without writing them to disk. Latency is that of two onion hops: expect a noticeable delay, more like a walkie-talkie than a traditional phone call. If the contact can't be reached, the call shows as missed and you can leave a voice note. Lightweight screen sharing is also available.
Two modes
An optional component, off by default, that runs on the hub as an SFU (Selective Forwarding Unit). Media is encrypted in transit, but the SFU decrypts it to forward it: the hub sees meeting audio and video in both modes. We don't use SFrame. For video you trust the hub, that is, whoever runs it.
Protected
media travels over Tor, forwarded by the Outpost as a relay, at low resolution to fit the bandwidth and latency of an onion circuit. No IP exposed: neither the participants' nor the hub's. No extra network configuration.
High quality
direct WebRTC connection between clients and Outpost, outside Tor, with DTLS-SRTP encryption and TURN included. It needs a public IP on the hub and one or two open ports. Self-signed certificate: its fingerprint and the address reach clients through Tor, no external service. Participants' IPs are seen only by the community's Outpost, not by the other participants. Participants know the hub's IP. As with any direct connection, each person's network provider sees that there's a connection to that address.
Chats always stay on Tor, whichever mode you choose for video.
Requirements
The hub does little heavy cryptography: it forwards envelopes and orders MLS commits. The real load is the disk (attachment queue, up to 30 days) and Tor bandwidth. The working disk must be an SSD: the queue writes constantly. The node measured at steady state uses 34-46 MB of RAM.
| Community | Recommended setup |
|---|---|
| Up to ~25 people | A PC or laptop left on, 4 GB of RAM, 32 GB free on SSD |
| From ~25 to 100 people | A computer or mini-PC, 8 GB of RAM, 64-128 GB SSD |
| Over 100 people | Multiple Outposts |
| High quality video, 5 participants | ~10 Mbit/s upload on the hub, public IP, 1-2 ports |
| High quality video, 10 participants | ~45 Mbit/s upload on the hub; 8 GB computer |
| Protected video | No extra network requirements; quality limited by Tor bandwidth |
Outpost for Windows 10/11 x64 and Linux x86_64. Starts automatically, online within 3 minutes of power-on. For chat a home uplink of a few Mbit/s is enough: the practical limit is Tor latency, not the hardware.
Code
Client and Outpost are written in Rust: Arti for Tor, OpenMLS for encryption. The Outpost is a single binary, with no installation and no administrator rights.
Continue from here
For you and your group
The kids' photos, grandma's voice notes, the club chat: they stay between you. See what whoever runs the group has to do, and why Chat Control affects you.
For your company
Projects under NDA, video meetings, chats between colleagues: the data stays on a computer in your office. Naisho works alongside the tools you already use.