💾 Archived View for idiomdrottning.org › my-myopic-gemini captured on 2022-04-29 at 12:34:37. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

My myopic view of where Gemini needs to be simple

It might seem strange that I advocate for Atom, or at least a pre-existing format like RSS or (⚞shudder⚟) JSON Feed.

And that my own current publishing workflow (for making the atom files and such) is an extremely cockamamie and kludgy shell script that in turn calls a scheme binary and two separate python scripts and is dependent on Markdown files with a YAML front matter. Yes, it’s not great :/

But here’s the one hangup I have on all the current proposals:

What the client gets from the server needs to be as simple as possible. That’s the, uh, “touch-point”, “needle’s-eye“, “interface” that needs to be as simple as possible.

When something is a format that one person/server/platform emits and another person/server/platform receives and parses, that’s when you have a protocol. That’s what I do not want to see proliferate without very good reason.

I want protocols to be simple and I don’t want protocol-space to grow recklessly. That’s also why I’ve been opposed to the computer-readable alt text extension.

A proposal for where you can put your proposals

A simple line oriented easy-to-write format can be fantastic and is something very welcome — as input to a simple app that turns that into atom.

That’s where it could be amazing. I might ever write the app.

Not as a format for something that is published online and is expected to be parsed by other rando peeps.

What I wish Gemini would’ve been

It seems to me that Gemini is trying to make the web simpler by adding to its complexity.

Now a browser that wants to be able to access the entire web (including Gemini) needs to be able to handle yet another protocol, yet another format, or be able to pass URLs through a proxy.

I wish, of course, that gemtext would’ve been a subset of HTML. Even a subset that has the strictures of gemtext, the whole “one link per line” schtick, no style, no scripts, all that woulda been fine.

Yes, this is addressed in the FAQ.

It’s entry 2.5. But the “you can be served garbage” arguments there aren’t true anymore now that HTML is being parsed serverside and proxied to Gemini.

You can’t be tracked on gemini://, hopefully, but you can stumble upon links that just don’t work well because you’re pushing the web through some sorta remote lynx.

Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch.

But we don’t want it to be graceful. We want it to be absolutely brutal.

As the FAQ says:

HTML where the only tags are <p>, <pre>, <a>, <h1> through <h3>, <ul> and <li> and <blockquote>

and then when it discovers <script> or <style> or <div> or <em> or something, it refuses to parse that. Just as how gemtext clients today don’t parse those tags.

Opening tags in this “gemsubset” could have even been required to be at the start of line (after zero or more spaces) with the exception of <br>, IDC.

You would’ve used this “Gemini browser”, Gemini client, AV-98 or whatever people like, to browse this subset and be absolutely ruthless towards things that didn’t fit the subset. CAPCOM, Spacewalk, GUS etc could’ve be set up for the community around this subset.

But. Everyone could’ve read the subset with normal browsers and been able to follow links to the subset normally.