Just came up with a new plan for fixing replaceable events with nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj

The biggest issue with replaceable events (contact lists, profiles, lists,) is that there is no versioning scheme. This leads to many issues where your contact list is dropped, comments+likes+zaps appearing only on older versions of a post, etc.

We need a concept of versioned events in nostr and a way of querying those effectively. Looking forward to working with nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj on this and implementing it in Damus, nostrdb and hopefully strfry once we figure it all out.

Reply to this note

Please Login to reply.

Discussion

Good things about of this for sure πŸ™ŒπŸ‘

Thank you πŸ‘ and Pura vida πŸ«‚

Maybe timestamps could indicate versioning. Sounds like we need relays to treat them differently though.

We just need to not add information destruction as a core protocol feature. It leads to many awkward outcomes.

This is great. I was just digging through the nos code to try and find a bug where it sometimes rewrites your mute list. Other times if you mute in two apps at the same time one of those updated mute lists overwrites the other. It’s frustrating.

Great πŸ’‘

Laugh at your division?

As a group, or that you can't organize?

Or incorrect?

ohh.. I thought somebody would go for a Unified Format type of thing. :(

You should probably specify what happens when Clients filter for replaceables. I am willing to bet very few clients add a limit 1 to get only the latest update. They might end up receiving all historical events if relays are now keeping the entire history and we change the way the filter works.

Could this be used for editing notes?

Sorry not sorry typo maxis

Replaceable events are already being used to edit notes (longform, etc). The problem is you lose edit history when you abuse replaceable events like this.

Chain of hashes? The new event hash has to probably include the hash that it's replacing?

Probably