Well, if kind 1 doesn't make sense for some apps I don't see that as a problem at all and I am not trying to force those apps to use kind 1.
But many other use cases can have their own independent existence but also use kind 1 for signaling/discovery -- most notably the common "social" things like long-form events, video events, song events, podcast events, picture events, livestreaming events, calendar events, perhaps even nip29 group events.
Nip 01 is mandatory. Which means kind 1s are mandatory. If you think it is optional, the text is wrong.
All other use cases were using kind1 for replies but now they are all moving to use nip22. Kind 1 is really only for Twitter-like clients. 90% of nostr doesn't need to bother by kind1.
I agree that kind 1 must not be considered mandatory.
Then, let's remove it from NIP-01.
I really hope nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z's PR will be merged.
OK, time to get that thing moving again.
So you would have a reference to other NIPs in NIP-01? Like for implementation of kind 1?
This makes sense. A base protocol without a specific application. One had to look up another NIP to get something real working. So NIP-01 would lose one aspect of its beauty: it‘s self-contained and complete. At least for the „SMS-case“ in a world with „internet“.
.jpg)
