What if... we had Markdown as a first-class citizen of Geminispace?

gemini://skyjake.fi/gemlog/202
gmi.skyjake.fi/gemlog/2021-10_

I'm feeling a bit conflicted about this, but ultimately it's up to you to decide which format suits your content the best.

@jk this scares me, especially in lagrange which seems to have the largest client following. I'm glad you're limiting the set of decorators you're allowing and not including things like inline links, but oof, it's scary.

Markdown basically is HTML, as you point out. Once that nut gets cracked open we have to face the question, "does content in mime-types other than text/gemini allow for nested requests?" Does the image pre-load in Markdown? And if that happens, is there any functional difference between Gemini and HTTP? Yes, there's a slippery-slope argument and that's a fallacy, but in this particular case I think we are literally dealing with a slippery slope.

You're dipping your toe into it for richer text formatting. It's something people have talked about before. Clients were bound to do it eventually. I dunno... it's just scary.

@tomasino @jk maybe we could have something like gemtext but with inline links allowed. I've never fully understood why that's supposed to be so evil

@Hyolobrika @jk i talk about this in my Why Gemini? video. There's going to be a line somewhere where we say these things are okay and these things are too much. Yes, it's arbitrary, but it's essential for a protocol determined not to grow and mutate. No matter where we draw that line someone will say, "by why not this one small thing more?"

Inline links were an easy one to say no to because it simplifies things without really hurting stuff. Gopher has had it that way all along, after all. Parsing is easier. Text wrapping is simple. The mark-up itself is simple.

Why not underlines, bold, and italics? That's a harder one. Again, it's arbitrary. We justify rules like "the first 3 characters define the line" but that's not a real reason. The real reason is there's an arbitrary line that someone drew.

@tomasino @Hyolobrika @jk

"Clients were bound to do it eventually. I dunno... it's just scary."

I really respect and look to what tomasino's contemplations opine. He has (You, Tomasino, have) been one of the more thoughtful contributors not just here in Geminispace, but also Tlldespace.

That having been said @jk , you do make mention in your paper:

"Sure, the protocol can serve any other type of content as well, but does it make sense to serve pages in a format that virtually no client supports?", and "...dumping all non-Gemtext pages to an external viewer is a terrible user experience.", but this is exactly how the spec expects it to be done, and it's how Gopher has done it forever too. I used to install Gopher services at public libraries, back in the days when we believed that we were actually going to replace card catalogs... and yes, that is ugly, lauching an external application based on Mime types to accommodate images and such.

Taking your thought process a little bit further, having native internal support for your published variant of .md files within Lagrange, perhaps a superset .md file that offers those authors the additional formatting you're seeking to accommodate?

Just thinking out loud here, but I do support where you're going with this notion, and there's this:

https://pleroma.cloud/notice/ACTbW16Yn1dBY1JEDg

I'll certainly be following closely and like I said, my interest is piqued.



.
Follow

@tallship @Hyolobrika @tomasino

There is still more to experiment with here, but yeah the idea would be to eventually have some flavor of Markdown that is natively displayed in the app. It would still be subject to every rule of the Gemini protocol.

This reply turned out quite long for Mastodon; continuing here:
gemini://skyjake.fi/misc/2021-

@jk @tallship @tomasino Btw, Pleroma has no built-in character limit. Gemini links don't seem to work as well though.
Sign in to participate in the conversation
skyjake.fi

skyjake's personal Mastodon instance