an example of the retardation of #nostr kinds, instead of using industry standard #mimetypes

i'm writing a full text index, and i've made a decent filter that ignores symbols and URLs and suchlike

so, actually, which event kinds even have content fields that you even want to search? textnote kind 1 and articles? there will be more, thanks to the awesome folk at nostr:npub1s3ht77dq4zqnya8vjun5jp3p44pr794ru36d0ltxu65chljw8xjqd975wz so i will have to update the kind whitelist in the future to cover their cases, but just imagine... what if i could just filter on a mimetype prefix of "text"

omg! what a revolution!

to not have to constantly scan through hundreds of bullshits and their format definitions to figure out if they might contain relevant content to your search engine's hunger for actual fucking text

nah, what a stupid idea. only been in use for 20 years it's surely not stable at this point

*cough*

Could we still make MIME types for events?

Reply to this note

Please Login to reply.

Discussion

We are. MIME types in the `m` tags and Nostr-specific classification in the `M` tags.

I agree with nostr:nprofile1qyghwumn8ghj7mn0wd68ytnvv9hxgtcpzemhxue69uhhyetpd3ujumtvv44h2tnyv4mz7qpqfjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsfa5ckl, implementing numeric kinds was a design misstep in the Nostr protocol. Numeric identifiers are inherently more difficult to memorize, standardize, and use correctly, also they create confusion.

A better approach would have been to implement standardized mime types or namespaced types instead of numeric kinds, which would have created a more intuitive and self-organizing system.

while I absolutely think you should use the `m` tag with your use case, I also think that we're early enough in nostr that we can still add mime-types as a replacement for kinds.

I actually like the kinds, as they're an easy way to find the relevant spec for some particular implementation (just search for all of them listing the kind number), and they allow numerous similar implementations to occupy the same space, without having to agree on a spec.

But the M space they occupy should be defined. Also, kind numbers only need to be unique _within a particular M space_, which means the devs working within that space need to keep a list of the kinds. Nobody needs to keep a full list.

nobody has bothered to keep a list either, should be a necessary part of a PR merge to add your new kinds to the list

There is the NIP repo ReadMe.md list, but many kinds aren't on it.

The ReadMe list additions are the only PRs that usually go through.