Removes the local_relay SharedPrefs entry, KeyRepository's
localRelayFlow / save/get/load helpers, and RelayViewModel's
local-relay state and update methods. StartupCoordinator no longer
wires the relay pool to localRelayFlow. reloadPrefs clears the
orphaned local_relay key on account switch.
Removes LocalRelayConfig, LocalRelayWritePolicy, the LOCAL value in
RelaySetType, and isLocalRelayUrl from RelayConfig.kt. Strips local
relay state, forwarding paths, lifecycle pause/resume, and the
own-notes OutboxRouter branch from the relay layer.
Wisp can now only sign events with a locally-stored nsec. Existing
REMOTE accounts are logged out on first launch via a one-shot
migration that filters them from the registry and scrubs the
indexed signer_package keys. Other accounts (LOCAL, READ_ONLY) are
preserved; the user is auto-switched to a remaining account or
dropped on the AuthScreen if none remain.
- Delete RemoteSigner, RemoteSignerBridge, SignerIntentBridge, and
the two signer exceptions
- Drop the "Login with Signer" button and intent launcher from
AuthScreen
- Collapse SigningMode to { LOCAL, READ_ONLY }
- Remove the REMOTE gift-wrap deferral branches in DmListViewModel
and EventRouter (decryption is always local now)
- Drop the dead contentResolver ctor param on WalletViewModel
- Remove the nostrsigner: <queries> intent filter and 9 related
strings across all locales
When a new user finishes profile setup, OnboardingViewModel.finishProfile
saves the discovered+tested relays locally and publishes a kind 10002
relay list event. Insert wss://relay.wisp.talk into that list before
saving and publishing, so every new Wisp account advertises Wisp's relay
to the network from day one.
Read+write so the new user both publishes to and reads from it. Dedup
on URL (case-insensitive) so we don't duplicate if probing already
discovered the relay independently.
Reverts the earlier change to RelayConfig.DEFAULTS — that was the wrong
place. The DEFAULTS list is a fallback for users without an onboarding
flow; new-account injection belongs in onboarding where the relay list
event is actually constructed and published.
Adds Wisp's own relay to RelayConfig.DEFAULTS so every new account
picks it up automatically. Covers all signup paths via the existing
loadRelays() fallback — Sign Up, Google auto-create-at-0, Google
"Create another account", and read-only npub login.
Existing users with an explicitly-saved relay list are unaffected
(their stored list takes precedence). Existing users who never saved
a custom relay list will pick up wisp.talk on next load.
Read+write so new accounts both publish to and read from it.
Previously a first-time user with no Nostr activity yet would land on a
chooser screen with an empty list and a "Create your account" prompt
explaining the deterministic-derivation model. Cuts an extra tap and
some explanatory copy.
Now: if the probe returns zero accounts, auto-derive the keypair at
index 0 and transition directly to ONBOARDING_PROFILE. The chooser
screen only appears for users who actually have existing accounts to
pick from.
Deterministic derivation means auto-creating at index 0 is safe: if a
later sign-in (e.g. after a flaky probe) discovers existing activity
at index 0, the same nsec is regenerated, so no identity is lost.
Replaces the Google Drive backup flow (#528) with deterministic key
derivation. The user's Nostr identity IS their Google account — no
encrypted blobs to store, no backup events to publish, nothing for
Google or any third party to retain.
privkey = SHA-256("wisp-account-v1:" || sub || ":" || accountIndex)
Properties:
- Same Google account always derives the same nsec on any device
- No backup to lose: signing in regenerates the keys
- No `drive.appdata` OAuth scope, no scary Drive consent dialog
- Anyone with access to the Google account can derive every nsec.
Bounded by Google account security — same trade-off as #528, with
a much simpler attack surface and no third-party storage layer
Discovery on sign-in:
- Derive candidate keypairs for indices 0..15 from the user's `sub`
- One REQ to relay.damus.io, relay.primal.net, nos.lol, nostr.wine,
relay.wisp.talk, relay.ditto.pub asking for kind 0/3/10002 events
from those pubkeys
- Pubkeys with any activity = "in use" accounts that go in the chooser;
avatar + display name come from the same kind-0 events
- "Create another account" derives the next-unused index
Code shrinkage: DriveBackupService is gone, BackupCrypto's encryption
helpers are gone, the play-services-auth dependency is gone, and the
Drive-related ProGuard rules are gone. The whole flow is ~200 fewer
lines than #528 and easier to audit — the derivation is one line of
SHA-256.
Splash button switches to Google's dark-mode brand variant (#131314
container, full-color G, #8E918F stroke) per Sign in with Google spec.
No migration needed: nobody is on the #528 flow yet.
Adds a third splash entry point alongside Sign Up / Log In:
- Credential Manager + Google Identity for sign-in; AuthorizationClient
scopes drive.appdata so Wisp can read/write a hidden per-app folder
- Per-account backup files named wisp_nsec_<npub>.bin in appDataFolder.
One Google account can back up many Nostr identities; sign-in lists
every backup found and the chooser shows each with avatar + display
name fetched from relay.damus.io / relay.primal.net (kind 0)
- Encryption key derived via HMAC-SHA256 from the Google sub claim,
reusing Nip44's XChaCha20 + HMAC building blocks for the payload.
Plaintext nsec never leaves the device
- "Create another account" is always available, even when prior backups
exist, so users can keep adding identities without overwriting
- Google-branded splash button (white, full-color G logo) per Sign in
with Google brand spec
Previously the dismiss only fired once raw drag distance cleared 120px,
so a quick downward flick that released early stayed put. Match the
iOS counterpart in barrydeen/wisp-ios#117 — feed positions into a
VelocityTracker during the drag and on release project the end
translation by 0.3s of velocity, committing the dismiss when that
projection clears 120px. A slow drag still needs to cross the raw
threshold.
Applies to both ZoomableAsyncImage (image pages in the pager and the
standalone single-image viewer) and VideoPagerPage (video pages in
the pager). Horizontal page flicks already worked via Compose's
default PagerDefaults.flingBehavior — no change needed for those.
Adds a "Multi-image layout" setting (Gallery / Stack), default Gallery,
under Settings → Interface → Media.
Gallery mode collapses 2+ consecutive image/video segments inside a post
into a horizontal carousel — tiles are 4:5 with the next one peeking
from the right and an overlaid "n / N" counter at the bottom. The final
tile snaps flush to the right edge. Whitespace-only text between media
URLs is treated as a joiner so two images on separate lines still group.
Tapping any tile (gallery mode) or any inline image (stack mode) opens
a fullscreen pager:
- Horizontal swipe between images
- Pinch-zoom 1-4x with pan clamped to image bounds
- Double-tap toggles 1x ↔ 2x with the tap point pinned
- Swipe-down at 1x dismisses with a background fade
- Existing Download / Copy URL / Close action row
Single-image posts also route through the pager (one-page case), so the
viewer is consistent regardless of layout style.
Gestures are implemented in a single unified awaitEachGesture loop so
horizontal single-finger drags fall through to the parent HorizontalPager
for paging, while vertical drags drive swipe-to-dismiss.
8dp vertical spacing between every block in RichContent for breathing
room in stack mode and between text/media boundaries.
Test plan:
- Gallery mode: multi-image post shows carousel with peek-right and
bottom counter; last tile snaps flush right; tap opens pager
- Stack mode: multi-image post stacks vertically with 8dp gaps; tap any
image opens the swipeable pager at that image's index
- Fullscreen pager: swipe horizontal pages, pinch-zoom, double-tap,
swipe-down dismiss with bg fade
- Single-image post: tap opens swipeable pager (one page)
When typing @mentions, first check local follows and cached profiles.
If fewer than 5 matches are found, query wss://search.nostrarchives.com
(NIP-50) and stream results into the suggestion list as they arrive.
The relay subscription is cancelled on each new keystroke and cleaned
up on EOSE or after a 3-second timeout.
Also adds @mention autocomplete to the livestream chat input, which
previously had no mention support.
Adds an opt-in Interface setting that auto-triggers the existing on-device
ML Kit translation pipeline as notes render, so foreign-language notes are
translated without tapping each one. The toggle is off by default and the
manual Translate menu item still works.
The local relay socket was managed in a separate code path from
regular relays and was excluded from the lifecycle manager's
reconnect iterations. As a result it stayed connected indefinitely
across app backgrounding and only ever closed on account switch or
config change.
Add pauseLocalRelay/resumeLocalRelay helpers on RelayPool that drop
the local socket on pause and bring it back on resume while keeping
the localRelay / localRelayConfig references intact, and wire them
into RelayLifecycleManager.onAppPause / onAppResume. Also re-enable
reconnectEnabled in updateLocalRelay's same-URL branch so toggling
the relay off and back on while paused recovers cleanly.
https://claude.ai/code/session_01YHsgf89CpMXtj2wETzX588
For accounts using a remote signer the Keys screen now replaces the
"Reveal Private Key" affordance with a Remote Signer section, matching
the layout shipped on iOS:
- Section heading + subtitle explaining the private key never leaves
the signer app
- Status pill (Checking… / Available / Signer app not installed) with
a pulsing dot while checking
- Refresh button to re-probe
- "Signer App" row showing the recorded signer package id
Adapted to the NIP-55 protocol Android uses (Intent / ContentResolver
to a local signer app, no relay-mediated RPC): the health probe is a
PackageManager `getPackageInfo` lookup on the package recorded at
sign-in. iOS's relay-list and transport-pubkey fields don't apply
under NIP-55 and are intentionally omitted.
The local-keypair path (`SigningMode.LOCAL`) is unchanged — same
Reveal Private Key button + nsec card + warning text as before.
Mirrors the iOS work (barrydeen/wisp-ios): the zap dialog's custom
amount input is fiat-aware and uses register-style entry — the user
types digits, they fill from the cents place ('21' -> $0.21,
'2100' -> $21.00), and the field renders the formatted dollar string
with the configured currency's symbol.
Implementation notes:
* Field is bound to the raw digit string and a [VisualTransformation]
renders the formatted dollar view. Compose's cursor lives in raw-
string coordinates and the OffsetMapping pegs the cursor to the end
of the formatted view, so backspace removes the rightmost digit
cleanly. The earlier String-only attempt — binding the field to the
formatted string and re-formatting in onValueChange — broke
backspace on Android: when Compose's internal text changed from
'$0.2' to our re-formatted '$0.02', it couldn't map the old cursor
position into the new string and snapped it to the start, so
subsequent backspaces just moved the cursor instead of deleting.
* New ExchangeRateRepository.fiatToSats(majorAmount, currency) — the
inverse of satsToFiat — converts the typed (cents / 100) dollar
amount through the cached BTC-to-fiat rate.
* AmountFormatter.renderCurrency drops trailing zeros for sub-dollar
amounts ('$0.84' instead of '$0.840', '$0.8' instead of
'$0.800') by switching the DecimalFormat patterns to '#' optional
digits past the decimal. Whole-dollar amounts still pad to two
places ('$1.00') matching retail convention.
* zap_x_amount string flips from 'Zap %1$s' to 'Send %1$s' so the
Send button reads 'Send $X.XX' in fiat mode (was 'Zap $X.XX').
* LiveStreamScreen's zap button reads 'Send' / 'Sending...' in fiat
mode, 'Zap' / 'Zapping...' otherwise — matches the surrounding
wallet UX.
Companion to the iOS PR for the same UX (cross-linked at filing time).
PR #514 changed the bottom-nav handler to use popUpTo with the graph's
start destination plus saveState/restoreState. Two regressions resulted:
- Tapping a tab restored the tab's saved back stack, returning the user
to a previously-open thread instead of the tab's main screen.
- The graph's start destination (LOADING) is popped inclusive on first
successful load, so popUpTo never matched. The resulting back-stack
state could surface the splash/auth screen on system back from
Notifications.
Revert that block to popUpTo(FEED) { inclusive = false } + launchSingleTop,
which always lands the user on the tab's main screen with a shallow stack.
The refreshDmsAndNotifications() throttle introduced alongside the broken
nav block is preserved — that part addresses real REQ churn jank and is
independent of how the back stack is structured.
- give getNip05Client a dedicated 5/10s client (was aliasing the 10/15s
general client); slow .well-known/nostr.json endpoints no longer tie
up verification threads
- add getDownloadClient (30/60s) for MediaDownloader; the shared media
client (10/30s) is fine for ExoPlayer streaming but its read timeout
is too tight for full-file downloads on flaky networks
- tighten notification rebuild coalesce window from 50ms to one frame
(16ms) so single-arrival updates feel responsive
- add NotificationRepository.shutdown() and call it from
FeedViewModel.onCleared() so rebuildScope doesn't outlive the VM
Restore top-level tab destinations instead of recreating them on each tap, and avoid immediately resubscribing inbox streams when users bounce between tabs. This reduces navigation jank and repeated hangs on slower devices.
NIP-17 gift wraps are re-fetched on every cold start (the kind-1059
subscription has no since cursor because gift-wrap timestamps are
randomized up to 2 days in the past). Without a decrypted-DM cache,
remote-signer mode (Amber) re-runs two NIP-44 IPC decrypts per wrap on
every launch.
Adds an ObjectBox-backed cache keyed by ownerPubkey|giftWrapId. On
construction, DmRepository hydrates conversations, seenGiftWraps,
rumorIdIndex and the DM notification list from disk off the main thread.
addPendingGiftWrap now short-circuits on seenGiftWraps before queuing,
so relay-redelivered wraps never reach the signer; only newly arrived
wraps are decrypted. addMessage / addReaction / addZap re-persist the
parent message so reactions and zaps survive restarts. clear() and
purgeUser() propagate to the persistence layer.
Drops the embedded kmp-tor client, all .onion relay support, the Tor
toggle UI on splash/auth/drawer screens, the SOCKS proxy plumbing in
HttpClientFactory, all Tor-related strings across 11 locales, the
TorManager singleton, and the kmp-tor dependencies and ProGuard rules.
Relay URL validation now accepts only wss:// (with hostname, no port,
non-localhost, non-IP). The cleartextTrafficPermitted network security
flag stays — still needed for local relays on RFC1918 / loopback.
OkHttpClient.newWebSocket() can block on its shared TaskRunner lock
for several seconds under contention. UI callbacks that invoke
RelayPool.sendToRelayOrEphemeral were calling Relay.connect() inline
on the main thread, producing 5s+ ANRs. Dispatch connect() through a
small dedicated thread pool so callers never wait on WebSocket setup.
Inline video players in RichContent now use REPEAT_MODE_ONE so MP4s
auto-repeat when rendered inside a note card. Applied to both freshly
created and PiP-reclaimed players. Fullscreen and audio paths are
unchanged.
Barry Deen
The Daniel
Claude