Nothing. Most early nostr clients supported markdown. It was removed to keep kind-1 simpler.
The early Twitter was a success thanks to limitations and I think, limiting note length wouldn't be a bad idea in nostr neither. Make ideas bite-size so you can zap/like/comment an idea without having to refer to the whole book.
Markdown is so bad in so many ways. Here are some, but I'm sure I forgot many others:
1. it's not a standard, there are dozens of variations and quirks;
2. parsing is hard and slow specially when you get to combinations of markups blocks inside other markup blocks and lists;
3. it sells itself on being readable as plaintext -- and it truly was in the beginning --, but with ![]() and []() URLs and ## titles it's really a pure-markup language that can only be read as plaintext with great effort, like HTML;
4. no one really wants to write Markdown, only a dozen nerds, and for some reason they assume the entire world loves Markdown.
1., 2. it's good and easy enough
3. image urls and urls with title are indeed only meaningful readable once parsed but then again, how would you accommodate for these in any better way?
4. Maybe I'm guilty of that. But then again, how do you know the world doesn't love Markdown? 😅
That said, I stand by what I posted before. Markdown wasn't removed from kind-1 for the reasons you mentioned now.
I have tried to get normal people to use Markdown things multiple times in the past. They have no idea of what that is.
I am 100% of the opinion that "normies" can learn anything and that we shouldn't refrain from pushing "technical" things into them when that's important, but part of the Markdown sales pitch I see sometimes is assuming that Markdown knowledge and love is widespread, when that is so absurdly false it's ludicrous.
Not all devs are like this, but many devs grew up experiencing negative social situations which led them to spend time with computers rather than with people.
If this pattern persists, devs often grow to be extremely out of touch with normies, leading to the exact issue you pointed out with respect to “Markdown”, whatever that is.
The answer is for devs to test group their stuff using normies. When a dev watches just how little normies know the dev is more likely to realize that their work doesn’t end at coding. It ends when a bridge has been built that normies can walk on.
the Steem blockchain forum, circa 2016 introduced a standard markdown formatting (it's ok, but links are confusing syntax) and thousands of people were gleefully learning how to do it
but as a simple plaintext-that-can-become-richtext it's not the best, and it's notable that github is now supporting asciidoc, which will be unfamiliar, but has a lot more simple and important things (like admonitions, for example, eg NOTE and WARNING and its got a built in table of contents generator, in comparison, there is a dozen different "flavors" of markdown and more or less only github-flavored is widely known and understood
since it's mostly for writing longer form articles anyway, and there are rich text editor widgets available, the problem for normies doesn't really exist
not rendering normal kind 1/1111 notes as markdown is stupid because they are the same unless you put in the # header prefixes and the *emphasis* and **bold** etc and people already do a lot of these anyway, they have become common idiom
but for whatever reason, nostr client developers have declined to parse all notes as markdown, and as such we can't have nice links or sections in somewhat longer texts, no bold, italic, no plaintext or quoting (very helpful for technical discussions)
The original Markdown idea didn't have the []() URLs, the URLs were exclusively referenced at the bottom, it was much more readable, see https://daringfireball.net/projects/markdown/index.text
That reminds me of another bad property of Markdown: multiple ways of doing the same thing (a bug that likely was not present in the original idea -- but also I'm not saying the original was perfect or anything): there are 3 ways of doing links, 2 ways of doing each level of heading, at least 2 ways of doing ordered and unordered lists, 2 ways of doing bold and 2 ways of doing italic, and 2 ways of doing code blocks, arguably also 2 ways of doing quote blocks.
have you looked at asciidoc?
i am using it on my docs in my repos now, for one major reason being that it has an actual working built-in table of contents, and its tables are sane and readable without being rendered, the links are simple to understand: link:http://example.com[display text] and it lets you do a bunch of other cool stuff, the quoted preformated text is just two spaces indent though also you can use many of the more familiar things like backtick fences and single backticks `like this`
we will be using it as a standard for #alexandria because that is a book oriented application, also, so, it will happen
long form nostr posts have kinda not really caught on because the clients are crappy and actually without a reward people are not that interested in doing anything other than short notes
but it would be nice to be able to at least do sections, headings, quoted source code type blocks, and similar, for discussions
i should also point out, we are using it with #alexandria because it allows the creation of composite documents, with asciidoc it's possible to compose a series of separate documents together to become a composite document
The current Nostr "plaintext" format is pretty good to me: if you find a URL you turn it into a link.
That's good too because it prevents scammy links that fake as different URLs without requiring any fancy checks. "nostr:" links can be treated the same way -- or you can choose to enhance those (as you can choose to enhance HTTP URLs to display images inline or opengraph previews), but it's not absolutely necessary.
