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


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

@lutindiscret Yeah, using a well-defined spec as a reference is certainly the wisest approach.

Although I wouldn’t want to implement the full CommonMark spec in its entirety…

@jk well partial support is quite a pain for content creator.

If you can't write something without being anxious about it not being rendered correctly in some browser (and when you fix, it breaks in other browsers...).

You might be recreating what made the web a painful platform: spending more time to fix browser-compatibility issues than enjoying content creation. IMO, that would break what makes Gemini more enjoyable than the web for content creators 😔

@lutindiscret That's a very good point. Gemtext is always there as a hassle-free option, though.

Fully supporting Markdown essentially requires a web-grade rendering engine, and that is out of scope for Gemini IMO. That's why I discuss a "Gemini-flavored" Markdown in the gemlog post.

Also @jk, if you choose this path, please at least, don't have a "quirck mode" and make Lagrange do not print anything but an error message if the document has syntax error.

Allow rendering of poorly structured content is what made the web full of broken pages. Fail early will force creators to make things properly. I don't want "this gemlog is best rendered with <insert-not-my-gemini-browser-here>" to be back from the deads.

@lutindiscret Is there a way to validate CommonMark so as to detect if anything is a syntax error? I've been under the impression that there's basically no such thing as syntax errors in Markdown; everything will yield some sort of output.

When it comes to formal structured languages like HTML, I agree it's important not to bend the rules, as the history of the web has demonstrated.

> no such thing as syntax errors in Markdown

@jk I think you have a point 🤔 I can't think of any.

@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 It’s good to be careful here for sure.

One should not conflate page content and the protocol, though. A richer-formatted page is still served over Gemini, with its single request rule and no preloading. Even HTML can be used outside the context of a full-blown web browser, although I’m not sure anyone would want that.

IMO the biggest danger is fragmentation. If people don’t see the value of standard Gemtext as the glue that holds Gemini together, the community splits apart.

@tomasino In any case, I’m not planning to rush into adding non-Gemtext-based document formats to Lagrange. There are more important short/medium-term things to take care of, and there is also a maximum size for the code base that makes sense for a single developer.

@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 @jk I watched that video and it made me want to respond "why is it arbitrary?". To me the line is more clear: will this new feature enable unnecessary tracking in some form? if no, add it; if yes, don't
@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:

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


@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:

@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's personal Mastodon instance