serveBlob handed any held blob to anyone who knew its hash, on a public
port with require_opt_in:false. Combined with ssb-blobs sympathy that
meant publicly serving 4.6GB of strangers content we never reviewed.
Maintains a set of blob ids referenced by the local log (small, ~360KB,
rescanned every 5 min) and 404s anything outside it. Fails open until the
first scan completes so a read error cannot 404 the whole site.
Verified: a blob present on disk but referenced by no message returns
blobs.has=true over RPC while the viewer 404s it.
Nothing in ssb-server fetches blobs mentioned in replicated messages;
that was happening via ssb-blobs sympathy, which is the same mechanism
that let strangers fill the disk. This replaces it with explicit wants
scoped to feeds we actually replicate.
want() has no expiry and the want map is broadcast to every peer on
connect, so a standing want fires whenever a long-offline peer returns.
sbot keeps that map in memory, so this process ties its lifetime to the
connection and re-arms the backfill on every restart.
Verified: removing a referenced blob makes it report
already_have=266 newly_wanted=1 and issue the want.
ssb-viewer holds one muxrpc handle captured in a closure and has no
reconnect path. When sbot is OOM-killed and restarted by run-server.sh,
the viewer kept port 8807 open while holding a dead connection and never
answered again -- the silent wedge.
Listen for muxrpc closed and exit(1) so the while-loop in
run-ssb-viewer.sh restarts with a fresh connection. Also poll whoami to
catch half-open connections where closed never fires.
Verified: killing sbot now self-heals in ~4s instead of hanging.
ops