Hacker News Reader

> Even if we consider just the minimalist and well designed websites, this means hoards of content when compared to all gemini capsules. I missed a broader set of topics when I used gemini and ultimately that was what killed my interest.

This is definitely Gemini's biggest weakness. I looked around on it a bit when it was gaining attention, and most of the sites I saw were just complaints about how bloated the modern web had become. I get it, but it's kind of treating the whole thing as a novelty rather than an actual medium that can be used to convey information. It didn't have the wide and varied userbase that even the mid-90s academic web they were trying to replicate had. It kind of reminded me of all the people who write a static site generator for their blog, and then only write a single blogpost about how they made their static site generator.

There is some good information to be found actually, although it is true that it is not much. However, if you have something to write, then you can write it, and then if they are published then there will be more things to read.

Unfortunately, the topics I'm interested in writing about often require images, sound, and video to do a good page covering them.

You can still link to images, sounds, videos, and any other kind of files, even with the same protocol. (Inline pictures would be helpful for documents that you want to print out, or view at the same time as the text, though.)

The thing I liked about Gemini and its self-imposed limitations is that it was very much impossible to create a misbehaving Gemini document. There is no way a Gemini browser will phone home, run malicious code on my side, grab/upload my browser history or send sensor or other data because I forgot to turn off various options, etc. To me the entire thing was much more trustworthy.

You can of course recreate this experience using HTTP and modern browsers, but both are so complicated that you don't know what's really happening without a lot of work.

I liked that as well, but wouldn't remember it before reading your comment. I guess all in all it is a pretty nice protocol, the only real problem for me is that the content is too niche to appeal to me on a daily basis.

This should really be a more common feature in web browsers. Yes, it can be achieved by turning off JavaScript and so on but it should be a feature like Incognito mode where you have either a high visibility toggle button, or open tabs in this mode, where tabs with the same kind as the parent keeps being opened in this mode. That way, you’d have Gemini for the regular web just by making websites that don’t break when that kind of code is disabled.

HTTP has infinitesimal complexity compared to basically any other feature of a browser.

Instead of inventing a separate protocol, you can invent your own html meta tag that marks a website to be JavaScript-free.

This will let you create search engines that crawl and index these sites specifically.

With .gmi files or "gemini://" URLs and a compliant Gemini client, I don't need to even need to load the document beforehand to know if it intends to execute code on my device or not. It already won't by design, it won't in the future, and it doesn't require settings management, vendor whitelisting, popups, or caring who makes the browser for me to make it behave that way.

Whereas that .html document with it's noexec meta tag might be updated in the future to suddenly contain code.

You can create a browser plugin that detect such tag and automatically turns off JavaScript.

You can even configure the plugin to detect if a page contains JavaScript while claiming not to be.

With a dedicated Gemini client I simply have to trust/verify code provided the client developer.

With your solution now I have to trust/verify code provided by the browser developer(s), the apparatus the browser provides for extensions, and code provided by the extension developers.

If I'm super paranoid I can just look at a .gmi in Notepad or vi and understand it. I can't do that with all but the most basic HTML.

Ok I guess if you are that level of paranoid - even though both Chromium and Firefox are open source and under a heck of a lot of scrutiny for security vulnerabilities - then I understand why you prefer Gemini.

I just feel the fact that it cuts it self off from the wider clearnet completely kills your audience reach, if you’re ok writing to a very small insular community then sure, but most people want their writings to be read by as many people as possible.

> Again, I get it, but I can live with visiting only the websites or gopherholes I want. [...] Even if we consider just the minimalist and well designed websites, this means hoards of content when compared to all gemini capsules.

I agree. Personally, I'm a fan of progressive enhancement.

E.g. I use this Hugo partial to hide emails; it de-obfuscates an address using JavaScript, and falls back to printing a shell command:

    {{ $id := substr (sha256 .) 0 6 }}
    <a id="{{ $id }}"><noscript>echo </noscript>{{ base64Encode . }}<noscript> | base64 -d -</noscript></a><script>var el = document.getElementById("{{ $id }}"); el.innerText = atob("{{ base64Encode . }}"); el.href = "mailto:" + el.innerText;</script>

(Hopefully HN will preserve all the characters.)

Similar for CSS, although that one is a forever WIP...

This kind of approach is exactly why I believe we can have a nice experience over HTTP. Progressive content enhancement nails the perfect balance between too simple and too bloated. I personally believe client side scripting is important and ideally should be used sparingly. Your example illustrates a perfectly reasonable use case where JavaScript makes sense, yet still providing a scriptless alternative that solves the problem. Nice stuff.

I can attest that CSS is very effective for obfuscating e-mail. I displayed my academic e-mail on my webpage for over half a decade using CSS to flip the text direction[1] without getting significant spam.

[1] https://superuser.com/a/235965

> I personally would have preferred pure markdown and no gemtext at all

The gemtext format is much simpler than markdown, which can avoid the complexity of handling markdown files. (One thing I dislike about markdown and other text-based formats (including JSON, etc) is that escaping will then be required, which can make it messy).

(Nevertheless, you can serve files of any format like you can with HTTP and some other protocols.)

> Similarly, and although I understand the reasoning behind making encryption mandatory, I believe it should be optional in the spirit of KISS

I agree. (My own "Scorpion" protocol does make it optional, for this reason. However, the existing server implementation does not currently implement TLS, although the protocol does allow (and also recommend) it, as long as any files that do not require X.509 client authentication can also be accessed without TLS.)

(Also, if you are serving only static files with Gemini then you could also use Spartan which uses the same file format as Gemini. If you have dynamic files, then it is going to be more difficult because of the differences between the protocols, although it might still be possible.)

> Finally, the argument that it takes a new protocol to avoid a broken user experience, often exemplified by someone jumping from a simple and well behaved HTTP website into a chaotic one [...]

This might miss the point. As the FAQ mentions, there are benefits of a new protocol and file format, including a simplified implementation compared with HTML, and this does not prevent the possibility of also making and/or using well designed websites.

(If you specifically do want a subset of HTTP, HTML, and JavaScript, there is "gemiweb0", and is intended to also be compatible with common web browsers. However, this does not mean that Gemini and other protocols and file formats are worthless; they are still beneficial, in my opinion.)