Clients in the wild publish kind-4550 approvals whose content is plain
text (e.g. braille ASCII art) or a custom non-event JSON wrapper instead
of the NIP-72 stringified approved event. containedPost() fed any
non-blank content straight into Event.fromJson, producing a
JsonParseException and a noisy logcat warning for every such approval.
Only attempt the parse when the trimmed content starts with '{', so
plain-text contents are skipped silently while genuinely malformed
event-looking JSON still logs.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXiy3Ajmr3vdrV83jZsUx6
The left drawer banner used ContentScale.FillWidth inside a fixed
120dp-tall box, so banners wider than the box's aspect ratio left
empty bars above and below the image. ContentScale.Crop fills the
full banner height and crops the excess width instead.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhQ1FCyoKCD1UeBT5mWy18
New self-contained desktopApp/packaging/flatpak/flathub/ directory whose
contents are copied verbatim into the flathub per-app repo at submission
time (Flathub has no separate accounts — submission is a GitHub PR):
- manifest builds from the published GH Release tarball (pinned to
v1.12.6 url + sha256 from the release asset digest) instead of the
local type:dir tree CI uses — Flathub build servers must fetch all
sources themselves
- x-checker-data (json type, is-main-source) on the archive source so
flatpak-external-data-checker auto-PRs url/sha256 bumps and metainfo
<release> entries on every new GitHub Release
- own metainfo copy carrying the permanent <releases> history Flathub
requires (the CI variant keeps injecting its entry at build time);
screenshots remain the documented submission blocker
- flathub.json restricting builds to x86_64 (no aarch64 tarball exists
and jpackage cannot cross-compile one)
Verified locally: built the flathub manifest end-to-end from the real
v1.12.6 tarball (sha256 enforced by flatpak-builder), installed it, and
booted the actual app inside the sandbox under Xvfb — UI rendered and
the embedded Tor daemon spawned.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GYfNxhPZC3WRrn82Dm2Cb4
The spam check can fire via the spamMessages record alone, after the
original event id/address has been evicted from the 2000-entry
recentEventIds/recentAddressables LruCache. In that case existingEvent /
existingAddress is null and building the njump link threw a
NullPointerException, aborting event consumption in LocalCache.
Fall back to the current event's link when the original is no longer
cached, and use setOfNotNull in logOffender so a null cache entry can't
sneak into the Spammer sets through the platform-type hole.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UGiCujAHWMbmGT89X77S4K
The linux-portable release leg now wraps the createReleaseDistributable
tree it already builds into a single-file Flatpak bundle and attaches it
to the GH Release as amethyst-desktop-<version>-linux-x64.flatpak.
Packaging fixes to the existing (previously unwired) Flathub manifest:
- add the missing 512x512 icon (copy of desktopApp icon.png) and install
it under hicolor/512x512 instead of the never-present 256px path
- drop the openjdk module + sdk-extension: the jpackage tree bundles its
own trimmed JRE, so /app/jre was pure bloat
- grant --socket=x11 instead of wayland/fallback-x11: Compose Desktop
renders via AWT/skiko (X11-only on Linux, XWayland on Wayland), so
fallback-x11 left the app socketless on Wayland sessions
CI wiring:
- install flatpak tooling + the freedesktop runtime/sdk (version greped
from the manifest so the pin can't drift), retried like other fetches
- inject the AppStream <release> entry for the tagged version at build
time (the checked-in metainfo deliberately carries none)
- flatpak-builder with --disable-rofiles-fuse (GH runners) and a
--state-dir under desktopApp/build so the repo tree stays clean
- collect via the existing asset-name.sh contract (new flatpak ext)
Verified end-to-end locally: built the bundle from the manifest with a
stubbed jpackage tree, installed it, and ran the exported command inside
the sandbox (freedesktop 24.08, args forwarded through the wrapper).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GYfNxhPZC3WRrn82Dm2Cb4
Android never uses NotificationKinds.SUBSCRIPTION_KINDS for relay
subscriptions — every kind in it already arrives via Android's own
datasources (FilterNotificationsToPubkey, the chat datasources, the
wallet assembler) or via local unwrapping (14/15). Spreading it into
NOTIFICATION_KINDS only coupled Android's display gate to a list whose
job is desktop's relay-filter/toast allow-list, which is exactly how
the kind-1059 wrap leaked into the Android notifications tab.
Restore NOTIFICATION_KINDS as an explicit flat set (identical content
to the previous commit's subtraction) and add
NotificationKindsContractTest as the drift tripwire: envelope kinds
(1059/21059) must never render on the Android tab, and every kind
desktop notifies on must be either displayable on Android or a known
envelope.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011A6iSrJJHUoz686eDnCQMV
The relay-focused recommendations were built on a wrong premise: with the
outbox model, the number of open connections and the reconnect churn are
driven by the relays the user's FOLLOWS publish to, not by the user's own
relay list — so 'Edit relays' steered users at a lever that doesn't control
the number. Rather than ship a recommendations engine whose headline advice
is misleading, the section, the UsageInsights rules, their tests, and their
strings are removed. The measured data itself (rates tiles, cost cards,
subsystem bars, screen time) stays.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016RJ8EAsdkHx5WHHU2eQJ1P
The desktop notifications redesign (ecedc4af) extracted the shared
NotificationKinds.SUBSCRIPTION_KINDS list from Android's
NotificationFeedFilter and rewired NOTIFICATION_KINDS to spread it. The
shared list includes GiftWrapEvent.KIND (1059) because it doubles as the
relay subscription filter (you must ask relays for wraps to receive
NIP-17 DMs) and because Desktop renders the wrap itself as a DM inbox
row. Android's display list never had 1059 before that commit, so the
delegation silently started rendering wrap envelopes in the
Notifications tab — with created_at randomized up to 2 days back per
NIP-59, producing misordered, undecryptable rows instead of routing DMs
to the chat screens.
Subtract GiftWrapEvent.KIND from the Android display set, restoring the
pre-extraction behavior (1059 was the only kind the delegation added).
SUBSCRIPTION_KINDS keeps 1059, so the desktop relay subscription, the
desktop OS-toast allow-list, and the desktop inbox DM rows are all
unaffected. Android push is likewise untouched: NotificationDispatcher
already excludes 1059/21059/13 and notifies on the unwrapped inner
event.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011A6iSrJJHUoz686eDnCQMV
The profile header no longer replaces the big display name with the petname.
Instead, when the account nicknamed the user (or kept a private note about
them), an outlined card renders above it — petname, divider, private summary —
with the standard Lock private marker in its top-right corner, since both
fields live NIP-44 encrypted in the account's contact card. Tapping the card
opens the shared nickname editor. The profile's own display name stays fully
visible underneath. Feeds, chats and mentions keep rendering the petname
instead of the display name.
To carry the summary into the UI, the commons PetName holder generalizes to
Nickname(petName?, summary?, tags), built when either field exists — so a
note-only card (no petname) now shows on the profile too, while the name
override everywhere else keys strictly off petName.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QdvE4LvgkSewJXyFzyyAUY
A gift wrap with an empty content string carries no NIP-44 ciphertext,
so it can never be unwrapped. Filtering it at LocalCache's ingestion
choke point (justConsumeInnerInner) rejects it before the Schnorr
signature check and before it takes a permanent cache slot, and keeps
GiftWrapEventHandler from retrying a doomed unwrap on every batch.
Locally stripped wraps (copyNoContent, used to drop the ciphertext
after a successful unwrap) are assigned directly to note.event and
never pass through justConsume, so they are unaffected.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011A6iSrJJHUoz686eDnCQMV
UserCardsSubAssembler.newEose read the filter's p-tags to stamp each target
user's card EOSE, but kind:30382 filters address targets in the d-tag — so
no per-user EOSE was ever recorded, groupByRelayPresence always classified
users as never-checked, and every filter update re-downloaded the visible
users' cards with since = null. Read the d-tag instead, and use DTag.TAG_NAME
on both the filter builder and the EOSE reader so the two keys cannot drift
apart again. Pre-existing on main; surfaced while verifying that card syncs
are incremental from the account's outbox relays.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QdvE4LvgkSewJXyFzyyAUY
Generalizes the remaining platform-bound pieces of the nickname feature so
the desktop app can adopt it:
- ContactCardsState.displayNameFlow/cachedDisplayName own the NIP-81 render
policy (petname over profile name over npub); the Android observeUserName
is now a thin wrapper around it
- EmojiSuggestionState.autocompleteInto completes the word under the cursor
and closes the list — replaces the insert+reset pair copy-pasted in the 8
composer ViewModels and the nickname dialog
- the kind:30382 filter builders move to commons relayClient/assemblers
(cards about targets from trusted accounts, and the account's own cards by
author), shared by the user watcher and the login subscription
- ShowEmojiSuggestionList moves to commons nip30CustomEmojis/ui using coil
and commons string resources
- EditNicknameDialog moves to commons nip85TrustedAssertions/ui: it takes the
ContactCardsState and an onSave callback, so each front end only wires its
own publish path and menu entry; dialog strings move to commons resources
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QdvE4LvgkSewJXyFzyyAUY
Accuracy fixes:
- Insights are ranked by an estimated-impact score (rough hours of extra
radio/CPU activity, ranking only, never displayed) before the cut to
three — declaration order no longer decides which consumer gets dropped.
- The notification insight states the measurement ('held connections open
for N relay-hours in the background') instead of an unverified 'largest
background cost' superlative, and only fires when the service's uptime
covers at least half the background window — a service that ran 20
minutes can no longer be blamed for 30 hours of background connections.
- When the measured drain split shows foreground use dominating (>=3x the
background share with enough signal), an informational note leads the
list saying most battery went to screen-on use — so nobody flips a
setting expecting savings it cannot deliver.
Completeness — new rules, each with a deep link:
- PoW mining time -> compose settings (default difficulty), scored as
full-tilt CPU.
- Reconnect churn -> relay list (a flaky relay burns a handshake plus a
radio wake-up per retry) — distinct diagnosis from 'too many relays'.
- Push-processing wakelock time / process-start churn -> notification
settings.
Count strings converted to plurals per res/CLAUDE.md. Insight test suite
extended to 15 cases covering the attribution gate, score ordering, the
honesty note, and each new rule.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016RJ8EAsdkHx5WHHU2eQJ1P
The screen presented evidence and left the user to be the analyst; now it
draws the conclusions and links each one to the setting that acts on it:
- Insights: a UsageInsights rules layer (unit-tested, thresholds informed by
the ping study and normalized per observed day) renders up to three
plain-language recommendations, each deep-linking to notification
settings, media settings, the relay list, or privacy options.
- Rates: battery %/hour in app (from the measured drain sampler), data/hour
in app, and average simultaneous relay connections — totals aren't
judgeable, rates are, and avg relays is directly actionable.
- Subsystem bars rank by CELLULAR bytes when any exist (with totals as
secondary context) — Wi-Fi bytes are nearly free, so ranking by totals
pointed users at the wrong feature.
- Built-in Tor gets the same cost card as the always-on service: uptime,
bootstraps, and a link to privacy options.
- Per-screen time (screen.<Name>.ms): a ScreenTimeIntegrator fed by the nav
controller's destination listener, gated on foreground. PRIVACY: only the
route's base name is recorded — screenNameOf strips every navigation
argument before the value leaves the navigation layer, so the ledger says
'Profile', never whose profile. Shown as proportion bars and included in
the report's summary table.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016RJ8EAsdkHx5WHHU2eQJ1P
The daemon OOM needs a cache-cold compile of several :amethyst variants in
one invocation, which only CI's combined test/lint/assembleBenchmark run
produces; local builds are incremental and usually build a single variant,
and have never shown the problem. Gate the maxParallelUsages=1 service on
the CI env var (always set on GitHub Actions) so local multi-variant builds
keep their parallelism.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018ifbUGCADckUb3zaox9wBo
The uptime row told users the service ran, not what it cost — and the
setting to turn it off lives three screens away. The resource screen now
shows a dedicated card (only while the service has run this week) that
frames the cost in decision terms: running time and restarts, the relay
connections it held while the app was closed, and the measured background
battery drain — with a button straight to notification settings where the
delivery method can be changed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016RJ8EAsdkHx5WHHU2eQJ1P
Uptime alone can't distinguish a stable 24h service from one the watchdog
restarts every hour — each restart is a process wake plus a full round of
relay reconnects. Reported alongside uptime in the usage report.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016RJ8EAsdkHx5WHHU2eQJ1P
- ScheduledPostWorkGate now treats PUBLISHING as pending work: claiming the
last PENDING post no longer cancels the periodic worker mid-publish (which
stranded the post in PUBLISHING with no recovery). ScheduledPostStore also
releases stale PUBLISHING claims at initial load — a claim found on disk
belongs to a dead process and is reset to PENDING for retry.
- CalendarReminderWorker decides its self-cancel on a FRESH cache snapshot,
closing the race where an RSVP accepted mid-run was lost forever (the
observer's KEEP schedule no-ops while the chain exists). A second observer
on kind-31922/31923 re-arms the chain when the organizer reschedules the
target event — the existing RSVP never re-fires observeNewEvents, so the
moved appointment previously produced no reminder. The rescan is throttled
(conflate + 30s) and gated on the feature being enabled.
- UsageCountingInterceptor skips loopback hosts: local Blossom cache hits
(127.0.0.1) never touch the radio and were inflating mobile rx bytes,
radio-burst estimates, and potentially the background-data alert.
- The usage alert's 7-day rate limit is now consumed when the user acts on
the dialog (any button or dismissal) instead of before the first frame, so
a config change or process death no longer burns the prompt budget on a
dialog nobody saw.
- DEV_REPORT_PUBKEY is defined once in service/crashreports and imported by
both the crash and resource-usage send paths.
- ResourceUsageScreen remembers its summaries keyed on the loaded data — the
2s memory ticker was recomputing the full multi-day counter walk on every
recomposition.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016RJ8EAsdkHx5WHHU2eQJ1P
CI runs die with java.lang.OutOfMemoryError (GC overhead limit exceeded /
Java heap space) inside the shared Kotlin compile daemon when two variant
compilations of :amethyst run at the same time — e.g. compilePlayDebugKotlin
and compilePlayBenchmarkKotlin in the test-and-build-android job, which
demands four :amethyst variants (unit tests, lint, assembleBenchmark) in one
invocation. KotlinCompile submits its work asynchronously via the Worker
API, so the project lock is released while compilation is still running in
the daemon and Gradle happily starts the next variant's compile task in
parallel; two full :amethyst codegen passes no longer fit the daemon's
-Xmx8g heap (see runs 29260711359 and 29248908870; removing Kover in #3539
helped but was not sufficient).
Register a no-op shared build service with maxParallelUsages = 1 and make
every :amethyst KotlinCompile task use it. The scheduler then runs this
module's Kotlin compilations one at a time — a task holding the service is
not complete until its async worker finishes — while all other work (other
modules' compilation, JVM tests, lint analysis, packaging) keeps running in
parallel. Verified with Worker-API probe tasks: unconstrained same-project
tasks start simultaneously; with usesService they run strictly one after
the other.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018ifbUGCADckUb3zaox9wBo
New counters for the app's remaining heavy battery consumers, all
transition-based so tracking never adds work to the activities measured:
- pow.ms/sessions: NIP-13 mining time from the PoW queue's isMining flow —
the largest attributable CPU burner, previously an unattributed cpu.ms
mystery
- tor.ms/starts: in-app Arti uptime from the raw TorService status (not
TorManager.status, whose WhileSubscribed upstream would keep Tor's
control flow alive if the ledger subscribed to it)
- service.alwayson.ms, call.ms/sessions, nests.ms/sessions: foreground
service lifecycles for the always-on relay service, calls, and NIP-53
audio rooms
- crypto.decrypt/encrypt.count+us and sign.local/nip46/nip55.count via a
MeteringNostrSigner decorator wrapped inside NostrSignerWithClientTag at
account load; crypto durations only metered for local-key signers so
IPC/relay waits never poison the CPU numbers
- location.ms: GPS listening segments around LocationFlow collection
- battery.drain.fg/bg: measured percent-while-discharging sampled at each
flush — the ground truth to correlate the other counters against
Ledger infrastructure hardening the new counters build on:
- all duration math now uses SystemClock.elapsedRealtime; wall-clock jumps
(NTP, timezone) no longer fabricate or delete accounted time
- pre-flush-hook adds are drained in place and no longer re-arm the
debounced flush, killing a self-perpetuating 30s wake-and-write loop
- drain is now AtomicLong.getAndSet(0) instead of remove+sum, closing a
lost-update race that undercounted the hottest counters
- shared TimeSegmentIntegrator base extracted; relay/foreground integrators
and the new SessionTimeIntegrator all use it
- @Volatile on LocalCache.verifyMeter (matching the onchainBackend
precedent)
New counters surface in the usage screen (zero rows hidden), the NIP-17
report tables, and the per-day dump. 9 new unit tests including a
regression test for the flush loop.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016RJ8EAsdkHx5WHHU2eQJ1P
ShowEmojiSuggestionList sat in the same package as EmojiSuggestionState, so
it referenced the class without an import — moving the class to commons broke
the Android compile. Caught by an honest verification run: earlier gradle
invocations were targeting a nonexistent :amethyst:compileDebugKotlin task
(the app builds flavored compilePlayDebugKotlin/compileFdroidDebugKotlin)
with the failure masked behind a pipe, so the last three commits had never
actually been compiled.
Verified at this commit: quartz nip85 tests (13/13), :commons:compileKotlinJvm,
:cli:compileKotlin, :amethyst:compilePlayDebugKotlin, :desktopApp:compileKotlin.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QdvE4LvgkSewJXyFzyyAUY
Review pass over the nickname/contact-card feature for reuse, simplicity and
performance:
- EmojiSuggestionState moves to commons next to EmojiPackState and now takes
the EmojiPackState directly instead of the whole Android Account, so the
desktop app can reuse the :shortcode: autocomplete
- the findEmoji helper that was copy-pasted in 8 composer ViewModels is gone;
everyone calls the shared EmojiPackState.findEmojiTags, which now resolves
codes through a map lookup instead of a linear scan per code
- ContactCardsState owns the emoji resolution for nickname saves (Account
just publishes), takes EmojiPackState, and drops its unused scope param
- new synchronous cachedPetName path (decryption-cache read, no crypto) seeds
observeUserName/observeUserPetName initial values, removing the flash of
the real name before the flow's first emission
- nickname dialog prefill no longer clobbers text typed while a slow external
signer decrypts the existing card
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QdvE4LvgkSewJXyFzyyAUY
Replicates the PollEvent layout: all tag parsing moves to TagArray extensions
in TagArrayExt.kt with the event accessors delegating to them, builder
extensions use addUnique for single-instance tags, and construction goes
through template-returning builders instead of methods that sign internally.
- build() returns an EventTemplate<ContactCardEvent> (the signer is only used
to NIP-44 encrypt the private tags, matching TrustProviderListEvent);
create() remains as the signer.sign(build(...)) convenience and now takes
the emoji list directly
- updatePetNameAndSummary() returns an unsigned EventTemplate; callers sign
it (ContactCardsState and tests updated)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QdvE4LvgkSewJXyFzyyAUY
The composer's Notify row previously showed only the parent's p tags and
its author, each with an x that removed the user for good. It now lists
every thread member (authors along the reply chain plus the parent's
mentions), and each chip carries a bell instead: tapping it mutes the
notification for that user but keeps the chip — faded and with a
bell-off icon so the state is obvious — making it one tap to add them
back. Muted members are dropped from the outgoing event's p tags (and
from a private note's receivers), and drafts round-trip the muted state
by re-deriving thread members whose p tag the draft dropped.
The NIP-22 comment composer gets the same chip semantics; there the
mute is honored for the optional zap-sender tag, while the structural
root/reply scope tags stay as NIP-22 requires.
Adds the notifications_off glyph to the Material Symbols subset font.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013eK8mGPcuKYXNyhKVJ8Wg7
Feed videos run under REPEAT_MODE_ONE and looped forever. AutoReplayLimiter
counts each MEDIA_ITEM_TRANSITION_REASON_REPEAT as one completed play and
pauses the player when the 5th play finishes, leaving the video on its first
frame with the play button showing. Pressing play (or the feed mutex resuming
a video scrolled back into view) grants a fresh 5-play allowance, and pooled
players reset the count when they switch to a different media item.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N9RXiM42yqznwTVjw8tLZv
Closes the gaps the "should we track the non-websocket client?" question
exposed, and adds the battery-estimation layer bytes alone can't provide:
- Counting moves from per-role wrappers to a single interceptor on the
shared base client (OkHttpClientFactory), with role attribution via
request tags (role wrappers now only tag, inserted outside the counter).
Anything reaching the shared clients untagged lands in a new "other"
subsystem instead of escaping the ledger — which the napplet broker did,
and which Coil's image traffic did too: setImageLoader called
getHttpClient directly, bypassing the metered okHttpClientForImage.
The app's largest HTTP consumer was invisible; now it's tagged "image".
- Battery-relevant shape of the traffic, not just its size: per-subsystem
request counts and active-transfer time, plus a radio-burst estimator
(new HTTP activity after >10s of silence ~= one cellular radio
ramp+tail). Scattered small requests cost far more energy than one
continuous download of the same byte count; bursts/day makes that
pattern visible and reportable.
- Media playback time (ExoPlayer isPlaying segments via a listener in
ExoPlayerBuilder — every player in the app): decoder+screen+streaming
at once, turning "video used 800 MB" into "800 MB over 2h" (normal)
vs "over 10 min" (a bug).
All surfaced in the usage screen, the NIP-17 report, and UsageSummary;
20 ledger tests total (burst gap logic, play-time segments, and the
existing suites) all passing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016RJ8EAsdkHx5WHHU2eQJ1P
Nicknames can now use NIP-30 custom emojis: typing : in the nickname dialog
autocompletes from the account's emoji packs, and the emoji mappings for any
shortcode used are embedded in the card's NIP-44 encrypted content next to the
petname — so even the emoji set stays private. Renderers resolve the petname's
shortcodes against the card's decrypted tags instead of the profile's metadata
tags.
- quartz: updatePetNameAndSummary replaces the private emoji tag set wholesale
and keeps it out of the public tags; round-trip test added
- commons: PetName(name, tags) holder with content equality, decryption cache
returns the merged decrypted tag list, EmojiPackState.findEmojiTags resolves
:codes: against the selected packs
- amethyst: Account embeds resolved emoji tags on save; all petname render
sites pass the card tags to the WithEmoji composables; nickname dialog gets
the : emoji autocomplete via EmojiSuggestionState
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QdvE4LvgkSewJXyFzyyAUY
Adds petnames/nicknames per https://github.com/nostr-protocol/nips/pull/761,
reusing the kind:30382 contact card already used for WoT scores — a card only
acts as a nickname when signed by the account's main key. Petname and summary
are always stored in the card's NIP-44 encrypted content.
quartz:
- ContactCardEvent.updatePetNameAndSummary edits both fields in the encrypted
private tags, strips stray public copies, preserves every other tag
- TagArray.petName()/summary() parsers for decrypted tag lists + tests
commons:
- ContactCardDecryptionCache: LRU NIP-44 decrypt cache for own cards
- ContactCardsState: account-scoped access to the account's own cards,
petname flow per target user, create/update entry point
amethyst:
- Account.updateContactCardPetName publishes through the extended outbox
relays (NIP-65 write + private outbox + local + broadcast) and the login
subscription now downloads the account's own kind:30382s from its relays
- petname renders instead of the display name in usernames, profile header,
chats and @mentions (observeUserPetName)
- Edit-nickname action + dialog on the profile actions menu
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QdvE4LvgkSewJXyFzyyAUY
The relay NOTIFY (payment prompt) went into a process-wide NotifyRequestsCache
and DisplayNotifyMessages showed it under any account whose relay list contained
the relay — so a prompt billed to Amethyst surfaced under Vitor, and stale
entries re-appeared on every account switch.
A NOTIFY doesn't reliably name a pubkey, so instead of parsing the message we
correlate it with the AUTH that triggered it: a paid relay answers an
unauthorized AUTH with `OK <authEventId> false …` right before the NOTIFY, and we
signed that auth event. NotifyCoordinator remembers each auth event's signer,
maps the failing OK back to it, and files the NOTIFY into THAT account's own
Account.relayNotifications. Unattributable NOTIFYs are dropped. DisplayNotifyMessages
now reads only the current account's cache.
Also removes the now-unused app-wide RelayAuthPermissionStore singleton and wires
NotifyCoordinator with the pubkey -> Account lookup.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
One shared NostrClient serves every logged-in account, so a relay's NIP-42 AUTH
challenge is not tied to any one of them. AuthCoordinator used to fold every
account's verdict into one decision and then sign with EVERY account (or a random
throwaway key), so a paid relay like inbox.nostr.wine billed and de-anonymized
accounts that never used it — including via a merged read filter that merely named
them, and via account switches / the background notification consumer.
Decide and sign PER ACCOUNT now: an account signs only if the relay is in its own
relay list, or it is publishing its own event there (RelayAuthFirstParty), AND its
own ledger verdict (Account.relayAuthLedger) allows it. A subscription merely
naming the account is NOT first-party — that is the merged-filter false positive.
The random-ephemeral-key fallback is removed. Own-inbox reads still qualify: the
relay serving them is by definition in the account's own list.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Per-relay ALLOW/DENY AUTH overrides (and the policy ledger that reads them)
lived in one process-wide DataStore keyed only by relay URL, so a DENY set for
one account silently applied to every logged-in account. Move them to a
per-account file under accounts/<pubkey>/ and warm-cache the overrides in memory
on the Account (RelayAuthPermissionCache) so an AUTH challenge is answered
without a disk read.
DataStoreRelayAuthPermissionStore now shares one DataStore per file path —
DataStore v1 forbids two live instances on one file, and loadAccount can build
the store more than once per account.
Introduces the per-account state holders wired up by the following commits:
Account.relayAuthPermissions, relayAuthLedger and relayNotifications.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The first version was a wall of identical label-value rows: correct but
unreadable at a glance. The redesign gives the screen visual hierarchy
and proportion:
- Headline 2x2 stat tiles for today (cellular, wi-fi, relay time, time
in app) — the numbers that matter get the visual weight.
- A 7-day data-per-day trend chart (Vico, same line/area idioms and
weekday axis as the notification summary chart) with a cellular/wi-fi
legend. Color pairs validated for CVD separation and lightness on both
surfaces: BitcoinOrange+RoyalBlue on light, #C77414+RoyalBlue on dark
(a selected dark variant, not an automatic flip).
- Data-by-feature as ranked proportion bars, so "video dwarfs relays"
is visible without reading numbers.
- Live memory as meters: the heap bar keeps the retired debug chip's
green/amber/red thresholds; image caches as fill bars.
- Activity counters stay as compact rows under one section.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016RJ8EAsdkHx5WHHU2eQJ1P
Moves the debug-build memory chip (home top bar) into the resource-usage
screen as a "Memory right now" card visible to everyone: app heap, native
heap, Coil RAM/disk cache fill, LocalCache note/profile/addressable/
chatroom counts, and the device memory class — refreshed every 2s only
while the screen is composed (same off-main collection the chip used,
DiskLruCache.size() contends with journal I/O).
The same snapshot is appended to the NIP-17 usage report (both from the
screen's send button and the high-consumption dialog), so a report now
also shows whether the device was under memory pressure at send time.
MemoryUsageChip.kt is deleted and the chip call removed from
UserDrawerSearchTopBar — the debug feature is retired from the home UI.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016RJ8EAsdkHx5WHHU2eQJ1P
Extends the resource-usage ledger with the metrics that answer "what else
could be draining":
- Relay (re)connection + failed-dial counters per network/visibility via
the existing RelayConnectionListener hook. Every completed connect paid
a TCP+TLS handshake, so high daily counts are the reconnect-churn
signature — new alert threshold at >5000 connects/day.
- Whole-process CPU time (Process.getElapsedCpuTime deltas sampled at
ledger flush): the honest aggregate of parsing, crypto, coroutines and
UI — one syscall per flush, nothing while idle. Answers whether CPU
matters at all before any per-subsystem drill-down.
- Foreground time (time with UI visible): what display power scales with,
and the denominator that makes every other per-day number interpretable.
- Signature-verification count + CPU time via a nullable meter hook on
LocalCache.justVerify (wired like cache.onchainBackend), settling the
"does Schnorr verify cost matter" question with data.
Deliberately not tracked (documented in the plan): per-screen time (route
names leak behavior patterns into a shareable report — needs its own
privacy pass), per-coroutine CPU (needs a thread registry; cpu.ms first),
and signing (user-action-rate, negligible).
All metrics surface in the usage screen, the NIP-17 report, and
UsageSummary; 4 new tests (18 total for the ledger).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016RJ8EAsdkHx5WHHU2eQJ1P
Vitor PamplonaandGitHub
Claude
vitorpamplonaandgithub-actions[bot]
David KasparandGitHub