Skip to content

fix(collab): the dev bridge's provisionEntity now fans the DEK out to siblings - #471

Merged
th3-br41n merged 1 commit into
mainfrom
fix/collab-harness-provision-fanout
Aug 3, 2026
Merged

fix(collab): the dev bridge's provisionEntity now fans the DEK out to siblings#471
th3-br41n merged 1 commit into
mainfrom
fix/collab-harness-provision-fanout

Conversation

@th3-br41n

Copy link
Copy Markdown
Contributor

Found while running the two-device dogfood against the 10.3c producers. This is not the whole story — read the second half.

The defect

SharingEngine.provisionEntity minted a DEK via dekStore.persist and stopped. The production create path (createEntityWithDek) instead calls installEntityWrap, and the 10.3c sibling fan-out hangs off exactly that hook.

So every entity the collab dogfood harness created left this device as the only DEK holder, and no dogfood session could reach the 10.3c producer at all. The harness could not have produced evidence about the thing it exists to test.

This is why collab/012-lan-two-devices kept failing on no DEK for entity ent_lan_brief while every transport assertion passed. The LAN link was never the problem — the harness simply never asked for a wrap.

What it revealed

With this in, the producer is reached and is correct. Instrumented:

fanOut ent_lan_brief v1: roster=2 self=NXup0Zqb rows=KOB3NLjp:x,NXup0Zqb:x

One rostered sibling carrying an X25519 key, self excluded, a real ordinal — sealed and emitted to the identity inbox.

The spec still fails, on a separate product bug this change exposed rather than caused (filed as F-492): the joining device stays subscribed to its pre-pairing identity inbox, so the wrap lands on a channel it no longer listens on.

desktop emits    route=inbox:Se7lyssN…
desktop subscribes     inbox:Se7lyssN…   ✅
laptop  subscribes     inbox:Xmpqw4yo…   ❌  (its pre-pairing identity)

LiveSyncEngine derives #inbox once in its constructor from ctx.devicePub and start() is guarded, so it subscribes exactly once; the engine is rebuilt only on vault-session activation, and pairing happens with the vault already open.

Not fixed here on purpose — that is a sync/crypto change and wants its own rung plus /security-review + /pentester, per the gates rule.

Consequence for the roadmap

Multi-device sync stays in "In progress". It is not demonstrable between two real machines yet, and green unit tests do not change that.

typecheck:packages clean; collab/ 23 files / 194 tests passing.

🤖 Generated with Claude Code

… siblings

`SharingEngine.provisionEntity` minted a DEK via `dekStore.persist` and
stopped. The production create path (`createEntityWithDek`) instead calls
`installEntityWrap`, and the 10.3c sibling fan-out hangs off exactly that
hook — so every entity the collab dogfood harness created left this device
as the only DEK holder, and no dogfood session could reach the producer at
all.

This is why `collab/012-lan-two-devices` kept failing on `no DEK for entity
ent_lan_brief` while every transport assertion passed: the LAN link was
never the problem, the harness simply never asked for a wrap.

With this, the producer is reached and behaves correctly — instrumenting the
fan-out shows a rostered sibling with an X25519 key and a real ordinal:

    fanOut ent_lan_brief v1: roster=2 self=NXup0Zqb rows=KOB3NLjp:x,NXup0Zqb:x

The spec still fails, on a separate and now precisely-located product bug:
the joining device stays subscribed to its PRE-PAIRING identity inbox, so
the wrap is delivered to a channel it no longer listens on. Filed as a
follow-up rather than fixed here — that one is a sync/crypto change and
wants its own rung and gates.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@th3-br41n
th3-br41n merged commit 9a83c18 into main Aug 3, 2026
3 checks passed
@th3-br41n
th3-br41n deleted the fix/collab-harness-provision-fanout branch August 3, 2026 21:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant