v0.1.0

The first release — early, experimental, and unaudited. Silt 0.1.0 is
published to get technical feedback, not to be trusted with data you can't
afford to lose. Please read the
threat model —
it names the weak parts on purpose (a toy proof-of-retrieval, unhardened
Sybil/eclipse, a quorum-not-BFT chain, and more) — and help us break it.
Binaries are not code-signed; verify them against the attached
SHA256SUMS.

Added

• Content-addressed storage — every fragment is named by the SHA-256
  of its bytes; verification is intrinsic, so hosts are never trusted.
• Erasure coding — Reed-Solomon stripes (default any 10 of 16 rebuild
  the file); a repair loop restores redundancy as machines fail, and — like
  the initial placement — keeps each stripe's shards spread across distinct
  hosts as it rebuilds, so one machine's death never costs a stripe more
  than a single shard.
• Encryption at every level — chunks and manifests are both
  ciphertext; a file's share handle is a link (silt:v1:root:key)
  whose one-way key hierarchy also yields care links that grant repair
  and audit without the ability to decrypt.
• The swarm — Kademlia routing, provider records, and multi-node
  fetch over a deterministic simulator or real mutual-TLS sockets;
  identity is a keypair and a node's ID is the hash of its public key.
• Column placement — an erasure-coded file is placed by column (one
  shard position across every stripe), keyed by hash(root‖col), so a
  whole column lands together: one host holds one shard of each stripe,
  a reader finds a column in a single lookup, and losing a host costs a
  stripe exactly one shard (up to n−k columns can go and the file still
  rebuilds). Placement, retrieval, repair, and audits all speak columns.
• Failure-domain-aware placement — a node can declare a failure-domain
  label (AS / rack / geo / operator) and gossips it; placement and repair
  spread a file's columns across distinct domains, so an entire domain
  going dark costs a stripe as little as possible — not just distinct node
  IDs, but distinct domains.
• Dispersion audit — a caretaker doesn't just keep a stripe alive, it
  keeps it spread: each sweep it confirms which domains actually hold each
  column, and if any one domain holds enough of a stripe that losing it
  would drop below the recovery threshold, it seeds extra copies into other
  domains until no single domain failure could break the file.
• Demand-responsive dispersion — storage flexes with popularity. A node
  that finds itself serving a chunk hard pushes leased cache copies to more
  hosts (spread across domains) so readers divide across more sources; when
  the reads cool off, the copies expire and the file contracts back to its
  baseline. A flash-popular file fans out without permanently hoarding
  capacity.
• Capacity — nodes pledge a fixed budget (-capacity 2G); placement
  spills over as nodes fill, and every node estimates the whole network's
  size from local gossip alone.
• Proof-of-retrieval audits — hosts are challenged to prove
  possession with a fresh nonce; those that keep the proof but drop the
  data are slashed.
• The registry chain — an append-only chain kept by the operators;
  blocks commit only with a quorum of attestations from validators whose
  reputation (audits + serving) is earned, not bought.
• Genesis — every fresh network is born carrying a founding manifesto
  in block 0, declared identically on every node.
• Takedown by revocation — illegal or unwanted content is removed at
  the availability layer, not the ledger: an append-only revocation
  record, committed by the same reputation quorum, makes compliant nodes
  no-op on a denied opaque root (refusing to store, serve, prove,
  announce, or repair it) and purge what they hold — never decrypting
  anything. Operators may also load a local denylist they choose to honor
  (silt daemon -denylist). The project ships the mechanism and no list;
  it operates neither the network nor the policy.
• Web UI — an embedded dashboard, publish/fetch pages, and a network
  observatory, served by the daemon.
• Desktop client — one binary that consumes and serves at once, keeps
  a link-book library, and runs on macOS, Windows, and Linux.
• Public website (silthq.com) with brand, docs, operator guide, and
  build-from-source instructions.
• Continuous delivery — PR previews, a staging environment, and
  production deploys from main; a public changelog rendered from this
  file.
• Governance & strategy docs — the fresh-eyes council, risk register,
  launch plan, safety/takedown model, and GOVERNANCE.md.