they were looking for common rules, but I don't know if they succeeded in the end
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
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
one part will do right
WHY NOT JUST USE M TAGS?!!?
WARUM IMMER EXTRA WURST?
Es ist zum kotzen.
M tags instead of what? Kinds?
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
True.
But it's not really even MarkDown and AsciiDoc that we're using here.
We've got nostr : nevent links, invoices, custom emoji, inline profiles, etc...
Time to also have clear definitions of these nostrified versions imo:.
- Ntext
- NDown
- NosciiDoc
It's Nostr-flavored markup, but it's based upon Markdown or Asciidoc.
nostr flavored as in it recognises nostr: prefixed entities right? or are you supposed to use link: with those?
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. 😂
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?
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
As soon as you're like
* First of all
* Secondly
* And don't forget
It's markup. Someone can make that pretty, for ya.
