Built so there's nothing to hand over.
Most apps promise to protect your data. Stiq's bet is simpler: don't collect it. There is no identity table to hand over, because one never gets created — not on the relay, and not on the organizer's server either. This page is the long version of that claim: what actually crosses the wire, how membership works without identification, exactly who can see what, and — because a privacy page you can't disbelieve is worthless — what Stiq deliberately does not defend against. Every statement here is checkable against PLAN.md and the source beside it.
Six properties, none of them optional.
These aren't settings. Each one is an architecture mandate in the source repo — changing it is changing the product.
No identity to seize
No email, phone, or username database exists anywhere in the system — so there is nothing to leak, and nothing you could be compelled to produce.
Tor only, never clearnet
The relay is a v3 onion with no clearnet ingress and no IP logging. The app has no fallback: if Tor is down, it shows an offline state rather than reaching out in the open.
Blind write credentials
Every post, vote and comment spends a one-time, blind-signed credential — proof that a member is allowed to write, issued in a form that never names its holder.
You hold the relay
Content lives on hardware you control, and on each device in an encrypted cache siloed per community. Pull the plug and the community is gone.
No telemetry, enforced
No analytics, crash reporting, or attribution SDK — and the build fails in CI if one so much as appears in the dependency tree.
Invisible until invited
The relay’s onion address requires Tor v3 client authorization: without the key tucked inside an invite, it answers nothing at all. A community that can’t be found can’t be knocked on.
What actually crosses the network.
One protocol, one road. The wire format is standard Nostr; the road is a Tor circuit. There is no third thing.
The road: Tor v3, hidden-service only
The relay is reachable exclusively as a Tor v3 onion service. It binds loopback and Tor fronts it — there is no clearnet ingress to firewall, because there is none at all. The relay logs no IPs, not even Tor circuits; an onion connection never delivers a client address in the first place.
The app bundles its own Tor — no Orbot, no system proxy — and has no clearnet fallback, ever: if Tor can't connect, the app shows an offline state. There is no code path that reaches the relay in the open.
On networks that block Tor, a connection ladder steps through pluggable transports — webtunnel, obfs4, snowflake — so the traffic your network sees needn't even look like Tor.
The format: standard Nostr, standard NIPs
Every feature maps to a public Nostr standard — posts, votes, threaded comments, DMs, channels, groups, events. Nothing custom rides the wire, which means there is no private dialect to trust: any Nostr tooling can read the event shapes, and your data outlives the app that wrote it.
Direct messages are NIP-17 gift wraps — sealed to the recipient, published by ephemeral keys, opaque to the relay. Private-space content keys are delivered per member, per epoch, wrapped in NIP-44 encryption.
| Feature | Nostr kind(s) | Standard |
|---|---|---|
| Posts (community feed) | kind 1 | NIP-01 + NIP-12 tags |
| Votes | kind 7 | NIP-25 |
| Threaded comments | kind 1111 | NIP-22 |
| Polls | 1068 / 1018 | NIP-88 |
| Private DMs | kind 1059 gift wraps | NIP-17 |
| Channels | 30311 / 1311 | NIP-53 |
| Groups | 9 / 11 / 12 / 39xxx | NIP-29 |
| Events | 31923 / 31925 | NIP-52 |
| Moderation reports | kind 1984 | NIP-56 |
| Organizer config, space settings | kind 30078 | NIP-78 |
The full registry, with the rationale for each choice, is client/src/contracts/index.ts in the source repo.
The credential's journey, in four steps.
The core mechanism is an RFC 9474 blind signature — an IETF standard, served by audited libraries, not homemade cryptography. Here is the whole trick.
Keys are born on the device
The app generates an ordinary Nostr keypair on the member's phone. It is never transmitted and there is no account to attach it to — the organizer never sees it, and neither does anyone else.
The join is signed blind
The organizer's issuer holds an RSA keypair. At sign-up it signs a token the member chose without being able to read it — RFC 9474 blind RSA. The member walks away holding proof that an organizer authorized me, in a form the issuer can never recognize again.
The credential binds once
The app publishes a one-time binding event spending that credential. The relay verifies the signature, marks the token spent, and accepts the new identity from then on. One credential binds once — a new device or a re-enrol needs a fresh one.
Every write spends a fresh one
Posts, votes and comments are each published under a one-time credential drawn from a local token wallet and signed by a throwaway key. The relay checks entitlement and discards non-members' writes before storage; double-spends die against its spent-token set. Neither the relay nor other members can attribute the write.
The result: the organizer knows they let someone in. They cannot tell which account is theirs, and they cannot tell which posts they wrote — and neither can the relay they run.
Where moderator attribution exists at all, it rides as a NIP-44-encrypted tag readable only by the moderator roster — the public sees nothing. The full mechanism is §3.3 and §3.6 of PLAN.md.
Who can see what — party by party.
Privacy claims are only meaningful per observer. Four observers matter here; this is what each one gets, and what the architecture withholds from them.
Your network
Can see
- That encrypted Tor traffic is leaving your device — or, over a bridge, traffic shaped like ordinary HTTPS.
- When you're online, and roughly how much you transfer.
Can never see
- Which onion service you're talking to — the relay's address never appears on your network.
- Any content, any metadata inside the circuit, or that the app is Stiq at all.
The relay
Can see
- Standard Nostr events: kinds, timestamps, and whatever members publish to shared spaces — it stores and serves them.
- The same in-room attribution members see: each post and action carries its author's npub.
- That each write carried a valid, unspent credential.
Can never see
- A member's IP address — a Tor onion connection never delivers one, and the relay logs none.
- Who stands behind any npub — it connects to no invite, no IP, no name, and no identity in any other community.
- The plaintext of DMs (gift-wrapped end to end) or of private-space content sealed under member keys.
The organizer
Can see
- That an invite they issued was redeemed — they know they let someone in, and how many.
- Everything the relay sees: it's their hardware.
- The moderation record — which is open to every member anyway.
Can never see
- Which account belongs to which invite — the approval was signed blind.
- Which of the people they invited stands behind any handle. Letting someone in and reading the room are two facts that cannot be joined.
- A member's key. It never left the member's device.
Other members
Can see
- Your handle and your gradient — the identity you built at the door, changeable later.
- What you publish to the spaces you share with them — each post and action under the handle that made it.
Can never see
- Anything linking that handle to a person — no phone number, email or real name exists in the system to leak.
- Your identity in any other community: each one is siloed on the device with its own keys, its own wallet and its own encrypted store.
- What you read and when — opening the app, scrolling a feed, or sitting with a thread publishes nothing to anyone.
On the device, and on the record.
What the phone holds
The member's key and credentials live in the device's hardware-backed keystore, non-exportable — never in a database, never in a log line. Events cache to SQLCipher-encrypted storage for offline reading, one database per community; DMs are encrypted at rest in the same store.
Communities are siloed: each gets its own identity, its own credential wallet and its own encrypted database, namespaced so that one community cannot even observe that another exists on the device.
There is no seed phrase and no backup. Losing the device loses the identity — that is the honest cost of a key that can't be phished, exported, or surrendered.
Moderation is a record, not a delete key
Because the relay cannot tell whose event is whose, it cannot enforce a ban. Hides, bans and reports are advisories that conforming clients honour; a modified client can ignore them. Moderation constrains what members see, not what the relay accepts — authorship-blindness and server-enforced expulsion are mutually exclusive, and Stiq chose blindness. A community that needs hard expulsion rotates its credential and re-enrols.
What moderation produces is a record: every hide, tag and note lands on an append-only timeline any member can open — the moderator roster itself is a signed document only the organizer key can publish. The room can always audit its own government. The FAQ says this in plain words; the Log is where members read it.
What Stiq does not defend against.
A privacy page that lists only strengths is marketing. These are the edges — better learned here than in the field.
A modified client ignoring moderation
Advisory moderation means exactly that: a client built to skip the hide-list keeps seeing — and publishing — what conforming clients don't. The relay cannot tell whose writes to refuse. This is the standing price of blind authorship, and it is stated everywhere rather than fine-printed.
An organizer who turns the lights off
The organizer controls the hardware. They can read anything published to shared spaces, take the community offline, or rotate the credential and decide who re-enters. What they cannot do — even with full control of the box — is attribute a post to a member. Trust the math for anonymity; choose your organizer for availability.
Adversaries beyond Tor's model
Stiq inherits Tor's threat model, edges included: an adversary that can watch both ends of a circuit at once — a global passive observer — is outside what onion routing defends against, and therefore outside what Stiq claims.
The people in the room
Blind authorship hides who wrote; it does not make content secret from the members it was shared with. Anyone in the room can screenshot, copy, or repeat what you post. An invite-only room is only as discreet as the people invited.
A lost phone
Non-exportable keys and no seed phrase mean no recovery path — for you, and equally for an attacker. A lost device is a lost identity; re-joining needs a fresh invite from the organizer.
Every claim here is checkable in the source.
Free & MIT · you run the relay · no accounts, ever.
Found a hole? evergreenmarble@proton.me