sithbit-ipfsd: the IPFS pin daemon

Standard port(s): bind 8182, health 8197.

The self-hosted IPFS node run as its own daemon: an HTTP pin API (POST/DELETE /pins/{*name}, GET /ipfs/{cid}) over the same embedded node sithbitd can otherwise run in-process.

When you need it: only when multiple instances (several sithbitds, or sithbitd plus account-api) need to share a single IPFS node, via [ipfs] kind = "remote" pointed at this daemon. A single-instance deployment can embed IPFS directly inside sithbitd and skip this service entirely.

Quickstart:

cargo run -p ipfs-daemon

Config file sithbit_ipfsd.toml, or point SITHBIT_IPFSD_CONFIG at an alternate path.

Note: an empty [cluster] section (even with no keys set) enables shared-bucket membership heartbeats, GC, and reprovide-keyspace partitioning across multiple daemons — see Scaling out for the shared-bucket cluster model.

See the Configuration reference for the full key/default table.

Discovering a domain’s nodes (sithbit discover)

Once a node advertises itself on the swarm (a [swarm] section with service-record freshness tuned), clients can find a domain’s POP/ IMAP endpoints over the DHT instead of DNS SRV records — this is decentralized service discovery. The client side is a CLI resolver:

sithbit discover imap sithbit.com \
  --bootstrap /ip4/203.0.113.7/tcp/4001/p2p/12D3Koo... \
  --timeout-secs 20

• pop | imap — the protocol to discover, then the domain.
• --bootstrap/-b — a reachable peer multiaddr (/ip4/…/tcp/…/p2p/<PeerId>) that seeds the ephemeral node’s DHT routing table. Repeatable; without at least one reachable peer the lookup finds nothing. Point it at a node you already run for the domain (or any swarm peer).
• --timeout-secs — how long to keep retrying the DHT lookup before giving up (default 20).

It spins a throwaway discovery-only swarm node (it never pins), looks the (domain, proto) service record up, and prints only the endpoints whose authority-signed delegation chains to the domain’s on-chain MailDomain.authority. Verified multiaddrs go to stdout; a count of records that passed DHT validation but failed the on-chain check goes to stderr — a poisoned record pointing at an impostor is dropped, not printed.

The resolver only speeds discovery; it grants no trust. A real client still verifies each node’s self-authenticating TLS certificate against the chain when it connects, so a wrong address could never fool the session. Discovery is only safe to fail over across when the nodes share a cloud store; on a single-node SQLite deployment there is nothing to discover but the one box.