NIP-23: More specific interpretation of "Markdown"

63 views
Skip to first unread message

William Casarin

unread,
Jul 16, 2023, 2:36:05 PM7/16/23
to fiatjaf, Alejandro, Quentin, codytseng, franzap, gzuuus, nostr-p...@googlegroups.com, public...@w3.org, d...@damus.io
Hey guys,

On Fri, Feb 03, 2023 at 03:59:07PM -0300, fiatjaf wrote:
>+NIP-23
>+======
>+
>+Long-form Content
>+-----------------
>+
>+`draft` `optional` `author:fiatjaf`
>+
>+This NIP defines `kind:30023` (a parameterized replaceable event according to NIP-33) for long-form text content, generally referred to as "articles" or "blog posts".
>+
>+"Social" clients that deal primarily with `kind:1` notes should not be expected to implement this NIP.
>+
>+### Format
>+
>+The `.content` of these events should be a string text in Markdown syntax

I'm thinking we should be explicit about what implementation of markdown
to use in long-form notes. I'm seeing github-flavored markdown in Damus
which contains html. I really don't want to have to parse HTML in posts.

Can we do something to filter html on habla.news as well? It looks god
awful in damus at the moment. We shouldn't bring web baggage into this
spec.

There is also the issue of hard-linebreak, 80-col formatting in markdown
documents. This looks really bad on mobile. The Gemini protocol solved
nicely. It uses it's own gemtext document format (gmi), which is very
similar to Markdown except that it has a few requirements that makes it
much nicer to render on devices of any size. Specifically:

> Text in Gemtext documents is written using "long lines", i.e. you (or
> your editor) shouldn't be inserting newline characters every 80
> characters or so. Instead, leave it up to the receiving Gemini client
> to wrap your lines to fit the device's screen size and the user's
> preference. This way Gemtext content looks good and is easy to read on
> desktop monitors, laptop screens, tablets and smartphones.
>
> Note that while Gemini clients will break up lines of text which are
> longer than the user's screen, they will not join up lines which are
> shorter than the user's screen, like would happen in Markdown, HTML or
> LaTeX. This means that, e.g. "dot point" lists or poems with
> deliberately short lines will be displayed correctly without the
> author having to do any extra work or the client having to be any
> smarter in order to recognise and handle that kind of content
> correctly.
>
> For most "everyday" writing, this approach means you probably just
> want to use one line per paragraph.

See: https://gemini.circumlunar.space/docs/gemtext.gmi

Download Lagrange (https://gmi.skyjake.fi/lagrange/) to see how
beautiful one of their clients are and how well it works.

Maybe we could define a restricted subset of Markdown to be used in
nostr notes, because right now everything looks really bad. We could
spec single-line paragraphs like gemini. I'm not saying go the full
gemtext route, but we could add some sane clarifications to the existing
spec.

TLDR: Markdown is too underspecified to be a useful format for longform
notes, and it would be helpful to spec a sane subset of Markdown with
modifications to use instead.

Let me know what ya'll think.

Cheers,
-jb55

fiatjaf

unread,
Jul 17, 2023, 1:05:30 PM7/17/23
to William Casarin, Alejandro, Quentin, codytseng, franzap, gzuuus, nostr-p...@googlegroups.com, public...@w3.org, d...@damus.io
Sounds good to me!
No HTML.
No automatic line breaks.
Reply all
Reply to author
Forward
0 new messages