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.)
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.
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.
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.
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:
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 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.
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."
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 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.
> 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.
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?
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.
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?
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 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.
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 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.
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.
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.
* 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 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.)
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?
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?
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. :)
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.
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.
"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.
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.
reply