#159 - P1 — extend `ZARA/1` with bounded client capability advertisement and typed device action lifecycle - nsaspy/zara

lost-rob0t commented

2026-08-22 21:53:07 +00:00

(Migrated from github.com)

Parent epic: #150
Depends on: #158, #129, #130
Client migration baseline: #133.

Goal

Add the protocol plane that lets authenticated clients advertise a closed set of device capabilities and lets the server request typed device actions/results without creating a remote shell.

Protocol work

Research/version explicit message families for capability snapshot/change and device action request/accepted/result/cancel/error. Extend the closed ZARA/1 schemas; do not use arbitrary extension dictionaries as dispatch authority.

Each action must bind request/action id, authenticated principal, target session/device, capability id, typed bounded args, correlation/trace id, deadline, replay/idempotency class and result/error state.

Security invariants

advertisement reports availability only; it grants no server/admin authorization;
target device must belong to authenticated principal/session policy;
unknown capabilities/fields fail closed;
no shell/Python/Prolog source/import/executable string generic action;
local client permission denial is a typed result;
stale session/device advertisement cannot receive new actions;
revocation/disconnect cancels or resolves outstanding actions deterministically;
per-session action queues/rates/payloads bounded;
audit excludes clipboard/screenshot/private payload content where policy requires.

Mandatory tests

hello/capability negotiation golden frames;
bounded capability count/name/metadata;
duplicate/unknown/oversized entries;
open-uri/open-app fake device action round trip;
wrong principal/device targeting denied;
disconnect/reconnect with in-flight action;
replay duplicate side effect according to idempotency policy;
cancel/action-result race;
malicious body attempting shell/import/eval rejected;
client says admin or fake server capability -> no authority gain;
one slow device-action client does not block another.

Gates

Protocol tests first, golden fixtures/fuzz, focused ZARA/1 device-action integration script, existing 91+ protocol regression gate, full Nix/repo and exact-head Actions.

Acceptance

The server can safely discover what an authenticated device can do and request one allow-listed typed action with a correlated result, without any generic arbitrary-code execution mechanism.

Parent epic: #150 Depends on: #158, #129, #130 Client migration baseline: #133. ## Goal Add the protocol plane that lets authenticated clients advertise a closed set of device capabilities and lets the server request typed device actions/results without creating a remote shell. ## Protocol work Research/version explicit message families for capability snapshot/change and device action request/accepted/result/cancel/error. Extend the closed ZARA/1 schemas; do not use arbitrary extension dictionaries as dispatch authority. Each action must bind request/action id, authenticated principal, target session/device, capability id, typed bounded args, correlation/trace id, deadline, replay/idempotency class and result/error state. ## Security invariants - advertisement reports availability only; it grants no server/admin authorization; - target device must belong to authenticated principal/session policy; - unknown capabilities/fields fail closed; - no shell/Python/Prolog source/import/executable string generic action; - local client permission denial is a typed result; - stale session/device advertisement cannot receive new actions; - revocation/disconnect cancels or resolves outstanding actions deterministically; - per-session action queues/rates/payloads bounded; - audit excludes clipboard/screenshot/private payload content where policy requires. ## Mandatory tests - hello/capability negotiation golden frames; - bounded capability count/name/metadata; - duplicate/unknown/oversized entries; - open-uri/open-app fake device action round trip; - wrong principal/device targeting denied; - disconnect/reconnect with in-flight action; - replay duplicate side effect according to idempotency policy; - cancel/action-result race; - malicious body attempting shell/import/eval rejected; - client says `admin` or fake server capability -> no authority gain; - one slow device-action client does not block another. ## Gates Protocol tests first, golden fixtures/fuzz, focused ZARA/1 device-action integration script, existing 91+ protocol regression gate, full Nix/repo and exact-head Actions. ## Acceptance The server can safely discover what an authenticated device can do and request one allow-listed typed action with a correlated result, without any generic arbitrary-code execution mechanism.

nsaspy referenced this issue

2026-08-29 10:40:44 +00:00

[ORDER] ZARA-000 — Repository repair and real-time voice roadmap #1

nsaspy referenced this issue

2026-09-04 14:39:04 +00:00

P0 research gate — Samsung assistant role and Android integration architecture #195

nsaspy commented

2026-09-04 14:39:32 +00:00

Owner

Android RAGE handoff after #172/#299 landed on master 08c2bef5e317065820da49f927ebcee0e16c9fd0: #173 is now blocked specifically on this issue's closed ZARA/1 capability/device-action contract. Android needs the minimal protocol surface promised here before it can implement enrollment/session continuity without inventing Kotlin-only semantics: versioned capability snapshot/change; typed action request/accepted/result/cancel/error; authenticated principal + target device/session binding; request/action/correlation ids; deadline/replay/idempotency fields; bounded schemas and deterministic disconnect/reconnect handling. Please keep those message families authoritative in the core protocol so Android can consume them directly. Android worker will not duplicate this plane in Kotlin.

Android RAGE handoff after #172/#299 landed on master `08c2bef5e317065820da49f927ebcee0e16c9fd0`: #173 is now blocked specifically on this issue's closed ZARA/1 capability/device-action contract. Android needs the minimal protocol surface promised here before it can implement enrollment/session continuity without inventing Kotlin-only semantics: versioned capability snapshot/change; typed action request/accepted/result/cancel/error; authenticated principal + target device/session binding; request/action/correlation ids; deadline/replay/idempotency fields; bounded schemas and deterministic disconnect/reconnect handling. Please keep those message families authoritative in the core protocol so Android can consume them directly. Android worker will not duplicate this plane in Kotlin.

nsaspy referenced this issue from a commit

2026-09-04 22:29:00 +00:00

RAGE #159: record protocol research

nsaspy referenced this issue from a commit

2026-09-04 22:29:00 +00:00

RAGE #159: freeze device-action design

nsaspy referenced this issue from a commit

2026-09-04 22:29:00 +00:00

RAGE #159: add one-shot implementation harness

nsaspy referenced this issue from a commit

2026-09-04 22:29:00 +00:00

RAGE #159: run one-shot implementation harness