awai.network

AWAI NETWORK / NODE READINESS

What works.
What remains.

From a NixOS device to Awai Node, distributed state and HTTP access. Explore the four roles behind a node, how they compare with HoloPort, EdgeNode and Web Bridge, and the limits of the implementation and evidence.

See readiness ↓Compare with Holo ↓

THE SYSTEM

Equip a device. Run work. Keep state. Make it accessible.

This diagram shows responsibilities in the intended system. Its arrows do not mean every app calls remote servers in this order.

  1. 01 / DEVICE

    NixOS device

    Install the OS and Murakumo Client on a PC or mini PC, with startup, setup, updates and recovery.

    Comparable to HoloPort hardwareCurrent evidence: OS and setup in VMs
  2. 02 / EXECUTION HOST

    Awai Node

    Manage host admission, resources, permissions, execution and observation. The intended system runs Cells through hata.

    Comparable to EdgeNode executionCurrent evidence: individual native components
  3. 03 / STATE

    Distributed state

    mon, ito and nuno cover rules, history and synchronization; kotobase and Yataverse cover graphs, bytes and recovery.

    Comparable to EdgeNode data retentionCurrent evidence: selected recovery workloads
  4. 04 / HTTP ACCESS

    HTTP access

    A dedicated service layer makes distributed data readable by ordinary browsers and external devices.

    Comparable to Web BridgeCurrent evidence: delivery pilot; integration remains

Itonami is the agent-first workspace using this foundation. Aozora provides identity, social and collaboration features. Murakumo inference and compute are service roles placed on a Node. NixOS is the current OS; AIUEOS is a future replacement under development.

ROLE COMPARISON

How HoloPort, EdgeNode and Web Bridge relate.

A comparison of roles. It does not claim protocol compatibility or equal product maturity.
Holo componentResponsibilityCorresponding Awai components
HoloPortPhysical hardware used for hosting.NixOS + Murakumo Client deviceA PC or mini PC running Awai Node. Hardware readiness and the maturity of its node software are assessed separately.
Holo EdgeNodeRun a conductor and hApps, staying online to retain, validate and synchronize DHT data. Deployable on general physical hardware or virtual environments.Awai Node + hata + distributed stateThe counterpart combines the execution host with Cell rules, signed history, replication and recovery. Integration is still in progress.
Holo Web BridgeAn API service that makes application DHT data readable through standard HTTP GET requests.HTTP read service for distributed app dataThe corresponding responsibility. A completed product integrating mon, ito, nuno and state verification is not yet provided.

For Holo's roles, see the official service description and official EdgeNode implementation. The detailed mappings—conductor to hata, DNA to mon, source chain to ito, and per-DNA DHT to nuno—are in the architecture overview (Japanese).

Yataverse stores, retrieves and replicates CID-addressed bytes. App validation rules, membership, signed history and synchronization are also needed to establish distributed app state. Serving static files over HTTP alone does not complete the Web Bridge role.

IMPLEMENTATION & QUALIFICATION

Read each feature in three states.

Component successes are not converted into a percentage complete. The verified environment and the connections still missing are shown together.

Implemented

A feature with implementation and verification records, limited to the stated environment and workload.

Unverified

An implementation or candidate exists, but evidence for the target hardware or integrated operation is incomplete.

Not implemented

The required implementation or integration is not yet connected in the reviewed target path or delivered artifact.

01

NixOS device

The device foundation: install the OS and Murakumo Client so an owner can configure, manage and update it.

Implemented

  • Offline installation, Japanese/English setup, preserving updates, signature and update-sequence checks.Delivery records and VM verification, 10 October 2026.Evidence E1
  • Approved remote management and actual SSH connections over LAN and Kekkai.GTK and Kekkai VMs, 11 October 2026.Evidence E2
  • Opt-in NixOS provider and buyer-claim responder modules, disabled by default. They require an already provisioned identity, verified CLI and local model server.Nix module evaluation passed in CI. A rebuilt ISO and physical-host inference/restart acceptance remain unverified.Evidence E8

Unverified

  • Physical GPU, target-model inference and sustained load on this NixOS distribution. Inference evidence from another OS is assessed separately.
  • Physical remote management, owner configuration and automatic-update acceptance, including watchdog and power-loss recovery.Published update records exist. The latest manifest returned HTTP 403 in this review and could not be reverified.

Not implemented

  • A delivery path integrating the recent Amu-native node into the NixOS ISO, from installation through signed admission and service startup.The delivery evidence predates the opt-in NixOS services merged on 24 October. Those services do not integrate the Amu-native node.

Next acceptance gate:Install the same NixOS candidate on target hardware and verify native-node startup, the target workload, reboot and recovery as one journey.

02

Awai Node

Node software for host admission, resources, placement, permissions and execution. Docker, Podman and fune are possible execution mechanisms.

Implemented

  • Native signature verification and node-state derivation; TCP exchange, stale-heartbeat draining and return.Two processes in one arm64 Linux VM, not two independent production nodes.Evidence E3
  • Actual OCI startup after digest, runtime-class and grant checks; output CID and signed receipt.A local OCI layout in a single Linux VM.Evidence E4

Unverified

  • Admission-state convergence and continuous operation across hosts with independent network and power failure domains.
  • The same node path on NixOS x86_64: automatic startup after boot, key custody and rejoining after failure.A local signed-admission candidate is separate from active qualification in a distributed network.

Not implemented

  • Integration of the native hata conductor with node execution, services and the console.Launching an OCI workload alone does not establish a logical Cell bound to mon CID × agent key.Evidence E6

Next acceptance gate:Connect signed admission, heartbeat, placement and execution across independent hosts, then verify hata Cell identity, permissions and history.

03

Distributed state

Combine app rules, signed history and synchronization with commit graphs and CID-addressed bytes so state can be recovered after moving nodes.

Implemented

  • Restore a signed Git checkpoint on a separate physical host, continue work and verify a successor checkpoint. Tampering, missing data and incorrect identities are refused.arm64 Linux VM to a separate x86_64 physical host; selected Git workloads, 24 October 2026.Evidence E5
  • After producer-process loss, restore the actual accountability-steward Itonami profile and automatically continue its second read-only inference turn on a separate physical host.arm64 Linux VM → physical x86_64 Linux. Task process fault; public fixture signing keys. No tools, cron, authoritative writes or distributed writer fence.Evidence E9

Unverified

  • Production-app durable replica counts, retention and pinning, and cold readback from another failure domain.
  • Full app recovery after node loss using the same Cell identity, a verified head and writer fencing.The Git recovery demonstration does not qualify continuous storage or resumed inference for arbitrary apps.

Not implemented

  • An integrated app path connecting native hata Cell lifecycle, signed history and calls with nuno synchronization and kotobase/Yataverse recovery.Existing hosted implementations and completion of their native port are assessed separately.Evidence E6

Next acceptance gate:Restore the same Cell on another node and resume its history and real workload while refusing double commits from the previous writer.

04

HTTP access

A dedicated service exposes distributed data to the wider web. The Web Bridge goal and existing delivery paths are assessed separately.

Implemented

  • Static-site HTTP delivery and an existing delivery pilot using IPFS, DNSLink/IPNS and a read gateway.Pilot source reviewed. Current services and delivery architecture are described separately.Evidence E7

Unverified

  • Correct HTTP delivery of verified distributed-app data through failure and recovery of independent hosts.
  • Current availability of the delivery pilot and its connection to native nodes and Cells.An API or static site responding does not, by itself, complete DHT read access.

Not implemented

  • An integrated Web Bridge equivalent that exposes verified mon/ito/nuno app data through bounded GET operations and a defined response contract.

Next acceptance gate:Read one app's data through Cell → verified state → dedicated HTTP endpoint → external client, including tampering, unauthorized access and stale-state handling.

End-user app UI, workflows and local state run in the user's environment. The HTTP access service and the app origin distributing static artifacts have distinct roles. Browser operations using external services follow the shared client runtime's consent for each operation.

Host markets, automatic rewards and settlement have separate acceptance gates. Node startup, admission or an execution receipt alone does not establish revenue or a completed payment.

EVIDENCE & SCOPE

Evidence and the scope of this review.

Source main branches and verification records were checked on 24 October 2026. Links below pin the reviewed revisions. Delivery, main integration, candidate implementation and physical operation are distinct states.

  1. E1 / NixOS delivery and updates

    Delivery records from 10 October 2026: offline ISO, signed updates, preserving update, reboot and commit. The network-update test included a QA timeout extension; unmodified physical-hardware behavior requires separate qualification. Current release contents were not reverified in this review.

    Delivery and VM verification ↗

    Delivery evidence: 5911a37; latest source: 6a3a991

  2. E2 / Remote management

    GTK/Kekkai VMs verified actual SSH, reboot and revocation on 11 October 2026. The recorded physical SSH attempt did not succeed. Subsequent main integration is separate from physical rollout.

    Remote-setup verification ↗

  3. E3 / Signatures and peer state

    Two processes on one host agree on signed inputs and observe heartbeat loss and return. Independent failure domains, production key custody and unbounded operation are outside the evidence.

    Peer convergence and heartbeat records ↗

    Peer/OCI evidence: 8629ae1; latest source: 8fc1565

  4. E4 / OCI execution

    Check a local OCI layout's digest and grant, start it, and verify its output CID and signed receipt. Registry retrieval, a second node and distributed receipt persistence are outside the evidence.

    Startup and receipt verification ↗

  5. E5 / Recovery on a separate host

    Selected Git workloads on 24 October 2026: restore, native execution and a successor checkpoint on another physical host. Durable replica quorum and full production-app recovery are not qualified.

    Checkpoint and recovery demonstration ↗

  6. E6 / Remaining Cell integration

    Inventory of the native hata port and missing or unqualified connections: mon/Cell identity, lifecycle, history, calls, networking and storage.

    Native Cell implementation inventory ↗

    hata main: 5092266

  7. E7 / Existing HTTP delivery

    The operator reviewed the existing IPFS gateway pilot source dated 7 October 2026 and the public distribution architecture. Static-byte delivery and app DHT reads are separate features. The pilot's current operation was not requalified in this review.

    Current domains and delivery (Japanese) ↗

  8. E8 / Opt-in NixOS services

    Installer main 6a3a991 adds provider and buyer-claim services with opt-in defaults. Recorded Nix evaluation covers configuration; it does not prove a newly released ISO, model installation, physical GPU operation or completed fleet admission.

    NixOS provider source and module evaluation ↗ · CI ↗

  9. E9 / Actual Itonami profile continuation

    Murakumo main 8fc1565 records a two-host read-only profile drill using real inference after a producer process was killed. Provisioning and checkpoint replication were explicit. Heartbeat loss is a liveness hint, not a lease/fence; production credentials, tools, schedules and full app recovery are not qualified.

    Profile recovery and two-host evidence ↗
Full architecture (Japanese) →Awai Web Bridge design →Run the Mac preview (Japanese) →Resource-participation requirements →

The public Mac preview distributes local host observation and a static console. It does not bundle or connect every native component described on this page.

Translation coverage

The goal is 99% population reach and about 1,132 languages. Published translations and review status are listed here; population coverage has not been verified.

Linked architecture and setup guides are currently in Japanese. This language selection covers the home, participation and node-readiness pages.

Suggest a translation correction · Language manifest

Published translations