A possible approach for nostr-next #57

New issue

Open

opened 2025-05-10 18:24:10 +12:00 by melvincarvalho · 1 comment

melvincarvalho commented

2025-05-10 18:24:10 +12:00

(Migrated from github.com)

One possible way to approach nostr-next is to loosely bucket changes into three groups:

Non-breaking changes
Soft forks
Hard forks

While (3) is definitely interesting, it’s probably not where we want to start—it’s a bit heavy for now.

What might be more realistic is focusing on (1): a set of non-breaking improvements that new clients can adopt to solve real problems and improve the user experience. These new clients wouldn’t need to interop with legacy clients out of the box—but if they can, even better.

There’s actually a lot of room in this category. Some ideas wouldn’t make it through the current NIP process—not because they’re bad, but because the system tends to favor existing approaches. After five years, we might just have found better ways to do some things. It makes sense to let nostr evolve.

A new client could build a small set of features, document what it’s doing differently, and others could pick up what they like. Which parts stick could be up for debate, and that’s okay—it’s how things grow.

This way, nostr-next becomes a space for experimental client evolution, where ideas can prove themselves without blocking or breaking existing work. If any of them catch on, first-gen clients can adopt what works—on their own terms.

One possible way to approach **nostr-next** is to loosely bucket changes into three groups: 1. Non-breaking changes 2. Soft forks 3. Hard forks While (3) is definitely interesting, it’s probably not where we want to start—it’s a bit heavy for now. What might be more realistic is focusing on (1): a set of non-breaking improvements that new clients can adopt to solve real problems and improve the user experience. These new clients wouldn’t need to interop with legacy clients out of the box—but if they can, even better. There’s actually a lot of room in this category. Some ideas wouldn’t make it through the current NIP process—not because they’re bad, but because the system tends to favor existing approaches. After five years, we might just have found better ways to do some things. It makes sense to let nostr evolve. A new client could build a small set of features, document what it’s doing differently, and others could pick up what they like. Which parts stick could be up for debate, and that’s okay—it’s how things grow. This way, **nostr-next** becomes a space for experimental client evolution, where ideas can prove themselves without blocking or breaking existing work. If any of them catch on, first-gen clients can adopt what works—on their own terms.

mikedilger commented

2025-05-11 17:35:27 +12:00

(Migrated from github.com)

But I encourage figuring out ways to get some of these features that I rather recklessly(?) put here into nostr without breaking or forking nostr. Some ideas may have landed here because only the naive way of solving the problem would break nostr, but a more clever way of doing it wouldn't.

And of course if the NIPs repo votes something down, but it wouldn't break nostr, that is also fine for any software to implement, but it is neither here (breaking things) nor there (accepted things)... it remains a non-standard feature of a nostr component. Many such things exist.

My intent was to only list category (3) items in nostr-next ... things that we can't do in nostr because the break would be too substantial. I'm not sure what a soft-fork is, maybe I'm including (2) too. But if a change is non-breaking, then we should just propose it in the NIPs repo. But I encourage figuring out ways to get some of these features that I rather recklessly(?) put here into nostr without breaking or forking nostr. Some ideas may have landed here because only the naive way of solving the problem would break nostr, but a more clever way of doing it wouldn't. And of course if the NIPs repo votes something down, but it wouldn't break nostr, that is also fine for any software to implement, but it is neither here (breaking things) nor there (accepted things)... it remains a non-standard feature of a nostr component. Many such things exist.