feat(desktop): support provider-custodied agent keys - #7444

Why

A remote backend may need to create and keep an agent’s signing key. Buzz must not receive that private key, and it must not switch custody modes after telling the user which process will hold it.

What

Providers can advertise a narrow register and attest handshake. Buzz stores the returned public identity, records provider custody, and keeps attestation retryable.

The create request now carries the custody mode shown after the provider probe. Creation fails closed if fresh negotiation no longer matches.

How

Desktop validates the provider’s protocol response before the UI uses it. It performs all local checks available before registration, including owner-key, persona, team, relay, and behavior checks.

Providers without both capabilities keep the existing deploy flow. Provider-custodied agents skip local keyring and spawn paths.

sequenceDiagram
    actor User
    participant Buzz as Buzz Desktop
    participant Provider as Provider executable

    User->>Buzz: select a remote provider
    Buzz->>Provider: info
    Provider-->>Buzz: validated capabilities
    Buzz-->>User: show who will hold the private key
    User->>Buzz: create agent + observed custody mode
    Buzz->>Buzz: validate local inputs and selected custody
    Buzz->>Provider: register (name and config)
    Note over Provider: Create and retain private key
    Provider-->>Buzz: agent id + public key only
    Buzz->>Buzz: save public identity as attestation pending
    Buzz->>Provider: attest (public key + owner authorization)
    Provider-->>Buzz: acknowledged
    Buzz->>Buzz: clear attestation pending
    Buzz-->>User: agent created and ready

Risk

This changes only the unreleased remote-provider path. Final disk persistence can still fail after a provider returns an identity, so providers should expire registrations that never receive attestation.

Testing

Manually ran the full create path against a protocol-v1 provider on the latest commit.

Created a fresh provider-backed agent and verified that the provider recorded one successful REGISTER and one successful ATTEST for the same backend agent ID. Buzz persisted the provider-issued public key with provider custody, active state, no pending work, no error, and no local private key.

Restarted Buzz and confirmed the same agent remained active with the same public key and provider backend. The provider still showed exactly one registration and one attestation, so restart did not duplicate either call.

Bigger picture

Provider-side expiry for unattested registrations remains useful cleanup. Stable registration retries are outside this slice and are not required by this create flow.

Update Sep 8, 15:29: Scoped provider attestation to the active Buzz community.

• attest now carries community_url during creation and each later provider-backed start.
• Creation snapshots relay and owner together. A later enrollment failure no longer reopens global attestation.

Generated with Codex