Every member's key package is now resolved before anything is created. If one is
missing the room is not created at all, and the coordinator is told which member
to go and ask rather than being handed a room quietly short of people.
Previously the room was created and then whoever could be added was added, with the
rest collected into a list that only reached the log. Two things make that the wrong
trade here, and neither applies to ordinary group creation:
MarmotGroupData.adminPubkeys is baked into the epoch-0 GroupContext and names every
member of the ceremony. A room created without one of them therefore lists an admin
who is not in the MLS tree -- a group that disagrees with itself from its first
epoch, and MIP-01 leans on that list for most group operations.
And the id is derived from the shared key, so there is exactly one room per group at
this path. A half-created one occupies that address permanently; unlike a random id
there is no second one to retry with. Creating nothing leaves the retry clean.
The lookup moves ahead of group creation, which also means the batched add now
receives a list it knows is complete -- `addMembers` no longer has to reason about
absent key packages on this path.
`inviteAdmins` goes with it. Its job was resolving key packages and then adding
whoever it could; the first half moved into the precondition and the second is a
direct `addMembers` call.
The blocked members surface as `DkgRitualUIState.adminGroupBlockedOn`, carrying
names rather than public keys -- the action this prompts is asking a particular
person to open the app, so a name is what the coordinator needs. Cleared when the
button is pressed again, so a retry does not show the previous answer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
907dba3c3b