65e4a3acc0
No invite to a Marmot room has been delivered since1700e6d. The Welcome was built, hashed, queued and logged exactly as before -- and then refused one step short of the relay, by a guard that had no idea it was looking at one. **The guard.**1700e6d("send a direct message into the group, wrapped for one member") added a backstop at the top of sealGiftWrapPayload: val chatRoom = database.chatRoomDao().findChatRoomById(giftWrapPayload.chatRoomId) if (chatRoom?.chatRoom?.mlsGroupState != null) { log; return } Its reasoning is sound and still is: a Marmot direct message is a genuine, correctly signed NIP-59 gift wrap, indistinguishable from one this path would be right to publish, and the only thing keeping it off a relay is that it never becomes a GiftWrapPayload row. Refusing at the seal as well means a future caller cannot walk one onto a relay by accident. **Why it caught the Welcome.** MarmotOutboundDao.deliveryWelcome writes a GiftWrapPayload with chatRoomId = nostrGroupId -- the MLS room's own id, which by construction has mlsGroupState set. Every Welcome therefore matched a refusal keyed on mlsGroupState alone. There is no Welcome that does not: the tag identifying the room is the whole point of the event. The kind:444 arm further down -- the one that wraps only for the participant who published the referenced key package -- became unreachable, which is why nothing in the logs said "welcome" at all. **Why it went unnoticed.** The room reaches the correct state on the inviter's side whether or not the Welcome goes out: addMember advances the epoch, the group state is persisted, the Participant row exists, and "Invited X to chat" is written to the transcript. From the coordinator's side an invitee who never heard anything is indistinguishable from one who joined -- recorded as a known gap in docs/shared-key-ceremony.md, and this is what was behind it. **The second-order damage.** observeUnsealedGiftWrapPayloads is SELECT * FROM GiftWrapPayload WHERE publicKey = :p AND giftWrapSealId IS NULL collected as a Flow<GiftWrapPayload?> -- one row at a time. giftWrapSealId is only ever set inside persistAndBroadcastGiftWrap, which the guard returns before reaching, so a refused payload stays unsealed forever and sits at the head of that queue. The first Welcome a user queued blocked every gift wrap behind it, in every room, for the life of the install. **The fix.** Kind first, room second. MIP-02 addresses kind:444 to someone who is not yet in the group and holds no key to read a kind:445 -- a relay-borne gift wrap is the only way to reach them, and deliveryWelcome queues one on purpose. Every other kind is refused exactly as before. sendChatMessage already branches on mlsGroupState before writing a payload, so an MLS room's messages never arrive here anyway; the guard stays as the backstop it was meant to be. docs/marmot-direct-messages.md claimed "An MLS room should never produce a NIP-17 gift wrap for any reason". That premise is what made the guard look complete, so it is corrected rather than merely amended, with the test to apply when adding a kind to the exemption: can its recipient read a kind:445? If so, it does not belong on this path. **Not fixed, deliberately.** A refusal still leaves the payload unsealed and head-blocking. That is now unreachable -- nothing else can queue a payload against an MLS room -- but it remains a trap for whatever gets refused next. Marking a payload refused needs a state the schema does not have, so it is left for its own change rather than smuggled in here. Verified: :composeApp:compileDebugKotlinAndroid succeeds. No test covers this -- DatabaseChatRepository is Room-backed, and Room-backed code has no unit test harness in this project. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
mantra docs
Notes on the parts of this app whose behaviour is not recoverable by reading the code alone — where the reasoning lives in a protocol, a failure mode that is silent, or a decision that looked arbitrary and was not.
| document | covers |
|---|---|
| shared-key-ceremony.md | ChillDKG over NIP-17: the rounds, the approval gates, the chat transcript, participant ordering |
| shared-key-derivation.md | deriving further keys from the group's threshold key with FROST tweaks — why not BIP32, why no chain code, and the one rule that must not be broken |
| marmot-membership.md | how members join an MLS group, and the epoch race that makes a missing member look like a successful invite |
| marmot-direct-messages.md | a one-to-one message inside a group as a stock NIP-59 gift wrap — what its MIP-03 carve-out costs, why the sender cannot read their own, and the one query that would broadcast it |
| mls-skipped-keys.md | why a group event that arrives a moment late is dropped for good, which flows trigger it, the quartz fix, and the partial mitigation in this app |
| long-running-sync.md | the chat subscriptions that stay open instead of pulling once per screen — why the request queue could not simply hold one, and how the group filter follows the room list |
| dead-code.md | code in the sync and relay stack that nothing calls, why each piece is still there, and which of it is a bug rather than a leftover |
Start with the ceremony if you are new to this area; the Marmot notes all assume it. Read the skipped-keys note before debugging any "the other device never got it" report — it is silent, and it looks like every other kind of delivery failure. The sync note stands alone, and the dead-code inventory reads as a follow-up to it.