feat(hololake): add signed dynamic capability routing
This commit is contained in:
parent
9d1801266c
commit
ec8bbfd604
12 changed files with 1085 additions and 17 deletions
15
product-source/hololake-native-desktop/docs/ARCHITECTURE.md
Normal file
15
product-source/hololake-native-desktop/docs/ARCHITECTURE.md
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
# HoloLake Native Desktop Architecture
|
||||
|
||||
The stage-one shell is a Tauri v2 application with a Rust-owned local core and a React human projection. The five domains and their server fleet remain submerged system infrastructure rather than primary stage-one navigation.
|
||||
|
||||
## External programming AI entry
|
||||
|
||||
MCP may discover HoloLake, but it does not own continuity. The installed application starts a user-only Unix socket broker. A programming AI opens or resumes a HoloLake-issued local session, then uses the installed executable's `--connector` mode for newline-delimited protocol traffic. Session secrets are stored only as hashes. Events use exact cursors and idempotency keys.
|
||||
|
||||
## Dynamic capability routing
|
||||
|
||||
HoloLake stores a signed node capability registry rather than fixed server slots. A candidate route must bind the exact human, persona, domain and capability. It is eligible only while a fresh node-signed health receipt reports the capability as ready. Selection is deterministic by priority and node id.
|
||||
|
||||
The registry signer trust root is embedded independently from registry payloads and is currently `UNPROVISIONED_FAIL_CLOSED`. Registry and health mutation are not exposed to the webview. External AI route queries require possession of the active HoloLake local session secret. A route receipt never grants write authority; production node write admission remains a separate unimplemented gate.
|
||||
|
||||
HoloLake routes work but does not host the user's private work lake, pool users into a multi-tenant runtime, or carry server workload concurrency.
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
# ADR 0001: Signed dynamic capability routing
|
||||
|
||||
Status: Accepted locally; production trust provisioning pending.
|
||||
|
||||
## Context
|
||||
|
||||
Stage one must connect a changing fleet of team and user-owned nodes without hardcoded endpoints. SSH access, root access, a URL, or a health probe cannot establish Guanghu node identity or write authority. The client must also preserve the one-human-one-owned-root-node boundary and avoid becoming a hosted concurrency layer.
|
||||
|
||||
## Decision
|
||||
|
||||
Use a Rust-owned, file-backed dynamic registry whose complete canonical payload is verified with an independently embedded Ed25519 trust root. Each node carries a protocol public key and explicit human, persona, domain and capability bindings. Runtime eligibility additionally requires a fresh Ed25519 health receipt from that node with a strictly increasing sequence.
|
||||
|
||||
Route resolution is available to external programming AI only through an authenticated active local HoloLake session. It returns a non-authorizing route receipt. Webview code cannot install registries or submit health receipts.
|
||||
|
||||
The embedded trust file initially contains no signer. This makes production registry installation fail closed until the registered HoloLake/JD-controller signing identity is provisioned.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The fleet can grow without client code changes or fixed server slots.
|
||||
- Stale, replayed, unsigned or incorrectly bound nodes are not routable.
|
||||
- Registry publication, health, route selection and write admission remain separate facts.
|
||||
- Production node enrollment and write execution still require their own source, signing, deployment and readback receipts.
|
||||
Loading…
Reference in a new issue