Decentralized frontends

The property that distinguishes this from ordinary hosting is certification. The documentation describes the asset canister as certifying its responses: it includes a certificate that a client can verify against the network's root public key, proving that the response reflects state the network has agreed on. A browser that verifies the certificate is not trusting the node that served the response.

The documentation is precise about what this does and does not cover. Certification applies to the assets the canister serves and to the canister's own state. It does not certify the behaviour of the JavaScript that runs in the browser, and it does not prevent a canister's controllers from upgrading the canister to serve different assets. A user who verifies the certificate has verified what the network agreed to serve, not what the application's authors intended.

That distinction is the one most often blurred in discussions of on-chain frontends. Certification is a strong property about the delivery of bytes; it is not a property about the code those bytes contain. The canisters page covers the control model that determines who can change what is served.

The asset canister does not render on the server. The documentation describes it as serving static assets, which means a frontend that depends on server-side rendering, on a server-side templating engine, or on generating HTML per request is not supported by the canister as it stands. A client-side application that fetches its data from a canister after loading is the model that fits.

The documentation also notes the boundary between the frontend and the backend. The frontend runs in the user's browser, where it is outside the network's consensus; the backend runs in a canister, where it is inside it. A frontend that reads data through a query call is reading a single replica's response unless it verifies the certificate, and a frontend that writes through an update call is going through consensus. The canisters page covers the query and update distinction.

The honest summary is that an on-chain frontend removes the hosting provider from the path, and it does not remove the browser, the network's nodes, or the canister's controllers. It changes who must be trusted for delivery, and it leaves the rest of the trust landscape where it was.

The conventional arrangement puts a hosting provider between a user and an application. The provider can take the site down, change what it serves, or be compelled to do either. An application whose frontend is served from a canister has no such intermediary: the assets are in the canister, and the canister serves them as long as it has cycles and its controllers do not change it.

The documentation presents this as the completion of the on-chain story. A backend that runs in a canister and a frontend that is served from one are both on the network, and the only remaining external dependency is the browser and the network's own operation. That is a meaningful reduction in the number of parties a user must trust, even if it is not a reduction to zero.

The practical consideration is cost and control. A canister that serves a frontend burns cycles for storage and bandwidth, and its controllers can replace its contents. A project that wants the frontend to be as immutable as the backend must hand control of the asset canister to the same governance that controls the backend, which is what an SNS handover does.