I've been saying the same thing from the beginning. Though I'd go a step further and say that Nostr needs a BDFL. A stubborn forward-thinking mind is crucial to lead Nostr through the next couple of years when the explosion of new users and exposure of Nostr to the wide world comes. 

 I want to fork the existing NIPs repo, except #nip98.  That's the only one that will last. 

 How about adding a NIP with a list of the golden standard NIPs we consider to be a basic Client?

Aka. If you want to build a client in a weekend: only focus on these.

I certainly agree that webbrowsers have become bloated. And it affects their UX performance, but as @jb55 implies the w3 standards are so complex that even if open they are a barrier of entry for free experimentation. 

 Wonder if someone could automate a script checking opensource repos of nostr clients for what NIPs they have implemented. And then consolidate statistics over the usecase popularity of NIPs among clients.

Then we would get some clear data of the most foundational NIPs. Obviously, devs already know this by heart if they built a client. But numbers are nice :) 

 Why not just create nostr 2: electric bogaloo? 

 Yes, let's do it. Nostr 1 is so old. 

 dude you can just launch nostr 2 with its own token shitcoin, make a ton of money scaming everyone and disappear. It wouldn't be that hard.
Think about thay 

 this is exactly what Trump would want you to do. 

 NGL, the NIP madness is maddening at times. It’s hard enough to creat a decent client that is user friendly, it’s 100x harder when the landscape keeps shifting and changing while you trying to do it. 🐶🐾😭😭😭 

 i'm working on a codebase at the moment that uses a simple per-key 
password (or not) option. i considered creating a keyfile that can be 
used to encrypt multiple keys but i realised this was the wrong 
approach.

the better approach is to build a secondary encryption key management system that has one or multiple secrets unlocked by one or multiple passwords, in the same manner as used with dm-crypt and LUKS disk encryption. 

the crossing of the boundaries between the two systems with merging these two models into one creates more problems than it solves.

fiatjaf, of all people, you would think that he understands that systems should be simple and be layered, for reasons of simplicity and for reasons of security...

for this problem, what we need is a separate layer that keeps track of the grouped items. the users posts. the post threads. the subjects, the hashtags. these are second layer, and applying second layer techniques to first layer systems leads you to a mess.

nostr:nevent1qqs0svxgxfn66fwxy53ty55pymu82la9k73qrnuca3d9g5dcrzrzm3gpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy88wumn8ghj7mn0wvhxcmmv9uq3samnwvaz7tmjv4kxz7fwwpkx2cnnw3ezucm0d5hszxrhwden5te0wfjkccte9e3h2unjv4h8gtnx095j7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qgnwaehxw309ahkvenrdpskjm3wwp6kytcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszyrhwden5te0v5hxummn9ekx7mp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshszxnhwden5te0wfjkccte9emk2mrvdaexgetj9ehx2ap0faaxfp 

 They both have valid points 

 Yep, you've got the added problem that XMPP had: too many "MAY" pieces to the protocol and you wind up with a fragmented mess.

I don't think that's that big of a deal with nostr, but it is still a concern. The core parts of the protocol are standard, but if it isn't chess on nostr or some specific use case, you'll have different people using different clients that support subsets of the supported features and it ends in frustration. 

 I don't feel frustrated at all, when I see different clients I just feel joy. 

 Please do that.