awai.networkNetwork architecture

AWAI NETWORK / AWAI WEB BRIDGE

Awai Web Bridge

A public read boundary for verified Awai app data. The integrated API is a future gate.

Design accepted · public read API not yet operating · updated 2026-10-25.

Awai Web Bridge is the planned HTTP read entrance for selected public, verified Awai app data. A normal web page or script will be able to request a registered view without running a node. The bridge must trace each result to its app source and exact verified head. It is an Awai design inspired by Holo Web Bridge, not a Holochain-compatible endpoint.

HTTP reader→registered GET view→verified Cell or graph head→public result + provenance

The rest of the web follows different routes. A static dapp is delivered by immutable CID and a verified release record. The browser runs its own UI, workflow and state, then asks fresh operation-specific consent before contacting a selected external service. Awai Node and Kura provide qualified host and retention roles; operator controls stay off the public read API.

Route What it is for Current state
Static release HTML/CSS/JS/Wasm and pinned application artifacts; stable name advances after release checks. Individual CID/HTTPS pilots exist.
Awai Web Bridge Registered, bounded GET/HEAD view of public app state with source/head provenance. Contract design; no live integrated endpoint.
Direct service Inference, identity, uploads, writes and payments with the selected service's authorization and fresh browser consent. Product-specific integration; not part of a public GET.
Hosting control Placement, Cell lifecycle, replication, retention, accounting and support. Component work; independent-host and economic gates remain open.

The proposed bridge.awai.network name is not configured as a service. No current awai.network API route becomes Web Bridge merely because it returns HTTP 200. The existing node readiness page lists measured components and missing integration. ADR 0015 is the normative boundary for future implementations.

Continue

  • Roadmap — evidence gates from static releases to independent hosting.
  • Hosting services — what a node, byte store, bridge and direct service each own.
  • Connect an app — release, descriptor, read and consent paths.
  • Node readiness — implementation evidence and omissions.