fix(collab): the dev bridge's provisionEntity now fans the DEK out to siblings - #471
Merged
Merged
Conversation
… 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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.provisionEntityminted a DEK viadekStore.persistand stopped. The production create path (createEntityWithDek) instead callsinstallEntityWrap, 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-deviceskept failing onno DEK for entity ent_lan_briefwhile 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:
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.LiveSyncEnginederives#inboxonce in its constructor fromctx.devicePubandstart()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:packagesclean;collab/23 files / 194 tests passing.🤖 Generated with Claude Code