ExploreTrendingAnalytics
Nostr Archives
ExploreTrendingAnalytics
fiatjaf2h ago
Of course you are right, but there are things more annoying than breaking backwards compatibility. One of them is Asciidoc. Asciidoc was a huge mistake, I got swindled by their marketing. Also the differences are small (most articles are just text anyway) and there are few implementations, the articles have broken formatting everywhere anyway. I should have just merged the change sooner to save you a headache, but I was ashamed of doing it and afraid of @Laeserin, and waiting to see what @PABLOF7z would say about it. https://github.com/nostr-protocol/nips/pull/2242
💬 4 replies

Thread context

Root: 8ff587a9eaca…

Replying to: 2dcef8e85c6c…

Replies (4)

PABLOF7z1h ago
I’ve already implemented it. I’m good with merging the PR. There’s nowhere near enough wiki articles published to be too concerned about the amount of data, although a few people that started doing good work got, very understandably, discouraged with the change and I can’t fault them for that. @7776c32d…45558888 immediately comes to mind since he was adding a lot of work there. In the new version I’m working on I’m doing what I can to detect markup and render accordingly.
0000 sats
Laeserin1h ago
😂 I am not a monster. We implemented both Markdown and Asciidoc (we the content and switch), but if everyone else hates Asciidoc, we'll stick to that. There isn't much difference. It's the same size for us, either way, as we need all of the advanced plug-ins. They're what takes up space. Asciidoc.js comes with some of them, that's why it's a bit larger.
0000 sats
Laeserin1h ago
Why not the NostrMarkup we had agreed on? I would have to change to a new Markdown parser, as well as convert all of the Asciidoc.
0000 sats
Laeserin1h ago
You guys have been working on this for five months and nobody even tagged me. Okay.
0000 sats