v0.1.1

Still early, experimental, and unaudited (see the
threat model).
This release is the first round of first-production-user feedback from 0.1.0,
fixed:

Changed

• Swarm registry docs & error messages (#17) — the registry is
  key-pinned HTTPS, and now everything says so. The README swarm recipe
  and silt daemon -registry help use the <ID>@https://host:port form the
  daemon prints; passing a bare https:// or an http:// URL to a pinned
  registry returns a message that names the fix instead of a raw TLS error.
• silt info summarizes by default (#18) — root, mode, size, chunk and
  stripe counts, erasure params; the full per-shard dump moved behind
  -shards. It was a wall of hashes on any real-sized file.
• silt add leads with the share link (#19), labelled, and prints the
  care link after with a "repair only, cannot decrypt" caveat. The bare
  link stays on stdout so silt add file remains pipeable.
• silt daemon pledges 5G by default (#21), matching silt client, so a
  fresh daemon contributes measurable, countable storage instead of an
  unlimited pledge that read as 0 B of network storage. -capacity "" still
  means unlimited.
• Shorter, easier-to-copy links (#20) — a link now encodes its two
  32-byte values in compact base64url (43 chars each) instead of 64-char
  hex, so a share link is ~30% shorter (137 → 95 chars). Old hex links still
  parse.
• Observatory (#22) explains it shows only the daemons you list that run
  -ui (no swarm auto-discovery), that "daemons observed" is not the peer
  count, and now displays the swarm's self-estimate ("~N peers") right beside
  it so the two numbers reconcile.

Added

• Build your own Silt test network —
  a public, end-to-end local walkthrough (sims → a real multi-node swarm that
  survives a node death), with all of the above fixes baked in.

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.