What’s public and private

SithBit is email built on a public blockchain, and that shapes its privacy model in a way ordinary email does not. The short version: SithBit puts the envelope on the chain — public and permanent — and keeps the letter sealed. Your message body and subject are encrypted so only the recipient can read them; almost everything around the body — who mailed whom, when, and for how much — is world-readable and stays that way forever.

This page is the plain-language map of that split. For the exact field-by-field inventory of every account and what it exposes, see What’s public and private: the field reference. For the adversarial framing, see the trust assumptions and threat model.

The one-line summary

The rest of this page unpacks each row.

On-chain: public and permanent

Everything an on-chain account holds is stored in the clear in a world-readable Solana account — anyone can read it, and history outlives deletion. What that means for you:

• Your wallet address is your public identity. It doubles as your email address (see Addresses), so it is inherently public — anyone you mail, and anyone watching the chain, sees it.
• Your account settings are readable. Your mailbox’s default stamp price, your published encryption key, your no_ipfs preference, your alias-to-wallet mapping, and any domain you authorize (its cleartext DNS name and authority) are all on-chain and public.
• Every send records metadata. Sending mail writes a message account: the sender wallet, a blake3 hash of the from address (never the string), a timestamp, and the body’s storage locator. So a chain observer learns which wallet mailed which wallet, and when — the address book, not the message. This is deliberate and covered in depth under message metadata is hashed, not hidden. It is permanent: this history survives even after you delete the mail.
• Money is visible. SOL balances, stamp purchases, and every transfer are public, as on any Solana account.
• Marketplace purchases are public. Listing an alias or domain for sale, the asking price, the winning bid, and the buyer’s wallet are all on-chain — an observer can see who bought which name and for how much.

Off-chain: the sealed body and your operator

The message body never touches the chain. It is sealed with crypto_box_seal to your wallet (or a delegated key — see Mailbox Keys) and stored off-chain. That keeps the plaintext private, but “off-chain” is not automatically “hidden”:

• The plaintext body and subject are private. They are encrypted before they are ever stored, and only your wallet key (or delegated key) opens them. The readable From:/To:/Subject: headers live only inside this sealed body.
• But the ciphertext on IPFS is public. By default the sealed body is pinned to IPFS, where anyone holding its content ID can fetch it. They get ciphertext, not plaintext — but a public copy of your ciphertext exists. That is a harvest-now, decrypt-later exposure: an adversary can archive the ciphertext today and decrypt it years from now if the sealing crypto is ever broken. If that trade-off matters to you, the no_ipfs opt-out keeps the ciphertext off public infrastructure (at the cost of decentralized availability).
• Your operator sees more than the chain does. Whoever runs your mail server handles your mail at delivery and at read time, holds your IMAP / POP credentials, and — for mail relayed through them — sees the SMTP envelope and headers in the clear. A relaying domain operator is a trusted party; see the domain authority is fully trusted for relayed mail. How much of your mail they can read afterwards, from their own store, depends on how your account authenticates — the next section unpacks it.

What your operator holds

The server that delivers your mail keeps its own copy so IMAP, POP, and webmail can serve it back to you. For accounts without a stored mail password — wallet-signature login only — that copy can be envelope-encrypted at rest¹: each delivered body is sealed once under a fresh per-message key (AES-256-GCM), and that key is wrapped to your account’s reading key with the same sealed-box construction that seals mail to your wallet. The reading secret is derived in your client, travels only at login — appended to the wallet-signature password over IMAP/POP, or as a field on the account API’s token exchange — is held in memory for the session, and is scrubbed when the session ends. A session that didn’t supply it gets a clear “log in again with your reading key” refusal; the server never hands back raw ciphertext pretending it is a message.

This at-rest sealing is automatic on chain-connected deployments — there is no operator switch to forget. Any sithbitd or account API with a chain gateway configured seals password-less accounts’ mail at spool time; only a chain-less development stack (which has no way to resolve reading keys) stores plaintext. The one thing that opts an account out is setting a stored mail password. Your reading secret is accepted only where reading happens — IMAP, POP, and the account API’s login. The SMTP submission service refuses a wallet-signature login that carries it: sending mail never requires your decryption secret, so a client configured to ship it there fails loudly instead of leaking it.

Be clear-eyed about what it does and does not buy you. What it protects against:

• A stolen disk, a leaked backup, a store snapshot or dump — none of them contain your plaintext, only the envelope-sealed bytes.
• After-the-fact browsing — an administrator paging through the store (or its backups) later cannot read sealed bodies without your reading key.

What it does not protect against:

• A live, malicious operator. The running server necessarily sees your reading secret at login and the decrypted plaintext at read time — a hostile operator can capture either in-process. At-rest sealing protects data at rest, not from the operator while you use their server. If that is your threat, the answer is no server at all — see Trustless webmail.
• Accounts with a stored mail password. They keep a readable copy by design: challenge-response logins (CRAM-MD5, APOP) never transmit a reading secret, so the server must be able to serve those sessions from a copy it can read itself.
• Metadata. Who mailed whom, when, message sizes, folder activity, and the SMTP envelope of relayed mail all stay visible to the operator — sealing covers bodies, not traffic.
• The public copies. The body pinned to IPFS and referenced on-chain was ciphertext all along — sealed to your wallet, a separate model this section changes nothing about; see IPFS storage: benefits to users.

The same at-rest-versus-operator distinction applies to any per-recipient pin-provider credentials you register: sealed on disk, readable by the running server.

What you control

• no_ipfs — keep your sealed bodies out of public IPFS, stored only by your operator. Removes the public-ciphertext exposure; re-centralizes availability onto one operator. See Opting out of IPFS storage.
• A delegated encryption key — publish an X25519 key so senders seal to it instead of your signing wallet; see Mailbox Keys. The key itself is public (it is a public key); the point is key separation, not hiding.
• Skipping the stored mail password — wallet-signature login (with a reading key) is what keeps your server-side copies sealed at rest on chain-connected deployments; see What your operator holds. A stored mail password trades that away for CRAM-MD5/APOP compatibility.
• Sharing your DND schedule (expose_dnd_schedule) — by default, anyone probing the anonymous do-not-disturb check learns only whether you are away right now, never your calendar; the away windows themselves appear only if you opt in. See What the refused sender sees and the account API.
• Alias vs raw wallet — an alias is a friendly public label for a wallet; it does not add privacy (the mapping is on-chain), it adds memorability.

The honest limitations

SithBit hides message contents well and message metadata poorly — by design, because it settles on a public chain:

1. The social graph is public and permanent. Who mails whom, how often, and when is readable on-chain forever, even though the messages themselves are sealed. Traffic analysis is possible; the plaintext is not.
2. Public ciphertext is a long-horizon risk. Default IPFS storage means your encrypted bodies are publicly archivable — safe against today’s cryptography, a bet against tomorrow’s. no_ipfs is the lever if you don’t want to make that bet.
3. Your purchases are visible. Marketplace buys tie your wallet to the names you acquire, publicly.

None of these are bugs — they are the cost of a trustless, operator-independent system. Knowing them lets you decide what to route through SithBit and what to keep elsewhere.

Further reading

• What’s public and private: the field reference — the exact per-account inventory.
• Trust assumptions and threat model — the adversarial view.
• How sealed-box encryption works and IPFS storage: benefits to users — why publishing ciphertext is safe, and how to opt out.
• The split model: body off-chain, envelope on-chain.

1. “At rest” contrasts with in transit: TLS protects mail moving on the wire, at-rest sealing protects the copy sitting in the operator’s storage. Neither covers the moment the running server handles plaintext — that is the live-operator caveat below. ↩