coinosv3.git/tools/profile-batch-test.js, branch fdroid-v1.6

The feed keeps up, and stops moving the page while you read.

2026-09-13T21:55:18Z

A phone freezes a backgrounded tab: timers stop and the relay sockets are cut, so the feed came back holding whatever it had when you left and only caught up if you pulled it down by hand. Features now hear about the return — app.js calls f.resumed(awayMs) on focus — and the feed answers it by forcing a pass past the thirty-second throttle and rebuilding its subscriptions, which were talking to sockets that no longer exist. A blink between apps (under five seconds) is left alone. That catch-up raises the second problem rather than solving it: dropping eight posts in at the top moves the words under the thumb of whoever was reading. So posts that arrive on their own — live, or as a catch-up — wait when you're scrolled away from the top. A floating pill says how many, and the tap that lets them in also takes you up to them. Scrolling back to the top by yourself lets them in too, since up there they cost nothing. Anything you actually asked for still goes straight in. Also, on profiles that still show an npub: the batch now falls back to the relays whose whole job is indexing kind 0 (purplepag.es and friends), which we never read notes from and so never asked. profile-batch-test's "handful of asks" bound was a fraction of the row count, which that fallback broke; the property it means to assert is that the number does NOT grow with the rows, so it is a constant now. tools/feed-live-test.js drives a real signed event down a real open subscription — an unsigned fake is dropped by the signature gate and would prove nothing — and checks the page does not move, the pill says "1 new post", tapping it scrolls to the top, and coming back from hidden re-asks the relays on its own. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_019mrt228Upn9nNCwGixzSLx

The front door points at your own keys.

2026-09-13T16:48:54Z

Four buttons of equal weight, and only the sign-in ones said what they did. "Get started" said nothing, so the concrete offer on that screen was Google — which is a convenience wrapped around a seed phrase, not an alternative to one. Now the page says what the wallet is before it offers a button, the way in reads "Create a new wallet" with the cost under it (a minute, twelve words), and the three sign-ins sit below a line labelled "or, if you already have an account". And the second half of the same problem: a wallet that arrives by sign-in has a recovery phrase its owner has never seen and nobody can reissue. So the wizard shows it once, right after the first login, while it still reads as setting up rather than as a warning out of nowhere. "I've written it down" is the way on; "Later" is a real answer, and the wallet then keeps one quiet line — not a modal, not dismissible, gone the moment the phrase is actually seen, here or in settings. seedSeen records that per account: creating shows the words, importing means they typed them, revealing in settings counts. Only a derived seed starts false, which is exactly the case worth asking about. tools/onboard-backup-test.js covers both halves, including that "Later" leaves a reminder that survives a reload and leads somewhere. The sixteen tests that clicked the old button by its text are updated, and it has an id now so its copy can change without breaking them again. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_019mrt228Upn9nNCwGixzSLx

Feed rows wore punks and npubs because we asked for profiles one at a time.

2026-09-13T05:53:21Z

A screenful of eighty rows sent eighty kind-0 REQs in the same breath. Relays cap how many subscriptions a connection may have open, most were refused, the five-second timeout expired, and the empty answer was then believed for ten minutes — which is a real account dressed as a punk with a shortened npub for the rest of the session. Measured against this wallet's own feed, 131 of the 133 people on screen had a kind 0 sitting on relays we were already connected to. It was never reach; it was us. So profiles go out in batches: a 250ms beat collects a paint's worth of rows into one request of up to 200 authors, and each batch paints as soon as it lands rather than waiting behind the outbox fallback chasing stragglers. A miss now backs off instead of sticking — fifteen seconds, then half a minute, up to the ten minutes that's right for someone who genuinely has no profile. And noteRow no longer calls prefetchProfilePage. That fetches an author's whole page — kind 0, relay list, last thirty notes — which for twenty rows is sixty requests, and is what starved the batch in the first place. A row is not a profile tap; the page still loads when the profile is opened. profile-feed-test had rotted in three places (onboarding copy, and .header-msgs now matching the settings button first) — repaired, not rewritten. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_019mrt228Upn9nNCwGixzSLx