Sol design review — Devices & the agent layer

Part of the site’s external review; reproduced verbatim below the header. sol’s positions are folded into the design frontier as External review input lines.

Date: 2026-07-18
Reviewer: gpt-5.6-sol (codex exec, model_reasoning_effort=xhigh, codex-cli 0.144.1, lane-182)
Scope: src/part2/devices.md · src/part2/agent-layer.md · src/part3/devices.md · src/part3/agent-layer.md · the devices-agent-layer marker block of src/part5/emerging-specs.md (full text inlined in the prompt; sol had no filesystem)

Orchestrator summary (5 lines): Sol’s verdict: the device fabric is materially real, but the security model is not yet coherent enough to implement — the biggest problems are unresolved semantics, not missing code. Grant/lease: onward:false contradicts lease-minting under a grant; sol recommends “lease = audience-bound invocation, not delegation,” a deterministic attenuation-subsumption algorithm with conformance vectors, a published max stale-authority window for revocation, and requalifying “verifiable offline” as “verifiable against a named signed snapshot under a declared staleness ceiling.” Authed-wake: same-network v1 is right but is “process activation, not wake”; a relay mailbox is not an activation mechanism (nothing polls it); the sovereignty-fitting pattern is a user-controlled home broker doing authenticated WoL plus contentless push hints (self-hosted UnifiedPush / opt-in FCM), and “force-stopped” must be split from “process killed.” Agent: the shell is not a defensible boundary — sol proposes a five-part split (agent daemon / policy+signing service / browser broker / shell-as-UI / page+model both untrusted), excludes raw CDP, execute.script, and persistent injection from v1, and names human approval as inspection, not an authority bound; audit: the 64-bit-truncated chain is corruption detection, not adversarial tamper evidence — converge on one full-hash, signed-checkpoint ledger with cross-device head gossip. Movable memory: ship replicated-home collections (single-writer, signed epoch transitions, durable-replica acks) before any generic CRDT; top follow-ups: wire the apps.list responder under a constrained launch descriptor, freeze a grant/lease v1 verifier profile, and land one out-of-shell capability-enforced agent action end to end.

The device fabric is materially real; the security model around it is not yet coherent enough to implement. The largest problems are not missing code but unresolved semantics: onward:false conflicts with lease minting, “offline revocation” is overstated, a relay mailbox cannot by itself wake a dead process, and the audit chain provides much less adversarial tamper evidence than the text implies. The resident agent should still be described as a research preview until an out-of-shell enforcement boundary exists.

(1) The grant/lease delegation model

The UCAN analogy is directionally useful, but the current mapping is not yet internally consistent.

`onward:false` conflicts with “lease minted under a grant”

A grant is described as a delegation to an install principal with onward:false. The same principal then supposedly mints a lease carrying narrower authority to an agent or surface. If that lease transfers authority to another principal, it is precisely the onward delegation the grant forbids.

There are two coherent ways to resolve this:

Treat the lease as an invocation, not a delegation. The install principal signs an exact request to a specific executor, and the executor checks it against the parent grant. The agent never receives transferable authority.
Permit one explicit delegation step: the grant permits attenuation to an executor-bound, non-delegable lease. In that case the grant cannot truthfully be onward:false; it needs a delegation-depth or audience restriction.

The first option is cleaner. The grant audience should be a local policy service/install principal. That principal invokes an executor using an audience-bound, short-lived authorization. The model and page remain untrusted requesters, not capability holders.

Attenuation is not proved merely by linking the lease to a grant

Signatures prove who issued tokens. They do not prove that the child capability is narrower. A verifier needs a deterministic subsumption algorithm:

Every lease capability must be covered by at least one capability in the parent grant.
Resource containment must be precisely defined. URI prefix comparison is unsafe without canonical schemes, hosts, ports, paths, percent-encoding, origin rules, and app identifiers.
Ability implication needs an explicit lattice. Does read.dom contain read.text? Does execute.script subsume every read and mutation ability? Can mutate.form navigate or submit network requests?
Every constraint type needs a partial ordering. Shorter expiry is narrower; fewer allowed fields may be narrower; arbitrary JSON constraints are not automatically comparable.
Unknown abilities or constraints must fail closed.
Token encoding, hashing, and signature inputs must be canonical and domain-separated.

Aggregate constraints are especially difficult. If a grant allows ten calls, minting ten leases that each allow ten calls is not attenuation. Budgets, call counts, and rate limits require shared accounting at the minting service or executor. Independent offline verifiers cannot enforce a global counter.

The parent grant identifier or digest must appear in the lease proof. The verifier should check the complete chain, issuer and audience bindings, capability subsumption, time intersection, revocation status, executor binding, and replay state.

The statement that a nonce is “CID-equivalent” should be removed. A CID identifies content; a nonce supplies uniqueness. Neither makes an invocation single-use. Single-use requires a durable consumed-nonce database at the relevant enforcement point.

Revocation has an unavoidable availability boundary

“Revoke a grant to end all leases” is valid only as an admission rule:

Every lease must name exactly one parent grant or grant-family generation.
Revocation must identify that grant, family, or install principal in a signed, monotonic revocation record.
Every executor must check revocation before beginning the action.
Already-completed side effects cannot be revoked.
The design must state what happens to an action admitted before revocation but still running: finish, cancel at the next boundary, or require continuous authorization.

Revocation cannot be immediate on a disconnected device. Gossip on the next accepted connection provides eventual convergence, not instantaneous revocation. The product must publish a maximum stale-authority window and decide whether an executor fails closed when its revocation checkpoint is older than that window.

Short leases alone do not solve this. If a compromised install principal can mint fresh leases while offline, it can continue indefinitely until it learns of the grant revocation. Bounding this requires at least one of:

short-lived grants that require periodic renewal;
a fresh signed revocation checkpoint required when minting or executing;
an online authority for sensitive actions;
an explicit acceptance that offline local authority cannot be remotely revoked.

Device membership revocation and grant revocation must also be related explicitly. Does revoking a device invalidate every grant whose audience is a principal on that device? A verifier should not have to infer this.

Expiry and renewal need exact boundary rules

A lease must be valid only within the intersection of all parent validity windows:

effective interval = grant interval ∩ lease interval ∩ revocation-freshness interval

At minimum, v1 must specify:

whether boundaries are inclusive or exclusive;
permitted clock skew;
whether lease.notBefore >= grant.notBefore;
whether lease.notAfter <= grant.expiry;
that parent expiry invalidates the lease even if its own notAfter is later;
whether validity is checked only at admission or throughout execution;
maximum action duration;
behavior when clocks move backward or a device reboots.

Renewal should issue a new grant identifier or generation. It must not silently extend leases under the expired grant. Otherwise historical proofs become ambiguous and grant revocation can accidentally affect renewed authority.

Offline time is itself a trust assumption. Wall-clock validity is weak if the holder controls the clock. Short TTLs can use a monotonic clock during one boot, but cross-reboot offline verification needs an authenticated time source or an explicit weaker guarantee.

Offline verification is possible, but only with qualified claims

An offline device can verify:

signatures;
proof-chain linkage;
issuer/audience identities;
structural attenuation;
expiration according to its local clock;
revocation as of its latest signed checkpoint;
locally observed replay.

It cannot know:

whether a newer revocation exists elsewhere;
whether the same invocation was consumed on another disconnected verifier;
whether a fleet-wide budget has been exhausted;
whether its clock has been rolled back.

Therefore “verifiable offline” must mean “verifiable against a named signed state snapshot, subject to a declared staleness ceiling,” not “currently authorized everywhere.”

What v1 must pin down

Before implementation, v1 needs:

the principal graph: authority, device, install, policy service, agent, and executor;
whether a lease is an invocation or delegation;
canonical token encoding and signature domains;
grant and lease identifiers and proof linkage;
the resource grammar and ability implication table;
comparison rules for every constraint;
executor and surface binding;
replay-store scope and durability;
revocation record format, distribution, and freshness policy;
device-revocation cascade rules;
temporal and in-flight-action semantics;
key custody and rotation;
conformance vectors covering valid attenuation and every rejection case.

If “one Ed25519 key” means one key reused for transport identity, membership, grants, and audit, that should also be changed. Separate role keys—or at least separately certified subkeys—are needed to limit compromise and support independent rotation.

(2) The authed-wake crux

The design needs to distinguish four states it currently blurs:

Runtime process stopped while the OS is awake.
OS awake with no resident Xe process.
OS suspended.
Application force-stopped or device powered off.

launchd/systemd socket activation addresses the first two. It does not generally wake a suspended machine. Waking suspended hardware requires platform power-management support, Wake-on-LAN, or a local broker. Powered-off behavior is separately hardware-dependent.

Same-network-only is the correct v1 scope—with narrower wording

A same-LAN, kernel-held TCP socket can start a small verifier when the OS is awake. That is a tractable first version, but it is “process activation,” not generic “wake.”

Even there, authentication occurs after the socket causes a process to start. A network scanner can therefore create some amplification before cryptographic verification. The activated component must be tiny, fixed-cost, rate-limited, and unable to start the full runtime until it has verified a bounded request. Firewall scope and per-source activation budgets matter.

For actual suspend wake, an authenticated user-controlled router or always-on home device can receive a request and emit a local Wake-on-LAN packet. The WoL packet is normally not itself strong authorization; the broker supplies the security boundary.

A relay mailbox is not an activation mechanism

A mailbox solves store-and-forward reachability. It does not cause a zero-resident process to poll it.

For desktop WAN wake, something still has to be resident or platform-integrated:

a small background service;
a scheduled OS task;
a vendor wake facility;
an always-on local broker that can perform WoL.

On mobile, mature systems use an OS-integrated push provider to deliver a contentless wake hint, after which the app fetches encrypted data over its normal authenticated channel. Apple effectively requires APNs for this class of background reachability. Android commonly uses FCM; UnifiedPush replaces the central provider with a user-selected distributor, but that distributor must itself remain reachable and survive Android background restrictions.

A true Android force-stop is stronger than an ordinary process kill. Normal push delivery should not be claimed to override it; the package generally remains stopped until the user launches it. The design should replace “force-stopped needs notifications” with separate rows for “process killed/background restricted” and “user force-stopped.”

Sovereignty does not require pretending the relay is absent

Asynchronous internet reachability requires some component that remains available. A sovereignty-first design can make that component:

replaceable and user-selectable;
self-hostable;
unable to mint authority;
blind to payload contents;
unnecessary on the LAN;
optional when the user accepts reduced reachability.

A self-hosted UnifiedPush distributor or user-controlled relay fits that definition better than an obligatory vendor service. FCM can remain an explicit opt-in reachability provider. Neither should carry an action: the push should say only “check your authenticated mailbox.”

A user-controlled home broker is the strongest fit for desktop wake because it can authenticate a remote request, then perform local WoL without trusting a central server. An untrusted iroh-adjacent mailbox may deliver the encrypted request to that broker.

Relay-mailbox replay and amplification controls

A safe wake envelope needs:

a target-issued, narrowly scoped admission;
target identity and mailbox binding;
fixed wake class such as ensure_running;
expiry and issuance generation;
a random invocation nonce;
sender proof;
strict maximum size;
encryption to the target;
no arbitrary reason string or executable payload.

The relay should authenticate admission before accepting storage, enforce target and sender quotas, deduplicate envelope identifiers, expire entries quickly, and avoid responses to attacker-selected addresses.

The target needs a durable consumed-nonce store. Reboot, database rollback, or reinstall must not reopen old admissions; an admission epoch or monotonic generation is needed. Relay deduplication is useful but cannot be trusted as the security boundary.

At-most-once per nonce is insufficient against a peer generating unlimited fresh nonces. The target-issued admission must also constrain total uses or rate. Wake should cause at most one fixed-cost state transition and no reflected payload response. Otherwise a small request can produce a process-spawn storm, repeated model startup, network fan-out, or a reflection channel.

For v1, I would ship LAN process activation on the platforms that support it, accurately label suspend and WAN cases unsupported, and reserve the mailbox format without building it until there is a real target-side wake consumer.

(3) The resident agent architecture

The shell is not a defensible home for the security boundary. It can remain the user interface and browser integration surface, but it should not hold the agent’s durable memory, model credentials, grants, or signing material.

Physical architecture

A workable split is:

Agent daemon: task queue, memory, model adapter, planning, and provider credentials.
Policy/signing service: validates grants and consent, accounts for budgets, and issues executor-bound invocations or opaque handles.
Browser actuator/broker: exposes a small typed operation set against the Controlled Frame and enforces the invocation at the final moment.
IWA shell: displays state and collects user intent; it is not an authority source.
Page and model: both treated as untrusted inputs.

The browser actuator may need to remain close to the Controlled Frame, but it should receive typed operations such as “read visible text from this navigation epoch” or “click this identified element.” It should not expose raw CDP.

The console.log('iwa:…') channel should be retired as an authority-bearing IPC path. Typed messaging improves accidental safety, but authentication inside the same compromised shell is not sufficient. The meaningful boundary is an OS process boundary with peer credentials, explicit protocol versions, message sequencing, and fail-closed behavior.

Lease-signing root

The runtime authority root should not be continuously available to the shell or model process. It should sign install grants through a narrow consent/admin path, preferably using an OS keystore or hardware-backed key where available.

The per-install principal key used to sign invocations should be held by the policy service, not the IWA. A non-extractable OS key helps against key theft, but it does not prevent a compromised authorized process from asking the keystore to sign. Process isolation and request validation remain necessary.

Calling this the “lease-signing root” risks collapsing two roles:

the authority root certifies the standing grant;
the install/policy principal signs a particular invocation under that grant.

For same-device execution, an opaque single-use handle maintained by the policy service may be safer and simpler than a transferable signed lease. Signed leases become valuable when a separate device or independently implemented executor must verify them.

Human approval is not an authority bound

Per-call approval provides inspection, but it fails under click fatigue, misleading previews, prompt injection, UI spoofing, and time-of-check/time-of-use changes. It also does not constrain what the approved primitive can do. Approving Runtime.evaluate effectively approves arbitrary page-context computation and potentially broad data extraction.

The executor needs enforceable bounds independent of the model and approval UI:

exact device, app, top-level origin, frame, tab, and browser partition;
navigation epoch so authority expires when the page changes;
separate read, mutation, navigation, persistence, and network abilities;
selectors or stable element references where practical;
allowed output fields and maximum returned data;
destination allowlists and byte/call/spend budgets;
invocation count, duration, and concurrency limits;
task/session binding and cancellation;
step-up consent for irreversible effects;
an emergency revocation path enforced outside the shell.

execute.script, persistent injection, and unrestricted CDP should not be grantable in the first bounded version. They collapse the proposed ability lattice into ambient authority. Begin with a small brokered set such as visible-text read, one-origin navigation, and constrained element activation.

The human should approve policy or high-risk effects, not serve as the only reference monitor. Audit records are evidence after the event; they are not enforcement.

(4) The companion audit hash-chain

The current chain is useful as a corruption-detection and diagnostic format. It is not strong adversarial tamper evidence.

What it resists

Assuming a verifier retained a trusted prior head, the chain detects:

accidental changes to an earlier line;
unintentional line reordering, insertion, or deletion;
malformed manual edits that do not recompute subsequent hashes;
field injection through newlines or separators, due to sanitization.

The off versus kill distinction is worth preserving because it captures useful lifecycle semantics.

What it does not resist

An attacker able to modify the file can:

rewrite any event and recompute the remainder;
replace the entire chain with a new one;
truncate the tail;
roll back to an older valid copy;
delete the ledger;
create two valid forks;
omit an action before it is logged;
make the logger record a false event;
manipulate timestamps;
exploit concurrent append or partial-write behavior, which is unspecified.

There is no secret or signature in the chain and no trusted head outside it. A public hash therefore does not authenticate the history.

The 64-bit truncation is unnecessary and materially weakens collision resistance: generic collision work is on the order of (2^{32}), while full-history rewriting is already trivial for a file attacker. Keeping the full 256-bit result costs little. The main defect, however, is the lack of anchoring, not the truncation alone.

seq = lines.size + 1 also needs hardening. It is vulnerable to truncation, malformed trailing records, and concurrent writers unless there is a single append service with locking and atomic durability.

One fleet-wide discipline

The companion and agent should use one versioned event schema and one implementation discipline:

full SHA-256 chain values;
stable event and device identifiers;
device-local monotonic sequence;
wall time plus boot/session identity;
actor, cause, grant, lease, invocation, and result identifiers;
hashes of sensitive before/after values rather than indiscriminate plaintext;
explicit schema version and canonical encoding;
atomic append, locking, recovery, rotation, and linked segments;
signed periodic checkpoints using an audit-specific device key.

Fleet unification should preserve per-device chains rather than pretend there is a reliable global order. Devices can gossip signed segment heads and immutable segments over iroh. The group document or its anchor mechanism can periodically commit checkpoint digests without carrying the full log. Once another device has seen a head, later truncation or forking becomes detectable.

Historical verification must retain the membership/key history needed to validate an event from a device that was later revoked. Revocation prevents future trust; it should not invalidate authentic historical entries.

Audit sync also needs privacy and lifecycle rules: encryption at rest and in transit, retention, export, redaction, quotas, and who may inspect which records. Agent prompts, origins, and action results can be more sensitive than the actions themselves.

(5) Movable memory / cross-device sync

The minimum honest v1 is not generic multi-writer synchronization. It is a replicated-home collection with explicit limitations.

For each opted-in app data set, define:

a stable collection ID, app owner, schema version, and encryption key;
one authoritative home device and home epoch;
immutable versioned snapshots or an append-only change log;
at least one durable replica on another selected device;
content-addressed chunks and a signed collection-root manifest;
explicit quota, retention, and replication status.

Only the home accepts writes in v1. Other devices can read their last complete replica while offline, clearly marked with its generation and freshness. They do not accept offline mutations. That is weaker than local-first multi-master operation, but it is implementable, avoids silent conflict loss, and makes device loss survivable once another device has acknowledged the latest root.

Moving the home must be a signed epoch transition. A clean move requires the old home to flush and participate. A disaster promotion must say that an unreplicated tail may be lost. If the old home later returns with divergent changes, preserve its branch for explicit recovery; do not silently choose by wall clock.

A generic last-writer-wins rule is not acceptable for opaque app data. It silently discards work and depends on clocks the design does not otherwise trust. Multi-writer support should be opt-in by data type:

CRDTs for structures with a defined merge;
revision trees with preserved conflicts for documents/blobs;
application-provided merges for domain-specific state.

CRDT adoption brings its own requirements: stable actor IDs, causal metadata, tombstone retention, compaction, schema migration, revoked-device handling, and bounded history.

The existing authenticated iroh session can carry a dedicated sync protocol:

Exchange collection manifests: ID, home epoch, generation, root digest, schema, and chunk inventory.
Authorize the collection separately from group membership.
Transfer missing content-addressed chunks with resumption and backpressure.
Verify the root before atomically installing a new snapshot.
Return a durable replica acknowledgement.
Audit transfer, promotion, conflict, and deletion events.

Membership authentication alone is too broad; not every group member necessarily receives every app collection. Revoking a device can stop future sync and trigger key rotation, but it cannot erase data the device already copied.

Agent memory and audit data should ride the same transfer machinery but use different semantic profiles. Agent memory may be a replicated-home or CRDT collection. Audit is immutable signed-segment replication. Calling all three “peer sync” must not imply they share one conflict algorithm.

(6) Prior art

UCAN

Borrow:

issuer/audience capability tokens;
proof-chain linkage;
explicit delegation versus invocation;
canonical capability grammar;
monotonic attenuation;
expiry and not-before checks;
interoperable conformance vectors.

Avoid assuming UCAN supplies global revocation, single-use enforcement, budget accounting, trusted time, or offline freshness. Those require a product-specific profile and stateful verifier. Do not describe a nonce as a content identifier or treat proof-chain validity as proof of current authorization.

Matrix device verification and cross-signing

Borrow:

explicit per-device keys;
QR or short-authentication-string verification;
a hierarchy separating recovery/user authority from device keys;
signed device lists and visible trust state;
clear UI when a device key changes or is revoked.

Avoid importing homeserver dependence, room-state complexity, or federation machinery into a one-person fleet. Also avoid treating “cross-signed” as synonymous with “currently safe”; compromised but not-yet-revoked devices remain a problem. Matrix’s recovery UX is more relevant here than its messaging data model.

Signal sessions, Double Ratchet, and sealed sender

Borrow Double Ratchet-style forward secrecy and post-compromise recovery only for asynchronous stored messages where iroh’s live QUIC session protection is insufficient. For a mailbox, encrypt to the target and minimize retained message history.

Borrow the sealed-sender principle—minimize what a relay learns about the sender—but preserve abuse controls. A relay may still need an opaque target token, rate-limited admission, and message size information.

Avoid adding a ratchet to every live iroh stream merely because Signal uses one; QUIC already supplies an encrypted session. Also avoid using messaging-session keys as authorization capabilities. Confidentiality and authority are different layers.

Push-notification relay patterns

Borrow:

contentless or opaque wake hints;
short TTLs and collapse/deduplication identifiers;
“wake, then fetch over the authenticated channel”;
provider-specific reachability treated as advisory;
user-selected vendor or self-hosted delivery.

Avoid carrying commands, app data, or authority in a notification payload. Avoid claiming guaranteed delivery or force-stop recovery. Vendor push providers remain availability and metadata dependencies even when they cannot decrypt content.

For desktop wake, borrow the authenticated-broker-plus-WoL pattern used by managed home networks. The broker authorizes; WoL is only the local actuator.

SPKI/SDSI

Borrow:

signed authorization certificates;
issuer-local naming;
linked authorization chains;
explicit validity intervals;
threshold authority where recovery eventually requires it.

Avoid recreating a global naming PKI. The relevant lesson is decentralized authorization, not X.509-style identity administration.

Macaroons

Borrow:

monotonic caveat attenuation;
verifier-enforced first-party caveats;
contextual restrictions such as time, resource, and operation;
optional third-party discharge concepts for explicit consent.

Avoid adopting bearer macaroons without proof-of-possession or executor binding. Copying and replay remain possible, and symmetric root secrets complicate public offline verification and multi-device delegation. Macaroons may fit local opaque lease handles better than the fleet-wide grant chain.

Object-capability and sandboxed process systems

Borrow the central rule of no ambient authority: give the executor a narrow handle to one surface and operation rather than general access to a browser, filesystem, or network. Capability-secure IPC, pre-opened handles, and browser broker/renderer separation are directly applicable.

Avoid treating a signed JSON token as a complete object-capability boundary. If the holder still has raw CDP, unrestricted network access, or shared signing memory, the token is advisory decoration.

CRDT and sync systems

From Automerge/Yjs-style systems, borrow causal changes, deterministic merges, local operation, and hash-linked change graphs for data types that genuinely support multi-writer editing. Avoid assuming every app’s state is a document CRDT or accepting unbounded histories.

From Syncthing-like replication, borrow device-to-device block hashing, resumable transfer, version vectors, and preserved conflict copies. Avoid inheriting filesystem-specific semantics or an always-running-daemon assumption.

From CouchDB-style replication, borrow revision trees and explicit conflict preservation for opaque documents. Avoid silent last-writer-wins resolution.

Transparency logs and TUF-style metadata

For audit and revocation, borrow signed checkpoints, monotonic versions, expiry, rollback detection, and gossip between witnesses. A small private fleet does not need a public global transparency service; devices can witness one another’s heads.

Avoid copying the full operational complexity of Certificate Transparency or TUF. The applicable pieces are signed state, freshness, and rollback protection.

(7) Top-5 concrete improvement proposals, ranked

Ratify one constrained launch descriptor and wire the member-gated apps.list responder.
Why: this converts the most-built path from an honest error screen into a working product with very little code. It also resolves the current mismatch between d/104’s .localhost plane origin and the protocol’s acceptance of arbitrary HTTP(S) and isolated-app:// targets.
Smallest first step: freeze app_id, label, exact plane origin, tier, serving-device identity, and catalog signature rules; then register and dispatch the existing ALPN responder.
Freeze a Grant/Lease v1 verifier profile before minting any leases.
Why: the current outline cannot consistently enforce attenuation, replay, or revocation, and onward:false contradicts lease delegation.
Smallest first step: choose “lease as audience-bound invocation,” define three grantable abilities, and publish table-driven positive and negative conformance vectors.
Implement one out-of-shell, capability-enforced agent action end to end.
Why: one narrow real boundary is more valuable than expanding the unbounded preview. It tests the mission’s core claim.
Smallest first step: place read.visible-text behind a local policy service and browser broker, bound to one tab/origin/navigation epoch, with the shell and model holding no signing key.
Replace both audit variants with one full-hash, signed-checkpoint ledger.
Why: this is modest engineering work, removes duplicate semantics, and turns rollback/fork detection into a fleet property rather than a local-file claim.
Smallest first step: define a canonical v1 event envelope and have two devices gossip and persist each other’s signed chain heads.
Ship replicated-home collections before attempting generic CRDT sync.
Why: it gives app data a second durable home and a credible recovery path without taking on universal multi-writer conflict resolution.
Smallest first step: replicate one versioned app collection to one peer over iroh, install it atomically by root hash, and surface whether the latest generation has a durable remote acknowledgement.

(8) Missing session-agenda questions

What is the v1 threat model? Are the page, model output, IWA shell, other group devices, relay, and local OS administrator considered malicious, compromised, or merely buggy?
What is the exact key and principal graph? Are transport, group membership, grant signing, install invocation, and audit using one Ed25519 key or separate keys? Who rotates, backs up, and revokes each one?
Is a lease an invocation or a delegation? If the latter, how is it compatible with onward:false? If the former, which executor is its audience and who consumes its nonce?
What revocation guarantee is actually promised? What is the maximum stale-authority window, what happens offline, and do sensitive actions fail closed without a fresh checkpoint?
What are the first enforceable agent abilities? Are raw CDP, Runtime.evaluate, persistent injection, arbitrary network access, and cross-origin reads explicitly excluded from v1?
What exactly does a consent approval authorize? One operation, one displayed plan, a task, a session, or a standing grant? What page or navigation change invalidates it, and which effects always require step-up confirmation?
Who is the final reference monitor? Is authorization checked in the shell, policy daemon, browser broker, hosting device, or all relevant layers? Which component owns budget and replay state?
How is the launch catalog trusted? Can any member supply arbitrary labels and isolated-app:// targets, or must each descriptor be bound to a serving device, stable app ID, signed catalog entry, and exact .localhost origin?
What does “wake” mean per OS state? The agenda should separately decide process activation, suspend wake, ordinary Android process death, Android force-stop, and power-off behavior. A relay mailbox should not be approved until its target-side consumer is named.
What audit adversary is in scope? Is the ledger for diagnostics, user accountability, or evidence against a compromised device? What are the anchoring, retention, privacy, export, and deletion rules?
What is the minimum app-data consistency contract? Is v1 replicated single-writer, last-writer-wins, revision-tree, or CRDT? Are offline writes permitted, and how is home transfer fenced during a partition?
What happens after a forced home-device promotion? How are a returning old home’s divergent writes preserved, and who decides whether they are merged or discarded?
How do upgrades fail? If shell, daemon, executor, grant schema, or revocation format versions diverge, does the system fail closed, retain read-only access, or silently fall back to human approval?
What authority governs model-provider egress? BYO model selection does not answer which page data may leave the device, where provider credentials live, or whether prompts and responses enter the audit/memory sync system.
What does device revocation not accomplish? The session should explicitly acknowledge that revocation cannot retract previously synchronized app data, agent memory, or secrets, and decide when collection keys are rotated.

SOLREV-DEVICES-DONE

Keyboard shortcuts

Xe Computer — Architecture & Design