The Proposals button sat behind `mlsGroupState == null`, so it was offered in
NIP-17 rooms and withheld from Marmot ones. That is the wrong way round rather
than a gap: FrostSigningManager signs "in its #admins room", and an #admins
room is a Marmot group.
**Where a group actually proposes.** `FrostSigningManager.broadcast` writes a
signing message as an unprocessed `MarmotInnerEvent`, which `NotaryViewModel`
MLS-encrypts and broadcasts as a kind:445 -- "the same path every other event
in a Marmot group takes, which is why this needs no transport of its own". A
NIP-17 room holds no MLS state for that path to use, and since 9107b81
`encryptAndSendMarmotInnerEvent` throws `MarmotMissingChatGroupException` on
exactly that rather than silently doing nothing. So the button was shown in the
one kind of room where a proposal cannot leave the device, and hidden in the
kind where every proposal this app has made actually lives.
The Shared Key button beside it keeps the gate, and the comment above it keeps
its wording, because for a ceremony the gate is right: ChillDKG runs over NIP-17
because it has to -- its participants are not yet a Marmot group, and its whole
purpose is to produce the key one would be keyed on -- so a room that already
has an MLS tree is not a room a ceremony can run in. The two buttons stand next
to each other and answer different questions; only one of them is about the
transport the group already has.
**Not gated on whether the room can sign.** A plain DM now shows Proposals too,
and opening it says "This group has not been asked to sign anything yet."
Gating on `FrostSigningRepository.canSign` would mean threading that repository
into `ChatRoomDetailScreen` for one button's visibility, and the Shared Key
button it sits beside is not gated either -- a room with no ceremony behind it
still offers to hold one. An empty list is a truthful answer to a tap; an
absent button is no answer at all to a member wondering where the proposals
went, which is the complaint this commit starts from.
**One row is not the queue.** Tapping a signing line in the transcript went
straight to that session, and the list was reached only when the line predated
chat rows naming their session. That is right while the reader has one decision
outstanding and wrong the moment they have two: the second proposal is not in
the transcript beside the first -- it may be pages up, or have arrived while
they were reading -- so answering the one they tapped and leaving looks exactly
like being done. A group proposing a chapter and the translation that depends
on it is two sessions at once, which is the case `ProposalListScreen` exists
for; the transcript was still handing over one of them and calling it the
answer.
**Only for a row that is itself waiting.** `hidesOtherDecisions` asks two things
rather than one: that the tapped session is waiting on this member, and that it
is not the only one. A line about something the group has already signed still
opens that session directly. A reader who taps history is asking to see what was
signed, and meeting that with the queue would be substituting a general answer
for a specific request -- the same fault as the one being fixed, pointing the
other way.
**Where the answer comes from.** `ChatMessageListViewModel` observes
`observeSessionsForChatRoom` and keeps the ids of the sessions
`FrostSigningManager.isAwaitingApproval` calls pending. That is the same
question `ProposalListUIState.waitingForYou` asks, deliberately, so the
transcript and the list cannot come to different views about which proposals
still have a decision in them. Observed rather than read once, because a
proposal arrives while a room is open as often as before it is opened, and one
answered on another device stops being owed with nothing happening here at all.
Held as state rather than queried at the tap: a navigation callback is not
suspend, and there is nowhere inside one to put a query. The read happens in
the click lambda rather than during composition, so a proposal arriving moves
where the next tap goes without recomposing the transcript to do it.
That took the repository through `MantraNavHost` -> `ChatRoomMessagingScreen`
-> `ChatMessageListViewModel.factory`; the screen's preview takes
`NO_OP_FROST_SIGNING_REPOSITORY`, which already answers with an empty list.
**Not covered, deliberately.** `ChatRoomMessagingScreen` calls
`chatMessageListViewModel.initiate()` inside `key(true) { }` rather than a
`LaunchedEffect`, so it re-runs on recomposition and launches a fresh collector
each time. The three observers already there carry that exposure;
`observeProposalsAwaitingYou` joins them rather than diverging from them, and
since each collector writes the same value from the same Room flow the cost is
duplicate collection, not a wrong answer. Fixing it changes how this screen
starts all of its work, which is every observer's business rather than this
one's.
Nothing counts the outstanding decisions anywhere a reader can see them before
tapping. A signing line still says only whether the line it sits on has been
answered, and the room list says nothing. A badge wants this count somewhere it
outlives one open room, which is its own change.
No tests. Both changes are navigation decisions taken in composables --
`ChatRoomDetailScreen`'s visibility gate and `ChatRoomMessagingScreen`'s route
choice -- and there is no UI test harness here to press a button in; the one
piece with a seam, `isAwaitingApproval`, is already what the proposal list is
tested through.
Verified: :composeApp:compileDebugKotlinAndroid succeeds; 808 tests pass, 511
jvm and 297 android, unchanged from before the change. That a Marmot room now
offers the list and that a second waiting proposal redirects the tap are read
from the code, not asserted -- both want the app on a device with a group that
has a key.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
b97732643b