fix(follows): reconcile local follow cache with newest relay kind-3#385
Open
dmnyc wants to merge 1 commit into
Open
fix(follows): reconcile local follow cache with newest relay kind-3#385dmnyc wants to merge 1 commit into
dmnyc wants to merge 1 commit into
Conversation
The follow-edit source of truth (FollowsCache) was only ever written at onboarding and on in-app follow/unfollow, and never reconciled against a newer kind-3 arriving from relays. A follow list edited in another client (e.g. trimmed via an external tool) was therefore never reflected locally, and the next in-app follow/unfollow rebuilt off the stale set and republished it, clobbering the out-of-band change. Track the created_at of the kind-3 that produced the stored set and add FollowsCache.reconcile, which adopts a relay copy only when it is strictly newer than what is held locally — replacing a frozen snapshot while refusing a stale copy that would undo a fresher local edit. Reconcile on launch (FeedViewModel.loadUserProfile, which already fetches the user's own kind-0) and when viewing one's own profile (ProfileViewModel.loadContacts). Follow/unfollow and onboarding now stamp the cache with the event timestamp.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes the bug where editing your follow list inside Wisp could restore an old, larger list — undoing a change made in another client. Closes #384.
The follow-edit source of truth (
FollowsCache→UserDefaults["follow_pubkeys_<pubkey>"]) was only ever written at onboarding and on in-app follow/unfollow. Nothing reconciled it against a newer kind-3 arriving from relays, so a follow list edited elsewhere (e.g. trimmed from ~1700 to ~1100 via an external tool) was never reflected locally — and the next in-app follow/unfollow rebuilt off the stale set and republished it, clobbering the out-of-band change.What changed
FollowsCachenow tracks thecreated_atof the kind-3 that produced the stored set (newfollow_pubkeys_ts_<pubkey>key) and exposesreconcile(pubkey:follows:createdAt:), which adopts a relay copy only when it's strictly newer than what's held locally. This replaces a frozen snapshot while refusing a stale copy that would undo a fresher local edit.FeedViewModel.loadUserProfile()(which already fetches the user's own kind-0) and when viewing your own profile inProfileViewModel.loadContacts().FollowSender(follow/unfollow) and onboarding now stamp the cache with the event's timestamp so a later relay fetch of the same event doesn't re-trigger.NostrKeyclears the new timestamp key on account deletion.Note: this prevents future clobbering; it can't recover a list the old code already overwrote on relays.
Test plan