I really enjoyed messing around with Gemini a while ago! But after the "messing around" stage with the protocol itself, the restrictions inherent to gemtext sapped my excitement around it.
It's a mark up language squarely focused on those that write text, but arduous to use if you want to share things you've illustrated, which is most of what I share online that isn't tech related. There's of course the argument that inline images/a spec'd way to expose an image directory listing with thumbnails/etc would only serve to distract or exploit you... but that also ignores the fact that people make art for your eyeballs too. Text is certainly the first class citizen, where images/music/video are all tied for second class, accessible only by downloading them 1 by 1.
That does mean it's perfectly fit for purpose! I wouldn't say it's bad just because I don't get my specific needs met. Someone who's needs are met by Gemini will love it.
There are Gemini clients that can inline images, so visitors to a site could decide to enable that if they wanted to see for instance a list of thumbnails.
Are clients permitted/expected/tolerated to run off and fetch the contents of image links for inline display, once a page containing such links is retrieved?
Permitted? Technically, it can't be stopped (well, it kind of can, see "Tolerated?").
Expected? No, it's counter to the intentions of the community.
Tolerated? Maybe. Here's a fun one (saw this in one of the past discussions dang linked): https://github.com/makew0rld/amfora/issues/199. That was over favicons, but the response would be similar if linked images were automatically fetched. Though the protocol has a "backoff" return code that could be used to throttle those things that would be less disruptive than Drew's approach of banning specific clients.
They are not supposed to do that, but some clients have an option to enable it anyway.
There are also clients that make a second request to ask for a favicon. In the spirit of the protocol the "icon" is just a UTF-8 symbol, but that behaviour is still controversial.
Only if the page is inside of a ZIP archive stored on the local computer and only if the link is to a picture within the same ZIP archive. (However, it would be good to have an option to disable inline display even in that case.)
This would be my preferred way of document distribution. Images and video is allowed, but they have to be part of the same document as the text. Everything is in the same zstd'd tarball. No separate roundtrips for fetching images. Either you download the document or you don't. Would be cool with some limitations on overall document size as well.
Agree. I don't think Gemini plugs any hole that Gopher could've left open. As it is, it's just a motherfuckingwebsite.com, except it's trying to take itself seriously.
Maybe this is just me showing my age, but I don't understand why reinvent everything when you could just go back to something like HTML 2.0 or even 3.2 with some minor changes. I probably hate what happened with the "modern web" as much as the Gemini developers, but going full NIH is unlikely to be a good solution when there's an existing "unmodern web" to develop for, and as a bonus, can be experienced even with a modern browser.
Gemini is a reaction to all the negative changes that happened to the web. Their premise is that the design of the web was fundamentally flawed because it was extensible. You see this in both the protocol and the community where the dominant idea is basically, make it super hard to ever extend or change Gemini. HTML is clearly a failure from this perspective, because HTML changed.
Personally I don't have much use for this attitude, the main problem I have with the web is when faced with the choice of empowering the publisher vs empowering the user, we kept on choosing to empower the publisher. The standards and browsers were owned by the web publishers, no one represented the user, and now instead of having a "user agent" installed on your machine to browse the web, you have a piece of spyware, better referred to as "Google's agent."
I don't really need to trade Google's Agent for Drew DeVault's Agent, give me software that does whatever I want it to do, fuck the publishers. But what do I matter, I'm not building any of this stuff.
Gemini is technically extensible. The only reason servers and clients don't add "unofficial" features which eventually become official, like HTML did, is because of the community.
But a community could form around early HTML, make clients and servers that only support early HTML, and vow to never support later HTML features. Such a community wouldn't be much different from Gemini's. Psychologically, they would have more difficulty rejecting new features (that have already been implemented), be less exciting initially (since they have less novelty), and have more trouble distancing themselves with mainstream HTML. But psychologically, Gemini is apparently reinventing the wheel without any advantages over HTML...and that disadvantage, at least to me, feels worse than the aforementioned advantages.
EDIT: I actually think gatekeeping a community with a different protocol may be a good idea. But I haven't heard about any technical advantages of Gemini (e.g. a protocol design that would be especially hard to extend, like a bloated spaghetti protocol on purpose) and I think that's a wasted opportunity. Nor have I heard about anything particularly interesting in the Gemini community, which makes me think the psychological benefit of a separate protocol isn't enough for an effective community, Gemini's community would need some other advantage, then perhaps a separate protocol wouldn't be necessary.
If you reinvent something then people get to be a part of it. They get to help with implementation and maybe design. People like being a part of stuff.
The advantage of a separate protocol is that you know that every available site will be limited. If you use a search engine, it will give you a result your limited browser can read. If you use an old or limited web browser (Dillo, e.g.), then you will still have the problem of discovery of Smolweb content.
Interesting outro. Interoperability is presumably one very big reason for this protocol.
As for why, all I can say is, download Lagrange, go to gemini://bleyble.com/cgi-bin/random, and see for yourself. It's one thing hearing about it and a completely different experience browsing the geminispace.
The different experience is largely thanks to different content, not different protocol. The protocol just serves a gatekeeping role to keep the community small enough.
I think that the specifics of the protocol don't actually matter all that much. What matters is that it's sufficiently unappealing to filter out most potential users; you genuinely have to feel strongly about the state of the web etc to spend a lot of time on Gemini.
That was a terrible experience. For a start that site has an expired certificate, as do many of the pages it suggested, and of the pages that worked it was mostly people that dipped a toe in a few years ago and never came back or other broken function.
Are they? On client side, technically it is easier not to execute scripts then to do so (despite the UX of https://addons.mozilla.org/en-US/firefox/addon/noscript/ might let you think the opposite). Technically, with DOM inspection one can also easily filter out elements you don't like, both on client and server side. It is literally one XQuery/XPath away.
The problem is that most modern "apps" stop working once you prevent them from exchanging data with third parties or using nowadays-standard APIs such as XHR or Websockets. This is why a radical cut was chosen by Gemini.
I built and run a search engine and a "Wayback Machine" for Gemini:
gemini://kennedy.gemi.dev
There are ~4K hosts and ~1M documents/images/files which make for nice playground with experimenting with crawlers, indexers, and more. Its a nice hobby. Lots of primarily static sites, and CGI is used to add some interactivity:
Gemini users kind of have a meltdown if you try to implement any optional features. One browser implemented favicons and users were flaming the github issues demanding it be removed or they would implement IP blocks for any users requesting the favicon url. I tried to find the link but search results are drowned out by Google's Gemini.
The protocol supports query strings so the server can generate content based on the string, which can be used for an in-Gemini Gemini search engine. It doesn't have to be all static content. People could also build out a directory (like the now defunct DMOZ and similar directories for the Web).
It's an alternative to HTTP and HTML (primarily). With the protocol sitting, in terms of complexity, somewhere around the early HTTP/1 protocol and gopher, and the geminitext format being suited for a variety of displays and more text oriented rather than for interactive or multimedia use.
And its simple implementation (client and server) comes from the simple protocol that doesn't seem to need much code to implement. The content seems to be in something similar to Markdown but fewer features. So if one wanted one could achieve the same with simple HTML over HTTP. My guess this is also a community thing.
I'm not sure that something like HTTP 1.1 is hard to implement. There are miriads of HTTP servers and clients. It has its quirks, for sure, but you can code basic implementation pretty easily.
Now rendering HTML is completely another level of difficulty.
If you ask me, I'd suggest to use Markdown instead of HTML for "simple web", but keep HTTP/1.1. Rendering Markdown is relatively simple and it's rich enough for a lot of document-based websites.
As for "web apps": use webassembly as underlying execution engine, but build something new for rendering, not coupled with any markup languages. Just provide canvas to draw and efficient API to implement draw operations. Application developers will use frameworks and frameworks prefer to draw everything themselves anyway. I think that kind of "web app engine" would be possible to implement with limited development resources, unlike modern web browser.
> Just provide canvas to draw and efficient API to implement draw operations. Application developers will use frameworks and frameworks prefer to draw everything themselves anyway.
Markdown is a superset of HTML, so your assertion cannot be true. But even an HTML-less subset is very hard to parse efficiently (or, at all) because of the various grammatical ambiguities. And then there's the various competing definitions...
> And then there's the various competing definitions...
Someone always bring this up whenever a permutation of this thread comes up, but I don't see the problem. You choose a definition and make that the spec. Even Hacker News only supports a very limited subset of Markdown.
Agree, that was exactly my reaction. What a terrible introduction, wasting many words on such platitudes as telling me that the idea isn't new but it isn't old fashioned either, or that they want to provide "some respite for those who feel the internet has been disrupted enough already."
Jesus, god forbid someone share their motivation for a project for longer than it takes for a tiktok to play...
The link to the FAQ and spec is right there. If you have the attention span of a fruit fly (many such cases) I personally suggest trying to fix it, not feeling proud about it.
If this were an utterly pedestrian """deep dive""" about some AI thing it could have rambled as much as it liked that there wouldn't be this comment near the top, I assure you.
Reminds me of a commercial where an artist attempted to convince their friend in excited terms how amazing their new masterpiece was, only to reveal its a blank canvas and they ran out of paint.
It's in the FAQ which you can get to on one click:
>Gemini is an application-level client-server internet protocol for the distribution of arbitrary files, with some special consideration for serving a lightweight hypertext format which facilitates linking between hosted files. Both the protocol and the format are deliberately limited in capabilities and scope, and the protocol is technically conservative, being built on mature, standardised, familiar, "off-the-shelf" technologies like URIs, MIME media types and TLS. Simplicity and finite scope are very intentional design decisions motivated by placing a high priority on user autonomy, user privacy, ease of implementation in diverse computing environments, and defensive non-extensibility. In short, it is something like a radically stripped down web stack. See section 4 of this FAQ document for questions relating to the design of Gemini.
> Gemini is a new internet technology supporting an electronic library of interconnected text documents. That's not a new idea, but it's not old fashioned either. It's timeless, and deserves tools which treat it as a first class concept, not a vestigial corner case. Gemini isn't about innovation or disruption, it's about providing some respite for those who feel the internet has been disrupted enough already. We're not out to change the world or destroy other technologies. We are out to build a lightweight online space where documents are just documents, in the interests of every reader's privacy, attention and bandwidth.
Those words don't communicate much about Gemini at all. Gemini could be a webring for all this says (it's not, but you could build one on it), or it could be something entirely different. It turns out that Gemini is a protocol and a text format, but those 100 words don't say anything about either of those things.
It does a really bad job of explaining what it is. They could have said "modern gopher" and that would have conveyed way more information (for people who know what gopher is, which is probably 90% of the people ever reading it).
I've had a Gemini Capsule (what Gemini calls a 'website/blog' since about 2021. It gets very little traffic, but it's fun to have. Browsing the smallweb is nice in the evenings when I want a high signal-to-noise ratio of interesting content.
My main blog is now an "anonymous" gemlog. I use the kineto http proxy to provide a website version as well. I wrote a little deploy script that scrapes my posts and creates an atom XML feed (static doc) that kineto serves for those few people who want to stay up-to-date.
Once a quarter, I batch up the recent posts and bcc a bunch of folks I like to keep in touch with. Some of them respond. This is what I do in place of social media now; outside of email, Discord and WhatsApp are all I use to keep in touch with folks.
I also like to poke around different gemlogs with Lagrange, which is a nice desktop-oriented Gemini client. It's good fun.
I found it hard to extract any signal from this extremely chatty site. But AFAICT the tagline "basically modernized Gopher" wouldn't be too far off the mark?
Honest question, how do you discover interesting content over this protocol?
Is there people building the equivalent to web directories and web rings? Or search engines? What are the cultural expectations on navigating other people's published resources?
Like "they are good". Whole html with its features is "good", but when i want to use a privacy- first protocol, why the hell would i undermine it with tracking pixels, especially since it noted as the very feature of this protocol
There are plenty of ways to implement images without allowing for tracking pixels. Only allowing images to be served from first party domains would be a simple one.
Gemini's simplicity is refreshing! It feels like a cozy corner of the internet focused purely on words and ideas. Kinda perfect for offline reading sessions, almost like finding a quiet spot to when bored. Definitely not for sharing my doodles, but I get why some folks love this minimalist vibe. Exploring random capsules through Lagrange is oddly relaxing.
I like the idea of Gemini and was inspired to write a script to turn my blog posts written in markdown to gemtext. Sadly I still haven't finished that script ...
My main issue with the protocol is that it is requiring creating a new TLS connection for every request. That is indeed a simple approach but I argue that the extra round trip times added due to this are not worth the trade-off for the simplicity gained in this case
Coming up with a simple way to reuse a connection would reduce the round trips needed drastically. If we put our heads together, I feel like we could come up with a way to do that, that doesn't overly complicate the protocol ...
Unrelated but I went to the linked website, then a while later to Youtube and now I'm getting videos recommended about the Gemini protocol that I have never heard of before today.
I'm on Arc and use uBlock Origin Lite, NextDNS, if I had searched I would have used Kagi. How do they (Google) know?
EDIT: I'm not implying that the gemini project is doing anything wrong here
The prediction algorithms are so good that indirect behaviors and data can be informative.
You might also be profiled by Google and bucketed into a group of similar people who leak their data. They also went to this website and their YT recommendations became a signal to inform your own.
Not claiming any certainty here just possible ideas.
They aren't necessarily tracking you personally. Gemini Protocol hitting the front page of HN means a spike in interest generally, which the YouTube algorithm could be reacting to in aggregate.
I rather like Gemini. I have several presences on the protocol, as well as a hefty list of gemlogs I follow. The somewhat slow and niche nature of this corner of the internet has meant that I come and go, rather than using it daily (like I do with the web); but it always feels sort of cozy and welcoming when I do eventually return.
I have a theory that the idea you'd call your project "Project X" comes from TV shows.
We work with project codenames and we don't call anything Project X. We just call it X. It feels like adding the word "Project" is something a screenwriter would do to make the dialogue clearer.
I would say that it comes from the military, where projects are given codenames that try hard to be opaque random monikers, and spill no beans about the nature of the project. The Manhattan Project predates mass TV, and most of it did not happen on Manhattan.
I don't mean codenames. I mean literally saying the word "project". It's like meeting a friend and saying "hello my friend I've known for the last 20 years".
Compare: "We are working on Project Paperclip" and "We are working on a paperclip". I suppose the former implies that what you're working on is not a literal paperclip (but a secret operation to snatch scientists).
So "Project Gemini" is not about, say, he constellation.
Google renamed Bard to Gemini last year. Side note: Google's "Gemini" product name is way overloaded. They have like 6 different things that you can buy/use that are named that.
Right? I clicked in here thinking it meant Google's Gemini but of course not just another uncreative name that clutters search results. (I'm not sure if Google's Gemini or Project Gemini is the uncreative clutter, but either way.)
sun is not doing Allah is doing to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
If this is being developed, it should have a more modern description. Comparing it to Gopher is fine as a historical point, but comparing it to http/html is more useful today. I read the faq for geeks and didn't learn much:
> 1.1.1 The dense, jargony answer for geeks in a hurry
> Gemini is an application-level client-server internet protocol for the distribution of arbitrary files, with some special consideration for serving a lightweight hypertext format which facilitates linking between hosted files. Both the protocol and the format are deliberately limited in capabilities and scope, and the protocol is technically conservative, being built on mature, standardised, familiar, "off-the-shelf" technologies like URIs, MIME media types and TLS. Simplicity and finite scope are very intentional design decisions motivated by placing a high priority on user autonomy, user privacy, ease of implementation in diverse computing environments, and defensive non-extensibility. In short, it is something like a radically stripped down web stack. See section 4 of this FAQ document for questions relating to the design of Gemini.
Annoyed that for a system about plain text links, there's no link to "section 4".
The transport sounds like http without saying so. It doesn't go into why it doesn't use http. I'd probably be fine with HTTP and Markdown + image/video links. Maybe the Gemini document capabilities/scope is better but they're not described.
Edit: they are in "4.1.2"[0] Be warned, there's still a lot of beating-around-the-bush.
> 4.1.2 I'm familiar with HTTP and HTML. How is Gemini different?
A Gemini client is an application like a web browser, but simpler. It sends a one-line plain text request to a Gemini server over a TLS socket. The server sends back a document with a MIME type, or an error message, and closes the connection. The client renders the response for the user. That's basically it. It's similar to Gopher or to HTTP/0.9. A common document type returned is Gemtext, which is a text format like a simplified Markdown that can be parsed on a line-by-line basis.
Given the amount of servers and clients people have written for it[0] I'd say there are definitely people out there who understand how it works. What don't you get exactly?
As someone who got onto the web in HTML 2.0 era I can feel the appeal of Gemini, although I disagree about their attitude towards static inline images. In day-to-day world that's what separated HTML from the earlier text-based hypertext systems that you could run over a terminal connection (or in a window, like AmigaGuide). You could actually have real documents from the internet, on your own screen, without loading up a word processor. White pages, black text in different sizes, blue links, and color images! Cool!
Obviously, Gemini is a niche that's as futile as it can be. It's like going back to living without a running water because once there was a peaceful village, then first came running water, then electricity, and then the whole village was rebuilt into a big city, and the old village is now gone. But the logic goes: if they didn't get running water in the first place, the people who wanted electricity too wouldn't have moved in, and the city wouldn't have been built. So, reverting back to living without running water now will, if it doesn't maybe demolish the city, at least remind me of the good old days.
The problem with the current web is that before, maybe just 10 years ago, you could use a good browser to remove and disable all the user-hostile cruft aimed at you on websites, and maybe browse pages in relative peace. Now the fight has moved to removing and disabling all the user-hostile cruft aimed at you in the browser, that intend to remove the tools you could use to fight the websites, and given the de-facto monopoly of Google that's just incredibly sad.
What's more demoralising is that it's just one slice in the big trend to erode the concept of ownership alltogether. It's a matter of time until you can no longer even try to own your browsing experience. The web will have changed from a place where people could freely download and view other people's documents over HTTP to people using one-way thin-clients with attestation so that the producer can guarantee their website is interpreted correctly as intended. Good luck writing your own browser that does the right thing for you, it won't be served data off the web unless it can prove the client is unmodified and signed by Microsoft. That is, of course, assuming you could still write code yourself for your computer and actually run it on your own without asking permission from the vendor.
It seems that the 20's answer to what Gemini represents is probably something like asking an AI to load a web page, extract the real contents of the document, possibly with cues from accessibility hints, and reproduce the document as text and still images for viewing.
as a recent gemini user i like that clean looks, amazing fast page loading if compares with http web, low stimulation feedback, that makes me feel more concentrated and allow me to be less distracted while reading contents. There is a good browser options, graphical but that lovely terminal and hyper-fast ones.
In a world full of marketing/publishers psychopaths, Gemini protocol is a hope and part of human resistance.
Gemini's native protocol isn't HTTP, they invented their own. I don't really see what this does you couldn't do with simple HTML pages (or Gopher 35 years ago).
Even simple HTML pages may require Javascript and want to run code on your computer or phone. You need knowledge of the document, knowledge of its author, or constant keepup and awareness of browser settings (e.g. did some update re-enable Javascript) to mitigate this.
A .gmi is 100% certain not to need any extra code capable of potential unwanted external communications, not now and not in the future.
Also .gmi is extremely simple and can be rendered very simply (and thus more securely) because it can be processed nearly statelessly line by line, without need of a rendering tree or document model.
... which looks even more stupid when you can force quite a number of browsers to get you something through gopher if you just pretend it's http on port 70. of course you have to self interpret the result, but gophermaps are quite readable. :)
Why provide yet another overload for "Gemini" rather than thinking of something either novel or not in common current usage in a totally different context?
Back when I was a Googler, I used to play a little game where I would think of a random word and then check if there was a Google internal project code named for it. It was a bit hard finding stuff that wasn't some system or project, and often there would be multiple ones. I actually found one that I thought would be a nice name and reserved the go link for it, but naming anything after it never panned out, when I finally got to design a system from scratch my manager wanted a boring descriptive name like "consolidated data system" (it was a bit more specific but that was the vibe).
Side note: I noticed that more "boring" and less sexy projects had cooler names a lot of the time, and my theory was that people were compensating for doing unsexy work.
Google eats their own with names. Their latest and greatest AI framewofk is Agent Development Kit (ADK). Not to be confused with the Android Development Kit...
I remember a comment on here years ago from someone in GCP who mentioned that they did not control the "Cloud" namespace. So any VP could launch a new project and call it cloud something and make people very confused about why it wasn't showing up in the cloud dashboard and API.
At least the internal name of that kit is a cool name. So we should blame the Cloud marketing people who likely don't know about Android since they're Cloud people.
Fun fact: one of the first 10 bugs filed on the Go programming language was "Hey, I've been working on a programming language named Go for the last 10 years, please pick another name." https://github.com/golang/go/issues/9
Large tech molochs don't care about any name, it seems. Their power and weight makes the name point to them. Seek on "Amazon" and find that, oh the 7th Wonder of Nature the "Amazon rainforest" is ranked second after some random Big Tech company run by a guy named Jeff. The "lungs of the earth" vs. cheap package delivery and AWS dashboards.
I mean, yeah. What percentage of searches for "Amazon" in today's world do you think is going to not be about acquiring cheap shit very quickly? I would expect the tech company to be a better answer than most when someone searches for Amazon. Searching for "the amazon" gives the expected results as that's how it is more commonly referred. So it does seems like your search query as performed was just a bad search
Amazon does not need to pay Google for this. There is no world where Google puts an organic result about the rainforest in the top spot, because it's not what most users are looking for.
At most there might be a world where Google puts someone else's ad above the organic results.
Well, we also know Google isn't trying to help the user leave Google's site as quickly as possible, because they get more ad money when the user clicks on a few pages or does a few searches before finding what they want.
you'll probably find a Google expense for the same value of Amazon services so that no money ever trades hands, but both companies' valuations are inflated
I've always wondered if he meant coming up with good names or if he meant ensuring that names, however they're chosen, reliably resolve to the named thing.
There is no such thing as a good name. A name is good or not only in relation to the reasons why you want that name. Different teams, orgs, etc have different reasons to name systems. Traditionally, tech names have been in English or English sounding bisyllabic mostly (Game Boy, Windows, Office, Adobe, XBox) with PlayStation being unusually long for a name competing in the anglosphere. But examples like the Bard to Gemini change, Veo (Spanish), Claude (French) break the pattern, even then you still have DeepSeek, Lyria and ChatGPT.
"It should almost never be the case that project names conflict"
My corollary to this is "You should never reach for a language you are not fluent in for a name. Especially, just stop it with using Japanese words to name stuff please ffs"
> You should never reach for a language you are not fluent in for a name
I agree, but that still doesn't stop funny name related issues between languages. One of my favourites was Pidora (a Fedora release for the RPI) which caused offence to some Russian speakers.
Yeah they missed an opportunity to more fully support something more like markdown that offered in-line links and basic text formatting. Missing tables is also quite the deal breaker for a bunch of things.
But yeah it seems like these lack of features is a willful and highly-opinionated approach to what the author of the protocol wants to take a stance on (their excuse is ease of implementation for clients, but I think it is a more of a deliberate choice). That's fine. It's their protocol and they can do what they want with it, but I think they missed an opportunity for it to take off.
Various people since have suggested we just settle on HTML 4 (with no scripting) and we'd be way better off and I agree.
The thing is, while I agree we could just make decent and frugal websites, gemini not being based on html is a feature. It allows us separate both worlds.
When I open lagrange (a gemini client) and click on a gemini link from any gemini capsule (site), I am confident it will open something similar.
If I am opening a website, even a good frugal one made in HTML without js and click on an https link, I can't be sure if that won't send me to a page full of ads, tracking and heavy javascript with an embedded crypto miner.
You often find some http/https links on gemini capsules, but most clients will render the link in a different color so you kbow what to expect when clicking on a web link.
HTML 4 without JavaScript would go a long way to combat a lot of that. If you use the Gemini protocol to deliver it then you don't have to worry about cookies either. You could even prevent cross-site requests to avoid 1x1 pixels etc.
You can prevent many kind of ads and tracking from working and disable JavaScripts (and other features if wanted, e.g. CSS) entirely, although there is no guarantee that it will work.
I had a different set of criticisms, such as: mandatory TLS, no file size in the response, no range requests, etc. (I made up my own in order to address these and some others.)
There was (and still is to a degree) a group of people critical of TLS. One half of the group (which I think you belong to) bitch about it being mandatory. The other half bitched about the use of TLS instead of <bespoke encryption system they just read about that is better/easier/smaller than TLS>. TLS was the main point of Gemini.
And about the lack of file size: I proposed a way to sneak it in, and it was rejected outright. Oh well.
You can use the Scorpion protocol that I made up if you want optional TLS and including the file size (and if you don't like the Han unification). You can use Spartan protocol if you want the Gemini file format (with one difference) but a different protocol that does not use TLS (although it is not the same as just Gemini without TLS, but works significantly differently), although if you have any dynamic files then you might need to handle them differently for Spartan than Gemini.
* Inline links
* Image support
* Video/audio support?
I /kind/ of like the idea of fonts not being customizable, that it makes people focus on the content rather than over-styling. A lack of server-side font customization would be good for forcing inline links to be obvious, rather than potentially obfuscated.
Font customization is need to emphasise, it helps the reader understand the sentence better, other styles such italics, underline, and strike through… would greatly improve understanding the context and increase readability, it's just a matter of good typesetting.
Inline links also help with the same, people who dislike it should be able to move them out of the context (like some terminal based browsers).
I don't care about image, video etc, they can just be a link to the resource if/when needed... given alt text/CC is supported or accessibility.
Same for color coding stuff and CSS, users should customize their client for that if they want to, not the server.
I agree that fonts should not be specified by the document, although it would make sense to specify that you want a fixpitch font, or emphasis font. Pictures within the document might make sense (especially if you want to print it out); video/audio would be better as a separate file that you can link to, and display using a separate program.
I really enjoyed messing around with Gemini a while ago! But after the "messing around" stage with the protocol itself, the restrictions inherent to gemtext sapped my excitement around it.
It's a mark up language squarely focused on those that write text, but arduous to use if you want to share things you've illustrated, which is most of what I share online that isn't tech related. There's of course the argument that inline images/a spec'd way to expose an image directory listing with thumbnails/etc would only serve to distract or exploit you... but that also ignores the fact that people make art for your eyeballs too. Text is certainly the first class citizen, where images/music/video are all tied for second class, accessible only by downloading them 1 by 1.
That does mean it's perfectly fit for purpose! I wouldn't say it's bad just because I don't get my specific needs met. Someone who's needs are met by Gemini will love it.
There are Gemini clients that can inline images, so visitors to a site could decide to enable that if they wanted to see for instance a list of thumbnails.
Are clients permitted/expected/tolerated to run off and fetch the contents of image links for inline display, once a page containing such links is retrieved?
Permitted? Technically, it can't be stopped (well, it kind of can, see "Tolerated?").
Expected? No, it's counter to the intentions of the community.
Tolerated? Maybe. Here's a fun one (saw this in one of the past discussions dang linked): https://github.com/makew0rld/amfora/issues/199. That was over favicons, but the response would be similar if linked images were automatically fetched. Though the protocol has a "backoff" return code that could be used to throttle those things that would be less disruptive than Drew's approach of banning specific clients.
They are not supposed to do that, but some clients have an option to enable it anyway.
There are also clients that make a second request to ask for a favicon. In the spirit of the protocol the "icon" is just a UTF-8 symbol, but that behaviour is still controversial.
Only if the page is inside of a ZIP archive stored on the local computer and only if the link is to a picture within the same ZIP archive. (However, it would be good to have an option to disable inline display even in that case.)
This would be my preferred way of document distribution. Images and video is allowed, but they have to be part of the same document as the text. Everything is in the same zstd'd tarball. No separate roundtrips for fetching images. Either you download the document or you don't. Would be cool with some limitations on overall document size as well.
Not really, in fact they're forbidden - those clients are spec-uncompliant.
Agree. I don't think Gemini plugs any hole that Gopher could've left open. As it is, it's just a motherfuckingwebsite.com, except it's trying to take itself seriously.
I want my protocols to take themselves seriously.
Maybe this is just me showing my age, but I don't understand why reinvent everything when you could just go back to something like HTML 2.0 or even 3.2 with some minor changes. I probably hate what happened with the "modern web" as much as the Gemini developers, but going full NIH is unlikely to be a good solution when there's an existing "unmodern web" to develop for, and as a bonus, can be experienced even with a modern browser.
Never underestimate interoperability.
Gemini is a reaction to all the negative changes that happened to the web. Their premise is that the design of the web was fundamentally flawed because it was extensible. You see this in both the protocol and the community where the dominant idea is basically, make it super hard to ever extend or change Gemini. HTML is clearly a failure from this perspective, because HTML changed.
Personally I don't have much use for this attitude, the main problem I have with the web is when faced with the choice of empowering the publisher vs empowering the user, we kept on choosing to empower the publisher. The standards and browsers were owned by the web publishers, no one represented the user, and now instead of having a "user agent" installed on your machine to browse the web, you have a piece of spyware, better referred to as "Google's agent."
I don't really need to trade Google's Agent for Drew DeVault's Agent, give me software that does whatever I want it to do, fuck the publishers. But what do I matter, I'm not building any of this stuff.
Gemini is technically extensible. The only reason servers and clients don't add "unofficial" features which eventually become official, like HTML did, is because of the community.
But a community could form around early HTML, make clients and servers that only support early HTML, and vow to never support later HTML features. Such a community wouldn't be much different from Gemini's. Psychologically, they would have more difficulty rejecting new features (that have already been implemented), be less exciting initially (since they have less novelty), and have more trouble distancing themselves with mainstream HTML. But psychologically, Gemini is apparently reinventing the wheel without any advantages over HTML...and that disadvantage, at least to me, feels worse than the aforementioned advantages.
EDIT: I actually think gatekeeping a community with a different protocol may be a good idea. But I haven't heard about any technical advantages of Gemini (e.g. a protocol design that would be especially hard to extend, like a bloated spaghetti protocol on purpose) and I think that's a wasted opportunity. Nor have I heard about anything particularly interesting in the Gemini community, which makes me think the psychological benefit of a separate protocol isn't enough for an effective community, Gemini's community would need some other advantage, then perhaps a separate protocol wouldn't be necessary.
If you reinvent something then people get to be a part of it. They get to help with implementation and maybe design. People like being a part of stuff.
The advantage of a separate protocol is that you know that every available site will be limited. If you use a search engine, it will give you a result your limited browser can read. If you use an old or limited web browser (Dillo, e.g.), then you will still have the problem of discovery of Smolweb content.
Interesting outro. Interoperability is presumably one very big reason for this protocol.
As for why, all I can say is, download Lagrange, go to gemini://bleyble.com/cgi-bin/random, and see for yourself. It's one thing hearing about it and a completely different experience browsing the geminispace.
The different experience is largely thanks to different content, not different protocol. The protocol just serves a gatekeeping role to keep the community small enough.
That's true to some extent, but it's also true that the side-effect of the protocol is that it results in a very different community.
It's a bit like saying that the camping experience has nothing to do with not having access to electricity. Well, true but also not true.
I think that the specifics of the protocol don't actually matter all that much. What matters is that it's sufficiently unappealing to filter out most potential users; you genuinely have to feel strongly about the state of the web etc to spend a lot of time on Gemini.
In that sense, I suspect that OP is right and they could have achieved the same on top of, say, HTML 2 (https://www.rfc-editor.org/rfc/rfc1866).
> download Lagrange, go to gemini://bleyble.com/cgi-bin/random, and see for yourself.
Well, I did, and I see "Expired Certificate - ... TLS certificate has expired" :(
Yes that's a site that I like because of the random site function, not geminispace as a whole. But just click past that.
For others: link for desktop downloads of Lagrange - https://git.skyjake.fi/gemini/lagrange/releases
That was a terrible experience. For a start that site has an expired certificate, as do many of the pages it suggested, and of the pages that worked it was mostly people that dipped a toe in a few years ago and never came back or other broken function.
You're welcome, I guess? xD
HTML 2.0 and NOSCRIPT are very hard to enforce both server and client side.
Are they? On client side, technically it is easier not to execute scripts then to do so (despite the UX of https://addons.mozilla.org/en-US/firefox/addon/noscript/ might let you think the opposite). Technically, with DOM inspection one can also easily filter out elements you don't like, both on client and server side. It is literally one XQuery/XPath away.
The problem is that most modern "apps" stop working once you prevent them from exchanging data with third parties or using nowadays-standard APIs such as XHR or Websockets. This is why a radical cut was chosen by Gemini.
You are not the only one to suggest that.
I think there is benefit in having multiple approaches available, and that is one of them, but the other one is the other benefit.
I built and run a search engine and a "Wayback Machine" for Gemini:
gemini://kennedy.gemi.dev
There are ~4K hosts and ~1M documents/images/files which make for nice playground with experimenting with crawlers, indexers, and more. Its a nice hobby. Lots of primarily static sites, and CGI is used to add some interactivity:
gemini://gemi.dev/cgi-bin/moon.py
From what I remember about the name, it's derived from NASA space programs. Where Gopher is Mercury, Web is Apollo and Gemini is in between.
Gemini is a new internet protocol which:
- Is heavier than gopher
- Is lighter than the web
- Will not replace either
- Strives for maximum power to weight ratio
- Takes user privacy very seriously
No images is a bit of a deal-breaker for almost everyone I would have thought.
Images aren't prohibited. They are linked but can be shown.
Gemini users kind of have a meltdown if you try to implement any optional features. One browser implemented favicons and users were flaming the github issues demanding it be removed or they would implement IP blocks for any users requesting the favicon url. I tried to find the link but search results are drowned out by Google's Gemini.
By users in plural you mean a professionnal troll called Drew Devault who afaik isn't a gemini protocol user anymore.
That sounds about right. My memory of the thread is a bit fuzzy.
Yes I mean images in the page.
I wonder how discovery and search work if it’s just a bunch of linked documents? Do search engines exist outside of Gemini and link into it?
There are several search engines of Geminispace, running as Gemini servers. There are also a number of feed aggregators that are widely used.
Also, part of the idea is discovery through linked high-quality sites. Like the webrings of the 1990s.
You find a capsule you like and discover others through that person's links.
The protocol supports query strings so the server can generate content based on the string, which can be used for an in-Gemini Gemini search engine. It doesn't have to be all static content. People could also build out a directory (like the now defunct DMOZ and similar directories for the Web).
Gemini was so much fun during lockdown - I loved the distraction of a new simple protocol, and the challenge of writing a gui client for it.
Can't say I'm surprised that it hasn't taken the world by storm, but it's still a cozy part of the Internet.
I completely missed out on this :'(
No doubt you were doing a myriad of other things that were worthwhile to you at the time.
Read the 100 word intro and still don't know what this is. Left.
It's an alternative to HTTP and HTML (primarily). With the protocol sitting, in terms of complexity, somewhere around the early HTTP/1 protocol and gopher, and the geminitext format being suited for a variety of displays and more text oriented rather than for interactive or multimedia use.
And its simple implementation (client and server) comes from the simple protocol that doesn't seem to need much code to implement. The content seems to be in something similar to Markdown but fewer features. So if one wanted one could achieve the same with simple HTML over HTTP. My guess this is also a community thing.
I'm not sure that something like HTTP 1.1 is hard to implement. There are miriads of HTTP servers and clients. It has its quirks, for sure, but you can code basic implementation pretty easily.
Now rendering HTML is completely another level of difficulty.
If you ask me, I'd suggest to use Markdown instead of HTML for "simple web", but keep HTTP/1.1. Rendering Markdown is relatively simple and it's rich enough for a lot of document-based websites.
As for "web apps": use webassembly as underlying execution engine, but build something new for rendering, not coupled with any markup languages. Just provide canvas to draw and efficient API to implement draw operations. Application developers will use frameworks and frameworks prefer to draw everything themselves anyway. I think that kind of "web app engine" would be possible to implement with limited development resources, unlike modern web browser.
> Just provide canvas to draw and efficient API to implement draw operations. Application developers will use frameworks and frameworks prefer to draw everything themselves anyway.
This is terrible for accessibility, though.
> Rendering Markdown is relatively simple
Markdown is a superset of HTML, so your assertion cannot be true. But even an HTML-less subset is very hard to parse efficiently (or, at all) because of the various grammatical ambiguities. And then there's the various competing definitions...
> And then there's the various competing definitions...
Someone always bring this up whenever a permutation of this thread comes up, but I don't see the problem. You choose a definition and make that the spec. Even Hacker News only supports a very limited subset of Markdown.
It's Gopher + TLS + UTF8 + text wrapping + headers + unordered list.
more like HTTP GET - LSB bit of response code + "please send the MIME type we like, not the MIME type we hate"
Agree, that was exactly my reaction. What a terrible introduction, wasting many words on such platitudes as telling me that the idea isn't new but it isn't old fashioned either, or that they want to provide "some respite for those who feel the internet has been disrupted enough already."
Jesus, god forbid someone share their motivation for a project for longer than it takes for a tiktok to play...
The link to the FAQ and spec is right there. If you have the attention span of a fruit fly (many such cases) I personally suggest trying to fix it, not feeling proud about it.
If this were an utterly pedestrian """deep dive""" about some AI thing it could have rambled as much as it liked that there wouldn't be this comment near the top, I assure you.
Reminds me of a commercial where an artist attempted to convince their friend in excited terms how amazing their new masterpiece was, only to reveal its a blank canvas and they ran out of paint.
Edit: Ah, found it. https://youtu.be/11EwyJ5fcBI?si=d4IxlsNADvl4zeG9
Fascinating. And what in the world compelled you to announce your short attention span to the world?
It's basically just the World Wide Web, minus images or scripting.
It's in the FAQ which you can get to on one click:
>Gemini is an application-level client-server internet protocol for the distribution of arbitrary files, with some special consideration for serving a lightweight hypertext format which facilitates linking between hosted files. Both the protocol and the format are deliberately limited in capabilities and scope, and the protocol is technically conservative, being built on mature, standardised, familiar, "off-the-shelf" technologies like URIs, MIME media types and TLS. Simplicity and finite scope are very intentional design decisions motivated by placing a high priority on user autonomy, user privacy, ease of implementation in diverse computing environments, and defensive non-extensibility. In short, it is something like a radically stripped down web stack. See section 4 of this FAQ document for questions relating to the design of Gemini.
Are you for real? Or is this some irony I'm not getting
Presumably these are the 100 words they read:
> Gemini is a new internet technology supporting an electronic library of interconnected text documents. That's not a new idea, but it's not old fashioned either. It's timeless, and deserves tools which treat it as a first class concept, not a vestigial corner case. Gemini isn't about innovation or disruption, it's about providing some respite for those who feel the internet has been disrupted enough already. We're not out to change the world or destroy other technologies. We are out to build a lightweight online space where documents are just documents, in the interests of every reader's privacy, attention and bandwidth.
Those words don't communicate much about Gemini at all. Gemini could be a webring for all this says (it's not, but you could build one on it), or it could be something entirely different. It turns out that Gemini is a protocol and a text format, but those 100 words don't say anything about either of those things.
Sorry I read the first 10 words of your comment but didn't understand the point.
It does a really bad job of explaining what it is. They could have said "modern gopher" and that would have conveyed way more information (for people who know what gopher is, which is probably 90% of the people ever reading it).
The time they save by not having the bells and whistles of JavaScript and "HTML5" they waste by being very blah blah blah around the point...
Tik-tok type thing to say.
I've had a Gemini Capsule (what Gemini calls a 'website/blog' since about 2021. It gets very little traffic, but it's fun to have. Browsing the smallweb is nice in the evenings when I want a high signal-to-noise ratio of interesting content.
I created one of the first social networks for it. Still running: https://martinrue.com/station
My main blog is now an "anonymous" gemlog. I use the kineto http proxy to provide a website version as well. I wrote a little deploy script that scrapes my posts and creates an atom XML feed (static doc) that kineto serves for those few people who want to stay up-to-date.
Once a quarter, I batch up the recent posts and bcc a bunch of folks I like to keep in touch with. Some of them respond. This is what I do in place of social media now; outside of email, Discord and WhatsApp are all I use to keep in touch with folks.
I also like to poke around different gemlogs with Lagrange, which is a nice desktop-oriented Gemini client. It's good fun.
i installed Kristall to try this all out. Seems nice. Should I stick to it or is there a better client you'd recommend?
I'm not really up to date on the client front at the moment. I've just used Lagrange since the beginning and it hasn't failed me yet!
If we maintain this trajectory Gemini is going to have as many dual meanings in the software world as Map.
I found it hard to extract any signal from this extremely chatty site. But AFAICT the tagline "basically modernized Gopher" wouldn't be too far off the mark?
I feel like to be in the really proper spirit, the software for this should be written in Forth, sort of like CollapseOS.
Honest question, how do you discover interesting content over this protocol?
Is there people building the equivalent to web directories and web rings? Or search engines? What are the cultural expectations on navigating other people's published resources?
There are search engines, directories and feed aggregators [1].
Best means of discovery is like the original web, you surf it, bouncing from capsule to capsule finding what you like.
1. https://github.com/kr1sp1n/awesome-gemini?tab=readme-ov-file...
I enjoy the smol web and I really think it's a great place for tech enthusiasts.
This is why I created finger://, gemini://, gopher:// and https:// mirrors for by website at sava.rocks
links for all protocols:
https://sava.rocks gemini://sava.rocks gopher://sava.rocks finger://sava.rocks/sava
I have read and liked the philosophy, no inline images, no tracking, nondistraction, no extensioms, security, etc.
so i went and downloaded the first android gemini browser from the links called "buran".
Then i surfee around links people posted in here.
Came upon a site gemini://hellomouse.net
First thing i see: an inline image that is against very principles of gemini and shouldn't be allowed
What am i doing wrong?
You're doing nothing wrong. Even gemini users realise that inline images are good actually.
Like "they are good". Whole html with its features is "good", but when i want to use a privacy- first protocol, why the hell would i undermine it with tracking pixels, especially since it noted as the very feature of this protocol
There are plenty of ways to implement images without allowing for tracking pixels. Only allowing images to be served from first party domains would be a simple one.
It would be noisy and would break the page size limit but you could also require that images be included inline as base64 encoded strings.
Ah yes. The main feature of images is tracking pixels. And not, you know, images.
Gemini's simplicity is refreshing! It feels like a cozy corner of the internet focused purely on words and ideas. Kinda perfect for offline reading sessions, almost like finding a quiet spot to when bored. Definitely not for sharing my doodles, but I get why some folks love this minimalist vibe. Exploring random capsules through Lagrange is oddly relaxing.
Too many things are named Gemini
To be fair, I believe this protocol existed before Google’s thing, if I remember right.
I like the idea of Gemini and was inspired to write a script to turn my blog posts written in markdown to gemtext. Sadly I still haven't finished that script ...
My main issue with the protocol is that it is requiring creating a new TLS connection for every request. That is indeed a simple approach but I argue that the extra round trip times added due to this are not worth the trade-off for the simplicity gained in this case
Coming up with a simple way to reuse a connection would reduce the round trips needed drastically. If we put our heads together, I feel like we could come up with a way to do that, that doesn't overly complicate the protocol ...
Unrelated but I went to the linked website, then a while later to Youtube and now I'm getting videos recommended about the Gemini protocol that I have never heard of before today.
I'm on Arc and use uBlock Origin Lite, NextDNS, if I had searched I would have used Kagi. How do they (Google) know?
EDIT: I'm not implying that the gemini project is doing anything wrong here
The prediction algorithms are so good that indirect behaviors and data can be informative.
You might also be profiled by Google and bucketed into a group of similar people who leak their data. They also went to this website and their YT recommendations became a signal to inform your own.
Not claiming any certainty here just possible ideas.
Tin foil hat comes off then for now, thank you :)
They aren't necessarily tracking you personally. Gemini Protocol hitting the front page of HN means a spike in interest generally, which the YouTube algorithm could be reacting to in aggregate.
I rather like Gemini. I have several presences on the protocol, as well as a hefty list of gemlogs I follow. The somewhat slow and niche nature of this corner of the internet has meant that I come and go, rather than using it daily (like I do with the web); but it always feels sort of cozy and welcoming when I do eventually return.
Recently:
Six Years of Gemini
https://news.ycombinator.com/item?id=44578143
HTML is a corrupt standard, remember when W3C agreed with DRM as a 'standard'.
> Project Gemini
I have a theory that the idea you'd call your project "Project X" comes from TV shows.
We work with project codenames and we don't call anything Project X. We just call it X. It feels like adding the word "Project" is something a screenwriter would do to make the dialogue clearer.
I would say that it comes from the military, where projects are given codenames that try hard to be opaque random monikers, and spill no beans about the nature of the project. The Manhattan Project predates mass TV, and most of it did not happen on Manhattan.
I don't mean codenames. I mean literally saying the word "project". It's like meeting a friend and saying "hello my friend I've known for the last 20 years".
Compare: "We are working on Project Paperclip" and "We are working on a paperclip". I suppose the former implies that what you're working on is not a literal paperclip (but a secret operation to snatch scientists).
So "Project Gemini" is not about, say, he constellation.
With modern two-random-word codenames we tended to just say things like "I'm working on Crystal Banana all next week"
(Crystal Banana was a local joke codename where I worked)
We would say "We're working on Paperclip."
> Tube Alloys
Why is everything named Gemini these days?
The Gemini protocol started in 2019, before Google's Gemini in 2023.
It's proably a popular word for tech workers fans of the american space race.
Or for people who want to evoke notions of duality/parallels/twinship.
Google renamed Bard to Gemini last year. Side note: Google's "Gemini" product name is way overloaded. They have like 6 different things that you can buy/use that are named that.
Sounds like IBM’s “Watson”
Yeah it seems like everybody and their brother is naming things Gemini, is there a dual meaning I’m not aware of?
Nice pair of Gemini puns
yeah seems like an odd choice for a new project.
The project is six years old
I stand corrected.
This long predates Google LLMs
Because Copilot was already taken
Right? I clicked in here thinking it meant Google's Gemini but of course not just another uncreative name that clutters search results. (I'm not sure if Google's Gemini or Project Gemini is the uncreative clutter, but either way.)
I looked at this a few years ago and it seemed to be a graveyard of toy implementations and personal blogs.
Isn't that what it's meant to be?
sun is not doing Allah is doing to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
I'd love a minimal protocol like this that was also somehow scraping resistant.
If this is being developed, it should have a more modern description. Comparing it to Gopher is fine as a historical point, but comparing it to http/html is more useful today. I read the faq for geeks and didn't learn much:
> 1.1.1 The dense, jargony answer for geeks in a hurry
> Gemini is an application-level client-server internet protocol for the distribution of arbitrary files, with some special consideration for serving a lightweight hypertext format which facilitates linking between hosted files. Both the protocol and the format are deliberately limited in capabilities and scope, and the protocol is technically conservative, being built on mature, standardised, familiar, "off-the-shelf" technologies like URIs, MIME media types and TLS. Simplicity and finite scope are very intentional design decisions motivated by placing a high priority on user autonomy, user privacy, ease of implementation in diverse computing environments, and defensive non-extensibility. In short, it is something like a radically stripped down web stack. See section 4 of this FAQ document for questions relating to the design of Gemini.
Annoyed that for a system about plain text links, there's no link to "section 4".
The transport sounds like http without saying so. It doesn't go into why it doesn't use http. I'd probably be fine with HTTP and Markdown + image/video links. Maybe the Gemini document capabilities/scope is better but they're not described.
Edit: they are in "4.1.2"[0] Be warned, there's still a lot of beating-around-the-bush.
> 4.1.2 I'm familiar with HTTP and HTML. How is Gemini different?
[0] https://geminiprotocol.net/docs/faq.gmi#412-im-familiar-with...
Edit 2: Seems opinionated in many stupid-by-todays-needs ways. It feels like text-web made by some group of deniers.
Ya, I still don't understand how this works at a high level. Does anyone actually understand how it works?
A Gemini client is an application like a web browser, but simpler. It sends a one-line plain text request to a Gemini server over a TLS socket. The server sends back a document with a MIME type, or an error message, and closes the connection. The client renders the response for the user. That's basically it. It's similar to Gopher or to HTTP/0.9. A common document type returned is Gemtext, which is a text format like a simplified Markdown that can be parsed on a line-by-line basis.
Given the amount of servers and clients people have written for it[0] I'd say there are definitely people out there who understand how it works. What don't you get exactly?
0: https://github.com/kr1sp1n/awesome-gemini
As someone who got onto the web in HTML 2.0 era I can feel the appeal of Gemini, although I disagree about their attitude towards static inline images. In day-to-day world that's what separated HTML from the earlier text-based hypertext systems that you could run over a terminal connection (or in a window, like AmigaGuide). You could actually have real documents from the internet, on your own screen, without loading up a word processor. White pages, black text in different sizes, blue links, and color images! Cool!
Obviously, Gemini is a niche that's as futile as it can be. It's like going back to living without a running water because once there was a peaceful village, then first came running water, then electricity, and then the whole village was rebuilt into a big city, and the old village is now gone. But the logic goes: if they didn't get running water in the first place, the people who wanted electricity too wouldn't have moved in, and the city wouldn't have been built. So, reverting back to living without running water now will, if it doesn't maybe demolish the city, at least remind me of the good old days.
The problem with the current web is that before, maybe just 10 years ago, you could use a good browser to remove and disable all the user-hostile cruft aimed at you on websites, and maybe browse pages in relative peace. Now the fight has moved to removing and disabling all the user-hostile cruft aimed at you in the browser, that intend to remove the tools you could use to fight the websites, and given the de-facto monopoly of Google that's just incredibly sad.
What's more demoralising is that it's just one slice in the big trend to erode the concept of ownership alltogether. It's a matter of time until you can no longer even try to own your browsing experience. The web will have changed from a place where people could freely download and view other people's documents over HTTP to people using one-way thin-clients with attestation so that the producer can guarantee their website is interpreted correctly as intended. Good luck writing your own browser that does the right thing for you, it won't be served data off the web unless it can prove the client is unmodified and signed by Microsoft. That is, of course, assuming you could still write code yourself for your computer and actually run it on your own without asking permission from the vendor.
It seems that the 20's answer to what Gemini represents is probably something like asking an AI to load a web page, extract the real contents of the document, possibly with cues from accessibility hints, and reproduce the document as text and still images for viewing.
as a recent gemini user i like that clean looks, amazing fast page loading if compares with http web, low stimulation feedback, that makes me feel more concentrated and allow me to be less distracted while reading contents. There is a good browser options, graphical but that lovely terminal and hyper-fast ones.
In a world full of marketing/publishers psychopaths, Gemini protocol is a hope and part of human resistance.
So Gopher?
gopher over http: Seems like firefox et al removed support for it years ago.
Gemini's native protocol isn't HTTP, they invented their own. I don't really see what this does you couldn't do with simple HTML pages (or Gopher 35 years ago).
Even simple HTML pages may require Javascript and want to run code on your computer or phone. You need knowledge of the document, knowledge of its author, or constant keepup and awareness of browser settings (e.g. did some update re-enable Javascript) to mitigate this.
A .gmi is 100% certain not to need any extra code capable of potential unwanted external communications, not now and not in the future.
Also .gmi is extremely simple and can be rendered very simply (and thus more securely) because it can be processed nearly statelessly line by line, without need of a rendering tree or document model.
I think some of the point is what you can’t do with it rather than what you can. It’s an intentionally very restrictive protocol.
Nothing.
But that's not the point.
... which looks even more stupid when you can force quite a number of browsers to get you something through gopher if you just pretend it's http on port 70. of course you have to self interpret the result, but gophermaps are quite readable. :)
Related (and a little hard to sift apart from you-know-what):
Gemini (2023) - https://news.ycombinator.com/item?id=45238536 - Sept 2025 (46 comments)
Six Years of Gemini - https://news.ycombinator.com/item?id=44578143 - July 2025 (166 comments)
The Gemini protocol as seen by cURL's creator - https://news.ycombinator.com/item?id=43054583 - Feb 2025 (6 comments)
Ask HN: Are you using a Gemini browser? Would you follow a link if posted on HN? - https://news.ycombinator.com/item?id=41491928 - Sept 2024 (5 comments)
The Gemini protocol seen by this HTTP client person - https://news.ycombinator.com/item?id=36104533 - May 2023 (107 comments)
Bye, Gemini - https://news.ycombinator.com/item?id=37049064 - Aug 2023 (159 comments)
Show HN: Gemini web client in 100 lines of C - https://news.ycombinator.com/item?id=36786239 - July 2023 (45 comments)
The Gemini protocol seen by this HTTP client person - https://news.ycombinator.com/item?id=36104533 - May 2023 (107 comments)
What the eff Is Gemini? - https://news.ycombinator.com/item?id=34392811 - Jan 2023 (92 comments)
On the Shortcomings of Gemini Protocol - https://news.ycombinator.com/item?id=31560509 - May 2022 (46 comments)
Lagrange Pre-Release – A Gemini client that also supports Gopher and Finger - https://news.ycombinator.com/item?id=30998033 - April 2022 (30 comments)
Offpunk 1.0: Offline Gemini/Gopher/Web Browsing - https://news.ycombinator.com/item?id=30669799 - March 2022 (17 comments)
Gemini is a new internet protocol - https://news.ycombinator.com/item?id=30667545 - March 2022 (72 comments)
Gemini is a little gem - https://news.ycombinator.com/item?id=30072085 - Jan 2022 (122 comments)
Gemini is Solutionism - https://news.ycombinator.com/item?id=30067400 - Jan 2022 (218 comments)
Lagrange: A desktop GUI client for Gemini - https://news.ycombinator.com/item?id=29291392 - Nov 2021 (90 comments)
Gemini: The Misaligned Incentives - https://news.ycombinator.com/item?id=28688232 - Sept 2021 (84 comments)
What is this Gemini thing, and why am I excited about it? (2020) - https://news.ycombinator.com/item?id=28600436 - Sept 2021 (208 comments)
Gemini's "uselessness" is its killer feature - https://news.ycombinator.com/item?id=27490769 - June 2021 (193 comments)
Why Gemini is not my favorite internet protocol - https://news.ycombinator.com/item?id=27480324 - June 2021 (1 comment)
Gemini Space - https://news.ycombinator.com/item?id=26670464 - April 2021 (27 comments)
Agate, a simple Gemini server written in Rust - https://news.ycombinator.com/item?id=26401158 - March 2021 (34 comments)
Beyond the Web: Gopher, Gemini, and the Rise of the Small Internet - https://news.ycombinator.com/item?id=26359454 - March 2021 (5 comments)
gemini:// space - https://news.ycombinator.com/item?id=25986378 - Feb 2021 (170 comments)
The Tragedy of Gemini - https://news.ycombinator.com/item?id=25807633 - Jan 2021 (28 comments)
Hacker News over Gemini - https://news.ycombinator.com/item?id=25225810 - Nov 2020 (21 comments)
Show HN: Taurus – A Concurrent Gemini Server - https://news.ycombinator.com/item?id=25045130 - Nov 2020 (5 comments)
A Gopher View of Gemini - https://news.ycombinator.com/item?id=25005307 - Nov 2020 (9 comments)
A look at the Gemini protocol: a brutally simple alternative to the web - https://news.ycombinator.com/item?id=23730408 - July 2020 (347 comments)
Castor: A browser for the small internet (Gemini, Gopher, Finger) - https://news.ycombinator.com/item?id=23161922 - May 2020 (75 comments)
Gemini – A new, collaboratively designed internet protocol - https://news.ycombinator.com/item?id=23042424 - May 2020 (62 comments)
---
Bonus: First Gemini AI thread looks to have been:
DeepMind's new Gemini AI will combine LLMs with techniques from AlphaGo - https://news.ycombinator.com/item?id=36495892 - June 2023 (6 comments)
... and the first mammoth one looks to have been:
Gemini AI - https://news.ycombinator.com/item?id=38544729 - Dec 2023 (1602 comments)
Why provide yet another overload for "Gemini" rather than thinking of something either novel or not in common current usage in a totally different context?
This project started in 2019.
Why do programmers have so little imagination when it comes to names? It should almost never be the case that project names conflict
For one, the project started in 2019 https://geminiprotocol.net/history/ So, I guess Google should rename their LLM?
For another, to do that we'd have to follow something like the prescription drug naming process https://globalhealthnow.org/2024-07/why-do-prescription-drug...
That way, instead of "Gemini", they could have named it something like "Cymbalta", "Xeljanz" or "Cialis" :P
Ask Google, this project predates the LLM.
Back when I was a Googler, I used to play a little game where I would think of a random word and then check if there was a Google internal project code named for it. It was a bit hard finding stuff that wasn't some system or project, and often there would be multiple ones. I actually found one that I thought would be a nice name and reserved the go link for it, but naming anything after it never panned out, when I finally got to design a system from scratch my manager wanted a boring descriptive name like "consolidated data system" (it was a bit more specific but that was the vibe).
Side note: I noticed that more "boring" and less sexy projects had cooler names a lot of the time, and my theory was that people were compensating for doing unsexy work.
I reserved go/poop years ago, but the ability to name a project with that name is diminishing
What happens to your go links when you leave Google?
This one is still up. I just checked it. I was underwhelmed by where it linked to.
Google eats their own with names. Their latest and greatest AI framewofk is Agent Development Kit (ADK). Not to be confused with the Android Development Kit...
Can't wait for Google to announce a humanoid robot project called "Google Android"...
I remember a comment on here years ago from someone in GCP who mentioned that they did not control the "Cloud" namespace. So any VP could launch a new project and call it cloud something and make people very confused about why it wasn't showing up in the cloud dashboard and API.
At least the internal name of that kit is a cool name. So we should blame the Cloud marketing people who likely don't know about Android since they're Cloud people.
Try being Microsoft and having two different LLM products and an entire office suite named Copilot.
Please no more "Project Espresso" nonsense that is entirely meaningless to anyone reading this.
Pick a descriptive name. Everyone else who is not in your team will thank you.
An alternate take that I tend to agree with:
https://medium.com/better-programming/software-component-nam...
Fun fact: one of the first 10 bugs filed on the Go programming language was "Hey, I've been working on a programming language named Go for the last 10 years, please pick another name." https://github.com/golang/go/issues/9
Too small for Google to care about.
Large tech molochs don't care about any name, it seems. Their power and weight makes the name point to them. Seek on "Amazon" and find that, oh the 7th Wonder of Nature the "Amazon rainforest" is ranked second after some random Big Tech company run by a guy named Jeff. The "lungs of the earth" vs. cheap package delivery and AWS dashboards.
I mean, yeah. What percentage of searches for "Amazon" in today's world do you think is going to not be about acquiring cheap shit very quickly? I would expect the tech company to be a better answer than most when someone searches for Amazon. Searching for "the amazon" gives the expected results as that's how it is more commonly referred. So it does seems like your search query as performed was just a bad search
I bet it would be a few percent less and the world would be a fraction of a percent better if the first result was the rainforest.
I wonder how much they pay Google for the top spot.
Amazon does not need to pay Google for this. There is no world where Google puts an organic result about the rainforest in the top spot, because it's not what most users are looking for.
At most there might be a world where Google puts someone else's ad above the organic results.
Well, we also know Google isn't trying to help the user leave Google's site as quickly as possible, because they get more ad money when the user clicks on a few pages or does a few searches before finding what they want.
you'll probably find a Google expense for the same value of Amazon services so that no money ever trades hands, but both companies' valuations are inflated
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
You forgot the "and off by one errors"
I would add also hearing this quip every time either of those things come up un conversation.
“There are only two hard things in computer science. Cache invalidation, naming things, and off-by-one errors.”
My favorite form is when someone shouts "concurrency" in the middle of the sentence.
"There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors"
I've always wondered if he meant coming up with good names or if he meant ensuring that names, however they're chosen, reliably resolve to the named thing.
You forgot "Off by one errors."
Why single out programmers? Name collisions happen in constantly, across every single industry.
It turns out that there really aren't that many possible project names before you get into the made-up "that sounds stupid" words.
> It should almost never be the case that project names conflict
Sure, if you want projects to have the same naming strategy as Chinese Amazon Marketplace vendors.
Away from that, significance in naming begins to cluster quite quickly.
They all watched the same movies or read the same books
Do you have a pile of projects lying around with good names? Coming up with a good one is hard and getting harder every day.
There is no such thing as a good name. A name is good or not only in relation to the reasons why you want that name. Different teams, orgs, etc have different reasons to name systems. Traditionally, tech names have been in English or English sounding bisyllabic mostly (Game Boy, Windows, Office, Adobe, XBox) with PlayStation being unusually long for a name competing in the anglosphere. But examples like the Bard to Gemini change, Veo (Spanish), Claude (French) break the pattern, even then you still have DeepSeek, Lyria and ChatGPT.
Oh I see. When you said:
> Why do programmers have so little imagination when it comes to names?
I assumed that you had a better than average method that you could share. But I guess you answered your own question:
> There is no such thing as a good name.
"It should almost never be the case that project names conflict"
My corollary to this is "You should never reach for a language you are not fluent in for a name. Especially, just stop it with using Japanese words to name stuff please ffs"
> You should never reach for a language you are not fluent in for a name
I agree, but that still doesn't stop funny name related issues between languages. One of my favourites was Pidora (a Fedora release for the RPI) which caused offence to some Russian speakers.
Heh good point. Coq comes to mind too...there was something else recently that sounded terrible in French..."Bitchat" maybe?
The engineering team at Deep Mind does have penchant for names in foreign languages as seen in Veo, Lyria and Gemini.
Not the Gemini I was hoping to see in the front page today :D
I have got only two annoyance on Gemini, lack of inline links and _font styling_, and they are by design (https://geminiprotocol.net/docs/faq.gmi#44-questions-about-t...)
It's fine for something like HN, but I heavily rely on named links and emphasis on all my blogs and is a dealbreaker.
Yeah they missed an opportunity to more fully support something more like markdown that offered in-line links and basic text formatting. Missing tables is also quite the deal breaker for a bunch of things.
But yeah it seems like these lack of features is a willful and highly-opinionated approach to what the author of the protocol wants to take a stance on (their excuse is ease of implementation for clients, but I think it is a more of a deliberate choice). That's fine. It's their protocol and they can do what they want with it, but I think they missed an opportunity for it to take off.
Various people since have suggested we just settle on HTML 4 (with no scripting) and we'd be way better off and I agree.
The thing is, while I agree we could just make decent and frugal websites, gemini not being based on html is a feature. It allows us separate both worlds.
When I open lagrange (a gemini client) and click on a gemini link from any gemini capsule (site), I am confident it will open something similar.
If I am opening a website, even a good frugal one made in HTML without js and click on an https link, I can't be sure if that won't send me to a page full of ads, tracking and heavy javascript with an embedded crypto miner.
You often find some http/https links on gemini capsules, but most clients will render the link in a different color so you kbow what to expect when clicking on a web link.
Gemtext can be full of ads too.
HTML 4 without JavaScript would go a long way to combat a lot of that. If you use the Gemini protocol to deliver it then you don't have to worry about cookies either. You could even prevent cross-site requests to avoid 1x1 pixels etc.
You can prevent many kind of ads and tracking from working and disable JavaScripts (and other features if wanted, e.g. CSS) entirely, although there is no guarantee that it will work.
And CSS from the client only!
I had a different set of criticisms, such as: mandatory TLS, no file size in the response, no range requests, etc. (I made up my own in order to address these and some others.)
There was (and still is to a degree) a group of people critical of TLS. One half of the group (which I think you belong to) bitch about it being mandatory. The other half bitched about the use of TLS instead of <bespoke encryption system they just read about that is better/easier/smaller than TLS>. TLS was the main point of Gemini.
And about the lack of file size: I proposed a way to sneak it in, and it was rejected outright. Oh well.
You can use the Scorpion protocol that I made up if you want optional TLS and including the file size (and if you don't like the Han unification). You can use Spartan protocol if you want the Gemini file format (with one difference) but a different protocol that does not use TLS (although it is not the same as just Gemini without TLS, but works significantly differently), although if you have any dynamic files then you might need to handle them differently for Spartan than Gemini.
Agreed.
* Inline links * Image support * Video/audio support?
I /kind/ of like the idea of fonts not being customizable, that it makes people focus on the content rather than over-styling. A lack of server-side font customization would be good for forcing inline links to be obvious, rather than potentially obfuscated.
Font customization is need to emphasise, it helps the reader understand the sentence better, other styles such italics, underline, and strike through… would greatly improve understanding the context and increase readability, it's just a matter of good typesetting.
Inline links also help with the same, people who dislike it should be able to move them out of the context (like some terminal based browsers).
I don't care about image, video etc, they can just be a link to the resource if/when needed... given alt text/CC is supported or accessibility. Same for color coding stuff and CSS, users should customize their client for that if they want to, not the server.
I agree that fonts should not be specified by the document, although it would make sense to specify that you want a fixpitch font, or emphasis font. Pictures within the document might make sense (especially if you want to print it out); video/audio would be better as a separate file that you can link to, and display using a separate program.
To me, inline links could be formatted as footnotes, the way we do in plain-text email.
Same here. Those are my gripes exactly.