The components at a glance

From the outside, SithBit looks like ordinary email: you open a mail app, read what arrived, and write to people by address. Under the hood, four groups of pieces cooperate to make that work without a central provider:

• On-chain programs — the shared rulebook, living on Solana where anyone can read it.
• Servers — the post-office machinery that anyone with a domain can run.
• Graphical clients — the apps and extensions most people actually use.
• The command line and the console — terminal tools for developers and operators.

This page introduces each group in plain terms, then puts them together on one map. Nothing here is required reading to use SithBit — it’s the orientation tour, with links into the deeper chapters when you want more.

The on-chain programs — the shared rulebook

A blockchain “program” is a small piece of software that lives on the blockchain itself, where everyone can see it and no one can quietly change it. Think of it as a vending machine for rules: put in a correctly-formed request, and it does exactly what its published rules say — the same for everybody, every time.

SithBit is built on three such programs, running on Solana:

• The mail program is the heart of the protocol. It keeps the record of every mailbox and its prices, holds each sender’s prepaid postage balance (a frombox), and moves the SOL when a message is delivered — sender pays, recipient collects. It also hosts the postoffice, the one shared account that records protocol-wide settings.
• The alias program maps human-readable names (aliases) to wallet addresses, so mail can go to pat@example.com instead of a long string of characters.
• The domain program keeps the registry of domains whose owners have proven, via DNS, that they control the name — and runs the marketplace where aliases and domains are bought and sold.

Two things make this arrangement matter. First, everyone consults the same three programs — every server and every app, no matter who runs it, reads and writes the same shared record, which is what makes SithBit a protocol rather than a company. Second, your messages are not on the blockchain: the chain holds only small delivery records and balances, while the message body itself is encrypted by the sender and stored on IPFS, a distributed storage network. What’s visible to whom is laid out in What’s public and private.

The servers — the machinery an operator runs

The on-chain programs can’t answer a mail app’s call on their own — somebody has to speak the languages your mail apps already know. That somebody is a mail operator: anyone who owns a domain, authorizes it on-chain, and runs the SithBit services. The full set is described in Running a mail server; the short version:

• sithbitd, the mail daemon, is the big one. It accepts and delivers mail (SMTP), lets your apps read it ( IMAP and POP), and runs the behind-the-scenes workers that encrypt each message, store it on IPFS, and settle its postage on-chain.
• account-api handles sign-in and account settings — you prove you own your wallet, it hands your apps a session.
• mail-grpc is the operator’s gateway to the three on-chain programs: postage checks, delivery records, name lookups.
• domain-sithbit verifies domain ownership against DNS so a domain can be authorized on-chain.
• sithbit-ipfsd and sithbit-gateway are the IPFS storage plumbing — a shared storage node for a fleet of servers, and a read-only window for fetching stored mail over plain HTTP.

The crucial point for a newcomer: operators are replaceable. Prices, balances, and delivery records live in the on-chain programs rather than only in one operator’s database. Your operator may still hold a server-side copy of your mail, but it does not own your on-chain identity or the sole record of delivery. Operators compete to carry traffic — and earn a share of the postage on every message they relay.

The graphical clients — where most people live

Most people never touch a terminal or a server, and never need to. SithBit ships a family of GUI clients:

• The webmail app — a full mail client in your browser, installable as an app on desktop and phone.
• The Chrome extension, the Outlook add-in, and the Thunderbird extension — the same account tools, embedded in the mail software you may already use.

All of them run one shared core, so a screen behaves identically wherever you meet it — and everything that must be signed with your wallet key is signed on your device. The server only ever relays already-signed requests; it never holds your key. That shared core also includes the guided first-run wizard that creates or imports a wallet and claims your mailbox, and the browser name marketplace for buying and selling aliases and domains.

Because the servers implement standard mail protocols, compatible ordinary mail apps work too: point a client at a SithBit server over IMAP or POP and read your mail without installing SithBit client software. The standards table records exact coverage and partial features. The GUI clients add the parts standard apps cannot provide — wallet sign-in, pricing your senders, and trustless reading, where your browser checks the chain and IPFS directly instead of taking the server’s word for it.

The command line and the console — power tools

Two terminal tools round out the set, for the people who want them — typical users never need either:

• The sithbit CLI is the developer’s tool: the full protocol surface as typed commands. It talks directly to the on-chain programs — no SithBit server required — so everything from claiming a mailbox to pricing a sender to sending and reading mail can be done from a terminal. If you’re building on SithBit, this is your surface: the whole protocol is three small programs with documented instruction semantics, reachable from the CLI, its C library, the gRPC gateway, or WebAssembly in a browser — paid, postage-gated messaging between any two wallets, with standard email on the other end.
• The sithbit-console TUI is the operator’s dashboard: a keyboard-driven console for inspecting accounts and mailboxes, watching the mail queues, and unsticking failed jobs. It talks only to the account API’s admin surface, never to the operator’s database directly.

How the pieces fit together

Put the four groups on one map and the shape of the protocol appears. Follow a single message through it:

1. You write mail in a client — a GUI client or any standard mail app — and it hands the message to your operator’s sithbitd the same way email always has.
2. The servers do the protocol work: sithbitd checks through mail-grpc that the sender has postage for you, encrypts the body so only you can read it, stores it on IPFS, and records the delivery on-chain — the moment your postage is collected.
3. The chain and IPFS hold the truth: the mail program’s record says a message exists and was paid for; IPFS holds the sealed body. Any operator’s servers — or none at all — can show it to you from there.
4. You read it in whatever window you prefer: webmail, your usual mail app over IMAP or POP, the CLI straight from the chain, or trustless webmail verifying every step itself.

The division of labor, in one breath: the programs are the rulebook, the servers are the machinery, the clients are the windows — and because the rulebook is shared and public, the machinery is replaceable and the windows are many. Ready to go deeper? Start with Addresses for the core concepts, or jump straight to Getting started.