Oddbean

Just looking at the NIP-01 and I noticed: 1: text note: the content is set to the plaintext content of a note (anything the user wants to say). Content that must be parsed, such as Markdown and HTML, should not be used. Clients should also not parse content as those. Why no html/markdown? Seems like clients users should be free to do as they please? #nostr #asknostr #nostrdev

I agree with no html but markdown syntax was used in plain text messages years before markdown existed. It was basically a way to enhance formatting of email/messages on old green screen text based email systems. So it should render well either way text or not.

Yes in this I agree on first thoughts. Would be great to hear from nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprdmhxue69uhhyetvv9ujuam9wd6x2unwvf6xxtnrdakj7qgnwaehxw309amk7apww468smewdahx2tckuej4c, why Markdown should not be included for client rendering.

That is a myth. Markdown was not used in plain text messages previous to its creation in 2004. There is no way anyone would write [bla](https://bla.com/) or [![alt text](https://img.com/image.jpg)](https://link.com) in a plain text document. Also the language is completely unspecified and ultimately unparseable, such that every parser is different and adds a new thing to it, thus making everything incompatible with everything else and incentivizing everybody to support all features that any random person comes up with, which just increases the work for everybody and bloats software everywhere. To be fair, the initial Markdown version example, https://daringfireball.net/projects/markdown/index.text, was very readable as plain text specifically because it did NOT use the horrible link formats anywhere. If those were added later by rogue implementations that's another example of the bloat that the Markdown brand has accumulated over the years. Asciidoc is a much better language, but I also don't think we should use it for the same bloat reasons. We want clients to be simple to implement and kind:1 is already too hard to deal with without all these things. Bluesky's text formatting is actually the best way to handle this problem I've seen: https://docs.bsky.app/docs/advanced-guides/post-richtext and @arthurfranca has a NIP proposal that is very similar to that -- but again I don't think we should do any of that at all.