Serve HTML over CXO — content-addressed static web behind the mesh browse gateway

[0pcom]

Serve HTML over CXO — content-addressed static web behind the mesh browse gateway

Idea

Add CXO as a third backend behind the mesh browse gateway (the meshproxy / resolving-proxy that already fronts dmsg and skynet), so a browser can load a published site straight out of the CXO object store — an IPFS-style content-addressed web, but over skywire's own CXO propagation instead of a separate stack.

Why it fits cleanly

CXO is content-addressed pub/sub (a merkle-DAG replicated to subscribers), not request/response. So it stands in for the HTTP GET of static resources, not for a live app backend. That maps onto the existing gateway with almost no new surface:

• <pk>.cxo.localhost/path → resolve the publisher PK's latest CXO root → walk the DAG to the object → serve its bytes as an HTTP response on the loopback origin the iframe browser already trusts.
• Because it's served from a trusted local origin, it's a secure context (HTTPS-equivalent, no TLS-MITM) — same property as the real-origin route browsing.
• The iframe browser is unchanged; it doesn't know the bytes came from CXO vs. a route.

Value

• Offline-first / censorship-resistant: content is servable even when the origin is offline, because it's already replicated across subscribers.
• Integrity + caching for free: hash-addressed objects are verify-on-read, dedup, and cacheable.
• Reuses the existing CXO mesh: the same propagation layer that already carries reward / registration / transport-survey feeds now also carries a published-content layer. HTML is just an HTML-typed object with a gateway that renders it.

Scope boundary (what it is NOT)

CXO serves published objects, not computed responses. Forms, APIs, per-request server logic, and live/dynamic pages do not map — those stay on the route-based backends (dmsg/skynet via meshproxy). This is complementary: routes for live/dynamic origins, CXO for the published/static subset (sites, docs, archives, the skynet content layer) where offline-availability and integrity matter.

Cold-fetch UX

A not-yet-replicated <pk>.cxo root needs a subscribe-and-pull before it can be served — the same "fetching from the mesh…" interstitial shape as the cold-route warming already implemented for the mesh reverse-proxy (#3960). Reuse that interstitial path.

Rough implementation sketch

1. A cxo network selector in the mesh gateway's subdomain resolver (alongside dmsg/skynet).
2. A CXO-root→HTTP handler: resolve latest root for the PK-feed → DAG walk by path → content-type from the object → serve bytes; subscribe-and-pull with the transient interstitial on a cold/missing root.
3. A publish path: write a site (directory tree) into a CXO feed keyed by the publisher PK (CLI: e.g. cxo publish <dir> → root hash under the visor's key).

Status

Design note captured out of a routing/browse discussion; filing as a tracking issue for later. Not blocking anything.