Creating a NIP-17 group sends nothing to anybody. Membership under NIP-17 *is*
the p-tag set on each message, so the group only materialises on the other
members' devices when the first gift wrap lands. The chat-message branch of the
inbound path knows this and builds the room from the arriving payload's p-tags;
the ChillDKG branch did not. It looked the room up, found nothing, logged "DKG
payload for unknown chat room" and dropped the message.
That is fatal for the flow the feature is reached through.
SelectChatRoomTypeViewModel.createNip17ChatRoom writes the room and its
participants locally and navigates straight into the chat without publishing
anything, and ChatRoomDetailScreen offers "Shared Key" for exactly these rooms
(mlsGroupState == null). So "create group -> Shared Key -> Start key ceremony"
makes the ritual's own proposal the first event the group is ever heard of, and
every recipient dropped it. Nobody joined, and the coordinator sat on one host
key -- its own -- forever.
getOrCreateNip17ChatRoom builds the room the way the chat branch does: the
payload's p-tags plus its sender. That set is the aggregate ChatRoom.id is
derived from in the first place, so any payload that routes here already carries
the whole membership and there is nothing else to wait for. Placeholder profiles
are inserted first because both ChatRoom.userPublicKey and
Participant.participantPublicKey are foreign keys onto Profile, and a payload
whose membership does not include this device is refused rather than used to
build a room we are not a member of.
Deliberately not shared with the chat branch: that block also queues relay-list
and profile synchronisation per participant, which is best-effort enrichment
tangled into the surrounding loop's profilePublicKeysToSync map. Lifting it out
is worth doing on its own, not inside a fix whose job is to make the ceremony
reachable at all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
739314ccb4