mleku @mleku - 16h
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*
nope, nostr isn't gonna move into the nineties and add mimetype tags that's why it's fortunate that i am an esteemed data architecture expert for the best nostr project and fortunate that they are all old school people who understand that what works for WWW should be valid and prevail on a much newer protocol
mleku @mleku - 15h
yeah, my recommendation is an M tag that uses standard mimetypes for now, textnote and article are pretty much plaintext and markdown for now, but they should have always had a mimetype tag attached to them having to write code that analyses content fields to divine their type is the epitome of retarded protocol architecture
Silberengel @Silberengel - 5h
WHY NOT JUST USE M TAGS?!!? WARUM IMMER EXTRA WURST? Es ist zum kotzen.
We are. MIME types in the `m` tags and Nostr-specific classification in the `M` tags.
For indexing.
You learn a heck of a lot about Nostr, if you hang out with backend devs.
Examples: https://njump.me/naddr1qvzqqqr4tqpzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqydhwumn8ghj7argv43kjarpv3jkctnwdaehgu339e3k7mgprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqq4xzetndac8xttxv93xcetn946x2um5ve5kcefdvfujmsuxwdhhqttk946x2um5v3shgcgm3ujq5 https://njump.me/naddr1qpzkzetndac8xttxv93xcetn946x2um5ve5kcefdw35x2tthdakxvtt5w4exuety94eksetsdpjhyepdxgkky7fdcwr8xmms94mz6ar9wd6xgct5vyq3kamnwvaz7tm5dpjkx6t5v9jx2mpwdehhxarjxyhxxmmdqgs06gywary09qmcp2249ztwfq3ue8wxhl2yyp3c39thzp55plvj0sgrqsqqqa2e5puf3m
I'm using `m` for MIME types and `M` for usage/category
mleku @mleku - 4h
it's just to limit how many indexes the relay's event store has to make to max 52 different kinds of tag keys, these are required to enable search, if you don't index them the only way to search is to exhaustively iterate through the records which would be insanely slow, but if you let any tag key be required to be indexed the database is again going to be very slow fiatjaf added this because he knows about database indexes, his code in the eventstore repo is quite extensive and actually even has a little bit of documentation
no, it's to tell the client what format of text is in the content field this would end the bullshit about not allowing markdown in kind 1 notes, for example
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
Silberengel @Silberengel - 2h
It's Nostr-flavored markup, but it's based upon Markdown or Asciidoc.
Yeah, I'm only building one editor, with a choice of Markdown or Asciidoc, as the basis. Why bother with plaintext? There is no such thing as plaintext.
1. This is *not* plaintext. 2. This isn't either. 3. You can write `anything` into a textbox. :heart:
Also, who died and said you can't use [[wikilinks]] in every note?
mleku @mleku - 1h
plaintext is from the before time, before Smalltalk at Xerox PARC as soon as it stopped being a dynamic version of a TTY there was no more plaintext even TTYs got colours and styles and blinking and underline and shit, not long after the arrival of GUIs
nostr flavored as in it recognises nostr: prefixed entities right? or are you supposed to use link: with those?
Silberengel @Silberengel - 1h
Yeah, it handles Nostr entities in a sensible manner, basically. You can see how that works in my latest PR. The Nostr Markup logic is actually complex. That's how the problem of the disappearing links came about. I'm not disappearing them, with my parser, I just add an internal link behind them, and then the user is free to choose. Sometimes external links are broken, after all, or you're someplace with slow Internet and avoiding websockets.
I've spent weeks figuring out how to do all of that stuff. Have a headache. 😂
As soon as you're like * First of all * Secondly * And don't forget It's markup. Someone can make that pretty, for ya.
