AFS UI is the architecture name for projecting AFS resources and capabilities into something a human or agent can interact with. It answers: given paths, providers, and operations, which UI device and contract present them?
It is not a third large authoring board next to AUP and Web Device. Author interactive apps in AUP. Author static sites in Web Device. Use this page only to keep those targets aligned with AFS.
What exists in current code
Checked against ARC source 44fbd616f and packages at 2.0.0-beta.31 in tree:
| Piece | Package / location | Role today |
|---|---|---|
| AUP types and pure helpers | @aigne/afs-aup (packages/aup) | Semantic node graph, validation helpers, degradation helpers shared by devices |
| Interactive UI device runtime | @aigne/afs-ui (providers/runtime/ui) | Sessions, AUP app loading, node store, event/exec wiring, web-page surfaces |
| Web Device provider | @aigne/afs-web-device (providers/runtime/web-device) | Reads site trees (pages, content, .web/) and renders static HTML; can render supported AUP shells for sites |
| AFS provider base | @aigne/afs (packages/core) | Mounts, list/read/write/search/exec, capability and access modes |
AUP node fields that connect UI to AFS include src (read-only binding), bind (read-write binding), propBind (server-resolved prop paths), and events that map to AFS exec. Those fields are part of the AUP contract, not a separate “AFS UI API.”
Architecture relationship
AFS (paths + providers + operations)
└─ AFS UI (projection lens)
├─ AUP + UI runtime → interactive sessions / device renderers
└─ Web Device → static HTML sites and content objects| Concern | Owned by | Notes |
|---|---|---|
| Path operations and provider capability | AFS | UI cannot invent an operation the provider does not declare |
| Semantic tree, events, degradation | AUP | Device must report capabilities; support is not universal |
| Session handshake and interactive render | UI runtime (@aigne/afs-ui) | Present-tense behaviour is version- and target-specific |
| Site directories, markdown content, themes | Web Device | Separate from interactive session protocol |
| Comments / collections surfaces on sites | Web Device + UI surface code | Platform surfaces exist; not a guarantee that every site enables them |
What draft architecture docs claim that this page does not
Internal draft materials (for example docs/architecture/afs-ui.md in the ARC repo) describe a broader vision: every UI element as an AFS path, a full /dev/ui device model, window managers, and multi-backend renderers. Treat those as archaeology and design intent.
This public page only states:
- AFS UI is a useful lens for relating UI to AFS.
- AUP and Web Device are the documented authoring and runtime contracts.
- There is no public, versioned “implement any third-party AFS UI device” extension guide with a guaranteed E2E sample for external authors—unless and until a sibling board documents one against current code.
Do not infer:
- Every AFS path has a UI
- Every UI can write through AFS
- Every renderer supports the same primitives
- Old ArcBlock admin UIs are shipped as stable ARC products
Where to go next
| Task | Board |
|---|---|
| Author or validate AUP source | AUP |
| Device capabilities and degradation | AUP device capabilities (and related AUP pages) |
| Build a static site | Web Device |
| Mount data or implement a provider | AFS |
| Package the app | Blocklets |
| Caller and session data views | Identity & Data Spaces |