I'm about to implement replaceable events in nostrdb and just had an idea that fix the contact-list unfollow problem for good:

when replacing a note with a new note, generate a "delta", which is the difference between the old and new note (tags, contents, etc).

This delta can be quite small, so it can be done automatically for all replaceable events.

This would enable any nostrdb app (damus ios, notedeck, etc) to "self-heal". it could detect simulatenous follow and unfollows and discard the unfollows.

You could also use this to show diffs in longform posts, and follow/unfollow histories for all users in your local db.

Reply to this note

Please Login to reply.

Discussion

Will I will pay sats for this!

Shouldn't the one with the newest created at always remain anyways though?

there can be situations where another client is updating an older version of one you have locally that is newer. this would technically be the "newest" even though its updating an older list. A delta would notice something is off

I'm going to end up reinventing CRDTs aren't i

chatgpt things so:

CRDT-Based Approach

Model the contact list as a Set CRDT:

• Add-Wins Set (AWSet): Always prefer additions to the set unless explicitly removed.

• Ensure removals are deliberate by tracking deletion markers (tombstones) for each p tag.

hrm

Now that i think about it, the safest thing to do is ask the user which follows and unfollows were intentional whenever it notices that it is updating multiple p tags at once. You don’t even need historical deltas for this

nm im dumb

safest isn't best

That's very elegant, yes.

The alternative would probably be moving to individual relationship status events.

Brilliant.

Lists should have been event-driven (added/removed entry events) instead of updated through full state transfers. Saving the entire contact list as an event should be used only as an ocasional check-point rather than for every single change. In that way, you could always read the latest checkpoint and then apply the delta events in sequence one after the other to compute the current state.

Don't really see the advantage in storing diffs, rather than just versioning in the db and generating diffs on the fly. Like git does.