From a8ba589ecc497fca204cb2751162a6023737113a Mon Sep 17 00:00:00 2001 From: Kgothatso Ngako Date: Sun, 13 Sep 2026 13:19:51 +0200 Subject: [PATCH] docs: record what the profile preview plan built, and the places it chose differently Two strings that already existed, a room rule that follows the old code's intent rather than its branch, a retry that never takes an open chat back to checking, the flag the ordering cases asked for, and the test harness the other view models use. Co-Authored-By: Claude Opus 5 Pulled-From: curated/curated@b3bcc06047cba0e77bbccee1406c5e66af51d01f --- docs/README.md | 6 +++--- docs/npub-profile-preview.md | 26 ++++++++++++++++++++++++-- 2 files changed, 27 insertions(+), 5 deletions(-) diff --git a/docs/README.md b/docs/README.md index 02bcfb50..eb82fa8c 100644 --- a/docs/README.md +++ b/docs/README.md @@ -65,8 +65,8 @@ identities, and its first phase changes one rule the other two share — a seed' key becomes a credential like any other — so read it with `StoredIdentity.merge`, `SovereignWalletViewModel.switchToIdentity` and the startup screen open, and read its table of where the build chose differently first. -The npub profile preview note is a phased plan that has not been built, and is the +The npub profile preview note is a phased plan that has been built, and is the smallest of the plans: it changes the entrance to the direct-message flow and nothing past it, so read it with `StartDirectMessageToNpubOrNip05Dialog` and -`ChatRoomMessagingViewModel.initiateNewChat` open, and its four decisions before -its four phases. +`ChatRoomMessagingViewModel.initiateNewChat` open, its four decisions before its +four phases, and its table of where the build chose differently first. diff --git a/docs/npub-profile-preview.md b/docs/npub-profile-preview.md index 2c8be310..848c417b 100644 --- a/docs/npub-profile-preview.md +++ b/docs/npub-profile-preview.md @@ -9,10 +9,28 @@ Read this with `HomeScreen.kt`, `StartDirectMessageToNpubOrNip05Dialog.kt` and flow and nothing past it: the room is still created where it is created today, by the code that creates it today. -**Not built.** Four phases, one commit each, in the order given. Phases 1–3 are the +**Built**, phases 1–4, one commit each, in the order given. Phases 1–3 are the request as stated — a preview, and a button on it — and ship as a strict improvement on today. Phase 4 is what makes the button honest, and it is last so that the first -three do not wait on it. +three do not wait on it. The phases are kept as written because they are the +reasoning; where the implementation chose differently the table below says so: + +| what the plan said | what it turned out to be | +|---|---| +| a new string, `no_profile_was_found_for_this_npub` | the sign-in screen's `we_could_not_find_a_profile_for_this_key` — "We could not find a profile for this key on the relays we asked." One string, two screens, one meaning, as the npub plan found with `use_a_different_key` | +| a new string, `open_chat` | it existed: `SelectChatRoomTypeScreen`'s. The build failed on the duplicate key, which is the catalogue doing its job | +| `findDirectMessageRoom` as "the rule `initiateNewChat` applied" | the rule's *intent*: a room whose members are exactly the two keys, or the one key when they are the same. The old size-one branch would have opened any room in which the peer sat alone, whoever the peer was; the new rule needs that lone member to be you, and the repository test pins a room the peer has with somebody else as not yours | +| `retry()` from `NotYetOnMantra` | from any `Loaded`: it re-asks the DM relays alone and touches the readiness only when it was `NotYetOnMantra`, so a retry never takes an "Open chat" back to "Checking" | +| the timeout "fires with a person on screen" | a flag, `relaysHadTheirTime`, because the profile can arrive *after* the timeout and has to read not-yet-on-Mantra rather than checking; cleared by a retry, and `@Volatile` because the timeout and the collect are different coroutines | +| the view model tested on `TestScope` virtual time | real time, as the other view-model tests: `Dispatchers.setMain(UnconfinedTestDispatcher())`, a poll under `withTimeout`, and the twenty seconds cut to three hundred milliseconds through the constructor | +| `initiate()` "runs from a `LaunchedEffect`" | and is idempotent besides: a recomposition that calls it again opens no second collect, which the view-model test asserts | +| a screenshot pass under `docs/material-design-conformance.md` | five PNGs from a throwaway `jvmTest` with `captureToImage`, looked at and deleted — the found, not-found, checking, not-yet-on-Mantra and existing-chat states, at a phone's width | +| Phase 2's screen with one repository | Phase 4 adds `chatRepository` to the screen, its host entry and its tests, as the plan said it would; the Phase 2 commit is the screen without it | + +One thing found on the way that is in no phase: the dialog's `Dialog` renders inside +the desktop test root, so `onNodeWithText` finds its field and its button without a +popup matcher, and `performTextInput` drives the `inputTransformation` on every +edit — which is what made the `nostr:npub1…` row a four-line test. ## The flow today @@ -709,6 +727,10 @@ the same shape and got it wrong twice before it was right — the comments at li 116 and 138 are the record — so the view model test's ordering cases (profile first, key package first, neither, late) are the phase, and the screen is what is left. +Phases 1–4 are now implemented, in one sitting and in order. The Phase 4 +uncertainty resolved as predicted: the ordering cases are where the flag in the +table above came from, and the screen was what was left. + ## Out of scope - **nip05.** The dialog's email-like branch still lands on `ImplementationPendingRoute`.