Forking nostr is impossible, it's a myth. It's what we have, we just have to live with the good and the bad. However it is proprietary as in "property of". I know this as a fact, as ive known FJ 10 years, longer than anyone else here. It's neither good for nostr nor for FJ. But it is what it is. Nostr would have benefitted by moving to an open transparent, community run project, but it was not to be. Not all is lost, you just need to know the rules and keep on building.

Reply to this note

Please Login to reply.

Discussion

1) If forking nostr is in fact a myth then I would agree with what you're saying.

2) However, Nostr is merely a protocol that is implemented by many clients. I personally use noStrudel and amethyst. I'm not sure how 1 is true.

3) It's unclear to me why you knowing FJ for 10 years should give more credibility to your argument. Either nostr is forkable or it isn't. And the answer to that question doesn't seem dependent on you knowing or not knowing FJ.

Knowing him means I chat to him alot. I wont disclose those chats, but he has made it clear "Its my project and I can do what I want". That's OK, but it should also be known. You have no idea the hard work that it took to get nostr to where it is, any fork is impractical. The core protocol can change on a whim. So saying "no one owns it", is inaccurate. That's the only simple point I was making. IMHO this was a mistake, nostr should have gone community driven when we had the large influx of devs, and before the exodus. But it is what it is.

"It's my project and I can do what I want" can be both true and irrelevant. He can do what he wants to his project. But that doesn't mean he can prevent forks.

Getting nostr to where it is absolutely was difficult. But that doesn't make forking impractical now.

The core protocol can't change on a whim. If that happens tons of different clients break.

I remain skeptical of your claim.

fiatjaf cannot unilaterally change the protocol

I don’t understand the argument for why it’s not forkable … nostr consists of clients which implement NIPs and relays. Fiatjaf doesn’t control any implementations. Maybe he has the ultimate merge say (I don’t even know if this is true) but it’s up to clients what they wish to implement. And if enough devs decide they don’t like the direction, I don’t see why they couldn’t fork off and ignore FJ’s version …

But I don’t know anything so… I’ll be quiet now.