RFC: One identity, many bodies. Body registry, event leasing, and ghost-key repair

[Czaruno]

Evidence collected on a private two-machine fleet; identifiers anonymized. Machines are Machine A and Machine B, keys are Key-A through Key-G, the shared persona display name is N1, the local bound-record name is N2, the human owner is "the operator". Dates, timestamps, the buzz version, and upstream source references are verbatim.

1. Problem

Two distinct failures produce the same confusing surface: one agent name, unclear which machine answers.

A. Ghost keys. When a second install starts an account-scoped agent, it mints a new key instead of reusing the original. The result is two independent identities under one display name. On our fleet this happened twice: once across machines (the live duplicate pair) and once on the same machine across time (a replacement key minted on 2026-07-30 instead of a reuse).

B. No per-body control. Even when one key runs as designed, every body answers every event, and persona-level edits (model, prompt, name) apply to every body. There is no row in any UI that configures just one body, and no way to address one body from chat.

2. Evidence summary

Full receipts are in the appendices. The short version:

• A persona model edit made on one machine reconfigured the body on the other machine about 7 minutes later. Nothing on the second machine asked for or could have blocked the change (B.1, corroborated by A.1: the origin install carries the microsecond-precision local write, the receiving install carries the second-precision sync timestamp).
• Each machine's full-history log census proves the identically labeled management rows are different keys. Machine A has never run Machine B's key and Machine B has never run Machine A's key (A.2, A.3, B.2).
• Deleted duplicate keys leave addressable residue: four orphaned keys on this fleet are deleted at the relay (kind-5) yet retain live profiles, remain channel members, and absorb exact-name mentions (B.4).
• The kind-30175 persona event has no per-body fields, so a per-body overlay needs a new event or tag, not a tweak (B.5).

3. Design intent vs. current behavior

Buzz's stated model is that the key is the agent and machines are disposable bodies behind it. Current behavior contradicts this twice. Second installs create new identities instead of new bodies (Problem A). And when one key does span machines, the bodies are indistinguishable and jointly configured, so "disposable body" degrades to "unaddressable clone" (Problem B).

4. Proposal

Four parts, ordered so each is useful on its own.

4.1 Body registry. Each running body registers itself under the agent key: machine identifier, harness, and a capability manifest (which filesystem it can reach, which connectors are attached, which rail or role it carries, which model it runs). The identity then knows its bodies apart, and clients can display them.

4.2 Event leasing. A body claims an incoming event at the relay before acting. Other bodies see the claim and stand down. Note from B.5: the relay currently keeps no delivery bookkeeping at all (delivery_log is empty on the authors' fleet), so leases are the first such mechanism, not an extension of one.

4.3 Per-body config overlay. Model and prompt additions become settable per body while the persona stays shared for identity. B.5 documents a startup-ordering defect (agents.rs:393) where a body can re-pin before pending inbound persona events apply. The overlay must define its ordering against inbound sync or it inherits that race.

4.4 Ghost-key repair. A second install enrolls as a new body of the existing key instead of minting a new one. For duplicates that already exist, a merge path: consolidate to one key, and make relay deletion actually terminal so retired keys stop absorbing mentions and holding channel membership (B.4).

A note on 4.2: a cooperative client-side form (a claim event published by convention, no relay changes) is small enough that we can PR a proof of concept on request. It has a race window that relay enforcement would close later, but it demonstrates the mechanism.

5. Prior art

While drafting this RFC, the two bodies of one agent on the authors' fleet ran the proposed protocol manually over a group DM: single writer, explicit handoffs by mention, the unnamed body standing down. It worked, and it is exactly the leasing discipline of 4.2 at human speed. The need is real enough that users are already hand-implementing it.

---

Appendix A. Machine A forensics

A.1 Origin of the persona edit. Machine A's managed-agents store carries the shared persona (N1) with model claude-fable-5[1m] and updated_at 2026-08-12T03:39:10.014164+00:00. The microsecond-plus-offset format is a local write, marking this install as the edit's origin. Machine B received the same edit as a second-precision sync timestamp (B.1).

A.2 Log census. agents/logs on Machine A contains eight keys. Machine B's body key (Key-B) is not among them. That key has never run on this machine.

A.3 Live process-to-key mapping. At capture time Machine A ran three acp harness processes. lsof maps each to exactly one agent log file: Key-A and two unrelated agents. No process holds Key-B.

A.4 Name lineage. Recovery snapshots from 2026-07-26 show the display name N1 bound to Key-A on Machine A. Machine B's identically labeled row is Key-B (B.2). Same label lineage, two keys.

Appendix B. Machine B forensics (buzz 0.5.4)

B.1 One persona edit reconfigured a body on a different machine (2026-08-12). The operator switched the Machine A body's model to claude-fable-5[1m]. Machine B's store shows the same edit landing there: the persona record carries model claude-fable-5[1m], updated_at 2026-08-12T03:39:10Z. Second-precision UTC is the inbound-sync timestamp format, proving the edit originated on the other install. The Machine B body (Key-B) restarted at 03:46:33.551822+00:00 (microsecond+offset format, a local write) and its bound record now reads claude-fable-5[1m]. Net: an edit intended for one body reconfigured both, about 7 minutes apart, with no operator action on the second machine and no UI control that could have prevented it.

B.2 Full-history log census: the identically named management rows are different keys. agents/logs is never rotated on this install, so it is a complete census of every key that has ever run on Machine B. It contains exactly four: Key-B (live), Key-C (an unrelated live agent), Key-D and Key-E (deleted). Key-A has never run on this machine. So Machine B's management row labeled N1 can only be Key-B, while Machine A's row with the identical label is Key-A.

B.3 Three name fields, three owners: why chat and management UIs disagree. (a) The persona display_name (N1) is shared, syncs between installs via the kind-30175 event, and is what agent management shows, hence the collision. (b) The bound-record name (N2) is local, set at body creation; divergence from the persona is normal. (c) The relay kind-0 profile is republished by Desktop from the local record at agent start (the agent-managed-profiles flag verified ON on both installs), which is why the two keys are distinct in chat while identical in management. Any fix must say which of these three layers it changes.

B.4 The duplicate-key mint, observed twice on one fleet. Cross-machine: Key-A (Machine A) and Key-B (Machine B) are the live duplicate pair under one persona. Same machine, across time: Machine B previously ran Key-D as this agent's body; Key-B was minted 2026-07-30 as its replacement rather than a reuse. Fleet-wide there are exactly four such orphaned keys (Key-D through Key-G), all explicitly deleted at the relay (kind-5 on the agent record, and on the persona where one existed), yet they retain live relay profiles, remain channel members, and absorb exact-name mentions. That is the concrete case for the merge path: deletion today leaves addressable residue.

B.5 Relay schema facts that constrain the design (source-read at 0.5.3/0.5.4). The kind-30175 persona event publishes exactly six fields: display_name, model, parallelism, respond_to, runtime, system_prompt. Its parallelism and respond_to land locally as definition_*; effective per-body values exist only on bound records and are never on the relay. So the per-body config overlay in section 4 has no relay representation today and needs a new event or tag, not a tweak. Two adjacent facts for the leasing design: (1) websocket fan-out leaves zero server-side trace (delivery_log empty across all partitions on the authors' fleet), so leases would be the relay's first delivery bookkeeping, not an extension of existing bookkeeping; (2) known startup-ordering defect: a body that re-pins before pending inbound persona events apply starts on the stale definition (fix site agents.rs:393). Any overlay mechanism must define its ordering against inbound sync or it inherits the same race.

[wolfyy970]

Strong evidence. I think the registry is the right first move, but I would settle the objects before adding leases.

Buzz already has most of the intended split: a definition is the portable blueprint, an agent pubkey identifies the durable instance, and a body is one running generation on an execution target. The proposed per-body prompt and model layer sounds like an instance or deployment override, not body state. Otherwise a restart changes which configuration object owns it.

The registry should report target-owned facts: target and Project, applied definition revision, runtime generation, and observed capabilities. It should not become portable definition authority or carry credentials. The definition declares Skills and logical tool needs; the target binds connections and reports readiness.

Importing a definition should still mint a fresh identity by default. Reusing an existing key on another target is recovery or enrollment, not ordinary import, and needs an explicit owner-authorized flow.

I would also avoid making leasing universal. The owner may want one active target, failover, or deliberate fan-out. Make routing policy explicit first, then use a lease for the single-writer and failover modes.

This connects directly to #4999 for private agent state, #5575 for visible instances, #5328 for agent versus template edits, and #5443 for deployment handoff. I would land the registry and identity-repair boundary first. It gives the UI a truthful object to operate on and makes the later routing decision testable.

[ScaleLeanChris]

Additional validation from another real local profile: its managed-agent store currently has 11 duplicated display names, including two Fizz, two Bumble, and two Honey identities. PR #5575 makes those pubkey-backed identities visible, but the cards still cannot answer which machine will execute a turn. That confirms the registry is the next useful layer.

I agree with separating durable deployment configuration from ephemeral body state. A minimal first registry should expose, with owner-scoped visibility:

• stable body ID and agent pubkey
• owner-approved host label and execution target
• runtime generation and applied definition revision
• online and last-seen state
• declared capabilities and current readiness
• routing eligibility

It should not publish filesystem paths, connector credentials, or environment data. Host enrollment must be explicit and revocable because authorization of an agent identity does not automatically authorize every body to use local machine capabilities.

For later single-writer leasing, the smallest safe scope is community, agent pubkey, and incoming event ID. A cooperative claim event is useful as a prototype, but it cannot provide exactly-once execution under a race. Relay enforcement is the eventual correctness boundary.

[Czaruno]

Reposting this from the correct account; the original went up under the wrong handle and has been removed. The two replies above were written against this text, unchanged.

Two more observations from the authors' fleet, both from the same day as the appendices. The first amends B.3. The second is the reverse-direction case for B.1.

1. The kind-0 profile republish is not restart-bound

B.3 says the relay kind-0 profile is republished from the local bound record at agent start. That is incomplete. It also fires on the persona-edit path, from the still-running body, before any restart.

Timeline for 2026-08-12, all times UTC, two machines:

Time	Event	Source
15:06:11.368592+00:00	persona (kind 30175) written locally on Machine B, microsecond+offset format	Machine B store
15:06:11Z	same persona revision at the relay	relay events
15:06:12Z	Key-B publishes kind 0, display_name changes from N2 to N1	relay events
15:06:22.096Z	Machine B body begins shutdown	Machine B process log
15:06:23.127Z	stop line, already reading N1	Machine B process log
15:06:23.186Z	new process starts and re-pins	Machine B process log

The republish lands eleven seconds before the restart, so it came from the old body on the persona-edit path. The local persona write also overwrote the bound-record name: the 03:46:33Z process lines read N2, the 15:06:23Z stop line reads N1.

The same day's earlier edit is the control. The 03:39:10Z persona edit reached Machine A by inbound sync (B.1). Inbound sync does not touch the local bound-record name, so name and profile still agreed and nothing was republished. Key-A's most recent kind 0 is still 2026-08-02. A local edit renames the body and republishes; a synced edit does neither.

That matters for the RFC because B.3 names chat as the one layer where the two keys stayed distinct. A local persona edit removes it. Key-B had carried N2 in chat since 2026-07-30, and after 15:06:12Z both keys present N1 to every client, so the operator's sidebar shows three identically labeled rows (two 1:1 DMs and a group DM). The trigger was an ordinary model change in the persona editor. A per-body overlay (4.3) needs to state what it does to the bound-record name or it will propagate names the same way.

Smaller detail from the same event: the republished profile dropped the about field that Key-B's previous kind 0 carried, so the republish composes from the local record instead of merging with the existing profile.

Sourcing: timestamps from the relay event log and from process logs on both machines. We have not read the republish code path, so the mechanism is inferred from timing.

2. Persona sync runs in both directions, with the origin and receiver signatures reversed

B.1 documents one direction. The same fleet ran the reverse eleven hours later.

	03:39 edit	15:06 edit
origin install	Machine A	Machine B
origin record	03:39:10.014164+00:00	15:06:11.368592+00:00
receiving install	Machine B	Machine A
receiving record	03:39:10Z	15:06:11Z
receiver body re-pin	03:46:33 (about 7 min)	15:15:39 (about 9 min)
origin body re-pin	not captured	15:06:23 (12 s)

Microsecond+offset marks the local write and second-precision Z marks the inbound copy, in both directions. The origin body re-pins in seconds while the receiving body keeps running on the old configuration for minutes. For that window one identity has two bodies on two different models, and nothing in any client surfaces the difference.

[Czaruno]

Thanks both. Taking the ordering point: registry first, leasing later.

4.2 was wrong to make leasing universal. Revised shape: the owner declares a routing policy per agent (single active target, failover, or deliberate fan-out), and a lease enforces only the first two. Under fan-out there is nothing to claim. @ScaleLeanChris, agreed on scope (community + agent pubkey + event ID), and agreed that a cooperative claim event is a prototype while relay enforcement is the correctness boundary.

@wolfyy970 on 4.3, agreed it is a deployment override rather than body state, and #5328 is where it belongs. FIELD_OWNERS and emitAgentFormDiff already route fields to owning layers, so the overlay can be one more layer in that model. Our rename incident is a field-routing failure of that exact class: a model change wrote a display name onto the bound record.

One new constraint on the 4.1 field set, from the comment above. The kind-0 republish dropped the about field the previous profile carried, because it composes from the local bound record instead of merging with the profile already on the relay. So any capability field the local record does not model disappears on the next local persona edit. The registry needs merge semantics, or its own event outside that write path. #4999 resolves the overlay before every stale-disk republish site including the personas/update.rs rename, so ours is the adjacent case where an unmodeled field vanishes. Offering it as a test case for that PR. We have not read the diff, so it is not a defect claim.

Withdrawing half of 4.4: #4999's fresh-device materialization is the enrollment path we asked for. The relay-side half stands. Four keys on this fleet are kind-5 deleted and still hold profiles, keep channel membership, and absorb exact-name mentions. None of the four PRs touch that.

Two links we should have had in the original. #2648 is problem A on a different fleet three weeks earlier, and its expected-behavior line asks for 4.4 in the reporter's own words. #3554 wants machine-level enrollment for self-host, which is 4.1 approached from the other side. Both converge with this RFC and we would rather see them merged into one shape than run in parallel.

[jcg-git]

Cross-referencing from #2648 (the issue this RFC already links as "problem A on a different fleet") — we hit a version of the 4.4 ghost-residue problem too and traced it to a specific cause, which might narrow the fix.

We cleaned up several duplicate/orphaned identities using buzz channels remove-member (not raw Nostr kind-5 deletion), and afterward verified they don't reappear in mention resolution. The function that resolves bot mentions — get_bot_members() in crates/buzz-db/src/channel.rs — filters:

WHERE cm.role = 'bot' AND cm.removed_at IS NULL

and joins channels with c.deleted_at IS NULL. Everything we removed via remove-member correctly sets channel_members.removed_at, so it's excluded from this query — confirmed directly against the database, no residue, no absorbed mentions.

Our working theory (inferred from reading this code path, not from reproducing your exact scenario — we haven't tested kind-5 deletion specifically): kind-5 is a protocol-level "delete this event" instruction that has no reason to touch Buzz's own channel_members.removed_at column, since that's Buzz-specific application state, not something the Nostr deletion event model knows about. If the ghost keys in 4.4 were removed via kind-5 (directly, or through a generic Nostr client/tool) rather than through Buzz's own remove-member path, that would fully explain the residue — the deletion happened at the protocol layer while the row Buzz actually queries for membership/mentions was never touched.

If that holds, it suggests two possible fixes at different layers: either the registry proposal here handles it structurally, or get_bot_members()'s existing removed_at-based filtering could be made to also treat kind-5-deleted identities as implicitly removed, closing the gap without waiting on the larger registry work. Happy to help verify either way — we have a reproducible before/after setup (isolated relay, no shared state) if it's useful for testing.