Every community that runs a Citinet hub is trusting someone to operate it; that's true of any self-hosted software, and it's worth being direct about what that trust actually means before you join one, or start one.

This is that explanation. Not a marketing page. What's actually protected, what isn't, and why.

The honest starting point

Citinet hubs are self-hosted: a community (or one person on a community's behalf) runs the server. That operator controls the machine the hub lives on. Full stop.

No amount of clever engineering removes that; it's the nature of "you host it, you control it," and it's true of Mastodon, Nextcloud, WordPress, or any other self-hosted platform, not something specific to Citinet.

So the real question was never "can the operator see things." It's: what can they see, what can't they, and does that line make sense?

What the operator can see: the public layer

Posts, comments, spaces, events, marketplace listings, public profiles, the moderation log. All of it is readable by the hub's own database, because the hub needs to search it, and moderate it. This is the same model as any forum, any Mastodon instance, any community platform. Nothing new here, and nothing hidden: if you post it publicly on a hub, the hub can see it.

What the operator can't see: the private layer

Direct messages, private notes, and private files are encrypted in your browser before they ever reach the server. The hub stores ciphertext; ciphertext = mathematically unable to turn back into readable content, because the decryption keys never leaves your device.

Concretely:

• Your device generates its own key pair. The private half never leaves your browser's local storage.

• Only the public half; useless for decrypt

• Messages between two people use a key derived from both of their key pairs, computed independently on each device.

• Notes and files use a separate content key, generated the same way: on your device, never uploaded.

Even someone with full access to the hub's database and file storage sees only ciphertext for this layer. Not "hard to read"; mathematically not decryptable without a key that was never sent to them.

The one place this gets subtle: recovery

Encryption keys that live only on your device create an obvious problem: lose the device, lose the keys, lose access to your own encrypted content. Every end-to-end encrypted system has to answer this somehow.

Citinet's answer: at signup, you're given a recovery phrase; seven random words, generated by the app, shown to you exactly once. That phrase, not your login password, is what unlocks your encrypted content on a new device. Save it somewhere safe (a password manager, written down, wherever you'd keep something you can't afford to lose); it's the only way back in if you ever need to recover your notes or messages on a device that doesn't already have your keys.

Why a separate phrase instead of just using your login password? Because your login password and your encryption key need to be independent secrets. If they were the same thing, then anyone who could guess your login password, through a weak or common password, cracked offline, would also be able to decrypt your private content. Splitting them means a guessed password only grants login access to your account. It does not hand over your encrypted notes or messages. Two different failure modes, contained separately, the same way a house key and a safe combination are usually not the same number.

This is the same idea behind a cryptocurrency wallet's seed phrase, or a password manager's recovery key: the thing that unlocks your data is generated for you, not chosen by you, specifically so it can't be a weak, guessable password.

What actually protects a hub from outside attackers

Encryption protects data at rest from the operator. Separately, the hub itself has to be defended against attackers who aren't the operator at all; people just trying to get in from the internet. That's ordinary infrastructure security, and it matters just as much:

• Every connection is encrypted in transit. Each hub gets a real, browser-trusted HTTPS certificate automatically; no plaintext path in or out.

• Every database query is parameterized. No SQL injection surface: user input is never concatenated into a query string.

• Every route that should require permission does. Every endpoint in the hub's API (all of them) has been individually audited to confirm it requires the right login state and the right role (member, moderator, admin) before it does anything sensitive.

• Login is rate-limited and passwords are hashed, never stored in reversible form, with a real strength requirement; not just a length minimum, but a check against common/guessable passwords too.

• Sessions are cryptographically random tokers, and they expire.

• File uploads are restricted and validated: executable file types are blocked at upload, and served files are only ever rendered as their actual content type, never trusted to render as something more dangerous.

None of this is unusual for well-run infrastructure. It's the baseline any service handling real people's data should meet, and Citinet hubs are built to meet it by default; not something a community has to configure correctly themselves.

What we don't claim

• No independent third-party security audit has been done yet. Everything above reflects our own internal review, not an outside firm's sign-off. That's a meaningful distinction, and we're not going to pretend otherwise.

• A self-hosted hub's security is partly the operator's responsibility too; keeping the server's OS updated, not exposing ports it doesn't need to, general server hygiene. Citinet handles what it can handle for you (automatic HTTPS, hardened defaults), but "self-hosted" means some of this is genuinely yours.

• Metadata isn't the same as content. Encryption protects what you said, not always the fact that you said something to someone, or when, or roughly how much. That's a limitation shared by essentially every end-to-end encrypted system, including the well-known ones; it's a real, known trade-off, not an oversight.

If you find a problem

If you think you've found a genuine security issue, please report it through an issue on the GitHub repository rather than posting it publicly first; we'd rather fix it quietly than have it sit exploitable while people are still using affected hubs.

The bottom line

Citinet's trust model isn't "trust no one" and it isn't "trust everyone with everything." It's closer to: the community that runs your hub can see what you chose to make public, and moderate accordingly; the same as any community platform. What you keep private stays private, protected by keys that live on your device and nowhere else, recoverable only by a phrase generated for you and shown to you once.

That's a real, specific claim, not a vague promise. We'd rather you understand exactly where the line is than take our word for "it's secure."