lol you wrote it literally at the same time I posted about it 😂😂😂😂🎯

Running on: wss://ec1.f7z.io wss://ec2.f7z.io wss://ec3.f7z.io Demo client included in the repo or just use nak. View quoted note →

if you don't want replaceable events to be overwritten ... just retain them? no protocol changes required

calm down buddy and if you don't understand what this is for, move on.

Wut? This is no protocol change and retaining them wouldn’t solve knowing you’re working with old state, it would solve only recovering from it

so does keeping old replaceable events, without making resolution a client problem

PABLO!!! ADDING AN OPT-IN HASH CHAIN WITH THE ABSOLUTE MINIMUM SPECS (unique tip) IS HARAM! quote from this guy: "this centralizes the protocol on relays and kills distribution and censorship resistance. it trades one convenience for everything that makes the protocol valuable"

😂😂😂😂😂🪦🪦🪦

Unique tip? Dude that’s like the greatest lie out there, it’s never just the tip, trust me.

Is there any reason things like follow lists have to be a single state event rather than a series of intent-based events? Like CRDTs or event sourcing. Wouldn’t need a relay to determine the latest version, though holes would lead to some silent inconsistency. But it could also be said that different clients could end up publishing conflicting chain events to different relays and resolving the conflict wouldn’t be clear either. As a client hopper I can totally see this happening with blocklists for instance (or rather, wouldn’t stop what already happens). Maybe it would be useful to have both systems complementing each other, the ultimate complexity but also most likely to end 99% of these state bugs.

Howdy What does this solve exactly? Feels like this is kinda just turning a relay into a public DB/state machine Wouldn’t it make more sense to have: 1 reliable relays with specific policies/functions 2 users/merchants publishing preferred relay sets 3 clients prioritizing those relays appropriately …more Nostr native than enforcing sequencing at the relay layer? My 2 cents

This is good.

Can it stop my mute list from being wiped too? That keeps happening to me for some reason.

@npub1jj4x...45q3 добавь себе это где-то в закладочки, - пусть будет, хотя вряд ли пригодиться....

make nostr scuttlebutt again

If it wasn’t obvious and repeated enough, almost nothing needs this and it’s not something to be adopted by “big” “public” relays, this is more for stuff like not accidentally overwriting your own drafts and nip60 wallets state because a client started working with bad state or something; all state you’d want to write to your private relays anyways View quoted note →

No, it’s not meant to be used by public relays; it’s meant to be used with your own relay to keep track for example of draft events such that you don’t accidentally overwrite from a client that hasn’t properly retrieved the latest stuff.

Ah gotcha, thank you!

@npub1gvfm...vyex could be an interesting feature for Congee in a personal relay setup

Neat, i like the problem its solving. I think there is more optimization client side to ensure REQs for drafts or other stateful material completes gracefully before enabling user changes or updates.