Snapshot of the decentralized-web stack at the point of the resolver+Theseus rebuild deploy. Includes: - Argus (BNS engine + resolver daemon + Sia gateway) - AriadneResolver (Windows Inno installer bundle + Android APK sources + Firefox extension) - TheseusNavigator (Electron browser) - site/ (silentmode.st content, deployed to Sia at bns/silentmode/) - design docs, roadmap, protocol spec Secrets excluded via .gitignore: Argus/sia-s3.json, Argus/wallets.json, Argus/ca/*.key,*.crt. Build outputs, node_modules, and bundled runtimes also excluded. Shipped hashes on dl.silentmode.st at this commit: AriadneResolver-Setup-0.1.0.exe 5bcb216eef31ea28ed767e4134ab74bd5ac69dfbd365fd249e9e6938e55c986a TheseusNavigator-Setup-0.0.1.exe 7c735e88bad2da3347145adba3016c8f626a18b8422289c8c6ba471972e2952b TheseusNavigator-0.0.1-portable.exe 008fd84445babeabb401b2bca40ea9466b24b0e6d6c85104da7640c5c5c84521 ariadne-v0.2.apk 635c8f04d44ef855a8390b9eeddb8cd2d50622e81cc4e5004e8daffc1bb0425c
5.1 KiB
Argo — the hosting pact: dilution-pool incentives for serving the decentralized web
Argo is the host network; the hosts who crew it are Argonauts. Part of the
Silent Mode stack (hub: D:\Dev\SilentMode\README.md).
Status: design idea (July 2026). Not yet implemented. Companion to
PROTOCOL.md; assumes BNS names on BCH and content on a storage
network (Sia, IPFS, or on-chain h records).
The idea in one paragraph
A site owner funds a pool tied to their name's content (monthly / quarterly / yearly). Hosts join permissionlessly — no one selects them — by bonding a small stake and proving they store/serve the content. Each epoch the pool pays out, split among all current provers. More hosts → thinner slices; fewer hosts → fatter slices. Replication count is not configured anywhere: it is the equilibrium of pool size vs. hosting cost, discovered continuously by the market. Paying more is the owner's only knob — and it directly buys more redundancy and serving capacity. Client software suggests a price from the median of on-chain host asks.
How Sia works, for contrast
Sia is renter-driven, closed-membership: the customer's agent (renterd)
scans the host market, selects ~30 specific hosts, forms bilateral fixed-term
contracts with each, monitors them, and migrates shards when hosts die. Hosts
advertise general capacity and wait to be picked; they cannot volunteer for a
specific dataset. Repair requires the renter's agent to be online and funded.
Why Sia's model is not enough (for websites)
- A manager must exist. Sia heals because renterd notices dead hosts and re-uploads. If the renter agent is offline or unfunded, redundancy silently decays. The pool heals without any manager: a dead host stops proving → its share flows to the survivors → each slice fattens → the pool becomes more attractive → new hosts join. The noticing is done by economics, not by an agent. This is the core automation the idea adds.
- Membership is closed. In Sia, a host that wants to help serve a popular site cannot join its contract set. In the pool, joining is the default; the algorithm that "decides who hosts" is replaced by self-selection under price pressure (the same open-entry mechanism as Bitcoin mining: reward fixed, participants join until marginal profit ~ 0).
- No serving incentive. Sia pays for storage possession, never for serving the public — the gap that killed Skynet (decentralized storage, centralized unpaid portals). The pool's payout can cover gateways/seeders, the actually-scarce resource for websites.
- Designed for private data. Sia encrypts client-side and hides data from hosts — right for backups, unnecessary for websites, which are public goods. Public content is exactly the case where open membership is safe: there is nothing to leak, and anyone may legitimately serve it.
- Lifetime is administrative, not economic. Sia contracts expire per contract term. A pool's site lives exactly as long as someone values it enough to fund it — a market-driven expiry that doubles as the namespace garbage collection Namecoin lacked (cf. Kalodner et al. 2015).
Known hard problems (and mitigations)
- Sybil splitting — one disk posing as N hosts to collect N shares. Mitigate: per-host-unique erasure-coded shards (k-of-n), so each identity must store distinct data; stake per identity; diminishing returns per new host as slices thin.
- Proof of possession — challenge from a future block hash → Merkle proof over the host's shard. Verifiable in a BCH covenant post-May-2025 limits (clunky but plausible); v0 can verify in an auditable coordinator.
- Proof of serving — unprovable on-chain (true for Filecoin/Sia too). Layered approach: watchtower spot-checks, client-side reputation, coordinator attestation; shrink the trusted surface over versions.
- Pool exhaustion — funding dries up → hosts leave → site dark. Feature, not bug (see 5 above), but resolvers should surface "pool low" warnings so owners/fans can top up (anyone may pay into a pool — patronage built in).
Sketch on BCH
- Site → storage network → per-host shards (off-chain tooling).
- Name's chain record:
{"cid"|"s3": ..., "pact": <pool id>}. - Hosts post asks via beacon txs; wallets suggest the median (owner's knob).
- Pool = covenant UTXO funded by owner (or anyone); hosts join by bonding stake in a registration tx naming their shard commitment.
- Per epoch: block-hash challenge → hosts submit proofs → covenant releases the epoch tranche split among provers; missed proof = no pay (+ stake slash on repeated failure).
- Resolvers discover hosts from registrations and fetch from any of them.
Version ladder
- v0 — coordinator does audits + payouts openly on chipnet (trusted but fully auditable; all money flows on-chain).
- v1 — possession proofs verified by CashScript covenant; coordinator only attests serving quality.
- v2 — multi-watchtower serving attestation, coordinator eliminated.