Domain-scoped aliases

See Domain-scoped aliases for the namespace model, the domain-then-global resolution precedence, and who is trusted to register into a domain’s namespace. This page covers the sithbit alias register-domain / update-domain / remove-domain commands, inbound delivery, and the public encryption-key keyserver.

Register, repoint, remove

All three are signed by the domain authority’s keypair (-k), and take a local-part@domain address:

# Map [email protected] to a wallet
sithbit alias register-domain [email protected] --wallet <WALLET_PUBKEY> -k authority.json

# Repoint it to a new wallet in place (keeps the account and its rent)
sithbit alias update-domain [email protected] --wallet <NEW_WALLET_PUBKEY> -k authority.json

# Remove it, refunding the rent to the authority
sithbit alias remove-domain [email protected] -k authority.json

The --wallet the address points at need not be the signer — the authority designates it. The local part is normalized to lowercase and must use the same a-z0-9._- character set as a global alias.

Resolving a domain-scoped address

sithbit alias get resolves a domain-scoped mapping first, then falls back to the global namespace when none exists — see Resolution precedence:

sithbit alias get [email protected]

• If acme.com registered alice, this returns that wallet.
• Otherwise it falls back to the global alias alice, so existing global aliases keep resolving unchanged.

The same precedence drives the lockbox plugins: mail addressed to [email protected] seals to the domain-scoped wallet when one is registered.

Receiving mail at a domain-scoped address

Registering [email protected] and resolving it from a native client is only half of an email address; the other half is that internet mail addressed to it actually arrives. A verified domain’s user@domain addresses now do — a SithBit MX accepts an inbound RCPT TO:<[email protected]> and delivers it to the wallet the authority mapped. This is the delivery counterpart of native resolution: the same mapping that a client reads to seal mail is now the one the server reads to receive it.

Resolution runs on the same precedence as alias get above, but starting from the SMTP envelope rather than a CLI argument:

1. The MX takes the recipient’s domain from the RCPT address and lowercases it, so it matches the on-chain PDA seed exactly (the domain-scoped account is hashed on the domain and the local part).
2. It asks the chain gateway to resolve the local part within that domain — the domain-scoped DomainAlias lookup.
3. If a mapping exists, delivery targets that wallet’s mailbox. If none does, resolution falls back to the global alias namespace, exactly as alias get does — so a bare alice global alias still receives, and an empty domain is the legacy global path. Nothing about pre-existing global-alias delivery changes.

Because the authority alone writes these mappings, it decides which wallet receives mail for each local-part it issues — the same trust already placed in it for relayed mail, now reaching inbound delivery as well as resolution.

Discovering a recipient’s encryption key: the cert keyserver

Before anyone can seal mail to a SithBit address they need the recipient’s published X25519 key. The account API exposes a public lookup for exactly that, with the recipient identity in the ?email= query parameter:

GET /v1/chain/[email protected]

It is public and unauthenticated — deliberately, in the spirit of PGP keyservers (HKP) and Web Key Directory (WKD). Everything it returns is already readable on-chain by anyone, so gating it behind a login would add friction without adding privacy. Give it any recipient identity — a wallet address, a global alias, or a domain-scoped user@domain — and it resolves that identity to a wallet (composing the same domain-then-global precedence as resolving a domain-scoped address above), then returns that wallet’s published encryption key.

Two response cases matter:

• Empty key, 200 OK. The recipient exists but has published no delegated key. This is not an error — a sender seals straight to the wallet address itself (see Mailbox Keys and sealed-box encryption).
• Unknown recipient, 404. No wallet resolves for that identity at all — there is nobody to seal to.

Because it is a convenient public surface over on-chain data, it carries a threat-model note; see the discovery keyserver is a public enumeration surface.

See Closing accounts for the general rent-refund model that remove-domain follows.