Anyone can host signed capsules: the seed is one provider among many (free and paid) #281

Direction from Anders (7 Oct): after the first signed install, everything comes from inside ElastOS. Like IPFS or a CDN, anyone can pin and serve signed capsules and releases: some people won't share, some share for free, and service providers sell premium access. The signature and CID decide trust, never the host.

Today: the seed serves every release. availability-provider ("SmartWeb availability adapter for Elacity or supernode replication targets", in the public-gateway and full profiles) already replicates content to configured targets.

Done means (to refine when selected)

• An operator can pin a signed release and its capsules and serve them to other Homes with one command.
• A Home fetches a release from any reachable provider, verifies it by signature and CID, and falls back to others when one is gone; the seed is not required once another provider holds the release.
• A Home can choose providers (own, free, paid) without changing what it trusts.
• Test: install and update succeed with the seed offline while another provider holds the release.

Related: #217 (no third-party downloads), #174 (seed service), #83 (seed reliability). Broader anyone-hosting, provider choice and failover acceptance stays parked until after 0.8.0 unless Anders selects it.

The 8 October scoped producer decision assigns this issue the held-only, bounded Content/Carrier fetch used by signed payload consumers, including #217/#288. This contribution proceeds independently of the broader hosting checklist. #287 supplies accepted generic CID selection; the Browser image path still needs to consume its admitted signed CID, checksum and size through this bounded operation. The execution owner, exact compatible candidate, review and accepted Browser acquisition receipt remain to be recorded; this clarification changes neither assignment nor active-task state.

Acceptance record

• Candidate: preserved held-only CID producer 5070b48560018599b778acbd5e19925bbbbf342f was reviewed against develop d430a1330e2b2e07afe0db3c13a13563b149ac3f. It remains an unpublished source input; an accepted compatible producer is still required by Wrap third-party software as capsules served over Carrier; never download from other servers #217/Browser: prepare the selected local Engine during normal installation and repair #288.
• Checks: read-only source comparison found an unbounded Content stream open, reintroduced one-hour Browser image timeout, removal of current Carrier request/header/body bounds if the older file is imported, and backend preparation before its enclosing deadline. The current UP-07: Accept updates on Mac, Linux and Jetson #113 idle-only progress and 30-second stream-open rules must be retained. No build or installed acquisition was run for this review.
• Review: an independent scoped source review recommends a small port onto current helpers: SignedContent plus held-only serving/refusal and the signed Browser image fetch seam. Preserve the current anonymous download, cancellation, final checksum, blocking staging owner, inherited file lock and atomic replacement. Resolve the deadline findings before accepted consumption.
• Installed evidence: exact Browser signed acquisition and held-only refusal receipts are pending; existing generic Undo and older Homes fetch components by name, so they get the newest release's bytes #287 acceptance covers its own scope.
• Remaining gate: one execution owner, compatible reviewed producer, stalled-readiness refusal and current slow-progress/cancellation/integrity checks, then the accepted Browser acquisition receipt. Broader hosting, provider choice and failover remain separate.
• Next owner: @andersalm identifies the execution owner and publishes the scoped producer for review. Port the changed operations onto current develop rather than replacing older whole files; run the existing Carrier file, carrier_fetch and Browser image test seams under the agreed build owner.