Skip to content

Fleet ## Parent #3

Description

@Jhazy33

Parent

#1 (fleet spec)

What to build

A machine's name is settable from both ends and safely carried on the wire. Daemon: pew2 pair [--name] (default os.hostname()), persisted, re-announced via the existing ProviderAnnounce.machine. App: a sealed SetName frame renames a machine in place — and unpair is real revocation: a sealed rotate/forget request makes the daemon rotate the pairing token (existing rotation path). Name validation runs at both trust boundaries (≤64 chars, control/bidi stripped, empty/whitespace rejected) before any announcement or notification title sees the value. The app only sends new frame types after receiving machine metadata from that daemon (skew gating). Demoable: a round-trip test renames a machine; an adversarial test proves an unproven sender cannot.

Acceptance criteria

  • pew2 pair --name X persists X and the next announce carries it; default is the hostname
  • Sealed SetName from a proven paired app sender renames and re-announces; idempotent; rate-limited
  • Adversarial: SetName from an unproven sender refused; replayed frame refused
  • Name validation at daemon and app boundaries: rejects empty/whitespace-only, >64 chars; strips control and bidi-override characters
  • Unpair request rotates the pairing token daemon-side; the old key no longer admits the phone
  • Skew: new app → old daemon never sends the new frames before metadata arrives, so unknown_message cannot clear requests or kill push registration; old app → new daemon unaffected
  • Existing wire tests stay green; new frames are optional-on-arrival (absent = older peer)

Blocked by

None — can start immediately.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions