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>
This is a Kotlin Multiplatform project targeting Android, iOS, Desktop (JVM).
-
/composeApp is for code that will be shared across your Compose Multiplatform applications. It contains several subfolders:
- commonMain is for code that’s common for all targets.
- Other folders are for Kotlin code that will be compiled for only the platform indicated in the folder name. For example, if you want to use Apple’s CoreCrypto for the iOS part of your Kotlin app, the iosMain folder would be the right place for such calls. Similarly, if you want to edit the Desktop (JVM) specific part, the jvmMain folder is the appropriate location.
-
/iosApp contains iOS applications. Even if you’re sharing your UI with Compose Multiplatform, you need this entry point for your iOS app. This is also where you should add SwiftUI code for your project.
Build and Run Android Application
To build and run the development version of the Android app, use the run configuration from the run widget in your IDE’s toolbar or build it directly from the terminal:
- on macOS/Linux
./gradlew :composeApp:assembleDebug - on Windows
.\gradlew.bat :composeApp:assembleDebug
Build and Run Desktop (JVM) Application
To build and run the development version of the desktop app, use the run configuration from the run widget in your IDE’s toolbar or run it directly from the terminal:
- on macOS/Linux
./gradlew :composeApp:run - on Windows
.\gradlew.bat :composeApp:run
Build and Run iOS Application
To build and run the development version of the iOS app, use the run configuration from the run widget in your IDE’s toolbar or open the /iosApp directory in Xcode and run it from there.
Learn more about Kotlin Multiplatform…