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. 

 "gambiarra" = work-around

nostr:nevent1qqsxt67e7g0rc7a3ndkqfrwwctcsut8s37tg0pvwv8v42vpdm6s3tkspz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqqqqy4777t6 

 nostr:nevent1qqsxt67e7g0rc7a3ndkqfrwwctcsut8s37tg0pvwv8v42vpdm6s3tkspz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqqqqy4777t6 

 @fiatjaf is an attack on #Nostr. Good work @Vitor Pamplona amethyst is amazing 👏 
nostr:nevent1qqsxt67e7g0rc7a3ndkqfrwwctcsut8s37tg0pvwv8v42vpdm6s3tkspzpmhxue69uhkummnw3ezumt0d5hsygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5psgqqqqqqsf0k20q 

 Need a version of #Nostr for this meme 🤣

https://nostrcheck.me/media/34651a9392d34bf9d064e39f3c10beef74b5e28e710c07324317b687c4abd7e8/c5ecbc456ab80a62be19f54b2940c02249a9f97cd07c6083b7e75633dc3afba4.webp 
nostr:nevent1qqsvlaydyvq0z9xmvesg59g6hwajdkn0hrhfcprlzzxzegus6hs9m9qpzdmhxw309akx7cmpd35x7um58g6rsd3eqgsrgeg6jwfdxjle6pjw88euzzlw7a94u288zrq8xfp30d58cj4a06qrqsqqqqqp9xyqef 

 That's also bad. 

 So, don't do this, don't do that. What can I do? Either way, Edits are happening. 

 I gave my opinion, what else do you want? 

 Some would implement that kind, others wouldn't.

That's not normally a bad thing. It's part of how Nostr is meant to work. But it's bad in this case because those events would serve the same purpose as kind1 events most of the time, for most users, in most circumstances. 

 Your arguments are much better. I henceforth adopt them as mine. 

 you can always "edit" and "fork" the argument to make it yours 😌 

 I am flattered by your plagiarism. 

 Nostr is was never about building the "ideal", it was about building a thing that works well enough. 

 It’s the beta test of the future  

 In the sense of "ideals of uncensorable" I didn't mean the implementation needs to be ideal, only that uncensorability is the ideal to strive for. 

 My point was exactly that trying to get an "ideal" in this case would sacrifice other important values of Nostr, one of them being the practicality. So no, we shouldn't be always "striving for ideals".

The ideal social network would be a pure p2p thing with no IPs, no DNS. 

 Those are implementatiom details. What is the requirement you intend to fulfill with "no IPs and no DNS"? 

 The DNS system is centralized and prone to censorship.
You *can* add other DNS roots, but it doesn't really solve the problem.

I suppose systems like Namecoin or ENS might address the problem, if they get traction. Many on Nostr would have a problem with them because they are based on blockchains other than Bitcoin.
Personally I have no issue with that, although I don't know what secondary problems they would create.

The IP address space is also controlled and censored. 

 Decentralization > uncensorability?

I doubt this is your stand. Nostr is built on IP. Lets suppose they can censor IP and DNS. From what I see, nostr already addresses this risk with its architecture. Again, you jump to solutions but haven't amswered my question.

What is the underlying problem that nostr needs to solve? What are the requirements to that solution? Is it to solve the problem that people want to edit their own posts, is it to optimize relay bandwidth or is it to be a decentralized protocol? I doubt it is any of these.

I see nostr's primary aim is to enable uncensorable communication with a minimalistic protocol design. Tell me why I'm wrong. 

 > Lets suppose they can censor IP and DNS. From what I see, nostr already addresses this risk with its architecture.

Nostr addresses censorship by relays themselves. But if all involved organizations wanted it, and it's a closed market, they could censor all DNS names and IP addresses used by Nostr relays.
Obviously this is hard and unlikely, which is why Nostr does provide (some level of) censorship resistance.

> What is the underlying problem that nostr needs to solve? What are the requirements to that solution?

From my understanding it's corporate censorship and it mostly does solve that.

> I see nostr's primary aim is to enable uncensorable communication with a minimalistic protocol design.

I agree. I never suggested allowing edits is against the purpose of Nostr. 

 >They could censor all DNS and IP addresses that relays use

Even over tor ?

The simplicity of the protocol is its strength. The JSON can be sent over radio in morse code. 

 

 > Even over tor ?

If you use Tor to access a clearnet domain, the domain owner is the same as if you access it trough clearnet.

If you are referring to .onion domains for hidden services, then obviously that's outside of the scope of the centralized DNS system and does not have these problems. 

 I agree about editing since you have the older version. But deleting is not a good thing  

 > 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.