66119f34df
A translation covered the chapters that existed when it was proposed, and nothing put a later one into it. The chapter was signed, every device applied it, and in every translation of that artifact it simply was not there -- no translation chapter to hang translated chunks off, so the text could not be worked on at all. Invisible from the translation, which lists what it has. Adding a chapter now proposes twice: the chapter and its chunks as before, then a second session carrying one translation chapter per translation of that version. **Why a second session rather than more items on the first.** Because the two would compete for one batch. A session signs at most MAX_BATCH_SIZE events, a chapter is capped at MAX_CHUNKS_PER_CHAPTER paragraphs against it, and every dialect the group works in would have taken one of those places away. How long a chapter may be and how many languages it is read in have nothing to do with each other, and sharing the cap would have moved the first under whoever was typing whenever somebody else did the second. Nothing had to be built for a room to run two at once. Every FROST message carries the session it belongs to and everything is looked up by that id, so there is no "current" session on a room -- `liveSessionForChatRoom` is a fallback for a screen opened without one, not state the protocol keeps. And `itemsOver` mints an independent nonce seed per item per session, so two sessions running together can no more share an `R` than two items of one batch can. The cost is one more approval for the admins. **Naming a chapter nobody has signed yet.** The scaffolding needs the chapter's id, and the chapter is not signed for as long as a quorum takes. It does not have to be: the id is settled when the session opens -- it is the hash every signer puts their share behind -- so the second proposal reads the first session's item 0. `FrostSigningRepository.unsignedEvents` is that read, the counterpart of `signedEvents`, which by design gives back nothing until the group has answered. **What two sessions give up.** A batch is all-or-nothing; two batches are not. If the chapter fails to reach a quorum while its scaffolding succeeds, those are valid signatures over rows naming a chapter nobody has: they fail a foreign key on the way in, `applySignedEvent` logs them, and they never become rows. Nor is it recoverable -- a re-proposed chapter is a different id -- so those signatures are simply spent. Harmless, and the reason the next commit adds a catch-up. It also does not close the race. A chapter and a translation proposed at the same moment see neither the other, because both read what exists when they are proposed. No snapshot can fix that, which is again the catch-up's job. **Failure is one-way.** Scaffolding runs before navigating, not after: the route this screen sits on is popped on success, which clears the view model and takes `viewModelScope` with it, so anything launched afterwards would be cancelled somewhere in the middle. And a failure to open it is logged and swallowed -- the chapter is what was asked for and has already been proposed, and losing it because its scaffolding could not be opened would be the wrong way round. **The chapter's index, once.** It was read inline into the event; it is now a val, because the scaffolding has to place the translation chapter at the same one the chapter is signed at. `MantraTranslationArtifactVersionDao.getTranslationsByArtifactVersionId` is the new read, narrower than the by-artifact one: a chapter belongs to a version, and a translation of an older version is not one it is in. **Tests.** Three in TranslationBatchProposalJvmTest, against a real database and a real ceremony. Two sessions coexist in one room with the chapter's own batch untouched -- the chapter and a chunk per paragraph, whatever the translations -- and every scaffolded chapter naming the chapter of the other session. The caps do not compete: a chapter of the longest allowed length still proposes with eight translations waiting for it. And no two items across both sessions share nonce material, which is the one thing concurrency could actually get wrong; seeding an item's nonce from its index instead is caught here and by `SignedGroupKeyStateTest`, which already held the within-batch half of it. Not covered: that `AddChapterViewModel` opens the second session, which is plumbing across two dispatchers over templates these tests already pin. 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…