Well, when I started following nostr development, there were something like 6 or 7 NIPs. I always thought that the organization of the message specification in NIP-01.

I always thought that it made sense to have 2 or 3 "kinds", that basically designated the target of the message, either "broadcast to followers" and "message for the relay" and with just those two distinctions you could organize the data in the message portion better without so many application specific NIPs. Then, the content could be more than just plaintext, it could be nested JSON depending on the application for the message. For example, it could be cyphertext with a type *in the content section* specific to the application that the client understands. The core nostr spec would remain fluid, unrestricted and available for any application, and the proposals wouldn't need to be implemented in the protocol and message, they would just be client/application specific implementations of nostr.

Instead, now, we have specific tags and types for things like profile changes, things that attempt to imitate existing tools as use cases of nostr directly in the protocol.

I'm not saying I hate it or anything, I understand your approach was to allow nostr to be what the userbase wanted it to be and not be too restrictive or ideological about the protocol design. do think though that design decisions early on ripple through time and affect the growth of the protocol and so a bit more thought and rigor in the design can go a long way. I think the path taken has sort of solidified it's design as a distributed twitter, and it could have been used to replace everything from email to lichess (to use a concrete example that has been implemented as a PoC) with an uncensorable protoclol capable of private message sending where needed.

Again, to reiterate, it's easy for me to armchair critique after you've done all the work and made this real. But I don't think it hurts for people to voice their perspective. If what I say sounds stupid feel free to teach me something I don't understand. If you like some of what I say that's good too, I like discussing protocol design and things like that, it's fun.