https://github.com/nostr-protocol/nips/pull/1090 🤔  

 But it does make sense to force yours? 

 The PR is not my vision. I am a kind 1 developer. I want everything to circle and reuse kind 1s as much as possible. 

However, I agree that my interests are not aligned with the needs of other apps that could use the protocol. The world doesn't revolve on kind1. 

The earlier we accept that, the faster we are going to grow. 

 Unless you're referring to some other PR, this linked one above sounds precisely like it's your vision. You submitted it and you are the one avidly defending/promoting it in the comments. If it's not yours, then whose is it? You're free to fight for it. It just doesn't make sense to force your vision onto everyone else using the protocol. https://image.nostr.build/eb946e8640878d6b7c83beb137dfe34faaad62e283feb49f910a40fe7f9b35a2.jpg  

 I am not forcing it. It's up to the rest of the maintainers to merge it. I just provided the changes to the text. If they want to merge it, great, if they don't, then the text will keep stay inconsistent with reality.  

 So it's simply a suggestion/request, from you, with arguments in support of it made by you. How is that not your vision? Whatever merits your arguments for your proposed changes may or may not have, this is your vision for the organization and implementation of the Nostr protocol. My issue in this thread here is with your comments about others being free to "fight" for something while implying that your mere suggestion for the protocol is the defacto correct way to approach it. 

 I do a lot of things that are not my vision. I just follow reality where it goes. Sometimes it aligns with my vision, sometimes it doesn't. Life is hard.  

 Reality is that at its heart, its most basic level, the core purpose of Nostr is to be a social network where users are connected socially with each other across all sorts of "stuff." Is reading comprehension also hard? Have you considered that your vision is simply outside the scope of what Nostr intends to be? I know you are fond of forking stuff, so why not fork Nostr into "Nostr Vitor's Vision"? https://image.nostr.build/2a7b38edb8e90186cc53125fd8abfb7d2080055d8ae300310d2b1e3e09aee2fe.jpg  

 I don't really get your point. Every app is "social" these days. Even health care is, at the core, a social network (you, your doc, your pharmacy, etc).  So, what I am proposing is not against what you highlighted.

Every event kind in Nostr can be seen as a separate censorship-resistant social network. So, in many ways, Nostr has already forked itself multiple times. In fact, I do believe every client is also a fork of the network because no client displays **everything** the Network has yet. No client is complete. On top of that, every client does things differently. So, in some sense, they are all forks of the network. 

There is no consensus layer in Nostr. We don't select a single chain like we do when we run Bitcoin. So, the idea of forking the protocol itself doesn't really many any sense.

To conclude: Forks are either already happening with all event kinds or it's impossible to fork because Nostr already includes everything. There is no in-between. 

 > When I post a note with mistakes that make it illegible, i'm faced with either replying to my own note with corrections, or posting a new note.

Replying to your own note is the right path.

> This makes the recipient's experience degraded, and forces both parties into an idealology they have no connection to.

What's the ideology in question?
@Laeserin did make some ideological points against edits, but none of the points I made are ideological. In fact, they are mostly technical concerns.

> this is something that exisis already with any replaceable events such as the profile information

Yes, this is true and it's possible to see different info for the same account depending on what relays one uses.
Therefore, one shouldn't trust account info to be consistent.

Accounts info are metadata. One doesn't generally reply to an account description or reference it. Consistency is less of a concern, but modifications are arguably more important because it doesn't simply represent a statement made at some point in time.
Also, one doesn't generally identify (and verify) account info by an hash, but, rather, by the user ID, so account info wouldn't be necessarily consistent even if modifications were not allowed.

> but for notes it can easily be resolved on the client side by comparing revision data.

That means having to pull more data from relays, instead of stopping at the first answer which one can verify given the ID.