Looking up kind numbers / tag letters is probably around 0.1% of development time. And you need a dependency for that, that has to be maintained, and version bumped a lot. A lot of us don't want to do that. Just creating an enum for yourself for the kinds you use is probably the most productive for devs with bad memory.

But you can create that enum yourself for kinds and publish for everyone out there to use. If it's needed by many, it will be used. But expect some conflicts if the same kind is used by different apps. It's also a vector for supply chain attack, not to mention the case when the maintainer of the enum package goes on holiday and somebody wants to release sthg.

For tags, it's even more complicated because tags semantics is different for each kind. 

 Naming things is one of the notorious "hard problems with computer science". Using numbers allows us to have a referent without interpretation, avoiding a lot of bikeshedding and confusion. 

 take “bike shedding” for example 

 the stupid question IS bikeshedding 

 it's also easy to just make your own lexicon anyway, that's what i've done, i have a whole data structure with name/number/symbols bound together and reverse lookups so you can go the other way, easily create a printable version of the number

the question is silly because an enum scheme would mean fighting over the human readable forms and there's just no reason for that, it's irrelevant 

 write the dictionary of symbols in one place if you want to be helpful

nostr is ours, not handed to you on a silver platter... fiatjaf's go-nostr library is ok, but i found dozens of ways to improve it in my version at https://realy.lol i eliminated the complexity of maps in the filter structure by extending the use of tags for it, and this is the same data structure you are talking about

it's a work in progress, i suggest you try to build something first before you criticise the architecture 

 well defined by WHO is the reason

that should just be in the library you are using, so go ask them that question

this is how i did it in my fork of fiatjaf's go-nostr:

https://github.com/mleku/realy/blob/dev/kind/kind.go#L79

there is a forward index with symbols just below it that are named, some have synonyms because there is a couple of different ways to refer to it, and on the other side, there is a map and a mutex so it can be safely accessed concurrently with the function on the line shown there, from a reverse dictionary

i could probably change it into a generated form, so there is a simple one way lexicon and then programmatically generates the reverse lookup

this gives you a string you can get based on the number of the kind, and in reverse, you can use the name to refer to the kind as a symbol such as `kind.MemoryHole` which can give you the number with `kind.MemoryHole.Number`

writing a canonical, text formatted version of this would not be a bad idea, and i could then pull the latest version of it and update my table from it

i'm happy with how it is now though, but if you have the time to sit down and define the some 150 or so kinds that have been defined, and trawl all the pull requests and issues to find others that may be in early stages of being refined, you would be doing us all a service to help formalise it

it's just not that important, the majority of ones that a client needs to know about are specific to each module of the app that is being built, and the relays barely even need to know, i actually put all this in for debugging reasons more than anything else