the web of cells

A host that cannot tamper with what it serves.

Publish a minisite and you commit its blake3 hash to your cell: on-chain, in one cap-gated receipted turn. <name>.dregg.works serves the bytes, but it holds no power to change them. Every published page proves itself in the visitor's browser: the served bytes are re-hashed and matched against the commitment. You never have to trust the host.

See it can't lie Publish a cell
The model

A link is a capability, not a location

On the open web a link is a place: you trust DNS to find a host, TLS to authenticate it, and then you trust whatever bytes that host hands back. A dregg:// page is a capability into a specific cell, and its bytes are content-addressed: the page is the page the origin committed, checkable by anyone, from any source. dregg.works is that model wearing ordinary HTTP, so any browser can reach it.

1 · commit (the trust)Publish to your cell A cap-gated turn writes blake3(page) into slot 0 of your cell. The commitment is on-chain, signed, receipted, and yours. This is the only trust-bearing step.
2 · serve (just bytes)<name>.dregg.works The host ships the raw committed bytes over HTTP. It is untrusted infrastructure: convenience, never authority. It cannot forge a blake3 preimage.
3 · verify (you)Re-hash in your tab The verify badge re-hashes the bytes your browser received and compares them to the cell's committed hash, fetched from a node you can point anywhere. ✓ or ✗.
Prove it to yourself

Tamper with the bytes · watch it get caught

This is the exact check every dregg.works page runs, here in your tab. The committed hash is fixed (as if it were on-chain in a cell). Edit the page bytes below: the served hash recomputes live. Change a single character and it diverges: the host cannot slip anything past you.

the commitment is fixed, like a hash sealed in your cell's slot 0
…
committed on-chain (cell slot 0)—
served bytes · blake3, computed in your tab—

On a real dregg.works page the committed hash is not baked in: it is fetched live from a node via GET /api/cell/<id> (slot 0), so the host serving the page never supplies its own answer key. Same blake3, same comparison, against a commitment you can independently look up.

The badge

Every served page carries the proof

One self-contained script, dropped into a published page, gives every visitor the verdict in the corner of the screen: no extension, no install. It re-fetches the page's own bytes, hashes them with a vendored BLAKE3, and checks them against the on-chain commitment. A click opens the full reading.

✓ verified on-chain

<!-- in your published page, before </body> -->
<script src="/verify-badge.js"
        data-cell="<your 64-hex cell id>"
        data-name="mysite"
        data-node="https://<node-you-trust>"></script>

Then commit blake3 of the whole file, badge tag and all, to your cell. The page becomes self-certifying: the bytes that include the badge are exactly the bytes the badge re-hashes and the bytes the commitment pins. The check closes on itself. The badge carries no baked-in node: the host serving the page never supplies its own answer key. data-node names the node you trust (the script's header documents the meta-tag and window.__DREGG__ alternatives); with no node configured, the badge reports the page as unanchored rather than inventing one.

Published

Browse the web of cells

A published cell is sovereign: it committed its own bytes. The dregg:// ref is the content-addressed cell id; the .dregg.works name is just a convenient front for it. No public devnet is anchored right now, so no minisite is publicly served; publishing works against any node you run.

hello hello.dregg.works · dregg://<cell> The first minisite shape: a page whose bytes are committed to a cell and re-verified in the visitor's browser, served wherever a node is anchored.
+ publish yours dregg id → turn → commit Hold a cell, commit a page's hash with one cap-gated turn, point a name at it. Your bytes, your sovereignty boundary.
Publish

Commit a page to a cell

Publishing is one verified turn: write blake3(content) into slot 0 of your cell under the publish method. The commitment is the trust-bearing half; serving the matching bytes is just hosting. This is the publishMinisite drive action the interactive portal fires. 

import { hexEncode } from "@dregg/sdk/browser";
import { blake3 } from "@noble/hashes/blake3";

// blake3(page) → the 32-byte content commitment a publish turn writes
const contentHash = blake3(new TextEncoder().encode(pageHtml));

// one cap-gated, receipted turn: write the hash into the cell's slot 0
const receipt = await runtime.turn()
  .method("publish")
  .write(0, contentHash)        // SITE_CONTENT_SLOT
  .sign()                        // Ed25519, federation-bound
  .submit();                     // → Receipt

// the page is now self-certifying at dregg://<cell>
const dreggUri = `dregg://${runtime.cellIdHex()}`;

The convention is realized in portal/src/drive-actions.mjs (publishMinisite) and starbridge-web-surface/src/web_of_cells.rs (WebOfCells::publish / the ServedResourceCell shape). The serving host that maps a name to a cell and ships the bytes is untrusted infrastructure: by design, it never needs to be believed.