Drops the _connectedRelays changes (the removeRelayInner prune and the
derived-projection refresh) and restores RelayPool to match main. The
incremental onConnected/onDisconnected maintenance is sufficient; the
user-visible background relay-count issues are addressed by the lifecycle
teardown timing and the notification-update throttle, not here.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ukw6FJPFh3JKGXL532p3ae
Replaces the incremental add/remove maintenance of _connectedRelays
(including the removeRelayInner prune) with a recompute from the source of
truth: a relay is connected iff it is in the pool AND its socket reports
ready (isConnected()). refreshConnectedRelays() runs on connect, disconnect
and pool-membership changes.
The earlier prune patched the *readout* on the assumption that "removed
from pool ⟹ disconnected", which is only incidentally true. A set that is
hand-maintained per event drifts from reality whenever an event is missed —
OkHttp's async cancel() callback being dropped under mass teardown, or a
socket dying without an onDisconnected. Projecting the set from each pooled
relay's actual isConnected() can't drift: removed relays are already
disconnected so they fall out, and a silently-dead socket stops being
counted on the next refresh.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ukw6FJPFh3JKGXL532p3ae
removeAllRelays() has no call sites — it's dead code — so clearing
_connectedRelays there was never exercised. The live fix for the stale
connected count is the prune in removeRelayInner (driven by updatePool),
which keeps removeAllRelays untouched relative to main.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ukw6FJPFh3JKGXL532p3ae
Strips the BgRelayTrace instrumentation added while diagnosing the
background relay-count issues and restores the production grace period.
- LifecycleAwareKeyDataSourceSubscription: UNSUBSCRIBE_GRACE_MILLIS back to
30s, drop the per-subscription label + logs, refresh the doc to describe
the LifecycleEventObserver detection.
- RelayPool: drop updatePool trace logs and the now-unused Log import; keep
the _connectedRelays prune (with a trimmed comment).
- BaseEoseManager: drop the per-assembler relay-count log + Log import.
- SubscriptionController: drop activeRelays(), which only fed that log.
The actual fixes stay: lifecycle-observer teardown detection, the
connected-set prune, and the notification-count throttle + fg/bg wording.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ukw6FJPFh3JKGXL532p3ae
A device log showed the persistent notification stuck on a stale count
(e.g. "44 inbox relays") while the pool had actually settled lower
(flowConnected=8). Cause: the count collector posted the notification on
every connectedRelaysFlow delta — ~90 updates during feed load, then ~22
in ~250ms during background teardown. Android rate-limits notification
updates (~10/s) and silently drops the excess, so the last value the
framework rendered (a mid-cascade 44) stuck instead of the final 8.
Sample connectedRelaysFlow at 1s before updating the notification. That
caps updates to ~1/s — comfortably under the limit — and the settled
count always lands. Also drops the now-confirmed notif-collector/
notif-popup debug logging.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ukw6FJPFh3JKGXL532p3ae
A fresh process reset TorManager.hasEverBootstrapped to false, so the
stuck-Connecting self-heal watchdog used the gentle reset() (drop client,
keep state) instead of resetWithCleanState() (wipe state). When guards.json
carried guards poisoned by TooManyIndeterminateFailures from a prior
session, every retry reloaded the same poisoned guards and Tor stayed stuck
in Connecting forever — never wiping the one thing blocking it.
Seed hasEverBootstrapped at startup from durable on-disk evidence: Arti only
writes confirmed_at on a guard after it has built real circuits, so a
confirmed guard proves Tor bootstrapped successfully on this install before,
even across the restarts that clear the in-memory flag. With it set, a stuck
bootstrap correctly wipes the stale/poisoned state and rebuilds a fresh
guard sample.
- ArtiGuardState: pure, file/JNI-free parsers over guards.json
(hasConfirmedGuard + hasNoUsableGuards extracted from TorService).
- TorService.hasBootstrappedBefore() reads the file off-thread.
- TorBackend gains the suspend method; TorManager seeds in init.
- Tests cover the parser against a real captured poisoned-but-confirmed
guards.json fixture, plus a watchdog test for the wipe-on-first-stuck path.
Verified on an emulator stuck in Connecting from real poisoned guards:
self-heal wiped state and Tor reached Active in ~5s (clean 0-disabled
guard sample).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The always-on notification now reads "Connected to N relays" while the
app is foreground (the pool also holds feed/finder outbox relays) and
"Connected to N inbox relays" once backgrounded (feeds torn down, only
inbox + DM relays remain). The label is chosen from MainActivity.isResumed
at each notification refresh; since foreground/background transitions
always change the connected count, the existing count-driven re-post
picks up the new wording.
Both messages are now <plurals> (relay/relays declines in many locales),
converting the existing always_on_notif_connected across all 11 locales
that had it (other-only; Crowdin fans out the remaining CLDR categories).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ukw6FJPFh3JKGXL532p3ae
The persistent notification's relay count is rendered by a collector on
the service's Dispatchers.IO scope. If that collector is throttled while
backgrounded — the same throttling that delayed the lifecycle teardown by
60s — the popup would show a stale count while the real pool (logged as
flowConnected in updatePool) has already shrunk. Log every value the
collector receives and every count it actually posts, so we can tell a
stale popup from real connections.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ukw6FJPFh3JKGXL532p3ae
A device log showed the foreground feeds (and ~150 relays) staying
connected for a full ~60s after the app was paused, then collapsing to
the 11-relay floor all at once:
11:26:02 HomeOutboxEventsEoseManager — keys=2, relays=344 (paused here)
… 60s of silence …
11:27:02 grace-start(HomeFilterAssembler) — lifecycle=CREATED
11:27:02 updatePool done — flowConnected=9, inPool=11
The lifecycle-aware subscription detected ON_STOP by collecting
lifecycle.currentStateFlow on Dispatchers.Default. Backgrounded, that
collector wasn't resumed until the next NostrClient keep-alive tick
(KEEP_ALIVE_INTERVAL_MS = 60s), so teardown — and the relay disconnects
it drives — lagged a minute behind the actual pause.
Switch detection to a main-thread LifecycleEventObserver, which fires
synchronously during onStop. Only the grace delay still runs on the
background scope (so it isn't gated by the stopped UI frame clock).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ukw6FJPFh3JKGXL532p3ae
After fixing the stale connected-count, the background footprint settles
at ~25 relays (desired=22) — higher than the inbox+DM target. Add a
per-EoseManager log (assembler name -> key count + distinct relay count)
so we can attribute the 25 to specific always-on loaders (metadata/drafts
on homeRelays, gift-wrap history, marmot groups, notifications) and trim
precisely instead of guessing.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ukw6FJPFh3JKGXL532p3ae
Backgrounding the app correctly collapsed the desired relay set (e.g.
desired=22, toRemove=343) and the pool cache shrank accordingly, yet the
always-on notification kept reporting ~110 connected relays. Measured:
updatePool done — cacheConnected=18, flowConnected=87, inPool=22
_connectedRelays (exposed via connectedRelaysFlow() and read by the
notification) was only ever pruned from the async onClosed/onFailure
websocket callback. disconnect() uses OkHttp cancel(), which kills the
socket immediately but whose callback is unreliable when hundreds of
sockets are cancelled at once in the background — so the connected set
stayed stale long after the real connections were gone.
Prune _connectedRelays directly in removeRelayInner (and clear it in
removeAllRelays) so the connected set tracks the pool's membership
immediately. The async callback remains as an idempotent backstop.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ukw6FJPFh3JKGXL532p3ae
The background teardown works (desired collapses to 11, toRemove=349) but
the persistent notification still reports ~110 connected relays. That
points at the _connectedRelays StateFlow (what the notification reads)
being decoupled from the pool's desired set: it is only decremented from
the async onFailure/onClosed websocket callback, while disconnect() uses
OkHttp cancel() (immediate/violent). Add a post-reconcile log comparing
cacheConnected (relays still in the pool reporting isConnected) against
flowConnected (_connectedRelays.size) to confirm whether the 110 are live
sockets or a stale count.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ukw6FJPFh3JKGXL532p3ae
The Homebrew formula is the cli module's product (amy), and the CLI already
owns its packaging artifacts under cli/packaging/ (cli/packaging/macos/
amy.entitlements). The root packaging/ dir was new in this branch and held
nothing else, so co-locate the formula with the module that owns it and drop
the stray root dir. Updates the two BUILDING.md references.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015sso31DfSF9B6EFCVkEqWD
Phase 1.4 (App() smoke test), Phase 2.4 (fixture-relay wire-up), and
Phase 5.2 (bootstrap-gate fix + regression tests) all land in commit
48a8178c9. The progress-log table, acceptance-criteria checkboxes, and
pending-work section are updated to reflect the new state. 278/278
desktopApp tests pass.
Only follow-up enhancements remain — the cold-fork shell driver, a
Compose-driving benchmark variant, and Phase 5.3 (sequential remember
chain in MainContent). None are required for the in-scope set.
Adds a `LaunchTestOverrides` bundle (default null in production) so
`App()` can be driven from `createComposeRule()` against the in-process
fixture relay instead of the OkHttp + kmp-tor + DesktopHttpClient stack
it normally constructs via `remember { … }`. `DesktopRelayConnectionManager`
gains a secondary constructor taking a `WebsocketBuilder` so the
`LocalRelayManager` composition local (typed as
`DesktopRelayConnectionManager?` and consumed by ~20 screens) does not
have to be relaxed.
`AppStateMachineTest` exercises four scenarios:
1. `appShowsLoginScreenWhenNoSavedAccountExists` — App() with no
`accounts.json.enc` reaches LoggedOut and renders LoginScreen.
2. `appWithViewOnlyAccountReachesLoggedInWithoutCrashing` — App() with
a pre-seeded ViewOnly account reaches LoggedIn end-to-end through
`MainContent`, the deck columns, NWC wiring, etc.
3. `bootstrapSubscriptionFiresEagerlyEvenWhenRelayNeverConnects` —
wires a `NeverConnectsWebsocketBuilder` so no connection ever opens,
yet App() still reaches LoggedIn within 5s instead of the previous
30s gate timeout. Direct regression test for the Phase 5.2
bootstrap-gate removal.
4. `bootstrapSubscriptionFiresAtMostOncePerAccountLoad` — wraps the
fixture builder with a `RecordingWebsocketBuilder` and asserts the
bootstrap REQ does not loop or double-fire.
The `LaunchScenario` benchmark drops its private
`BenchmarkRelayConnectionManager` subclass in favor of the new
secondary `DesktopRelayConnectionManager(WebsocketBuilder)` constructor.
278/278 desktopApp tests pass.
Phase 1.4 / 2.4 / the four Phase 5.2 regression tests are all blocked on
the same broader App() dependency-injection refactor — relayManager,
localCache, localRelayStore, and subscriptionsCoordinator are still
constructed inside App() via remember { … }. The torManager slot has
been loosened to ITorManager in preparation, but the rest is wider work
than this session can absorb.
App() only consumes torManager.status, which is on ITorManager.
Loosening the parameter type lets future tests substitute a fake without
having to construct the concrete DesktopTorManager (which eagerly builds
a kmp-tor TorRuntime on first status access). No production behavior
change: DesktopTorManager already implements ITorManager and the existing
call site at Main.kt:633 upcasts naturally.
This is a small intermediate step on the road to the still-pending Phase
1.4 App() Compose smoke test, which is the last item blocked on broader
App() dependency injection (relayManager / localCache / localRelayStore
are still remember'd internally).
Phases 2.1/2.2/2.3, 3.1/3.2, 4, 5.2, and 6 of the launch-optimization plan
land together because they share a single set of seams and a single
benchmark report.
* InProcessWebsocketBuilder + LaunchFixtureRelay wrap quartz's existing
InProcessWebSocket + NostrServer (with EmptyPolicy) so any test can
drive a NostrClient against an in-memory relay seeded with arbitrary
events. Roundtrip verified by LaunchFixtureRelayTest.
* LaunchFixture builds a deterministic 50-note synthetic home-feed
snapshot from a fixed RNG seed (kind:1 + author kind:0 + kind:3 +
kind:10002). A real-world JSONL artifact is a drop-in replacement.
* NoteCard gets a stable testTag + a CompositionLocal-backed
onPlaced hook. Production overhead is one composition-local read
plus one null check per placement (default
LocalNoteCardInstrumentation = null).
* LaunchMarkers records named markers against TimeSource.Monotonic.
LaunchScenario.coldBoot drives the AccountManager (ViewOnly path)
+ DesktopLocalCache + RelayConnectionManager + LocalRelayStore
stack against the fixture relay and reports t_account_logged_in,
t_first_event, t_n_events.
* LaunchBenchmark runs 2 warmup + 5 measured iterations, computes
min/q1/median/q3/max, atomically writes the report file, and is
skipped by default — opt in via AMETHYST_BENCH=true. Baseline +
post-fix snapshots committed under desktopApp/benchmarks/.
* SubscribeBeforeConnectTest proves NostrClient / RelayPool queue REQs
issued before connect() and flush them when the connection comes up.
The bootstrap-config subscription in Main.kt drops its
`connectedRelays.first { isNotEmpty() }` + 30s withTimeoutOrNull gate
on the strength of that invariant — the subscription now fires
eagerly and recovers when no relay ever connects instead of silently
giving up after 30s.
All 274 desktopApp tests pass. No flaky tests introduced.
Investigating why backgrounding the app on the all-follows feed leaves
~172 outbox relays connected when only inbox + DM relays (~8) should
remain. The static teardown chain (lifecycle ON_STOP -> unsubscribe ->
client.unsubscribe -> PoolRequests.remove -> RelayPool.updatePool
disconnect) is correct, so this adds runtime tracing at the two decisive
hops to find where it stalls on-device:
- LifecycleAwareKeyDataSourceSubscription: log subscribe/grace-start/
unsubscribe/dispose with the assembler name (tag BgRelayTrace).
- RelayPool.updatePool: log desired/inPool/toRemove/connected counts.
Also drops UNSUBSCRIBE_GRACE_MILLIS 30s -> 0 as an experiment: if the
grace delay() was being starved on Dispatchers.Default once backgrounded
(Doze/app-standby suspends timers), unsubscribing immediately on ON_STOP
both proves and fixes the leak. To be reverted to a wakelock-safe grace
once confirmed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ukw6FJPFh3JKGXL532p3ae
amy is headless and compiles against zero Compose UI (the Compose deps are
`implementation` in :commons, so they never hit the CLI compile classpath),
but they still rode the runtime classpath into the shipped image — ~29 MB of
Compose desktop render stack, including skiko's native .dylibs that enlarged
the macOS notarization surface.
Exclude skiko + the org.jetbrains.compose UI groups (ui/foundation/material/
material3/animation) from :cli runtimeClasspath. Keep androidx.compose.runtime
(snapshot state + @Stable/@Immutable) — that IS CLI-safe and used by commons
models/state. This avoids the commons → commons/commons-ui module split: the
single-module, feature-cohesive design (commons/ARCHITECTURE.md §1/§3) is
preserved; only the runtime artifact is trimmed.
Result: amy image lib 77 MB -> 48 MB (-38%), and all 4 Compose/skiko notary
dylibs gone (only secp256k1/jna/sqlite natives remain — the ones actually
loaded). A create-release.yml assertion fails the build if the UI stack ever
leaks back.
Verified with the SDK hidden + an offline amy command battery (init/whoami/
--json/relay/marmot/login, plus a real 6-relay key-package round-trip): zero
NoClassDefFoundError/linkage errors; init derives a secp256k1 key cleanly.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015sso31DfSF9B6EFCVkEqWD
macOS validation (Developer ID D77MCV9NZ7) confirmed the hardened-runtime
entitlements are correct and load-bearing: amy init derives a secp256k1 key
cleanly, and dropping disable-library-validation reproduces the runtime
dlopen Team-ID failure. The one unverified gap is whether Apple's notary
service accepts the unsigned Mach-O dylibs embedded inside lib/*.jar
(secp256k1/jna/sqlite/skiko), which it inspects recursively.
- create-release.yml: the notarize step now submits with --output-format json,
and on any non-Accepted status dumps `notarytool log` (per-file issues) and
fails — so the first real run names the offending files instead of failing
opaquely. No speculative in-jar signing yet; gather the log first.
- BUILDING.md: record the validation result, the embedded-jar-native risk, the
one-run way to decide it (workflow_dispatch dry_run with MAC_* secrets), and
the staged fixes (sign-in-jar and/or strip the skiko/Compose leak). Note the
desktop app shares the same jars and needs its own dry-run.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015sso31DfSF9B6EFCVkEqWD
Sign the macOS jlink image (amy-<version>-macos-arm64.tar.gz) so users who
download it directly clear Gatekeeper. Reuses the same Developer ID cert and
the six MAC_* secrets as the desktop DMG; no-op when they're absent.
- .github/actions/import-macos-cert: factor the throwaway-keychain cert import
into a composite action; the desktop leg now uses it too (was inline).
- create-release.yml (build-cli macOS leg): import the cert, then codesign
every Mach-O binary in the bundled JRE (executables get hardened-runtime
entitlements, dylibs don't) and notarize via notarytool --wait. Runs before
the collect step so the tarred image is signed. Job timeout 30->45 min for
notarization headroom.
- cli/packaging/macos/amy.entitlements: hardened-runtime entitlements; the
disable-library-validation key lets the JVM load the secp256k1 native dylib
it extracts from a jar at runtime (would otherwise crash under notarization).
- BUILDING.md: document the tarball signing, the no-stapling/online-check
caveat, and that the Homebrew-core jvm bundle is intentionally left unsigned.
Untested end-to-end (no macOS runner / Apple creds here) — validate with a
workflow_dispatch dry-run once the secrets are provisioned.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015sso31DfSF9B6EFCVkEqWD
Enable distributing the `amy` CLI via Homebrew-core (mainline formulae).
Homebrew-core builds in a network-sandboxed env, so a from-source Gradle
build can't resolve Maven deps there; the accepted pattern for JVM tools is a
pre-built no-JRE jar bundle + `depends_on "openjdk"`. installDist already
produces exactly that (bin/amy + lib/*.jar, no bundled runtime).
- create-release.yml: publish `amy-<version>-jvm.tar.gz` (the installDist tree)
as a release asset on the linux leg. Pure JVM bytecode, so one
platform-independent artifact serves every OS.
- packaging/homebrew/amy.rb: reference formula (depends_on openjdk, livecheck
for BrewTestBot auto-bumps, `amy --help` smoke test). Not consumed by any
build here — it's the artifact to submit to Homebrew/homebrew-core.
- BUILDING.md: homebrew-core submission runbook; note that the desktop app is
already on mainline Homebrew (homebrew/cask); document name-collision and
pre-built-jar review caveats.
- asset-name.sh: document the jvm bundle naming exception.
Verified locally: :cli:installDist builds with only a JDK (no Android SDK),
and the extracted bundle runs via JAVA_HOME (`amy --help` exits 0).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015sso31DfSF9B6EFCVkEqWD
Add gated code-signing + notarization for the macOS desktop DMG so it can
clear Gatekeeper and stay in Homebrew's main cask (unsigned casks are
rejected after 2026-09-01).
- desktopApp/build.gradle.kts: macOS signing{}/notarization{} blocks, gated
on the AMETHYST_MAC_SIGN_IDENTITY env var. Absent => unsigned DMG, exactly
as before, so local dev and PR CI are unaffected.
- create-release.yml: import a Developer ID cert into a throwaway keychain on
the macOS leg and export the signing/notary env. Soft-gated on the
MAC_CERTIFICATE_P12 secret — no secret => unsigned build.
- BUILDING.md: document the six MAC_* secrets, how to generate them, and flip
the unsigned-cask fallback note to reflect the wiring is now in place
(pending Apple credentials).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015sso31DfSF9B6EFCVkEqWD
NUT-09 "Recover from seed" iterated only the configured kind:17375 mint
list, so funds at a mint dropped from the wallet config (while still
holding tokens) or auto-redeemed from a nutzap on an unconfigured mint
were silently skipped by recovery. Scan displayMints (configured plus any
mint we currently hold tokens at) instead.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TK5eNfhkNR1svcQxjY1JvR
Builds on the untrusted-mint highlight: the warning banner and each
flagged mint row are now actionable, opening an EvacuateMintDialog that
offers the three exits whose backends already exist —
- Move to a mint you trust: a new rebalanceOut() over the tested
CashuWalletState.rebalance (mint-to-mint, no new Lightning sats). The
amount is editable and defaults to the balance, with a hint that the
Lightning fee is taken from the source so the full balance may not fit.
- Withdraw via Lightning: hands off to the existing Send-LN dialog.
- Export as Cashu token: hands off to the existing Send-token dialog.
The two Send dialogs now source from displayMints (not just configured
mints) and accept an initial mint, so they can be pre-pointed at the
mint being evacuated.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TK5eNfhkNR1svcQxjY1JvR
Surface coins sitting at a mint the user never configured — almost always
auto-redeemed from a NIP-61 nutzap sent on a mint outside the recipient's
kind:10019. Until now such a balance counted toward the total and showed a
plain mint row, with nothing to tell the user it came from an unvetted
issuer.
- `CashuWalletState.unconfiguredMintBalances`: token-held mints minus the
configured (kind:17375) set, keyed by mint URL -> sats.
- Wallet screen shows an error-styled recommendation banner when any exist
and badges the offending mint rows ("Not in your wallet").
Informational first cut; the per-mint "move these coins to a trusted mint
or withdraw to Lightning" action (reusing rebalance / meltToLightning /
sendAsToken) follows separately.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TK5eNfhkNR1svcQxjY1JvR
Two related gaps around nutzaps redeemed from mints not in the user's
configured kind:17375 list (e.g. a NIP-61 nutzap auto-redeemed from a
mint outside the recipient's kind:10019):
- The wallet screen's per-mint list iterated only the configured mints,
so a token-only mint contributed to the total balance but had no row —
the displayed per-mint balances under-counted the wallet. Add
`displayMints` (union of configured + token-derived mints) so the rows
sum to the full balance.
- Stale-proof reconciliation (`scrubLocallyStaleProofs`) only ran for the
single mint a spend targeted, so proofs held at a non-configured mint
were never checked until spent. Add `syncAllMints()` (an all-mint,
non-destructive sweep) and wire it to the wallet screen opening via
`CashuWalletViewModel.refresh()`.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TK5eNfhkNR1svcQxjY1JvR
- Invalidate the cached NUT-13 seed in applyEvents whenever the live kind:17375
changes, so after a P2PK key rotation (recreateNutzapKey, or a rotation from
another client) deterministic secrets re-derive from the new key instead of a
stale cached seed. Removes the now-redundant reset in recreateNutzapKey.
- AccountSettings.updateNutzapInfo no longer backs up a mints-less kind:10019
(the "stop receiving nutzaps" tombstone), clearing the backup instead — so the
empty event round-tripping back through LocalCache can't undo clearNutzapInfo()
and resurrect a withdrawn nutzap advertisement on next launch.
- Key keyMode's remember on isEditMode in AddCashuWalletScreen so a wallet
delivered after first composition flips to KeepCurrent, preventing a silent
key rotation on save in the cold-open race.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SXRAunSJS2dBx7B79qTMew
- Restore the per-mint Verify button + reachability status on the already-added
mints list. Verify is now in BOTH places: the current mints and the
Matching/Popular suggestions (it was meant to be added to suggestions, not
moved off the current list).
- Settings hub order: My mints → Mint recommendations → Recover from seed →
Danger Zone, so the occasional recovery action sits last before the
destructive section.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SXRAunSJS2dBx7B79qTMew
Adjusts the mint editor to the post-key-rotation reality and tidies its UI:
- Settings hub: "Edit wallet details / Mints, nutzap key" row becomes
"My mints / Add or remove the mints your wallet uses." The edit screen title
changes from "Edit Cashu wallet" to "Edit mints".
- The per-mint Verify button moves off the already-added mints list and into
the Matching/Popular mints suggestion rows, sitting to the left of the +
button, with the reachability result shown under each suggestion. Reuses the
existing per-URL mintVerifications state.
- Fixes the Mint URL placeholder wrapping onto two lines (and inflating the
field height) by capping it to a single ellipsized line.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SXRAunSJS2dBx7B79qTMew
The Cashu wallet settings screen becomes a thin redirector. The NIP-87 mint
recommendations management (add-input + autocomplete + own-list + retract
dialog) moves out into a dedicated CashuMintRecommendationsScreen, reached via
a new "Mint recommendations" nav row. Recover-from-seed and the Danger Zone
stay inline on the hub.
- New Route.CashuMintRecommendations + AppNavigation registration.
- New CashuMintRecommendationsScreen with its own top bar; carries the
recommendation composables + previews that used to live in the settings file.
- CashuWalletSettingsScreen trimmed to nav rows + the recover action + the
Danger Zone dialogs.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SXRAunSJS2dBx7B79qTMew
Claude
Vitor PamplonaandClaude Opus 4.8
davotoula
Crowdin Bot
nrobi144