core(identity): identity-first ActorId — AID/SAID/delegation, key-expr addressable

[joeldsouzax]

Part of the core-rebuild epic — follows the shared rigor contract there. The one net-new design; the reference (kameo) is the wrong model here.

Component

src/actor/id.rs (~564 LOC), rebuilt as the ground-floor inversion.

Learning & discussion

The core realization of this whole plan: kameo is process-first / identity-incidental — an opaque AtomicUsize counter, with the global part (peer_id) hidden behind #[cfg(feature = "remote")]. We are identity-first / process-embodies-identity, and identity is core, not behind a transport flag.

• A local-only actor = a bare local handle (the counter). A dataspace actor earns a KERI identity when it joins.
• Three separated concerns: KERI = authenticity, Zenoh key-expr = addressing, nexus = ordering/consistency.
• Key-expr is a contact tree: agency/<user-aid>/<domain>/<aid> (e.g. agency/<user-aid>/agent/<aid>), and ** locates an identity anywhere.
• Authority is a KEL-backed DAG, not the tree: an AID delegated to X by Y has two edges (controller X, delegator Y); multisig AIDs add member+threshold edges. The path is just contact; the truth lives in the KEL.

Existing crates

keriox (Rust KERI), cesride/CESR encoding. Verify key-expr canonicalization (CESR/Base64URL chars vs Zenoh-reserved * $ ? #). Replace the local-handle AtomicUsize + try_into().unwrap() with AtomicU64 / portable-atomic (the #88 concern — platform-dependent width + banned unwrap).

Research — best algorithm/approach

KERI whitepaper (S. M. Smith) — AID/SAID, cooperative delegation, multisig group AIDs; CESR spec (confirm exact arxiv id during research). Self-addressing identifiers; Zenoh key-expr + ** identity lookup. This bleeds into M4 (KEL modelled as a nexus aggregate → an actor's identity is itself maintained by an actor).

Testing — hard as fuck

Identity invariants (self-certifying verify with no registry), key-expr validity/canonicalization, delegation-DAG (X≠Y controller/delegator; multisig threshold), boundary. loom on the local-handle counter (ties #88). DST over concurrent identity mint/lookup. Mutation: cargo-mutants, zero survivors.

Reframes / absorbs

#2 (ActorId: libp2p PeerId → Zenoh key-expr) — superseded and expanded here. Related: #88 (loom the counter), M4 (KERI identity on the edge).

[joeldsouzax]

Design direction — entity migration = KERI rotation (identity semantics for placement)

Surfaced while designing the activation/passivation runner (#20). This card owns the decision because it's an identity-semantics question; #20 only references it.

The tension

The virtual-actor model (#20) wants on-demand activation + passivation + cross-cluster migration, and it wants stable identity across all of that (identity is the routing key + persistenceId + nexus stream key). But if placement is encoded in the identifier itself (bombay/<cluster-aid>/<type>/<aid>, the coordinator-free static-placement idea), then "move to a new cluster" naively looks like it needs a new identifier — which breaks identity continuity. Resolving this is an identity decision, not a runtime one.

Decision direction — migration is a rotation, not a delegation

The two KERI primitives do different jobs:

• Delegation (dip / drt) mints a distinct delegate AID whose authority roots in the delegator. It models the hierarchy ("this cluster is authorized to host actors") and the initial placement (an actor is born as a delegated AID under its cluster). It does not preserve identity across a move — re-delegation reads as a new delegate.
• Rotation (rot) preserves the AID and changes the key state. The identifier is stable across rotations by design.

Identity continuity therefore points at rotation. And it's literal, not metaphorical: if key custody follows the cluster (the cluster signs on behalf of the actors it hosts), then moving to a new cluster requires a rotation because the new cluster holds different keys — the signing authority physically moves.

Consequences:

• AID stays constant → routing identity, persistenceId, and the nexus stream all survive the move.
• The rotation event carries the new cluster (anchored data / seal in the KEL) → placement changes inside a signed, KEL-ordered event.
• Because the KEL is totally ordered and signed, that rotation is the authoritative "who owns it now" record — it replaces Akka's ShardCoordinator with an event in the entity's own log. No coordinator, no split-brain dependency, self-certifying.

This dissolves the tension: the AID is stable; placement is the current key state in the KEL, not the identifier string. Routing derives the key-expr from the entity's current placement (looked up / cached); the AID never changes.

Granularity — pick the primitive by what actually changes

What changes	KERI primitive	Notes
Node within a cluster	none	handled by the runtime layer — Zenoh liveliness claim + nexus OCC (#20). No KEL event.
Cluster, custody moves (different signing authority)	rot	the heavy, authoritative case — "rot with a new cluster".
Placement metadata only, custody unchanged	ixn (interaction event, anchors data without rotating keys)	lighter; likely rare cross-cluster.

Boundary — KERI gives authority, not mechanics

The rotation tells you who legitimately owns the entity now — authoritative, ordered, coordinator-free. It does not by itself solve "how do in-flight messages not drop while the old cluster drains and the new one takes over." That drain/handoff is separate runtime plumbing (deferred hard part in #20). KERI supplies the trigger + the authority; the buffer-and-handoff supplies the no-loss mechanics.

Confidence flags (facts-only)

• Confident: rotation preserves the AID (stable identifier); delegated inception mints a distinct delegate AID; KELs are signed and totally ordered.
• To verify before committing wire details (M4 KEL-as-nexus-aggregate work): exact re-delegation semantics; whether rot vs ixn is the right granularity for placement; the precise seal/anchor mechanics for carrying placement in a rotation. Do not assert KERI wire format until checked against the KERI spec + the M4 KEL model.

Cross-links

Consumer of this decision: #20 (activation/passivation — derives routing key-expr from current placement; treats a rot as the authoritative migration trigger). Static placement + two-tier single-activation context: #20. Geo-locality: #27.

[joeldsouzax]

UPDATE — local slab-key ↔ global AID bridge (completes the two-tier identity)

Complements the earlier "migration = KERI rotation" note. The ref-model (#117) + registry (#119) decisions complete the identity model as two tiers:

Tier	Identity	Role
Local	the sharded-slab (index, generation) key (#117)	Copy, liveness-bearing, node-local, cheap. Hot path + local death-detection. Ephemeral — a passivation reap kills it.
Global	the KERI AID / Zenoh key-expr	durable, cross-node, the persistenceId. Addressing, persistence, migration. Stable across passivation.
Bridge	the papaya registry (#119): AID → local slab key (for resident actors)	resolves a durable identity to the current in-memory slot.

How they move together

• Passivation (feat: matching status -> interest-driven (lazy) actors #20): reap the slot → the local key dies (its staleness is the passivation signal, design: link-death — per-actor liveliness vs per-node + explicit death #8); the AID stays stable. Reactivation mints a new slot + re-binds AID → new key in the registry. So the local key is meant to churn; the AID never does.
• Migration: a KERI rotation changes the AID's key-state/owning-cluster (prior note) — the global identity's durable event, not the local key.

Reframes #2

ActorId: PeerId → key-expr (#2) is the global tier. The slab key is the local tier. Both are "an actor's identity" at different layers — the key-expr addresses across the dataspace; the slab key indexes the resident actor in-process. Neither alone is "the ActorId"; identity is the pair, bridged by the registry.

Cross-links: local key/slab #117 · AID→key registry #119 · passivation cycles the local key #20 · death = stale local key #8 · migration = rotation (above) · ActorStopReason carries the (global) ActorId #116/#120.

[joeldsouzax]

Revised by the adversarial review (#122)

With the arena dropped (#117 reversed), the local identity is not a generational slab key. Corrected two-tier:

• Local id = a generated id (kameo-style monotonic ActorId) — no generational-liveness semantics; liveness is the channel closed-flag + push-notify, not a key generation.
• Global identity = KERI AID / Zenoh key-expr (durable, cross-node, persistenceId) — unchanged.
• Bridge = the papaya registry (core(registry): rebuild from kameo reference — local name to actor lookup #119): AID → WeakActorRef (erased weak handle) for resident actors.
• Migration = KERI rotation and the stable-AID-across-passivation model are unchanged.

[joeldsouzax]

Note — the KERI identity actor is the canonical cross-tier actor (settles #9)

The client hosts its own KERI identity actor, so this actor runs on BOTH the multi-threaded server (Send) and the single-threaded constrained client (non-Send). That confirms the MaybeSend decision (#9, option a — cfg-gated marker alias; see #116/#114): the identity actor is the same code on both tiers, which is exactly why the actor trait's Send bound must be tier-abstracted. Canonical test: keri_identity_actor_compiles_and_runs_on_both_tiers.