removeAccountFromStorage was calling loadSavedAccount() which reads
from legacy last_account.txt — didn't trigger feed/relay reload.
Now calls switchAccount(nextNpub) for proper relay reconnection and
feed reload, or logout(deleteKey=true) if no accounts remain.
Also cleans up bunker ephemeral keys on removal.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replaced DialogWindow (OS native window with title bar, minimize/maximize)
with Dialog composable (in-app overlay with scrim). Matches the
ComposeNoteDialog pattern used elsewhere in the desktop app.
- Card wrapper with 480dp width, 24dp padding
- Title row with 'Add Account' + Close (✕) icon
- No OS window chrome — clean in-app feel
- Click outside or ✕ to dismiss
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
consumeMetadata() was looping ALL notes in cache (O(N)) to find notes
by the author whose metadata changed. With hundreds of cached notes,
this caused lag on every metadata event.
Added notesByAuthor index (ConcurrentHashMap<HexKey, MutableSet<Note>>)
populated at loadEvent time. consumeMetadata now looks up notes by
author in O(1) instead of scanning the entire cache.
Before: ~500 notes × per metadata event = lag
After: ~3 notes per author × per metadata event = instant
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Root cause: toNoteDisplayData(localCache) wasn't keyed on metadataState,
so Compose could skip recomputing it when metadata arrived for items
that were composed before metadata was available (first ~2 items).
Fix: remember(event, metadataState) { event.toNoteDisplayData(localCache) }
ensures display data is recomputed when the note's metadata flow
invalidates. Applied to both regular and repost note paths.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Pre-existing bug: regular (non-repost) notes in the feed never observed
note.flow().metadata.stateFlow. When metadata arrived from relays and
invalidateData() was called, the composable didn't recompose — author
names and avatars stayed as hex fallbacks.
The repost path already observed metadata correctly (line 130). Added
the same observation to the regular note path (line 211).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Display names weren't showing because metadata was never requested for
account pubkeys. Now:
1. LaunchedEffect triggers loadMetadataForPubkeys() for all accounts
in the switcher once relays connect
2. metadataVersion collector persists display names for ALL accounts
(not just active one) when metadata arrives from relays
3. Names available immediately on next dropdown open
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
saveCurrentAccount() previously returned failure for read-only and
bunker accounts, preventing them from being added to multi-account
storage. Now:
- Read-only (npub): skips private key save, still saves to storage
- Bunker: saves to storage (private key already saved during login)
- Internal (nsec): saves private key + storage (unchanged)
This was the root cause of npub-only accounts not appearing in the
switcher and accounts being lost when adding via AddAccountDialog.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
DesktopAccountStorage now caches AccountMetadata in memory after first
read. Subsequent loadAccounts/saveAccount/setCurrentAccount serve from
cache, only hitting disk on writes. Also caches AES encryption key to
avoid repeated OS keychain lookups.
Before: 3 decrypts + 1 encrypt + 4 keychain calls per login/switch
After: 1 decrypt + 1 keychain call on first access, then memory only
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Root cause of accounts not persisting:
ensureCurrentAccountInStorage() was fire-and-forget (scope.launch),
so loginWithKey() ran before the old account was saved. The old account
was lost. Now all steps run sequentially in one coroutine.
UI hanging fix:
metadataVersion LaunchedEffect fired on every metadata event, doing
encrypted file I/O each time. Now debounced with 2s delay so it only
writes once after a batch of metadata settles.
Also:
- loadInternalAccount falls back to read-only (test updated)
- bunker/nostrconnect paths also await ensureCurrentAccountInStorage
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Three fixes:
1. Display names now stored in AccountInfo/AccountInfoDto and persisted
in encrypted storage. Populated when metadata arrives from relays via
metadataVersion LaunchedEffect. Available immediately on next open.
2. loadInternalAccount falls back to loadReadOnlyAccount when no private
key found in SecureKeyStorage — fixes npub-only accounts that were
saved as SignerType.Internal from earlier sessions.
3. Dropdown uses persisted displayName first, cache lookup as fallback.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Root cause of npub-only switch failure:
loginWithKey() with pubkey created AccountState with signerType=Internal
(default). switchAccount then called loadInternalAccount which requires
a private key from SecureKeyStorage → failed. Now sets ViewOnly.
Display names not showing:
- resolveDisplayName() ran at composition time but metadata hadn't
loaded from relays yet. Dropdown never recomposed when it arrived.
- Added metadataVersion counter to DesktopLocalCache, incremented on
each consumeMetadata(). Dropdown collects it to trigger recomposition
when user names become available.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add loadReadOnlyAccount() for ViewOnly signer type switching
(was mapping to loadInternalAccount which requires private key)
- Remove remember() from display name resolution — now re-evaluates
each recomposition so names appear once metadata loads from relays
- Only show subtitle (npub row) when display name is available;
if no display name, show npub as title only
- Signer type badge shown as subtitle when no display name
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Account switcher dropdown improvements:
- Two-row display: Display Name on top, npub (middle-truncated) below
e.g. 'Alice' / 'npub1abc...wxyz · Bunker'
- Middle-truncation for npub: shows first 10 + last 6 chars
- Resolves display names from DesktopLocalCache user metadata
- Confirmation dialog also shows display name
- npub-only (view-only) accounts now persist to encrypted storage
(ensureCurrentAccountInStorage called in onLoginSuccess)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Root cause of 'follows at 0 after 2+ switches':
DesktopLocalCache.clear() reset _followedUsers to empty but did NOT
reset lastContactListCreatedAt. On re-subscribe after account switch,
the contact list event arrived with the same timestamp, was rejected
by the 'event.createdAt <= lastContactListCreatedAt' guard, and
followedUsers stayed empty.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When switching accounts, the feed showed stale data from the previous
account because subscriptions and LocalCache weren't cleared.
Now tracks previousAccountPubKey and when it changes:
1. Clears all relay subscriptions (subscriptionsCoordinator.clear())
2. Clears local event cache (localCache.clear())
3. Restarts subscriptions coordinator
Feed composables then resubscribe with the new account's pubkey
via their existing rememberSubscription(account, ...) keys.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
loadSavedAccount() reads from legacy files (last_account.txt) but never
wrote to the encrypted multi-account storage, so the account switcher
dropdown was always empty after restart.
Now calls ensureCurrentAccountInStorage() + refreshAccountList() after
successful load so the current account appears in the dropdown.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- ensureCurrentAccountInStorage(): saves current account metadata to
encrypted storage before switching to new account via AddAccountDialog
- AddAccountDialog calls ensureCurrentAccountInStorage() before each
login method to prevent losing the previous account
- LoginScreen onLoginSuccess now calls refreshAccountList() so the
switcher dropdown picks up the initial account immediately
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Account switcher now appears at bottom of NavigationRail in single-pane mode
(after tor indicator), matching placement in deck sidebar
- AddAccountDialog wired in single-pane mode too
- Dropdown scrollable with 400dp max height for many accounts
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- AddAccountDialog: DialogWindow (480×600) wrapping existing LoginCard
with back button, "Import Account" title. Supports nsec, npub, bunker,
nostrconnect. New account becomes active immediately after login.
- Per-account logout: ✕ button on each account row in dropdown, with
AlertDialog confirmation before removal.
- Wired both into DeckSidebar and Main.kt.
Matches Android's AddAccountDialog pattern (full-screen dialog with
LoginOrSignupScreen) adapted for desktop (DialogWindow).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Migration from single-account files didn't work reliably.
Removed migrateFromLegacyFiles() and migrateAndLoadAccounts().
Account list now populated only via saveCurrentAccount/saveBunkerAccount
when user logs in — no automatic migration from old format.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Fixes from code-simplicity and architecture reviews:
Critical fixes:
- Per-account bunker ephemeral key alias (bunker_ephemeral_<npub>) instead of
shared alias. Prevents wrong-identity handshake when switching bunker accounts.
Falls back to legacy alias for existing single-account setups.
- Resource cleanup in switchAccount(): closes NIP-46 subscription, stops
heartbeat, disconnects NIP-46 client before transitioning to new account.
- Manages signer connection state on switch (Connected for bunker, NotRemote otherwise).
Simplifications:
- Removed unused createWithStorage() factory (zero callers)
- Removed loadViewOnlyAccount() dead code (no UI path to create view-only accounts)
- Removed unused allAccounts collection at Window scope (duplicated in MainContent)
- Files.move with REPLACE_EXISTING for cross-platform atomic rename
- Remote signer with empty bunkerUri falls back to Internal (prevents corrupt state)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Phase 4: account switcher UI.
- AccountSwitcherDropdown composable (person icon → dropdown menu)
- Shows all accounts with active checkmark and signer type label
- "Add Account" button at bottom with divider
- DropdownMenu with DpOffset(48dp) to expand right of sidebar
- DeckSidebar now takes account params (activeNpub, allAccounts, callbacks)
- Replaces "A" logo text with account switcher button
- Migration called on startup to populate account list
- Account switch wired through to AccountManager.switchAccount()
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Phase 3: wire multi-account lifecycle into desktop AccountManager.
- Add DesktopAccountStorage field and allAccounts StateFlow
- switchAccount(): loads new account BEFORE cancelling old state
(prevents unrecoverable partial failure per coroutines review)
- addAccountToStorage / removeAccountFromStorage for CRUD
- loadViewOnlyAccount() for npub-only accounts
- migrateAndLoadAccounts() for legacy file migration on startup
- saveCurrentAccount / saveBunkerAccount now save to encrypted storage
- Updated test mock setup to support SecureKeyStorage key store
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Phase 1 of multi-account support. Move account types to commons/commonMain
so both Android and Desktop share the same data model:
- SignerType sealed class (Internal, Remote, ViewOnly)
- AccountInfo data class (npub, signerType, isTransient)
- AccountStorage interface (loadAccounts, saveAccount, etc.)
Desktop AccountManager now imports SignerType from commons instead of
defining its own. All existing tests updated with new import path.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The notification card BadgeCompose rendered the awarded badge via
BadgeDisplay (definition-only) and stopped there, so a recipient
viewing a fresh badge in their inbox had no way to add it to their
profile without navigating to the award's thread first.
Expose AcceptBadgeControls (was private inside Badge.kt) and call it
from BadgeCompose under the BadgeDisplay row when the underlying note
is a BadgeAwardEvent.
Other surfaces are unchanged:
- RenderBadgeAward (Badge feed / threads) keeps its own call to the
same composable; behaviour is identical because the controls were
already package-private.
- BadgeCompose has only one caller (CardFeedView, the notifications
feed), so the new row only appears there.
The FAB now opens the new-badge dialog directly. The dialog renders a
big bordered "Upload an image" placeholder where the picture will go;
tapping it opens the gallery. Once the user picks an image, the
placeholder is replaced by the existing ShowImageUploadGallery preview
and tapping the preview lets them pick a different image.
Lets the user see the whole form (name, description, server, quality,
strip-metadata) immediately instead of being thrown into the picker
the moment they hit the FAB.
Replace the form-first create screen with a picker-first media pipeline
that matches the other upload screens in the app.
- NewBadgeButton (FAB, AddPhotoAlternate icon) opens GallerySelect
directly.
- After the image is picked, NewBadgeDialog mirrors the NewMediaView /
ImageVideoPost pattern: a thumbnail strip, name + description fields,
server picker, compression-quality slider, and strip-metadata switch.
- NewBadgeModel drives the upload through the shared MultiOrchestrator.
Only on a successful upload does it reach into Account.sendBadgeDefinition
with an auto-generated UUID d-tag, the uploaded URL + dimensions, and
the uploaded URL reused as the NIP-58 thumb (a separate thumbnail
upload can land as a follow-up).
The Cancel / Post buttons use the CreatingTopBar so "Create" reads
right on the primary action. Submit is disabled until the name is
non-empty, an image is staged, and a server is selected.
Drops the old route-based NewBadgeScreen / NewBadgeViewModel and the
Route.NewBadge entry.
The accepted-first sort was keyed on acceptedAwardIds, so every toggle
changed that set and the list jumped around. Key the remember on a
"loaded" flag (first time either the 10008 or the legacy 30008 event
arrives) plus the existing bundle tick; acceptedAwardIds is read from
the enclosing scope at the moment of recomputation but isn't part of
the key.
Result: the list loads with accepted badges on top, new awards flowing
in during the session trigger a re-sort, but plain Switch toggles leave
the visual order intact.
The list event only stores content-discovery feeds (kind-5300 DVMs),
not every DVM, so the old name was misleading. Rename the wire-level
type to reflect what's actually in it.
- Quartz: package nip51Lists.favoriteDvmList -> favoriteAlgoFeedsList;
class FavoriteDvmListEvent -> FavoriteAlgoFeedsListEvent.
- DSL helpers renamed: favoriteDvm/favoriteDvms builder extensions ->
favoriteAlgoFeed/favoriteAlgoFeeds; TagArray.favoriteDvmList/Set ->
favoriteAlgoFeedsList/Set.
- create/add/remove parameter names dvm -> feed, publicDvms/privateDvms
-> publicFeeds/privateFeeds; public/private accessors
publicFavoriteDvms/privateFavoriteDvms -> publicFavoriteAlgoFeeds/
privateFavoriteAlgoFeeds. ALT string updated.
- EventFactory + LocalCache dispatch branches + AccountSettings backup
field type + FavoriteDvmListState + FavoriteDvmListDecryptionCache all
import the new type. Internal amethyst-side classes
(FavoriteDvmListState, FavoriteDvmListDecryptionCache), the top-nav
filter classes (FavoriteDvm*, AllFavoriteDvms*) and the orchestrator
keep their names — they still deal with content-discovery DVMs
specifically, and the narrower rename here is scoped to the Nostr
wire format the user was asking about.
- Quartz test renamed + rewired. Build + tests green on both modules.
Two interacting bugs were still eating badges when the user toggled
switches in the profile-badges settings page:
1. TimeUtils.now() returns seconds, and LocalCache.consumeBaseReplaceable
only accepts an update whose createdAt is strictly greater than the
one already stored. Two toggles within the same second produced
equal-timestamp events, so the second was silently dropped from
the cache — the UI reverted after a beat and the change looked
like it had never happened.
2. launchSigner coroutines run on Dispatchers.IO so two concurrent
toggles could both read the same pre-state, each write its own
fragment, and whichever landed last clobbered the other.
Wrap the read-modify-write with a Mutex and bump the outgoing
createdAt to maxOf(now, latestCachedCreatedAt + 1) so every write is
strictly newer than whatever sits in cache. The sign + local consume
happen under the lock; network publish stays outside it.
PdfRenderer.Page.render() only accepts ARGB_8888 bitmaps; RGB_565 is
silently rejected (the renderer produces no output), which is why the
preview card and viewer both stopped showing anything. Go back to
ARGB_8888 and update the memory estimates in the comments. The other
perf wins from 49e913b (FilterQuality.Medium, 4096 hi-res cap, 1.5x
threshold, remembered ImageBitmap wrapper) are unaffected and stay.
Three fixes to the Profile-badges flow:
1. TagArrayBuilder groups tags by name, so calling acceptedBadges() on
the builder scrambled [a1, e1, a2, e2] into [a1, a2, e1, e2] when
serializing. AcceptedBadge.parseAll expects adjacent (a, e) pairs,
so only one mangled badge survived, making each Accept toggle
appear to replace the previous one. Rewrite the build() of both
ProfileBadgesEvent (kind 10008) and AcceptedBadgeSetEvent (kind
30008) to collect the prefix tags (d / alt / initializer) via the
builder, then append AcceptedBadge.assemble(...) verbatim to keep
the pair order intact.
2. Rows in ProfileBadgesScreen were not clickable. Thread nav through
AwardRow / StaticAwardRow and wrap the row body in Modifier.clickable
that routes to the badge definition's thread. The Switch keeps
consuming its own clicks, so toggling still works.
3. Sort accepted badges to the top of the list, then the rest by
createdAt desc, so the user can see at a glance which badges are
currently shown on the profile.
The main cost during a live pan/zoom is the GPU re-sampling the page
bitmap every frame under the zoomable modifier's transform. Three
changes bring that cost down substantially:
- Bitmap.Config.RGB_565 instead of ARGB_8888. PDFs are opaque, so the
alpha channel is unused. Halves texture memory and GPU upload
bandwidth; visually identical.
- HI_RES_MAX_DIM_PX lowered from 6144 to 4096. 4096 stays within the
common GPU texture-size limit, keeping rendering hardware-accelerated
on mid-range devices. Peak bitmap is now ~24 MB (A4, RGB_565) instead
of ~107 MB (ARGB_8888, 6144).
- FilterQuality.Medium (bilinear) instead of High (bicubic/Mitchell).
High is recomputed per frame during pan/zoom and is the main source
of jitter on multi-megapixel sources. At 3072-4096 px base resolution
bilinear is effectively indistinguishable.
- HI_RES_ZOOM_THRESHOLD raised from 1.2 to 1.5 so we don't trigger a
costly re-render for marginal zoom levels where the base is fine.
- Cache the ImageBitmap wrapper via remember to avoid per-recomposition
allocations.
PdfRenderer.Page.getWidth()/getHeight() return the page size in
PostScript points (1/72"), so for a standard A4 that's 595 x 842
"pixels" passed to cappedRenderSize. The old early-return kept native
dimensions whenever longest <= targetDim (which was always), so the
base bitmap was 595 x 842 regardless of what we asked for — effectively
72 DPI. Zoom-aware re-renders hit the same early return and also
stayed tiny, which is why double-tap produced no visible improvement.
Remove the early return: since PDFs are vector, always rescale the
point dimensions so the longest side equals targetDim. Base renders
now produce ~3072 px bitmaps and the hi-res path actually goes to
6144 px when zoomed.
- User-facing rename. All user-visible strings switch from "favourite"
to "favorite" (American spelling) and from "DVM(s)" to "Feed
Algorithm(s)": settings entry, spinner group label, empty state,
banner messages, menu accessibility labels. Code identifiers still
reference NIP-90's "DVM" protocol name since that's the wire spec.
- Cold-start race. When the app relaunches with a persisted
TopFilter.FavoriteDvm, the AppDefinitionEvent may not be in cache
yet. mergeInterests was filtering out any favorite whose
AppDefinitionEvent didn't yet advertise kind 5300, so the spinner
didn't include a chip matching the persisted selection — it
showed "Select an option" while the orchestrator quietly fired the
RPC with no UI to ground it. Always include every favorite; the
5300 check at add time (in FavoriteDvmToggle) is enough.
SubcomposeAsyncImage was being called with just the URL (or local
File), so Coil auto-sized the decode target to the composable's
layout bounds. In the feed that's desirable — a small thumbnail
decode — but in the zoomable dialog the composable is fillMaxWidth
(~screen width), and pinch-zooming then GPU-upscales the already
downsampled bitmap, producing the same blurriness the PDF viewer
had before.
Add a fullResolution: Boolean = false flag to UrlImageView and
LocalImageView. When true, swap the model for an ImageRequest with
size(Size.ORIGINAL) so Coil decodes at the image's native
dimensions. Feed call sites keep the default (fast, sampled). Both
dialog call sites in ZoomableContentDialog now pass
fullResolution = true, so pinch-zoom shows native pixels.
The existing blurhash/aspect-ratio placeholder path already covers
the brief high-res load window in the dialog.
Revert of 93cf9f1 restored the BadgeCard chrome that works well when
embedded inside another NoteCompose (e.g. a BadgeAwardEvent's body).
But the badge feed was still bypassing NoteCompose's author header and
ReactionsRow because BadgeDefinitionEvent was hoisted out of
CheckNewAndRenderNote up at the top of NoteCompose.
Move BadgeDefinitionEvent into RenderNoteRow next to BadgeAwardEvent
so it flows through the same chrome path. Feed items now get:
- the author avatar / name / timestamp header
- the existing BadgeDisplay card body
- the standard ReactionsRow (reply / repost / zap / like)
Other call sites of BadgeDisplay are untouched:
- RenderBadgeAward still embeds BadgeDisplay as a child card
- BadgeCompose notifications still embed BadgeDisplay
- DisplayBadges profile strip uses BadgeThumb, not BadgeDisplay
nrobi144