Oddbean new post about login | logout Some fundamental issues of Nostr that make it difficult to scale (but can be fixed): - NIPs are not versioned. There’s no way to tag which version an event is using, which can lead to divergent interoperability issues. - List updates are all or nothing (leading to them being nuked in certain scenarios). Updates should be incremental. - Replaceable events don’t have versions so the created at timestamp is used as a proxy to determine freshness and that could be incorrect.
Interesting, I haven’t run into the problem with NIPs changing. The list problem has really been bothering me lately though.
It’ll happen naturally over time with breaking changes being introduced or multiple devs implementing things in different ways. Nostur does a really good job of keeping track of follow list changes and prompts the user to pick which copy should be kept. But it feels like a bandaid fix on top of a fundamentally flawed spec.
100% agreed about it feeling fundamentally flawed. On NIPs changing — I guess I just assumed that new NIPs would be introduced that supersede old NIPs. Is that not what happens (or will happen)?
They do, if you subscribe to the GitHub nips repo as the arbiter of truth. Meaning you trust the group of folks who have merge powers to make decisions you find reasonable and don’t break your client (which have happened). There’s already attempts to decentralize the NIPs repo by using Nostr as the mechanism to decimate spec updates. So you could have dozens of different specifications for the same concept / NIP. You could even introduce a NIP number where the spec has nothing to do with the same NIP number in the GitHub repo. There would need to be a way of specifying in the published event which truth it subscribes to. Or not, and we just plow through this chaotic decentralized environment and hope everything works out. 😅