Good point :writinghand:
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*
Discussion
You learn a heck of a lot about Nostr, if you hang out with backend devs.
which is how it should be and why we should be given a bit more respect
nostr is a protocol, the clients are just clients, they could just as easily be pulling from any data source, they are not as important for the capabilities of the way the data can be moved around