yeah, i'm implementing a complete NWC client library and simple CLI too to make sure it's all working rn. then i'm making a subscription manager, all the configs, the special events it will use to store the configs, and the "only visible to you" privilege check so it can message you without the user needing a client that groks DMs - not that any of them do anyway.
Discussion
it seems every kind# requires a separate set of rules, so breaking it down by endpoint (in my case by relay) is the only way to make it work in a generic for UI type way. but that may not matter if the UI is the code editor.
i don't believe in kinds, also. i think that they are a redundant, unclear and ambiguous, and arbitrary special tag.
almost none of the letters available for indexable tags are in use, either, there's a wide open field that nobody is treading.
i'm gonna show them how it's done.
the client will be the dumb part in my conception of nostr. clients should always be dumb, because most client devs are dumb and feature creep is extreme with dumb devs. i mean, aspirational, ok, i will grant that but i know from my dealings with jetbrains IDEs that the more features they add, the less of them actually work
focus on making the essential things work, and never drop that ball.