nip23: use Djot#2356
Conversation
|
Nothing making devs less happy than constantly changing formats because if it passes, we still need to format the past and now the future. You are not removing Markdown, just adding yet another dependency. We still need to parse and display both of them. |
|
At this point, I am confident the best way to change text formats is to pick a new event kind for Djot and leave the current one in Markdown. Then clients can choose which one to support. |
Yes. 100% |
There is nothing wrong with "reinventing parsers", specially when comes to markdown which lacks a proper spec, picking a new kind for a new format is the best approach when making changes like this, but even if Djot has a more predictable spec than markdown you still can't expect devs to use a single parser implementation or library, nostr already adds it's own "markup language" like NIP-27, NIP-30, BUD-10 that clients needs to parse on either text/markdown/djot (people even want NIP-30 inside zap comments), you can't expect full consistency across clients. |
|
Djot is much better, I agree. But it's too late to change this here. I think it's better to not do anything. Picking another event kind for Djot doesn't help much either if everybody has to support both anyway. The best we can do is define more strictly the amount of Markdown we aim to support. |
|
I still think it could be beneficial to make a change in a non-brutal way. What about having a MIME-type tag Ideally, clients could use a single Djot parser + temporarily a converter from Markdown. Additionally, if the article author opened their article in Markdown format, the client could show a warning to them that all their articles in Markdown need to be converted (with a single click); otherwise, they may stop rendering correctly in new clients. |
|
Why not just have many different ways to write blogs on Nostr? One in each format with a new event kind for that format. Then, clients decide which formats to support. They don't need to support everything. Each client can keep only supporting Markdown, for instance, and should not see anything from other formats. |
What client will decide to support just one format? Why would anyone do that? Both are functionally equivalent, it will make no sense to anyone that some clients show up in some places and not in others. If it was different kind of content or content with a different purpose then it would make sense to have clients choosing different things to support, but when it's the same thing you gain nothing by having two kinds because everybody is still forced to support everything, it's an illusion of optionality. |
|
Actually, this is not a rule, but in this case specifically if we really want to change things it is better to switch entirely, because Markdown parsers can render Djot with 99% accuracy, so the transition wouldn't be bad actually and clients could easily make the decision to support only Djot. (I didn't check these claims.) |
Because each client should be able to create and parse any format it wants. If any blog platform client wants blogs in HTML, for instance, so be it. They can simply choose a new kind for it. If a client wants to use LaTex for blogs, so be it. Just pick a different kind. If somebody wants to support RTF or PDF, so be it. These are all different types of blogs. They can all have different user bases while still using Nostr. Forcing all blogs to be Markdown or Djot is idiotic. |
PDFs are not really for blogging? Anyway, we already have NIP-94 for PDFs.
Djot supports LaTeX math and HTML in particular. I think it's worth having Djot as a single actual format for articles. Supporting multiple options will be painful for client devs and confusing for users. The MIME-type tag may help in future migrations if something more reasonable than Djot appears at some point. |
Then I am against this. I don't want to force all clients to have to support Latex and HTML to correctly render blog posts. You missed my point, though. It doesn't make any sense to force just one format for all blog platforms out there. |
Well, the entire point of having this discussion and having a set of standards in the first place is to try to prevent this from happening, because it benefits no one. No one can prevent anyone from doing anything, but encouraging it is a bad idea. |
Then Djot is the most stupid thing in the world. |
I don't think this needs to be prevented. Much on the contrary. People should be encouraged to use different formats for blog posts so that each client can best suit their install base. If somebody wants to develop a platform that uses Djot with LaTeX math and HTML, I don't think we need migrate everybody into that new encoding. |
Fairly and predictably, that was my first concern about it. Yet it most likely can be disabled and disallowed in the NIP as well. |
|
I mean, my concern is HTML only; LaTeX math is actually a missing thing for me personally in articles, but i don't mind if it will be rendered as plain text in some clients. |
5 participants
I believe this will make client devs happy. Clients currently show non-identical stuff; some devs keep reinventing parsers. And these parsers are possibly vulnerable to DoS attacks as well.