Clears real Kotlin compiler warnings surfaced across quartz, cli,
relayBench, amethyst, and desktopApp:
- quartz Sha256/EventHasher/ScratchLocal: ThreadLocal.get() is nullable
in Kotlin; assert non-null (withInitial never yields null).
- quartz GitHttpClient: PriorityQueue.poll() under isNotEmpty() is
non-null; assert it.
- relayBench CorpusDownloader: drop redundant !! on smart-cast Long;
Jackson fields() -> properties().
- cli GrapeRankCommand: drop redundant ?. where latest is smart-cast.
- PodcastRemoteContent: OkHttp body is non-null; drop dead elvis.
- Dead/redundant expressions: remove no-op when-branch values and a
redundant trailing Unit (HomeScreen, LocalCache, EmbeddedTabLayer,
ParticipantHostActionsSheet, NestActionBar, ControlWhenPlayerIsActive,
ShareNoteAsImageScreen exhaustive-when else).
- CalendarEventDetailScreen / SetPasswordDialog / ProfileClinkOfferResolver:
drop always-true conditions (reorder to keep smart-casts).
- WalletColumnScreen: OkHttp body non-null; drop unreachable null-guards.
- PcmTapRegistry: the @OptIn used androidx.annotation.OptIn, which does
not opt into Kotlin's ExperimentalCoroutinesApi; use kotlin.OptIn.
- GitRepositoryScreen: suppress the standard ViewModel-factory cast.
- PushNotificationReceiverService: suppress override-of-deprecated.
- Desktop GlobalScope call sites: @OptIn(DelicateCoroutinesApi::class).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016GMqkg1ndvFihEwZcENiRs
One-line summary log after loadKind3ViaOutbox so reviewers and manual
testers can confirm the outbox pipeline actually fired without wiring
in a full metrics collector. Shape:
DEBUG: [WotOutbox] fetchKind3Only authors=N covered=M fallback=K
kind10002=X kind3=Y
Zero overhead when the log level is above DEBUG.
Extends the messaging privacy lock to the Wallet deck column via the
same master `lockEnabled` flag (single toggle, single password) with
per-scope lock state so each route re-locks independently.
commons/ui/privacylock/
LockScreen.kt Shared internal composable (scope + copy)
WalletLockGate.kt Mirrors MessagesLockGate for scope=Wallet
MessagesLockGate.kt Shrunk to a 20-LOC wrapper delegating to LockScreen
desktopApp/security/
DesktopLockScreen.kt Shared password-input surface with optional
"No password set" deep-link (plan Q5).
DesktopMessagesLockGate.kt Now delegates to DesktopLockScreen
DesktopWalletLockGate.kt New; deep-links to Settings via
onNavigateToRelays when no password is set
WalletFirstRunBanner.kt Mirrors MessagesFirstRunBanner; both read
the single firstRunCardSeen flag (dismiss
once = dismissed everywhere)
MessagesFirstRunBanner.kt Copy updated: "Lock Messages and Wallet?"
PrivacyLockBlurModifier.kt Modifier.privacyLockBlurWhenUnfocused()
reads LocalWindowInfo.isWindowFocused;
applied to text nodes only (balance,
generated-invoice amount, QR code) — cards
and layout stay crisp (plan Q4).
desktopApp/ui/
wallet/WalletColumnScreen.kt Inserts WalletFirstRunBanner at top;
wraps sensitive text with blur modifier.
deck/DeckColumnContainer.kt Wraps Wallet branch with
DesktopWalletLockGate; passes
onNavigateToRelays so the "No password"
branch deep-links to Settings.
settings/PrivacyLockSettingsScreen.kt
Master-lock copy: "Enable privacy lock"
header; body mentions Messages AND Wallet
columns; auto-lock + caveat cards updated
to reference both routes.
Testing sheet: docs/plans/2026-07-07-wallet-lock-manual-testing.md
12 manual scenarios covering cross-scope lockout, blur-on-unfocus,
password-clear cascade, deep-link to Settings, and first-run banner
parity across the two routes.
All existing PrivacyLockStateTest cases green + the 3 Wallet-reuse
tests from the previous commit. amethyst + desktopApp compile clean.
Phase 3 of the outbox refactor (PR #3483, per Vitor's directive). The
WoT service's kind-3 seeding on Desktop and the `amy wot sync` verb now
go through OutboxDispatcher — index relays discover each author's
kind-10002 write relays, then per-outbox-relay REQs fetch kind-3.
Changes:
Desktop:
- DesktopRelaySubscriptionsCoordinator gains an inner
OutboxCacheGateway that bridges DesktopLocalCache
(cachedAdvertisedRelayList / consume) to OutboxDispatcher.
- New suspend loadKind3ViaOutbox(pubkeys) method returns the
dispatcher's Result for observability.
- Main.kt WoT-seed effect now:
1. gates on wotService.isDisabled to preserve MAX_FOLLOWS
guardrail (fix 2 from Phase 1)
2. calls loadKind3ViaOutbox instead of the direct
loadKind3Batched on index relays
3. keeps the 2s markReady safety net for cold-start UX
- clear() now also clears outboxDispatcher's dedup markers.
amy:
- WotCommand.sync rewritten to construct an OutboxDispatcher, buffer
events in the gateway, and persist to ctx.store after fetch
returns (store.insert is suspending; can't call from non-suspend
gateway callbacks).
- --json output additively gains kind10002_received,
outbox_covered_authors, fallback_authors, persisted keys.
- --timeout N still supported; now maps to overallTimeoutMs.
Not in this commit (deferred to a follow-up on same PR if reviewers
want it):
- Routing stranger-avatar kind-0 fetch through the outbox path
(MetadataPreloader wiring is more invasive; keeps this diff focused
on the primary WoT concern).
Plan: commons/plans/2026-07-06-fix-wot-outbox-model-and-review-fixes-plan.md
Reviewer Vitor (PR #3483): stop blasting kind 0/3 REQs at a static index
relay list. Use NIP-65: index relays discover each author's kind-10002,
then per-author kind 0/3 REQs go to that author's declared write relays.
New in commons/commonMain:
- OutboxCacheGateway — platform-agnostic bridge to the local event
cache. Three ops: cachedOutbox(pubkey), onOutboxDiscovered(event,
relay), onDiscoveredEvent(event, relay).
- OutboxDispatcher — three-phase pipeline reusing Quartz's existing
RelayListRecommendationProcessor.reliableRelaySetFor(...) for the
author→relay inversion + minimal-cover algorithm.
Phase 1: REQ kind-10002 for authors not already cached, from
index relays. Per-relay 4s timeout.
Phase 2: reliable-relay-set → per-outbox-relay REQ for kind 0
and/or kind 3 filtered to that relay's authors.
Phase 3: index-relay fallback for authors that never returned
a 10002. Preserves current behaviour on cold accounts.
Retries the "not in kind*Succeeded and not in kind*InFlight" set so
a zero-EOSE run is retryable on the next call.
New in DesktopLocalCache:
- route() branch for AdvertisedRelayListEvent (kind 10002) storing in
addressableNotes so cachedAdvertisedRelayList(pubkey) can serve
future lookups without a REQ.
- cachedAdvertisedRelayList(pubkey): AdvertisedRelayListEvent? — the
gateway's peek into the cache for Phase-1 skipping.
Tests (7): cached-outbox-skips-Phase-1, Phase-1-discovers-then-Phase-2,
Phase-3-fallback-for-no-10002, cached-author-covered-when-Phase-1-hangs,
clear-releases-dedup, concurrent-EOSE-safety.
Plan: commons/plans/2026-07-06-fix-wot-outbox-model-and-review-fixes-plan.md
Genericises the messaging privacy-lock state holder so a single master
`lockEnabled` flag can drive multiple gated routes independently:
- `LockScope { Messages, Wallet }` enum added.
- `MessagesLockState` → `PrivacyLockState(scope, settings, coroutineScope)`.
Each scope keeps its own StateFlow<LockState> + idle-timer Job; both
scopes share the same `PrivacyLockSettings` so failed-attempt counters
and lockout schedule stay device-global (brute-force protection).
- `LocalMessagesLockState` (single instance) → `LocalPrivacyLockState`
(Map<LockScope, PrivacyLockState>) + `lockStateFor(scope)` accessor.
- `redactionLevel` → `dmRedactionLevel` (Kotlin-side rename; persisted
prefs key `redaction_level_ordinal` unchanged).
- `setPasswordHashed(null)` cascades to `setLockEnabled(false)` so a
master lock cannot stay armed without a credential to verify against.
MessagesLockGate, DesktopMessagesLockGate, MessagesFirstRunBanner,
SetPasswordDialog, and RedactionCard now read `lockStateFor(Messages)`
— behaviour-preserving. Ships 3 new PrivacyLockStateTest cases:
independent per-scope state, shared failed-attempt counter, and the
password-clear cascade.
Plan: docs/plans/2026-07-07-feat-wallet-privacy-lock-reuse-plan.md
Reviewer davotoula (PR #3483) flagged three commons/wot issues that would
bite the Android app on adoption:
2. Guardrail bypass. handleFollowSet assigned myFollows before the
MAX_FOLLOWS check, so subsequent applyKind3 calls whose follower
landed in the huge set fully repopulated reverseIndex/_scores —
defeating the "skip WoT for mega-follow accounts" promise. Fix:
check size FIRST, clear myFollows, expose a disabled StateFlow, and
early-return handleKind3 while disabled. Guardrail also releases
itself when the follow set later shrinks back under the cap.
3. No teardown API. WoTService owned a writer coroutine + ops Channel
but had no close(). On account switch a new instance was created
while the old one leaked its writer. Fix: implement AutoCloseable;
close() shuts the channel so writerLoop exits and post-close
trySend calls are dropped silently. Main.kt wires it via
DisposableEffect(iAccount) so account switch is a clean teardown.
4. Misleading docs. KDoc claimed Snapshot.withMutableSnapshot conferred
per-key isolation. That's a SnapshotStateMap property, not a
withMutableSnapshot property; the wrap only coalesces an op's
writes into a single Compose commit. Rewritten to be accurate so
future integrators don't trust the wrong invariant.
Tests: existing guardrail test extended with isDisabled assertion, plus
new tests for guardrail-holds-under-applyKind3, guardrail-releases-when-
follow-set-shrinks, close-stops-accepting-ops, and close-is-idempotent.
Plan: commons/plans/2026-07-06-fix-wot-outbox-model-and-review-fixes-plan.md
Reviewer davotoula (PR #3483) flagged a P0 race in
DesktopLocalCache.consumeContactList: lastContactListByAuthor was stamped
before the self-check. During login, hydration launched on Dispatchers.IO
before Main.kt's LaunchedEffect bound accountPubkey. If the user's own
cached kind-3 hydrated first, the map got poisoned; the same event later
arriving from a relay was rejected by the createdAt gate, _followedUsers
stayed empty, and FollowAction.follow would call createFromScratch and
wipe the real follow list.
Two-part fix:
1. Reorder Main.kt so localCache.accountPubkey is set before hydration
launches. Also clear the pubkey on logout and on account switch.
2. Belt-and-braces: consumeContactList now only stamps
lastContactListByAuthor inside branches where we know self identity.
When accountPubkey is null (login/hydration window), skip the stamp so
the relay retry that arrives after bind can populate _followedUsers.
Regression tests reproduce the "hydrate before bind, replay after bind"
scenario and confirm the follow set populates on retry.
Plan: commons/plans/2026-07-06-fix-wot-outbox-model-and-review-fixes-plan.md
On Desktop, tapping a sidebar nav item while a detail screen (profile,
thread, article, editor) was open only mutated the sidebar destination.
The opaque `AnimatedContent` overlay driven by `ColumnNavigationState`
kept covering the (already-swapped) root content until the user hit
Back, creating the impression that the click did nothing.
Fix: emit a `clearOverlaySignal` from `SinglePaneState.navigate` and
`DeckState.focusExistingColumn`. Each layout collects the signal in a
`LaunchedEffect` and calls `navState.clear()`, draining any pending
detail stack so the tapped destination is what the user actually sees.
- SINGLE_PANE: one signal (Unit), one layout-local `navState`.
- DECK: signal payload is the column id; each `DeckColumnContainer`
filters on `column.id`, so only the focused column's detail clears —
other columns' navigation stacks are preserved.
- Same-item taps also clear (signal fires unconditionally, unlike a
StateFlow value comparison).
- `onOpenSettings` uses the same navigate / focusExistingColumn paths
and inherits the fix automatically.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Relocates the shared index-relays editor off the Configure/Settings
screen and into the Relays column's Configure tab as a 6th collapsible
section next to Connected / NIP-65 / DM / Search / Blocked relays —
where users already look for relay-list editing.
Rewrites the section to match the SearchRelayEditor pattern: local
SnapshotStateList buffer seeded from the persisted set, OutlinedTextField
with a compact IconButton(Add), per-row Close remove, Enter-key add,
plus a Save button that commits the buffer to PreferencesIndexRelays and
a Reset-to-defaults button that reseeds the buffer with the 4 built-in
defaults. Adds a savedMessage toast noting the 'restart to apply' caveat.
File moved: desktop/ui/settings/IndexRelaysSection.kt →
desktop/ui/relay/IndexRelaysEditor.kt (matches the *Editor.kt sibling
naming convention).
Unifies the "index relays" set (used for kind 0 profile metadata and
kind 3 follow list REQs) across the Desktop app and the `amy` CLI so
they always compute WoT scores against the same data source, and adds
a user-configurable settings section for the list.
Before this change:
- Desktop hard-coded `DefaultRelays.RELAYS` at coordinator
construction; users could not override.
- `amy wot sync` used `outboxRelays().ifEmpty { inboxRelays() }` —
NIP-65 write / DM inbox relays, which are semantically different
from index relays. `amy wot get` after `amy wot sync` could return a
different score than the Desktop UI would compute.
New `PreferencesIndexRelays` (commons/jvmMain) is a tiny class backed
by `java.util.prefs.Preferences.userRoot().node("com/vitorpamplona/amethyst/relays/index")` —
the same JVM-user-scoped shared-node trick `PreferencesHashtagSpamSettings`
already relies on. Both Desktop and amy running as the same OS user
observe the same value with zero extra plumbing. App-global (not
per-account); users typically have one preferred index-relay set
regardless of which account is logged in.
Behaviour changes for users who never open the settings UI: none.
`DEFAULT_INDEX_RELAYS` is byte-for-byte identical to the four URLs in
`DefaultRelays.RELAYS`.
Wiring:
- `DesktopRelayCategories` gains a straight-through `indexRelays`
StateFlow (no combine — index relays are a curated user choice, not
a NIP-65-derived set) plus `setIndexRelays(new)`.
- `Main.kt` instantiates `PreferencesIndexRelays` at App() root and
passes it into both the subscriptions-coordinator constructor and
`DesktopRelayCategories`. Coordinator snapshots the effective set
at construction — changes take effect on next relaunch (documented
in the settings section explainer).
- `Context.indexRelays()` reads the same preferences node so
`WotCommand.sync` produces identical relay batches to Desktop.
- New `IndexRelaysSection` composable in
`desktopApp/.../ui/settings/` — list + per-row remove + add-row
with URL normalisation. Deletion of all entries falls back to
defaults (delete-all is the reset — no separate "Reset" button).
Placed between the Local Relay and Content Filters sections of the
Relays settings screen.
Tests:
- `PreferencesIndexRelaysTest` — defaults fallback, round-trip
persistence, blank-token skipping, non-empty defaults guardrail.
- Full existing test suites remain green.
Companion PR (search-result badges) landed on `feat/wot-search-badges`
and is this branch's parent. Both remain stacked on the WoT feature
branch pending upstream review.
Plan: docs/plans/2026-07-01-feat-wot-followups-search-badges-and-index-relays-plan.md
Extends the WoT trust indicator to the Search screen's person-picker
results, matching the badges already shown on note-card avatars.
- `UserSearchCard` (commons) gains an optional
`badge: @Composable (BoxScope.() -> Unit)? = null` param, forwarded
to its embedded `UserAvatar` (which has the slot from the WoT PR).
Default null → no visual change for callers that don't opt in;
Android search screens continue to render as before.
- `SearchResultsList` (desktopApp) inlines the score-lookup gates in
a small `wotBadgeFor(pubkey)` helper and passes the badge lambda at
both person-result call sites (main list + expandable overflow).
Same visibility rules as the note-card avatar badges:
score > 0, past the 2 s startup readiness gate, and pubkey not in
`LocalSpamExemptKeys` (self / already-followed).
DesktopLocalCache stores Users in a WeakReference-backed LargeSoftCache. The
followee User in kind3IsHydratedBeforeKind0SoMetadataLoadsForFollowedAuthors is
created only during hydrate's kind:0 phase and has no Note referencing it, so it
is only weakly reachable once hydrate returns. A GC landing between hydrate()
and the assertions evicted it, flaking the test (reproduced deterministically by
forcing System.gc()).
Pin a strong reference to the followee's User for the duration of the test so
the cache cannot evict it, mirroring how followed users stay reachable via live
account/UI state in the running app. The ordering invariant the test asserts is
unaffected.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NHQ3g7wD9WbDvj7NspiAWW
- align voice-file debug log with deleteOrWarn's is-gone contract
- Convert the delete-then-warn sites the sweep left hand-rolled in already
touched files: ThumbnailDiskCache corrupt-file and temp-thumbnail cleanup,
NappletBlobCache.put leftover temp, and SecureKeyStorage's bare delete of
the fallback key file (the highest-stakes delete in that file).
- Drop the exists() guards left layered over deleteOrWarn — the helper
already treats an absent file as silent success.
- Collapse AccountManager's legacy-file triple into a loop and drop the
stale "silent" from its comment.
- Snapshot lastModified alongside length in NappletBlobCache.trimToSize so
sortedBy compares in-memory values instead of stat-ing per comparison.
- Promote DesktopTorManager's private restrictToOwner into a shared
File.restrictToOwner(tag) in commons (600 files / 700 dirs) — the repo's
sixth private copy of this pattern was one too many; the remaining copies
can migrate incrementally
TcpNoDelaySocketFactory's connecting overloads used
`socket().apply { connect(...) }`, which leaks the file descriptor if
bind/connect throws (the JDK's connecting Socket constructors close on
failure; ours didn't). Wrapped in a helper that closes on throw. OkHttp
only calls the no-arg overload, so this guards any other direct caller.
DesktopHttpClient's pre-init `simpleClient` (direct relay sockets opened
before setInstance) now gets the same TcpNoDelaySocketFactory as
directClient. failClosedClient is left as-is: it's a SOCKS client and
OkHttp bypasses the socket factory for SOCKS proxies.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TtDNpayEYvJH7QuPswND3A
Found while attributing the small-REQ wire floor (backlog item 6,
latency half): geode's new WireReqFloorBenchmark measured a flat
43.7 ms per REQ round trip that survived every server-side change —
store configs, dispatchers, the pump — and then vanished when the
round's preceding CLOSE was dropped. Root cause is client-side: OkHttp
does not set TCP_NODELAY, relays never answer a CLOSE (NIP-01), so its
bytes sit unACKed for the peer's ~40 ms delayed-ACK window and Nagle
holds the next REQ behind them. CLOSE-then-REQ is a Nostr client's
hottest pattern — every feed/filter switch.
relayBench's harness client already shipped a no-delay socket factory
(which is why benchmark numbers never showed the stall) but the
production clients did not. New TcpNoDelaySocketFactory (quartz
jvmAndroid, next to BasicOkHttpWebSocket) is now used by the Android
relay pool factory, the Desktop relay client, amy's relay connections,
and geode's mirror worker. Direct connections only — SOCKS/Tor paths
are untouched.
With the factory, the benchmark puts geode's ~21-row REQ at ~1.25 ms
on the wire (matching relayBench): ~0.6 ms Ktor CIO+OkHttp loopback
floor, ~0.5 ms per-REQ server work (already investigated). Per-frame
burst cost measured negligible and the pump adds ~nothing, so the
send-path latency angle of backlog item 6 is closed as not-a-problem;
its ingest-CPU share remains a separate throughput question. Findings
recorded in quartz/plans/2026-07-04-small-req-floor.md.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TtDNpayEYvJH7QuPswND3A
Passes decoder = CachingEventDecoder() at all four NostrClient
construction sites: the Android app pool (AppModules), the Android
crawl client (buildCrawlClient — Event Sync / Cashu discovery, the
duplicate-heaviest path), the desktop RelayConnectionManager, and
amy's Context. Duplicate EVENT frames (14-57% of production traffic)
now skip the full JSON re-parse; dispatch semantics unchanged.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018saXqYfAa3RvSJoDXK591R
Rework the Amethyst Desktop notification experience end-to-end.
**In-app inbox** (`desktopApp/…/ui/NotificationsScreen.kt`)
- Dedicated Notifications entry in the sidebar and a new
`DeckColumnType.NotificationSettings` overlay reachable from a ⚙ button
in the column header — back button renders automatically via
`navState.hasBackStack` in deck mode and via body Back in single-pane.
- Redesigned column: filter tabs (All / Mentions / Replies / Reactions /
Zaps / Reposts / DMs) with per-kind counts, grouped cards (reactions
and reposts collapse to "N reactions on your post" per day), unread
dots driven by a persisted `lastReadAt` per pubkey, freshest-first
ordering via `compareByDescending { timestamp }`.
- User metadata: avatars + display names on every row (including reactor
strip inside grouped cards) resolved from `LocalCache`, with
`metadataVersion` observation. Zap sender is the actual zapper (via
`NotificationItem.effectiveAuthorPubKey` unwrapping
`LnZapEvent.zapRequest.pubKey`), not the LNURL provider.
- Reaction/repost group cards are clickable → thread; DM cards click →
Messages column; expandable to show note preview + reactor list.
- `NotificationSettingsScreen`: master toggle, 7 per-kind toggles,
manual-DND dropdown, preview-privacy switch, per-platform status
card, "Send a test toast". Permission-aware button adapts across
NotRequested → Granted / Denied / BundleRequired with a macOS System
Settings deep-link. State syncs with OS-level changes via
`LocalWindowInfo.isWindowFocused` regain refresh.
**Native OS notifications** (`commons/…/moderation/notifications/`)
- `NotificationDispatcher` interface + `PermissionState` sealed
hierarchy in `commonMain`. JVM impl `NucleusNotificationDispatcher`
routes through Nucleus (three per-OS artifacts: macOS
`UNUserNotificationCenter` via Swift/JNI, Windows WinRT toast via
JNI, Linux libnotify via D-Bus). Falls back to `AwtTrayNotifier` when
native lib fails to load. Async `requestPermission` +
`refreshPermission` bridge Nucleus's callback API to `suspend`.
- `DesktopNotificationAutoDispatcher` subscribes to
`DesktopLocalCache.eventStream.newEventBundles` and fires OS toasts,
applying a 9-check suppression pipeline: kind allow-list, master
toggle, per-kind toggle, DND, window-focused, cold-boot
(event.createdAt < sessionStart or >30s stale), macOS permission,
semantic accept, 30s per-(kind,event-id) dedupe. Wired in Main.kt
with DisposableEffect(loggedIn.pubKeyHex); window focus tracked via
LocalWindowInfo → StateFlow.
- Adds `windows { menu = true; shortcut = true }` to
`desktopApp/build.gradle.kts` so AUMID persists and Windows toasts
survive reboot.
**Shared notification filter** (`commons/…/moderation/notifications/NotificationKinds.kt`)
- Extracted from Android's `NotificationFeedFilter`. Exposes
`SUBSCRIPTION_KINDS` (13 kinds: text, DMs kind 4 + 14 + 1059
gift-wrap, encrypted-file-header, comments 1111, reactions, reposts,
generic reposts, channel messages 42, nutzaps 9321, zap receipts
9735, onchain zaps 8333), `subscriptionFilter(pubKey, since, limit)`
builder that `FilterBuilders.notificationsForUser` delegates to, and
`tagsAnEventForUser(event, myPubKey, isTargetAuthoredByMe)` semantic
gate. Reactions/reposts require target-author-match; other kinds
require `p=me`. Fixes a bug where the helper defaulted to accept and
let cache-seed leak "mentioned you" notifications from unrelated
text notes.
- Android's `NotificationFeedFilter.NOTIFICATION_KINDS` now spreads
`SUBSCRIPTION_KINDS` + Android-only extras (badges, git, highlights,
polls, videos, voice, live-activities), so a change on either side
propagates. Downstream push consumers (`NotificationDispatcher.kt`,
`EventNotificationConsumer.kt`) read the resulting set transparently.
- Content sanitizer strips control chars, RTL overrides, zero-width
chars, and URLs from toast titles. DM cards never render ciphertext
body (decryption pipeline deferred).
**Tests** — `NotificationKindsTest` covers 17 scenarios: reactions
target-author-mismatch rejection, own-event rejection except zap kinds,
p-tag routing for text/DMs/zaps/nutzaps/gift-wraps/channel messages,
`SUBSCRIPTION_KINDS` sanity + `subscriptionFilter` shape.
**Testing constraint**: macOS OS notifications require a bundled
process. `gradle run` will always show BundleRequired — use
`gradle :desktopApp:runDistributable` and open the resulting
`Amethyst.app`. First permission grant surfaces the app in
System Settings → Notifications.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Part C of the dispatchers/thread-caps audit. Both LnurlEndpointCache and
DesktopCachedRichTextParser were bounded caches backed by a LinkedHashMap
behind a single monitor (@Synchronized / Collections.synchronizedMap with
accessOrder). An access-order map structurally mutates on get, so every
read took the lock — serializing all readers on paths that are hot
(kind-9735 zap-receipt validation; feed rich-text rendering).
Add ConcurrentLruCache<K, V> in quartz utils: storage is a
ConcurrentHashMap so get is lock-free; writes + eviction run under a small
write lock that is off the read path. Eviction is least-recently-put order
(get does not refresh recency) — exactly what LnurlEndpointCache already
did, and fine for the deterministic rich-text parse cache.
Point both caches at the shared helper. Covered by a new
ConcurrentLruCacheTest (round-trip, eviction order, re-put recency
refresh, get-does-not-refresh, clear, and a concurrent size-bound smoke
test); the existing LnurlEndpointCacheTest still passes unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ANuUziXKRafSTBxbh4SMoq
The consumeContactList scoping fix means kind-3 events only update
`_followedUsers` when `event.pubKey == accountPubkey`. Tests were
constructing a fresh DesktopLocalCache() (accountPubkey = null) and
publishing kind-3s authored by `userPubKey` / `ownerPubKey`, so the
guard silently rejected them and `followedUsers` stayed empty.
Bind `accountPubkey` in the test setup so the guard passes.
Adds a friends-of-friends trust score on every user avatar in Desktop
feeds, threads, profile headers, and repost overlays. For pubkey X the
score is the count of accounts in the active user's follow set who also
follow X — Gossip / Snort convention. v1 is display-only; no threshold
filtering.
Data flow
- `commons/wot/WoTService` — sparse `SnapshotStateMap<HexKey, Int>` +
reverse index + per-follower snapshot for diff-based updates.
Single-writer coroutine (Channel<Op> → `Snapshot.withMutableSnapshot`)
serializes all mutations. Cap at 5000 follows/event blocks DoS via
hostile kind-3s. Guardrail at 2000 follows/account skips WoT for
mega-accounts.
- `DesktopIAccount.wotService` — per-account instance, matches
`Kind3FollowListState` / `BookmarkListState` conventions.
- `Main.kt` binds `localCache.accountPubkey`, collects
`localCache.contactListEvents` → `applyKind3`, collects
`localCache.followedUsers` → `onFollowSetChange` +
`subscriptionsCoordinator.loadKind3Batched(...)` with
`onEose = markReadyOnce`. 2 s fallback timeout guarantees badge
visibility even if index relays never EOSE.
- `FeedMetadataCoordinator.loadKind3Batched(pubkeys, onEose)` — chunks
authors into ≤100 per Filter within one subscription. Matches
nostr-rs-relay defaults.
UI
- `commons/ui/components/UserAvatar` gets an optional
`badge: @Composable BoxScope.() -> Unit`. Android call sites pass
null (no compile-time coupling to Desktop-only tooltip APIs).
- `desktopApp/.../ui/note/WoTBadge` — Material3 `TooltipBox` +
`PlainTooltip` (multiplatform-ready, keyboard/screen-reader a11y).
`rememberTooltipState(isPersistent = true)` fixes the
vanish-too-fast desktop default.
- `desktopApp/.../ui/note/WoTBadgedAvatar` — drop-in replacement for
`UserAvatar` that overlays the badge when
`LocalWoTService != null && LocalWoTReady && pubkey !in LocalSpamExemptKeys`.
Score read is a plain `service.scores[userHex] ?: 0` — snapshot
system tracks per-key, so avatars only recompose when their own
score changes.
- Call-site migration at 4 v1 surfaces: NoteCard header (covers feed /
thread / bookmarks / search / QuotedNoteEmbed via NoteCard),
FeedNoteCard repost header (2 avatars), UserProfileScreen header
(2 sizes).
Amy verbs
- `amy wot get <pubkey|npub> [--json]` — hydrates a WoTService from the
local FsEventStore, prints score for target pubkey.
- `amy wot list [--threshold N] [--limit K] [--json]` — sorted score
list.
- `amy wot sync [--timeout N]` — batch-fetches kind-3 for the active
follow set from outbox/inbox relays, persists to the event store.
Tests + docs
- 14 unit tests: `WoTServiceTest` covers happy path, sparse map,
self/follower exclusion, kind-3 churn diff, guardrail, event cap,
ready gate, clear.
- Manual testing sheet with 17 scenarios at
`desktopApp/plans/2026-07-01-wot-score-manual-testing-sheet.md`.
- Plan at `docs/plans/2026-07-01-feat-desktop-wot-score-plan.md`.
Prerequisite `DesktopLocalCache.consumeContactList` scoping fix landed
as a separate commit.
The old implementation tracked kind-3 replaceability with a single global
`lastContactListCreatedAt` scalar and unconditionally overwrote
`_followedUsers` on every accepted event. Once *any* subsystem starts
fetching other users' kind-3 events (WoT scoring, mutual-follow lookups,
etc.), a newer-createdAt kind-3 from a follower silently hijacks the
active user's follow-set state, cascading into feed filters, mute logic,
and sidebar counts.
Fix by tracking newest-per-author (`ConcurrentHashMap<HexKey, Long>`) and
guarding writes to `_followedUsers` / `lastContactListEvent` on
`event.pubKey == accountPubkey`. `accountPubkey` is bound from `Main.kt`
on login.
Also expose `contactListEvents: SharedFlow<ContactListEvent>` (buffer 64,
DROP_OLDEST) so downstream consumers (the incoming WoT service) can
observe every accepted kind-3 without adding a bespoke listener API.
relay.nostr.band has been decommissioned. Remove it from every runtime
relay list and route search-relay defaults through the shared
AmethystDefaults.DefaultSearchRelayList in commons:
- amy NipCommand: SEARCH_RELAYS now = DefaultSearchRelayList (drops the
hardcoded relay.nostr.band/nostr.wine pair; RelayUrlNormalizer import
no longer needed).
- desktop DesktopRelayCategories: DEFAULT_SEARCH_RELAYS now =
DefaultSearchRelayList instead of a single relay.nostr.band entry
(which would otherwise be empty after removal).
- desktop DefaultRelays and FollowPacks DISCOVERY_RELAYS: drop
relay.nostr.band.
- Update NIP-50 example hostnames in desktop comments, the search-relay
editor help text, and the localized search_relays_not_found_examples
string across all locales to nostr.wine.
Preview sample data, captured sample-event JSON, and quartz test
fixtures that mention relay.nostr.band are left untouched (no runtime
effect).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011Ttcqa3V78bugGraGhtehj
relay.damus.io is being decommissioned, so remove it from every runtime
default/fallback relay set to stop the app and amy from wasting connection
slots on a dead host:
- commons Constants: remove `damus`; it dropped out of `bootstrapInbox`
(default NIP-65 inbox) and `eventFinderRelays` (default outbox/fallback),
both still carrying 6 healthy relays.
- ChessConfig: remove damus from CHESS_RELAYS / CHESS_RELAY_NAMES, leaving
the 3 relays the FETCH_TIMEOUT comment already assumes.
- desktop DefaultRelays: remove damus and the also-dead relay.snort.social.
- desktop FollowPacks DISCOVERY_RELAYS: remove damus.
- amy NipCommand SEARCH_RELAYS: swap damus for the NIP-50-capable nostr.wine.
Comments, @Preview sample data, and test fixtures that mention damus.io are
left untouched — they have no runtime effect.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011Ttcqa3V78bugGraGhtehj
CI failure: AppStateMachineTest called App() directly, bypassing
the outer Window { CompositionLocalProvider } shell in Main.kt.
DesktopMessagesLockGate read LocalMessagesLockState and hit the
compositionLocalOf { error(...) } trap.
Fix: construct the state holder + provide both LocalMessagesLockState
and LocalPrivacyLockSettings INSIDE App() itself. Extracted the body
of App() into a private AppInner() so the provider can wrap it
cleanly. The outer providers are removed from Main.kt — no longer
needed.
Trade-off: MessagesLockState is now scoped to App() (via
rememberCoroutineScope) instead of windowScope. That means it
rebuilds on appRestartKey change, which is intentional — an app
restart should reset the coroutines too. The seeded initial value
is still read synchronously from prefs so the first composition
sees the correct LockState (deep-link race fix preserved).
Also fixes an unrelated `!!` warning on existingHash in
SetPasswordDialog by using a safe smart-cast check.
Addresses the P0 items in the security review at
docs/plans/2026-07-01-privacy-lock-security-review.md.
## PBKDF2 iterations 100k → 600k (M1) via versioned hash format (M2)
- New PasswordHasher storage format: `v1$saltB64$hashB64` (600k
iterations, matches OWASP 2023 Password Storage Cheat Sheet for
PBKDF2-HMAC-SHA256).
- Legacy `saltB64$hashB64` (100k iterations) format still verifies
correctly — no user gets locked out by the bump.
- `hash()` always produces `v1$…`; users migrate to v1 opportunistically
when they Change or Set a new password.
- New `PasswordHasher.isLegacyFormat()` helper for callers that want
to force-migrate on next successful unlock.
- Verify cost goes from ~50ms → ~250ms on a modern laptop — well
within tolerable UX for a lock users open a handful of times per
session.
## Exponential backoff on failed unlock (M3)
- `PrivacyLockSettings` gains `failedUnlockAttempts: StateFlow<Int>`
and `lockedUntilEpochMs: StateFlow<Long?>`, both persisted via
java.util.prefs so a reboot cannot reset the backoff.
- `MessagesLockState.onFailedUnlockAttempt(nowMs)` implements the
schedule: no lockout for first 4 fails, then 30s / 60s / 120s /
300s (capped at 5 min).
- `MessagesLockState.onUnlockSuccess()` transparently clears the
attempt counter and any active lockout (also called from the
banner-enable path).
- DesktopLockScreen shows a countdown ("Try again in 27s") in the
supportingText, disables the password field and Unlock button
during lockout, ticks every 500ms via a LaunchedEffect.
- RemovePasswordDialog inherits the same protection — Settings can't
bypass the throttle by disabling the lock.
- 4 new unit tests cover threshold behavior, base trip, doubling +
cap, reset on success. All 13 tests green.
## Not in this commit
- L1/L2 (String/CharArray memory retention) — out-of-tree fix in
Compose; accepted per threat model.
- L3 (post-uninstall prefs) — release-notes item.
- M4 (Limitations copy update) — deferred; existing "does not
protect against filesystem access" line already covers.
Toggling the Messages lock OFF now prompts for the current password
via a new RemovePasswordDialog. On successful verification, the
password hash is cleared AND the lock is disabled — re-enabling
later requires setting a fresh password.
Rationale: a user should not be able to disable the lock without
proving they know the password. Clearing the hash on remove prevents
a "silent re-enable" attack where someone toggles OFF then ON again
and inherits the old password. Matches Signal PIN, WhatsApp Chat
Lock, macOS FileVault disable posture.
- New RemovePasswordDialog in SetPasswordDialog.kt: single Current
password field, reveal toggle, red "Remove" button (colorScheme.error),
Cancel + Escape dismiss. Auto-focus + Enter submits. Uses the same
Dialog+Surface+DialogHeader shell as SetPasswordDialog.
- DialogHeader refactored to take a title String (was isChange Bool).
- PrivacyLockSettingsScreen toggle-off path routes through the new
dialog when a hash exists. Corner case (lockEnabled=true but no
hash — user manually cleared prefs) still disables directly.
- On successful remove: setLockEnabled(false) + setPasswordHashed(null)
+ "Privacy lock removed" snackbar.
Rewrites SetPasswordDialog.kt with modern 2024-2026 UX. Adds
"Privacy lock enabled" / "Password updated" confirmation snackbars.
Dialog changes:
- Dialog + Surface(shape=shapes.large, tonal=6.dp) shell instead of
default AlertDialog. Fixed width 440dp. Matches NewDmDialog.kt.
- Header row with Lock icon + title (titleLarge). Softer body copy
under the header for the first-time-set path.
- Set-a-password flow uses ONE password field with a reveal toggle
(Visibility / VisibilityOff, per-field independent). The reveal
toggle IS the confirmation — no more "confirm password" field.
Matches WhatsApp Chat Lock + macOS Users & Groups.
- Change-password flow uses two fields (current + new), each with
its own reveal toggle. Current is verification, not redundancy.
- Real-time checklist row under the New field: green CheckCircle +
"Min 6 characters" when satisfied, outlined Circle + muted text
otherwise. Copy-pattern from EditProfileScreen NIP-05 status.
- Save button disabled until the checklist passes.
- Bumps PRIVACY_LOCK_MIN_PASSWORD_LENGTH from 4 to 6.
- Auto-focus first field on open (LaunchedEffect + FocusRequester).
- Enter submits (via onPreviewKeyEvent + KeyboardActions.onDone).
- Escape / click-outside-dismiss are disabled to prevent accidental
loss of typed password (dismissOnClickOutside = false).
- Wrong-current error shown inline under the Current field.
- All reveal toggles reuse the KeyInputField.kt idiom verbatim.
Snackbar plumbing (scope-local — no CompositionLocal):
- PrivacyLockSettingsScreen owns a SnackbarHostState overlaid at
Alignment.BottomCenter. LockToggleCard receives an onSaved
callback, fires "Privacy lock enabled" on first-time set or
"Password updated" on change.
- DesktopMessagesScreen (banner path) owns its own SnackbarHostState
overlaid at BottomCenter. MessagesFirstRunBanner takes an
optional onSaved callback (default {}), fires "Privacy lock
enabled" after the dialog saves.
Adds an inline banner at the top of the Desktop Messages deck column
that nudges users to enable the privacy lock. Fires only when
!lockEnabled && !firstRunCardSeen; dismissal is sticky across
restarts + lock enable/disable cycles.
- MessagesFirstRunBanner: AnimatedVisibility(expandVertically + fadeIn)
wrapper around a Surface + Row with a padlock icon, title, body,
and Enable / Not now buttons. Modeled on OfflineBanner.kt.
- SetPasswordDialog extracted from PrivacyLockSettingsScreen.kt into
a shared desktop/security/ file so the banner and the settings pane
both point at the same composable.
- MessagesLockState.onUnlockSuccess() relaxed to accept Disabled as a
valid previous state, so enabling from the banner keeps the user
Unlocked and doesn't flash the lock screen. New unit test covers
this path; all 9 tests green.
- DesktopMessagesScreen wraps its two-pane / compact layout in a
Column with the banner on top and a Box(weight(1f)) around the
panes so fillMaxSize propagates correctly.
Phase 5 (Desktop-only). Wraps the Messages deck column behind a
PBKDF2-hashed password gate; drops the Android-app slice.
- PrivacyLockSettings gains passwordHashed field + setter (salt$hash,
base64). Backed by java.util.prefs on desktop.
- PasswordHasher: PBKDF2-HmacSHA256, 100k iterations, 16-byte salt,
256-bit key, constant-time compare. Same primitive family as
SecureKeyStorage.
- DesktopMessagesLockGate: synchronous branch select in composition
(no LaunchedEffect guard) — closes the deep-link race per plan
§Security Hardening H1. Renders content when Disabled/Unlocked;
renders inline password TextField when Locked. Fires
MessagesLockState.onLeaveRoute() in DisposableEffect onDispose so
navigating away from the Messages column re-locks immediately.
- DesktopMessagesLockGate handles the "no password set" edge case
with a Disable-lock affordance.
- LocalPrivacyLockSettings CompositionLocal + LocalMessagesLockState
(from commons) both provided once at the App composition root in
Main.kt. Constructed with the existing windowScope so the state
holder's idle timer coroutines are lifecycle-scoped to the Window.
- DeckColumnContainer: DesktopMessagesScreen wrapped in
DesktopMessagesLockGate for the Messages column.
- Desktop PrivacyLockSettingsScreen: Column + Card layout matching
LocalRelaySettingsScreen (no Scaffold). Toggle, "Change password"
affordance with a full set/change dialog (old + new + confirm),
inactivity timer dropdown (1m / 5m / 15m / 1h / Never), redaction
level dropdown (Hidden / Full), honest limitations copy. Auto-opens
the set-password dialog if user toggles ON with no password set.
- Slotted into the existing Settings pane in Main.kt right after
LocalRelaySettings.
Damus-inspired content filter that collapses notes abusing `t` hashtag
tags into a compact reveal-on-click placeholder. Ships default ON with a
threshold of 5 (adjustable 1–20 in Settings → Content Filters, or off).
Scope
- Pure check (`HashtagSpamCheck`) + settings interface
(`HashtagSpamSettings`) live in `commons/moderation/`, callable by
Desktop, `amy` CLI, and (future) Android.
- JVM-backed `PreferencesHashtagSpamSettings` writes to the shared
`java.util.prefs` node `com/vitorpamplona/amethyst/filters`, so `amy`
and Desktop observe the same value automatically.
- `CollapsedSpamNote` placeholder in `commons/ui/note/` takes only
primitive scalars so Android can adopt it without touching commons.
- Desktop wraps every `NoteCard` call site (FeedNoteCard, QuotedNoteEmbed,
BookmarksScreen, 5 SearchResultsList sites) with a shared
`SpamCheckedNoteRender` helper. Thread root notes auto-expand via
`forceReveal=true`; replies still respect the filter.
Exemptions
- Long-form articles (kind 30023)
- Authors in the follow list plus self
- Repost wrappers check the inner event's tags via precomputed
`note.replyTo`, falling back to `containedPost()`
Search UX fixes bundled in
- Removed the `#hashtag` → "Direct lookup" card. `QueryParser` already
extracts `#xxx` into the query's hashtag filter, so typing `#bitcoin`
now goes straight to filtered results.
- Search-result rows now trigger metadata loading via
`subscriptionsCoordinator.loadMetadataBatched(authors)` and observe
each user's metadata flow via a new `rememberDisplayData` helper, so
display names + avatars refresh when kind-0 arrives from index
relays. Same helper reused in Bookmarks.
Tests + docs
- 19 unit tests (check × 10, displayed-event unwrap × 4, prefs × 5),
all green.
- Manual testing sheet with 16 scenarios at
`desktopApp/plans/2026-06-29-hashtag-spam-filter-manual-testing-sheet.md`.
- Plan at `docs/plans/2026-06-29-feat-desktop-hashtag-spam-filter-plan.md`.
- Cross-client desktop feature backlog reference at
`desktopApp/plans/_desktop-feature-backlog.md`.
Adds a Follow Packs experience to Amethyst Desktop:
- New "Discover" sidebar destination with featured-pack hero, hashtag chips
driven by NIP-12 `t` tags, a 3-up "From the pack" notes feed, and a
right-rail of mini pack thumbnails.
- New "Follow Packs" launchable column (App Drawer + Discover "Browse all")
with multi-field search across title, description, creator name/npub,
and `t` tags.
- Pack detail overlay (read-only) with per-member Follow/Unfollow buttons
that reflect the live kind-3 state, plus pack-level Follow all /
Unfollow all with a dedupe-aware confirm dialog ("Follow N new (M
already followed)").
- Bulk follow / unfollow batched into a single kind-3 publish via new
`FollowActions.buildUnfollowBatch` and `Kind3FollowListState.follow/
unfollow(users: List<User>)`. The mutating call sites are Mutex-
protected against concurrent races.
- naddr → 39089 references in notes render as a rich inline card with
avatar stack + Follow all CTA. Cache miss triggers a one-shot
subscription; empty / deleted packs render minimal states.
- Shuffle button rotates both the featured pack and the gallery,
excluding the last 5 shown.
- Pack image fields render via Coil `AsyncImage` with a deterministic
gradient fallback.
Protocol additions:
- Quartz: `FollowListEvent.hashtags()` convenience accessor.
Bug fixes wrapped into the feature:
- `DesktopLocalCache.consumeContactList` now also loads the event into
`addressableNotes` so `Kind3FollowListState.getFollowListEvent()`
returns the user's actual kind-3. Without this, every bulk follow
silently replaced (rather than appended to) the contact list.
- Added Material Symbols `Shuffle` codepoint and regenerated the
bundled subset font (still 432 KB).
Accounts dedup by npub (= pubkey), so adding/scanning your own read-only npub for
a pubkey you already hold the nsec for would overwrite the signing account:
- Android: setDefaultAccount rewrote the per-npub file from fresh read-only
settings — wiping the account's cached follow/relay/mute lists and flipping
hasPrivKey off, which silently disables its push notifications (every
notification path early-returns on !hasPrivKey). The account looked lost ("can't
post anymore") even though the nsec survived on disk.
- Desktop: saveCurrentAccount overwrote signerType to ViewOnly, orphaning the
stored key and routing every later switch through loadReadOnlyAccount.
Guard the downgrade at the single persistence point on each platform: when the
account being made current is read-only and a SIGNING account already exists for
the same pubkey, keep the signing account and switch to it instead. A signing
account already subsumes a read-only one, so this loses nothing.
- Android LocalPreferences.setDefaultAccount now returns the settings that
actually became current; AccountSessionManager.loginAndStartUI shows that.
- Desktop AccountManager.saveCurrentAccount reuses switchAccount() to reload the
signing account. Covered by a regression test (verified failing without the
guard).
This replaces the closed proposal e05208d9, which solved the same underlying bug
with a much heavier accountId rework (separate npub/nsec switcher entries — a
niche feature) that itself shipped a logout(deleteKey=true) data-loss bug.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The home tab inline search bar in FeedScreen.kt previously ignored
Namecoin identifiers (e.g. mstrofnone.bit) — only the full Search screen
resolved them via LocalNamecoinService. Users typing a .bit name into
the home search pill saw 'no results found' instead of the resolved
profile.
This wires the same Namecoin resolution pattern used by SearchScreen.kt
into FeedTabsHeader:
- Detect Namecoin identifiers with NamecoinNameResolver.isNamecoinIdentifier
- Resolve via LocalNamecoinService.resolveDetailed (cancelling stale lookups
when the user keeps typing)
- Render a compact InlineNamecoinResultRow above the regular search results
showing Loading / Resolved / NotFound / Error states
- Clicking the resolved row navigates to the user profile, matching the
full Search screen behaviour
Implements nostr-protocol/nips#2381: a client MAY attach an optional
4th positional parameter to the NIP-46 `connect` request carrying a
JSON-stringified `{name, url, image}` object, mirroring the fields
already present in `nostrconnect://` URIs. This lets a bunker:// paired
signer show who is asking to connect.
- quartz: add BunkerClientMetadata and a clientMetadata field on
BunkerRequestConnect; serialize it as the 4th param (omitted when
empty) and parse it back, degrading malformed/empty JSON to null.
- quartz: NostrSignerRemote carries and sends clientMetadata on
connect() and threads it through fromBunkerUri().
- commons: BunkerLoginUseCase.execute() accepts optional clientMetadata.
- desktopApp: advertise Amethyst's metadata on bunker login.
- cli: the receiving bunker logs the connecting client's identity
(display-only; never gates the ACK on it, since the client pubkey is
unauthenticated in bunker:// pairing).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PYpupiVAq4VyHDdjrYyPdi
The NIP-31 event-level "alt" tag is deprecated, so Amethyst no longer
emits it on any event it builds. Removed all `alt(...)` builder calls and
`AltTag.assemble(...)` insertions across every event kind in quartz (and
the few app-side builders), along with the now-unused `ALT`/`ALT_DESCRIPTION`
companion constants and the `TagArrayBuilder.alt()` / `AltTag.assemble()`
write helpers.
Reading alt tags from incoming events is kept (AltTag.parse/match,
TagArray.alt(), Event.alt()) for interop with clients that still send them,
and the imeta media accessibility `alt` field (NIP-92/94) is untouched.
Updated/removed tests that asserted alt-tag presence and refreshed the
deterministic event-id/sig golden masters in UpdateMetadataTest.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014xAESAz1H1VNjmQpMVqBXj
When replying to a note that is a kind 1 TextNoteEvent, is the root of a
new thread (no e-tags), and was itself posted from Amethyst (NIP-89
client tag), build a NIP-22 kind 1111 CommentEvent instead of a kind 1
reply. Forks keep using kind 1.
Applies across all kind-1 reply paths: the Android composer
(ShortNotePostViewModel), the notification quick-reply
(NotificationReplyReceiver), and the desktop composer (ComposeNoteDialog).
Adds Event.isClient / TagArray.isClient helpers (NIP-89, case-insensitive)
with unit coverage.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V7RyevA6jL1NuY7uev2agS
Phase 3 of relay-latency-health: wire the Phase 1 tracker and Phase 2 store
into the desktop UI across three surfaces. After this commit the feature is
end-to-end usable in the running app.
Wiring (Main.kt):
- Construct a RelayLatencyTracker per account (same lifetime as
RelayHealthStore).
- Install a RelayLatencyListener alongside the existing RelayHealthListener
on relayManager.client; uninstall both on account switch / app exit.
- Pass the tracker to the store via the new latencyTracker constructor
param so sweep + snapshot happen on the existing 60 s reclassify tick.
- nip11Provider: read live from Nip11Fetcher's session cache (new
`allCached()` accessor). The classifier reads it every tick.
- authProvider: hardcoded `{ false }` for desktop — NIP-42 isn't wired in
desktop yet, so any auth-required or payment-required relay is treated
as "auth not complete" and excluded from the slow cohort. Avoids
perpetually flagging paid relays that CLOSED our anonymous queries.
RelayMetricsTab + RelayMetricCard (dashboard):
- Tab collects latencySnapshots + slowRelays ONCE; per-row passes the
per-relay value snapshots (not the whole map). Strong-skipping then
handles the rest — unchanged rows skip on 60 s ticks.
- Each row gains three compact columns: OK / EOSE / FR p50s (in ms).
Missing metrics omit their cell — common in the first ~60 s before the
tracker's first snapshot lands.
- A red "Slow: <metric> 2.4×" AssistChip appears next to the columns
when the classifier flags the relay.
RelayDetailPanel (the per-row NIP-11 popup):
- New "Latency (rolling last 50 samples)" section below the existing
NIP-11 fields, listing each metric's p50, sample count, and cohort
multiplier when the relay is currently flagged on that metric.
- First-result row carries a tooltip explaining filter-dependence so
users don't misread "slow first-result" as pure network slowness.
UnhealthyRelaysPopup:
- Now also collects store.slowRelays and renders a "Slow relays" section
below the existing "Unresponsive relays" list (when slowRelays is
non-empty). Each slow row: relay URL, metric + p50 vs cohort, slow
chip, Dashboard + Snooze actions. Snooze reuses the existing 7-day
snooze field on RelayHealthRecord.
UnhealthyRelayBannerHost:
- Banner now visible when either unhealthy OR slowRelays is non-empty.
- Count text reads "$dead relays unresponsive — Review" /
"$slow slow relays — Review" / "${dead+slow} relays need attention —
Review" depending on which buckets have entries.
Compose stability:
- All public StateFlow types from RelayHealthStore expose ImmutableMap,
and RelayLatencySnapshot is @Immutable with ImmutableMap fields, so
strong-skipping engages.
- Per-row composables (RelayMetricCard, SlowRelayPopupRow) only take
@Immutable value parameters — no maps passed in.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase 2 of relay-latency-health: hook the Phase 1 tracker into the existing
RelayHealthStore lifecycle and persist its rings via the existing
PreferencesRelayHealthPersistence so samples survive restarts.
commonMain:
- RelayLatencyProvider: small interface so the store can drive a tracker
that lives in jvmAndroidMain (the impl needs ConcurrentHashMap).
- RelayHealthSnapshot: optional `latencySamples` field. Default empty;
older saved snapshots load cleanly without it.
- RelayHealthStore now takes optional `latencyTracker` / `nip11Provider`
/ `authProvider` constructor params:
* exposes `latencySnapshots: StateFlow<ImmutableMap<Url, RelayLatencySnapshot>>`
— MutableStateFlow updated inside the existing 60 s reclassify tick
(one timer, not two — the tracker is scope-less and gets
`sweep(now)` called from reclassify).
* exposes `slowRelays: StateFlow<ImmutableMap<Url, SlowReason>>` —
derived via `_latencySnapshots.map(classifySlowRelays).stateIn(
scope, SharingStarted.Eagerly, persistentMapOf())`. The classifier
reads `nip11Provider()` / `authProvider` live, so paid/auth-only
relays only join the cohort once their auth completes.
* `init {}` restores persisted samples into the tracker; the
existing `schedulePersist()` now bundles `tracker.samplesForPersistence()`
into the saved snapshot via a new private `snapshotForPersist()`
helper. The same helper feeds the final flush in `close()`.
No new dispatcher / scope / timer — everything piggybacks on the
existing infra (single SupervisorJob, 5 s persist debounce, 60 s tick).
jvmAndroidMain:
- RelayLatencyTracker now implements RelayLatencyProvider. Overrides drop
the inline `System.currentTimeMillis()` default; callers from commonMain
pass `TimeUtils.nowMillis()` explicitly.
desktopApp (jvmMain):
- PreferencesRelayHealthPersistence persists per-relay latency rings in
separate keys (`lat_<account-prefix>_<sha256(url)[..16]>`) so the 8 KB
Preferences ceiling on the main `health_<account>` key isn't blown by a
user with many relays. Each key holds one relay's four metric rings as
`wss://relay.url\tok:csv|eose:csv|fr:csv|ping:csv`. On save, keys for
relays no longer in the snapshot get removed so the prefs node doesn't
grow unboundedly across account churn.
Notes:
- Persistence still uses the existing 5 s debounce path. The deepened plan
called for 30 s for `lat_*` keys; deferring that micro-optimization
until we observe write thrash in practice. The cap on writes is
one-rewrite-per-5s-of-activity which matches what the existing snooze
persistence already does, so latency adds zero new flush events.
- Tracker is wired only when a `RelayLatencyProvider` is passed to the
store. Existing tests / Android continue to compile and run with
latency unconfigured — `latencySnapshots` stays empty and `slowRelays`
derives to empty. Desktop wiring lands in Phase 3.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Claude
Vitor PamplonaandGitHub
nrobi144
davotoula
mstrofnone