Whenever Gemini is mentioned here in HN people will ask: "Why not a subset of HTML with HTTP" or some similar "Why not $SOME_OTHER_TECH" question. Which for me is the same as hearing "Why not chocolate cake?" after saying "I like strawberry tarts".
What people don't realise is that Gemini is a different thing for each person involved with the ecosystem. Some people are in it because it is easy to implement, something that can't be said about the recent specs of HTTP/HTML specs. Others enjoy having a spec that is easy to understand and absorb, even if they're not developing with it. There are those that like how clients decide how to present the content, and that some clients allow for a ton of customisation thus placing the user in control of the presentation. Each person is enjoying the ecosystem for their own reason, and that doesn't need to be a reason that serves as an answer to "why not HTML and HTTP?"
Mostly, people do Gemini stuff because they're having fun, and that is enough.
Lagrange is a great client. There are a gazilion others. Pick one up for a ride, have fun.
> Which for me is the same as hearing "Why not chocolate cake?" after saying "I like strawberry tarts".
Desserts don't have network effects. The global hypertext network that we call the World Wide Web is a great achievement. Yes, commercialization has led to some awful excesses. But the Web still lets us all create the kinds of spaces we want, without needing to create separate networks that only a relatively few techies can access. That's why I think Gemini is misguided.
You can read my response to this at virgo://example.com/response567. It's not any harder to access you'll just have to close your current app and load one of the many Virgo apps (plenty on mobile too!) to read it.
In all seriousness Gemini (the protocol) is really no easier to implement than a subset HTTPS client as both are basically HTTP type commands over a TLS channel. Heck HTTP isn't even the hard part anyways, for everyone worked up about it I wonder how many wrote their own TLS implementation. Anayways don't conflate "every feature and function of a web browser" with "things an HTTPS client has to support" as even "Every HTTPS feature" is out of scope for most clients. When it comes to actually rendering Gemini (the document format) the difficulty doesn't change based on what protocol delivered the document.
Plus everyone already has tooling out their ass for HTTPS from viewers to libraries to debug tools to servers to command line clients to proxies to anything else you'd ever need. Plenty of these existing tools don't even care about the documents being transported, you're free to download a .md over HTTPS via wget hosted on a Caddy server even though nothing in that entire chain has a clue what .md is or should look like. These tools span from running on tiny microcontrollers to abstract high level user facing import functions in apps so it can clearly scale to any use case where you can render to a screen.
Wait until you read about HTTP upgrade mechanisms, HTTP transfer encodings or even 206 Partial Content implementations that are broken everywhere.
HTTP 0.9 was easy to implement, but everything starting from 1.1 and upwards is borderline insane, especially SPDY and QUIC.
While I don't agree with gemini's design decisions (and neither with gopher's), I can fully understand their point of view in regards to unnecessary complexity and side effects of network states.
Source: Building a peer to peer Web Browser, for around 2 years already (still far away from usable).
As I said just because a web browser may support a lot of things doesn't mean your simple subset client/server has to. I have no doubt implementing HTTP/2, HTTP/3 and its QUIC revisions, SPDY and its revisions, and every extension and option known in the specs would be a lot of work. Not doing so doesn't require making an alternative protocol. You're still free to implement a subset of HTTP/1.1 just like you're free to not implement Javascript or WebGPU when making a simple HTML browser.
You want to TOFU certs? Go ahead, HTTPS isn't going to stop you. You want to use client side certs even though most websites don't? Go ahead, HTTPS supports you. You want to use a custom port? Go ahead, HTTPS supports you. You want to leave some features out? Go ahead, you don't have to implement every feature Chrome supports
AFAIK, Gemini is the protocol and Gemtext are one of the types of documents. Be aware that you can transfer HTML documents over Gemini, and that many clients render more than just Gemtext. My own little client Fafi, built with Racket, can render Gemtext, images, RSS, and Markdown. If you attempt to transfer using HTTP such as having an HTTP link in a Gemtext, it will simply launch the default browser instead. I believe some clients will actually render the HTML in a webview.
Precisely, how many people are really interested Gemini because it's an HTTP like protocol over TLS+TCP instead of HTTP over TLS+TCP? It seems gemtext files are the real draw and those would be a lot less hassle to just do over HTTPS in the first place (for both browsers and custom applications).
But who knows, maybe all of the people hyped about Gemeni are just really excited about TOFU or something and just happen to not be interested in actually hosting non gemtext documents by sheer chance. More likely it seems it's more a form of gatekeeping than anything about the protocol of document format itself. It's almost like if programmers decided .md files should only be served and rendered to markdown clients over an HTTP-like markdown protocol - yeah, it'll keep less programmers looking at it but there is nothing special that couldn't have been done by serving the .md over HTTPS outside the "cool kids club" portion.
In practice it's mostly just programmers, so yeah that's what it mostly is. Gatekeeping to keep the "normies" out. There's nothing wrong with that but I wish the community were more honest about it.
You are wrong. It is "Why not chocolate cake?" after saying "I made strawberry tarts". And you can answer "I like strawberry tarts" as a reply. It is a perfectly valid answer.
People have the rights to do something for fun, and shouldn't be uncomfortable to say it out loud.
A HTML subset allowing client-side choice of presentation to the extent of Gemini would not even allow nested divs for layout, or top header bars (static or floating). It's a spartan choice that even most static blogs don't supply by default. IMO the ability for a client to render a page beautifully without page-supplied styling is essential (reader mode is a pile of heuristics they often fail), but pages do get monotonous and sites indistinguishable, with no server styling whatsoever.
I tend to spend hours browsing Gopherholes and Phlogs, but I tend to lose track of where I am. So I implemented a navigation system that I have yet to see in any other Gopher client (or web, for that matter):
- Drill-down Columnar Navigation.
It is heavily inspired by Finder's own column navigation, so if you like that, you'll be at home.
In addition, it has other features that every modern browser should have:
- A tabbed interface
- An omnibar with search capabilities (Using Veronica-2)
- Files and folders view
- Inline image previews with zooming
- Caching
I have many more ideas to contribute back to the Gopher ecosystem without losing its essence (see the roadmap), so if you want to contribute, send ideas, share your opinions, or just show support, please let me know! I hope you like it!
Lagrange is the best of the Gemini clients right now, if you are looking for a GUI app. It launches in a fraction of a second, which is blissful compared to launching a full-fat web browser, and you get the lean, clean pages that Gemini offers, with no need for extensions and adblockers, javascript or fancy frame-based pages.. Although Lagrange does handle multimedia well, it is focussed on making plain unicode text look beautiful.
I used amfora for quite a while before I found Lagrange and Diohsc. It is a very good client, also probably the easiest to use TUI client for starting out.
Diohsc takes a little getting used to, but once you start using marks and the queue, it becomes very pleasant.
Gemini requires SNI. Major design flaw, IMO. It should be optional. AFAIK there are no gemini sites that support TLS1.3 with ESNI/ECH.^1 That means every hostname gets sent in plaintext over the wire. No exceptions. (Not every site owner is going to do virtual hosting, yet every client request must send SNI anyway. That is dumb.)
Tracking a user's complete browsing history would seem quite easy unless sites add padding to disguise file sizes.
At least with HTTP, most Cloudlfare-hosted sites will support ESNI. Plus there are some other workarounds to avoid SNI on other sites. Better than nothing.
1. Putting an ECH-enabled proxy in front of gemini servers may be one solution. https://defo.ie
This is interesting, I've never heard of Gemini before... shame on me.
My first thoughts as an older internet builder, is that you're going to need a `mod_php` of some kind, call it `mod_gemini` for Apache to allow hosts and hosting ISPs to basically just have the ability to ftp and present "webpages" (what are they called, "geminipages"?) - same for nginx, caddy, etc. but not as trivial as it needs to present on another port.
Asking people to host their own webserver is basically the biggest show-stopper at this stage. Offering easy drop-in solutions like we used to have in the earlier days of PHP is crucial.
I had a look at the markup and a priori, it seems very straight forward, almost markdown like, which I like. Consider adding support to gemini to popular static site generators like Hugo etc.
From there you can build a small golang or python local client, like the early "dropbox client", living as a service on your computer that would convert html via beautifulsoup or other `outline.com` type converter to gemini on the fly, host it locally including local server, including proxy-ing the web links you visit, stripping all the javascript crap and cookies-we-want-to-fill-your-pantry-click-here-or-die-a-thousand-modals.
Sure, you won't have half the web working, but you still will have most of the important parts. Imagine browsing the web with Safari reader, almost a dream at this stage.
The content is what makes the web, not the interactivity, as much as people would like to believe. The essence of the internet is the thoughts it carries, not buttons that wobble when you hover them.
At that point, you can start talking about caching of online services in the gemini space - sort of like a shared global cache of internet content - with only the content and images/media making it through, start with blogs and websites that care about markup quality... No one will care at this stage because it's too niche, and because you're not caching linkedin or social medias, leave that crap behind please.
By that stage, start thinking about a search engine and classifiers, and you start having your own island of "new internet" going in the opposite direction of the metaverse, and "the people" (basically anyone that has installed an ad-blocker) will jump in with two legs, two arms, and their entire being - they just don't know it yet.
It's not that popular, there is literally just tens of gemini servers, for now you are not missing much.
Ironically there is no good search engine for Gemini; there is one at gemini://geminispace.info/ but it is shockingly bad, given how tiny geminispace is
There's a lot more than tens, see gemini://medusae.space/ (though ~20% of the links are down, I wish Gemini had free "static site" hosting like GitHub Pages, that didn't depend on the site owner continually babysitting or paying for hosting).
What do you find bad about it? I've never had any issues. Yes, it's not as scarily effective as Google at answering the questions you ask, but it's operating in a different environment and to a different set of principles. In particular, it doesn't track who follows what links which I imagine makes it harder to sort links by relevance.
I've been a Lagrange user for about a year and it is absolutely phenomenal. I know everyone getting into Gemini is building a server and some are building a client and it's a fun project to build, but as far as practicality goes, from an end user perspective, Lagrange is far and away the best user experience I've found in a client. Now granted, I haven't tried desktop gemini clients much since finding it, but the point still stands. If you find yourself wanting to read a lot and you find the content available over Gemini enticing give it a shot.
There are quite a few resources about the web, Microsoft and Apple also have their own documentation.
Nothing can ever beat the accessibility of a fully native UI, written with whatever toolkit is most popular on a given operating system. Yes, this means you need multiple completely different UIs, 1Password 7 style.
If you want to go cross platform and still be accessible, go with Electron. There's a lot of material written already on how to make web apps accessible, and that's basically what Electron is. Chromium's accessibility is top notch on Windows and Mac OS and pretty good on Linux (if you turn on a flag).
If, for whatever reason, you're not allowed to use Electron, QT and WX widgets also work, though there are certain controls that don't work that well on certain platforms, so you might need some really terrible workarounds. Same for Swing, which still requires enabling Java Access Bridge if I'm not mistaken.
I think the worst offender is GTK, it's pretty accessible on Linux, but completely inaccessible on anything else. The GTK developers have been promising changes in that regard for years, but I haven't seen those changes yet.
Custom toolkits, SDL based libraries and immediate mode GUIs are a complete no go. The operating system needs to know what kind of controls you have on the screen for a screen reader to work, but "draw a bunch of pixels here" is definitely not enough information, and that's what you get from those. You can implement each platform's accessibility APIs yourself, but that requires intimate knowledge of the platform internals (think COM on Windows) and is often poorly documented (there's almost no documentation for the Mac APIs). If you want to go that route, it's much easier to just go with 3 separate GUIs.
There's some ongoing work to change that state of things[1], but it's far from complete.
As the primary developer of the linked AccessKit project, I think this is a pretty good summary. I wouldn't call GTK the worst offender, because it is at least accessible on one platform. There are plenty of cross-platform GUI toolkits (e.g. Tk, FLTK) that don't even have that.
Can any Gemini proponents explain what its benefits are compared to just adopting a minimalist subset of HTML? The goal of bringing back the early web (hyperlinked text documents without all the other junk) is great, but making it incompatible with existing browsers makes it unlikely to grow beyond a small, walled-off community of enthusiasts. Is that considered a feature rather than a bug?
Pretty much, yeah. It's better seen as a souped-up Gopher than a Web alternative.
I've been making a concerted effort to learn Gemini while still keeping my head, and while I still think the idea fundamentally is pretty useless, the people involved are generally nice to hand out with.
If you click an "https://" link, you don't know whether or not it'll work in your minimal browser. If you click on a "gemini://" link, you know it'll work in your Gemini client.
Gemtext is easy to parse since a parser only has to read the first characters of a line to know a line's semantic meaning. Being line-oriented also improves a document's structure, as it's easy to navigate with links getting their own line.
That's the rationale for using a different protocol scheme and markup.
> If you click an "https://" link, you don't know whether or not it'll work in your minimal browser
Interesting point, it would be unfortunate not to be able to distinguish web links from links that commit to using only the subset. It doesn't strike me as insurmountable though. Off the top of my head, file-extensions and/or MIME types might work.
You cannot include this information in every URL. If you want to include information on how to handle a URL, the proper way is to use an appropriate scheme.
What can you infer only from the URL, before you click? File extensions show server side file formats, which reveal information about the backend's file representation; these do not necessarily correspond to the mimetype. .php, .asp, and trailing slashes are all examples of this; a trailing .html only means that the resource is (probably) a static file on the server, but neither gemini not the Web (nor even Gopher) are necessarily against dynamic content.
Furthermore, web servers can send a mimetype header along with an "x-content-type-options: nosniff" header to make compliant user agents disregard the file extension and use whatever mimetype the "mimetype: " header supplies. I personally use this to deliver a PNG favicon when a browser requests "https://seirdy.one/favicon.ico". The file extension tells you nothing if the scheme is HTTP(S).
If you see someone link both a gemini and an https url, you know what the difference is in advance and that can inform which one you click.
The point of a scheme is to supply a guarantee about what standards a URL will conform to without reading the response. This is necessary to inform the behavior of the request itself, and as I've just explained it can also convey information to the user before they choose to make said request.
It answers the question though if you stop and think about it. If a document opens in a program that can render any plethora of whatever, you don't know what is going to happen when you click that link. With Gemini, you do: a document is going to be fetched that has words in it and those words are going to be displayed on your screen.
Not sure how a subset would work in practice. Though I can imagine a javascript gemini client (as perverse as it sounds...) that could be used as a tunnel into the gemini world in cases where you just want to look something up quickly and/or don't have or want to install a proper client
What I'm imagining is a specification, defining which subset of HTML should be included, together with a <meta> tag which indicates a document's intention to be compliant with the standard.
I'm imagining some form of YAML or similar frontmatter and markup. A lot of markdown extensions really add a lot of value. Like graphs, admonitions, diagrams, presentations, tabs, mindmaps, etc. I am not particularly fond of XML. I remember liking some of the ideas behind Pug/HAML etc and wished that a browser would just render it natively.
> I'm imagining some form of YAML or similar frontmatter and markup
It sounds like you're expressing disagreement with Gemini's chosen feature-set, but the question being discussed here is whether it would make more sense to use a subset of HTML rather than an incompatible format.
The point of using an HTML subset would be to retain compatibility with conventional heavyweight web-browsers. A feature-rich YAML-based scheme would be neither minimalistic, nor natively web-compatible.
Yes, but how would it be enforced? Just slap on that gemini-tag and pretend to be compliant but continue using all the shady techniques of the modern web.
If most users would end up browsing gemini with a regular browser that sort of thing would be commonplace.
My question would be similar but different: what do you use Gemini for, day to day? Do you read the news, or a dictionary, or blogs? Or is it mostly the meta discussion of Gemini itself (which would also be fine, I hasten to add)?
I just read what people that publish over the protocol have to say. A lot of it is meta discussion, because of course it is, but a lot of it is just what you would want to read for the sake of reading, a bunch of words that someone wrote just to write them and put them out for random people to find, no likes or shares or viral this and that or influence intended. It really does feel fun in the same way "browsing" felt fun 20 years ago, there's not a lot in the way of sales pitches when you're reading Gemini documents. It really is hard to describe the weight that lifts off of you when you enter an environment where everyone isn't ruthlessly competing for your eyeballs, and the space to explore whatever you want as a writer when you're not pressured to do that is pretty liberating too.
Personally I trawl it (there's a couple of search engines) looking for the weird stuff from the early internet that's hard to find these days.
Is 90% of it crap? Sure, but 90% of everything is crap (sturgeon's law), and it feels less corporate than the current internet. Also people seem to be less angry (on average).
Using Gemtext and Gemini makes you acutely aware of limitations, so eventually you either stop using it, or start enjoying it, with most of Gemtext readers sharing the experience.
Using a limited subset of HTML is an exercise in self-restraint, with the ability to go full ham on JS and CSS always being there, but you abstaining from sin. With most of browsers hardly sharing your desire for a JS lent.
There is nothing technically precluding browsers from supporting Gemini and Gemtext eventually. However, the idea is that contemporary browsers are not really interested in supporting it. Having a separate client instantly carves you out an entire world to live in and gives you 100% mindshare in that world. Shoehorning your document format into what browsers support right now gives you 0.001% of the browser world and its mindshare.
So this question gets asked any time Gemini comes up. Usually there are a lot of answers, some along the same vein, some about personal preference, some that don't seem to sell the concept much and maybe some that do.
A core part of the idea is that with Gemini you know what you're getting when you open a link. If I wrote a blog with a very very minimal rendering (which are nice) and I put the link up, you wouldn't know it from blogspam until you clicked it. With HTTP a link can deliver anything. It is reassuring to know you're getting a document to read and nothing more.
The restrictions on what you can do are a feature. I want to know that when I'm in the mood to just read that I am not going to have a video autoplay and get asked to sign up for a newsletter and have to accept cookies and have infinite scrolling recommendations and a nested menu unique to your site. And when what I'm about to click starts with https:// I have no guarantees.
It gets a little walled off feeling, and that's OK. If only a handful of people care about this thing, then it works. If it becomes widely used, that's cool too. It isn't intended to take over the world, it is intended as a tool, to be used by people who have a use for it.
It's mostly just a social club oriented around a protocol and a format. Initially there was talk about distributing alternative formats (like HTML), and the possibilities of screen readers, but these days it's mostly Gemtext and some syndication/feed formats (e.g. RSS/Atom). In theory you can render Gemtext however you like; in practice the community favors ASCII/figlet art content and spartan text, and doesn't care (positively or negatively) about other ways to view content. The community is mostly technical folks with socialist or anarcho-socialist views. The content is what you'd expect from a webring of blog posters with those views/preferences.
It's a pretty specific community, but if you like that stuff you'll probably fit right in.
I think that's the point. With broad accessibility comes catering to the lowest common denominator - ask anyone who was online a couple decades ago about the eternal September.
One no-brainer thing that I wish Gemini would add is proper footnote support. The reading experience is kind of a pain in the ass if you can't quickly get back to where the note was introduced.
It's not even "early web"; even that had forms and styles. Gemini is intentionally more simple; it does not have forms, it has virtually no input, it has intentionally no styles so all pages look more or less the same.
The early web was all "hypermedia" and people already stuffed images and videos and java applets. Geocities was all animated gifs. Gemini is more like gopher, if it was designed in 21 century.
Gemini does not even have forms, or cookies, or logins, or even any way to input larger text, or write. Intentionally.
Of course people try to hack around that and use the query argument for input. But in general, Gemini is almost actively fighting that.
While not always the intention of the creators, I see esoteric projects like this as a good way to gather like-minded people to work on interesting things.
Is there an effort toward creating a decentralized search engine for Gemini sites/capsules? The Lagrange/Amfora clients will be nice for adoption, but without a convenient way to locate sites it seems doubtful that the protocol will be widely adopted.
I'm not a protocol expert. I understand why one would not want to use a subset of HTTP, but why not use the existing, lighter weight gopher protocol instead and implement a server and client that supports TLS for gopher instead? Because TLS being baked into it seems to be the only technical difference between the two protocols.
Gopher has split between directory/text. Gemini does not.
Gemini is not so rigorous with formatting as gopher; in Gopher, the different clients can format the paragraphs and do their own thing.
The TLS is the most problematic part, for me; as Gemini decided to go with TOFU, which is IMO horrible in web-like setting; and the TOFU itself is vaguely defined and the specs basically says "client and servers can ignore it or whatever". But it's simple indeed.
While in one sense, it's trivial to transport gopher over TLS, in another sense, it's hard to add because gopher itself has no concept of TLS, and thus a client cannot know from within gopher to use TLS or not. I blogged about this: http://boston.conman.org/2019/03/31.1
Isn't keeping 3rd party stuff like TLS out of the core protocol a good thing? Regarding breaking existing clients in a catastrophic way, I think the server could send an error response to the client that don't support TLS (which is defined in the protocol so the clients should understand the error) if it doesn't want to serve some content without encryption or serve content over port 70 over plain text otherwise? I don't see why old clients are a show stopper there.
Know your market. There's a substantial number of people who use gopher from older computers (think of retro computing). Also, error reporting in the gopher protocol is terrible at best.
There are very few, if any Gopher+ servers. And because of that, there are very few clients that support it. And I do see some clients attempting TLS connections to my gopher server, and it clutters the logs with garbage attempts.
I think it is a bit of a chicken and an egg problem. There are a few Gopher+ servers out there (pygopherd gas Gopher+ support for example, which is reasonably widely used), and the Gopher+ protocol is pretty flexible and designed with the metaverse in mind originally (see GopherVR from the original authors).
It is a shame that a lot of current Gopher users seem to be strongly against anything apart from standard Gopher, when the original authors of the protocol had much grander ideas for interactivity & visual interfaces. Sigh.
https://github.com/gopher-protocol/gopher-plus/blob/main/gop... specifically mentions 3D representations of Gopherspace. They also provide provision for a "general purpose" scripting language - I think Javascript would fit the bill - there and in section 2.8
A little off topic, but which gopher server (and any management tools? ) do you use for hosting? I'm in the process of setting up one and trying different ones out but haven't settled on one yet.
I wrote my own gopher server [1] that works for me. I haven't looked at any other gopher servers in any detail to give a recommendation (unless you want to use the one I wrote).
No. That's actually the biggest myth about Gemini that seemingly everyone on HN believes.
When talking about this people are usually refering to this section of the spec:
"Clients can present links to users in whatever fashion the client author wishes, however clients MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol (e.g. links beginning with gemini://, gopher://, https://, ftp:// , etc.)."
But that only says that you can't automatically fetch images (or other resources). You can still make a network connection if the clicks on the link, for example.
On a tangential note, this is the first time I've seen OpenSUSE being the Linux representative in the installation instructions. As a TW user, what a happy surprise!
I could, but that sort of defeats the purpose of using a distro with a package manager that already has prebuilt packages. Graphical applications usually take a bit of time to compile as well. Seems like they'd have an official package by now.
What people don't realise is that Gemini is a different thing for each person involved with the ecosystem. Some people are in it because it is easy to implement, something that can't be said about the recent specs of HTTP/HTML specs. Others enjoy having a spec that is easy to understand and absorb, even if they're not developing with it. There are those that like how clients decide how to present the content, and that some clients allow for a ton of customisation thus placing the user in control of the presentation. Each person is enjoying the ecosystem for their own reason, and that doesn't need to be a reason that serves as an answer to "why not HTML and HTTP?"
Mostly, people do Gemini stuff because they're having fun, and that is enough.
Lagrange is a great client. There are a gazilion others. Pick one up for a ride, have fun.