Finger was the original Twitter. We used to get updates on Quake's development from John Carmack by fingering his email. He used to write elaborate ".plan" files too, no nonsense character limits were in sight yet. It was magical. It worked like this:
$ finger johnc@idsoftware.com
No retweets, no likes, no notifications, no HN frontpage, but John Carmack kept writing them, and we kept reading. Even without any amplification dynamics, it was still engaging.
I've tried the same now, 30 years after my last finger. It wasn't even installed on Ubuntu by default. I had to install it, and expectedly:
$ finger johnc@idsoftware.com
finger: connect: Connection timed out
You can do this with ATProto / Bluesky! You can self-host your own PDS (or use Bluesky) and clients are super simple. I just had Google Search AI Mode vibe code as a 60 line shell script.
$ curl -O https://raw.githubusercontent.com/snth/radar/refs/heads/main/radar
$ chmod +x radar
$ ./radar snth@bsky.social
[RADAR] Scanning for snth.bsky.social...
[RADAR SCREEN]
User: Tobias Brandt (@snth.bsky.social)
Status: Active
Last Seen: 2026-05-28T19:42:15.865Z
--------------------------------------------------
Just vibe coded a 60 line POSIX script Bluesky client in the style of `finger` of old:
github.com/snth/radar
--------------------------------------------------
If you wanted to be more authentic to the original you could implement a custom Lexicon.
Oh pretty please, if we revive this protocol, can we please pick a better name? Like, any name? Literally anything else, that doesn’t evoke weirdly sexual imagery?
Well I thought about it and if it's a body part there will be someone into that. Then I thought maybe poke, nope some are into that too. I guess maybe "status" port? Kindof like having an away message. It could be a fixed buffer as to not overlflow. Of course that could be accomplished in DNS using TXT.
Honestly I am too lazy to make an RFC. Maybe if enough people make a finger.domain.tld text record it would catch on. [1]
dig +short -t txt finger.nochan.net
"status: currently spending time on hacker news."
or replace the finger binary with a shell function: [2]
In my electronics class in high school we learned to strip and do joints.
We also learned the resister color codes via mnemonics.
"Bad Boys Rape Our Young Girls But Violet Gives Willingly, Get Some Now" Curious if they still teach that one. [1] Wikipedia says it is outdated / offensive but it was back then too.
Black Boys, since the first mnemonic letter is for the color black. And we didn't have Get Some Now, that feels redundant since everyone knows gold is better than silver.
Man, Gopher was part of my first internet experience. It felt so magical to basically explore a (seemingly) infinite file system. Found great servers that had all sorts of interesting stuff, and then would link to other interesting servers.
I still remember a book about the internet I got in the early 90s... it was a couple of hundred pages, and then in the last chapter there was one paragraph in a section about new technology for something called "the World Wide Web".
For years I would be frustrated at people who would conflate the internet and The World Wide Web. I gave up on that years ago, though.
Objections to Gemini that point out that nothing is stopping people from writing simple HTML miss the point.
It's not that HTML forces well-meaning creators to add complexity, size, or user-hostile behavior; it's that an ecosystem that permits such behavior eventually becomes swamped by adtech and other user-hostile content for financial gain. The problem is that this content drowns out organic, human-centric content.
Having said that, while format restrictions (to plaintext, markdown, gemtext, HTML without JavaScript) do help mitigate the damage somewhat by making tracking harder, I doubt they are sufficient: even text-only forums can become overrun with spam, ads, bots, and propaganda if they lack suitable moderation.
Ultimately folks who want to browse a web of authentic human content need to combine format restrictions with blocklists and web-of-trust tools. Browser plugins, reader mode, and customized search engines can already get us partway there, but there are still gaps.
You could theoretically have a web that does not bloat. HTML is a very good technology for building clean documents. You are not going to get that, though. What happens instead is that you start on a thoughtfully designed page and are always one click away from a cookie consent banner on top of an email capture modal beside four flavors of ad. "Sure, but you can install adblock/VPN/Pi-hole/reader mode/turn off JS/etc/etc..."
I like Gemini because it actually delivered a lightweight protocol that provides what I was looking for. Additionally, it is not just a technology. It is an ecosystem that gained more traction than the hundreds of other attempts that never went anywhere.
The spec made mistakes, but HTTP has mistakes too.
It's a good point, but I think the counter is that if the only people writing anything available via Gemini would have written nice simple HTML anyway, then not an awful lot is gained.
Sure, authors can adopt Gemini-like restrictions on their own simple HTML pages to gain some of the benefits of publishing with Gemini.
But this ignores the benefit for readers. Simple HTML pages are one link, search, or change of management away from a sea of enshittified internet slop. But Gemini capsules never have banners, unwanted sounds, intrusive ads, popups, etc, making browsing gemspace a qualitatively different experience.
To use a metaphor, a gardener can plant the same flowers alongside a loud, busy, trash-strewn highway as they can in a quiet garden. Many more people will see the flowers along the highway and it's a wonderful contribution. But wandering amongst the flowers in a peaceful garden is a qualitatively different experience than doing so alongside a busy highway.
Thats a big assumption. As Michael Goldhaber put it in the early days of the Internet - people have limited capacity to give Attention to anything but unlimited capacity to receive Attention.
Scientists and technologists are not immune. And it shows up in what they cook up.
> Mozilla, which still maintains one of the only independent rendering engines (Gecko), is the only viable competitor. Everything else is Blink and Google.
WebKit isn't really independent - while it is technically opensource, it is effectively controlled by Apple. In fact, Apple were the ones who originally forked it from KHTML. They continue to be majority contributors and drive the product roadmap.
On the other hand, there's Ladybird, Servo and Chawan which are indie, and although they're still in alpha - depending on the sites you browse daily (like HN - which works fine), you might be able to use one of these as a daily-driver.
I’d love to see CoAP/wg play a part here. It’s similar enough to HTTP to be familiar, but not supported in any browser. It supports content types and server sent events. It can be implemented in far less memory and uses far less CPU than TLS. It seems like the perfect protocol for this kind of thing.
IMHO Promoting lo-spec computing and text-based is always good, seems limiting but that's what I like about it. I tried fingering as the article says, but I only got a BRENNAN: no such user :(
I use a modified, "modern" text-only browser that compiles to 1.4 MB static binary after I remove some multilanguage encodings
I've been using this browser since around 2000. I think some HN commnters would be syrprised at how much of the www I can digest using this program. They wouldn't believe it was possible
I use localhost TLS forward proxies for HTTPS. Breaking TLS turns out to be an excellent method for blocking ads and telemetry, in addition to DNS and "ad blockers"
People like to pretend that Google and other so-called "tech" companies have killed off HTTP
It may be true depending on one's www usage, but I see evidence that HTTP still alive
When their "business model" is collecting data from and about unsuspecting computer users, it makes sense for these companies to want the transmissions encrypted. If users saw what is being sent over the wire to these companies they might be upset. If competitors saw it then they might use the data themselves. Too much data collection... I digress
There are bands of vocal "tech" workers who try to drown out any mention of HTTP. Others try to make fun of FTP
But both are still being used in a variety of places, whether it's by CAs themselves^1, Google, e.g., for autocomplete^2 or even the NY Times^3 or MSN
Anyway, the point is that these companies may try to kill off usage of certain protocols where it suits them, e.g., remember FTP in the web browser. But the protocols still survive and people still use them, even if it's only the "tech" workers themselves, and others in small numbers
With HTTP (cf. HTTPS) the user can easily control what is sent over the wire
I can monitor, filter and/or modify egress with a local network foward proxy, for example. I can neutralise or stop traffic I do not want to go to so-called "tech" companies based on its destination and contents, as opposed to "trusting" it simply because it's protected by HTTPS (including "protected" from review by the user)
This level of user control can interfere with the so-called "tech" company data collection, surveillance and ad services "business model"
The modern web very much goes by the Pareto principle. But what's almost impossible to digest without full-fledged machinery are some News websites. The complexity of running ads and gdpr flows is just out of this world. It even dwarfs social media websites in that regard.
It's a German website but zeit.de. At least the last time I checked. Looking into Firefox reveals almost 8 MB for loading the front page. One could easily skip this as an exception but it's one of the 2 large weekly news magazines in Germany. Also since it's part of a publishing house, I assume other publications of them might be using the same system.
Why is it that every gemini/gopher discussion throws out the baby with the bathwater?
> Chrome alone controls roughly 73% of global desktop browser market share.
> More and more, the webdevs of the world test and develop for Chrome only.
> It doesn't need to be this way. https:// is not the only way to connect and interface with the Internet
These are completely unrelated concepts! Google/Chrome doesn't control HTTP nor HTTPS. There is nothing wrong with the protocols, you can just make your website plaintext file if you like.
Before we ever come to this point I hope as a society we take a real swing as dismantling big tech. So much potential is being hoarded by literal dragons of progress.
You may be surprised to find out that the majority of gemini/gopher authors actually do have simple HTTP(S) sites. Some even have very complex HTTPS sites. Gemini and Gopher isn't really about getting rid of the WWW, it's about having a space that's entirely disconnected from it.
Why is it that every criticism of gemini/gopher throws the baby out with the bathwater?
When you browse to a pristine html page containing zero adtech it contains links. Those links you might click on without first thoroughly vetting them for behavioral exhaust.
Hyperlinks are a vector for contagion. A new protocol creates isolation. What's wrong with both existing? Defense in depth at all levels, I say. You think https can't enshittify, maybe you just haven't waited long enough.
> Particularly after Edward Snowden's 2013 revelations about mass surveillance, running an unencrypted protocol started to feel more and more like bad practice.
As far as i understood, NSA has access to the encrypted communication on the internet so all bets are off. They '"collaborate" with certificate issuers, they monitor all big internet nodes in the "west" and all relevant software is produced in their jurisdiction.
The certificate issuer doesn't have access to the underlying private keys, so while getting a fake certificate may be useful for MITM [0], undermining the certificate authorities doesn't actually allow spying on traffic that uses the genuine certs, no matter how corrupt the CA is.
There is such a thing as overestimating the power of the NSA, if the spooks actually had undermined the system to that degree they wouldn't need to lobby for all the surveillance bills that keeps popping up.
[0] And you can't get a fake certificate either without it being visible in the certificate transparency logs, or being an obvious fake since it is absent in those logs.
As a younger person I always see these discussions and I want an alternative to the modern web. But reading this I cant help but think "why are people so focused on building a web with none of the useful features". What use is any of this without a realtime component.
The largest disconnect between then and now, is the degree to which the internet was many things (telnet, ftp, usenet, finger, gopher, http, irc, mail, etc...), and not just webpages. Each with their own specific flavors. The article is trying to recapture that to a small degree.
Over time, almost everything has been compressed into this HTTP/HTML/JScript agglomeration. When the original thought was that there would be dozens of protocols for various uses, and a lot more client applications than the browser.
The best analogy I can think of is, imagine that plays(theaters), movies(bigscreens), novels(books), operas(concert halls), art(galleries), museums, etc... All disappeared in favor of delivering that content through games on your Xbox. All of that experience compressed into one method. Then the next generation says:
"Why would anyone miss physical art galleries? I can see art much faster on the 'Louvre 2026-season pass' on my Xbox? No travel, no walking, no lines."
...because a lot of us remember a web that was very useful already, without needing a realtime component? We did the realtime stuff over other protocols; the web was literally just a web of static hypertext documents.
In fact, even search engines were originally optional; various people and organizations used to simply maintain huge static directory service websites, simply listing out "everything else on the web" (or more often, just the parts the author thinks are cool.)
Says who? I, for one, don't really like the idea of "everything is http(s)".
After all, dissatisfaction with the status quo is the reasons this space (gopher, gemini, etc.) even exists. If, like you say, nobody wanted this we wouldn't be here discussing it.
I have started to try and always develop Gopher versions of my sites for my research work. I try and promote that version especially to those who live in countries where internet access is costly relative to income or internet access is limited. Usually the key differences are diagrams become ASCII based.
Ugh, the table of gopher search results in this article is like seeing someone take a can of modern expanding spray foam and using it to repair an axle on a horse buggy. ‘We have an excellent old technology and we’re doing our level best to backport our modern torment nexus to it’, sigh. For the first bit of the article I was really excited but of course there’s gopher crawlers now. Still, at least that opens up some ideas for ephemeral-rotating URIs that contaminate scraper databases.
I don't knock Gemini for existing and being a neat project, but even for hobby it seems too restrictive. No cookies means no authenticated interaction with a site, no inline images means it's less informative than a 100 year old encyclopedia.
Perhaps a "Simple Web" spec could be created to audit a site and verify its privacy and simplicity protections. Things like "Cookies only for auth", "No JS" or "low JS", "No ref tracking in or out", "No tracking pixels", etc.
You'd have to prove these things are possible in the face of the ingenuity of the entire adtech industry. The limitations you point out, on the other hand, have easy solutions:
What makes you think the adtech industry won't just embed ads in text if this becomes popular at all. You don't need any kind of technology for ads, only eyeballs.
Adtech isn't about showing ads. It's about targeting ads. And yes, if Gemini gets wildly popular maybe they'll think of something. Good problem to have! New mistakes instead of same old ones!
If you want to support cat pictures that show up without clicking a link, but prevent any behavioral exhaust from tracking pixels, that seems to be an open problem. Every new feature is like this: a risk surface until proven otherwise. So to reduce risk you have to limit features, i.e. jank.
The claim was, "Janky is the price you have to pay to avoid adtech", but adtech cannot prevent you from making a jank-less, universally accessible page or site about your cats or whatever you like. IMHO, one really can't be part of the solution if one's left the protocols mainstream for the digital equivalent of an off-grid cabin in the woods.
You're right from the perspective of a website author, but the original comment I responded to is from the perspective of the protocol designer. There is no known way to design a protocol that can be used to create polished experiences without also letting some ingenious website suck up behavioral data.
> One can still be part of the solution without leaving the modern-standards-based mainstream altogether for the digital equivalent of an off-grid cabin in the woods.
So many judging words there. A new protocol is an off-grid cabin in the woods, but building a non-janky universally accessible website isn't? You'll have to prove you can get a random new website more traffic over https without doing nefarious shit and letting the big adtech companies crawl it.
Astute observation. Gopher is in fact a portal that lets you teleport from one off-grid cabin to another, all around the world. And some people like that.
Authenticated sessions are supported using client certificates.
No inline images is a significant restriction indeed but it also gives you a high degree of confidence that most Gemini pages will be very lightweight. I don't find it that limiting. It all goes back to the point that Gemini is intended to supplement the web and not replace it - if you want image heavy content you can get it elsewhere. Personally I find the lack of inline formatting and links more frustrating.
No inline images is not a restriction of the protocol. It's a restriction of the text/gemini MIME content type, and of the browser implementations. A server can still respond with text/html content over the GEMINI protocol, with embedded <image/> data. The GEMINI protocol specification does not restrict what RFC2045 types can be used.
What exactly do you think you are proving? It doesn't matter what some spec theoretically allows, if you want to server something to gemini users it can't have inline images.
Nothing prevents a gemini browser from showing inline images (though it might be officially discouraged?). They are just links.
But actually loading images separately can work well. If you are reading for the text content you can save the time and bandwidth to load of all the images, or maybe you want to look at one image in detail, you can load just that one, and zoom or frame that independently of the surrounding text.
I do think it's a shame that Gemini doesn't have images and richer text, but maybe it would be even less popular/successful if it had those. Gemini won't be the last of these simple protocols so it's a useful learning opportunity.
My project at the moment is kind of related to these "simple web" ideas. Instead of giving up on HTML altogether I'm making a simple web browser, to see if there's a way to render even relatively complex existing pages, like Wikipedia or news sites, without needing to implement much or any CSS. A bit like "reader mode". (link if you are interested: https://codeberg.org/kaimac/weaver)
You can spin up a HTML-but-restricted XML grammar (with extra stuff even, like footnotes and stuff) and a CSS file in maybe half an hour, and it'll render in your browser just fine.
(Yeah, it'll be missing all the accessibility provisions, but you know, the base to build on is there, whereas "MarkDown in the browser" rendering has been often suggested and never implemented).
Inline images are a client implementation/styling detail. Some clients have it, but most don’t as most users don’t seem to want it. I believe Lagrange (the most “visual” browser) has this feature.
Finger was the original Twitter. We used to get updates on Quake's development from John Carmack by fingering his email. He used to write elaborate ".plan" files too, no nonsense character limits were in sight yet. It was magical. It worked like this:
No retweets, no likes, no notifications, no HN frontpage, but John Carmack kept writing them, and we kept reading. Even without any amplification dynamics, it was still engaging.I've tried the same now, 30 years after my last finger. It wasn't even installed on Ubuntu by default. I had to install it, and expectedly:
Finger still exists at sdf.org
A couple on shodan [1a][1b] Maybe we should make finger great again, but with TLS. fingers? Looks like there is a draft [2]
[1a] - https://www.shodan.io/search?query=finger+%2Bport+79
[1b] - https://www.shodan.io/search?query=finger
[2] - https://github.com/noveltylanterns/fingers
You can do this with ATProto / Bluesky! You can self-host your own PDS (or use Bluesky) and clients are super simple. I just had Google Search AI Mode vibe code as a 60 line shell script.
If you wanted to be more authentic to the original you could implement a custom Lexicon.Oh pretty please, if we revive this protocol, can we please pick a better name? Like, any name? Literally anything else, that doesn’t evoke weirdly sexual imagery?
Well I thought about it and if it's a body part there will be someone into that. Then I thought maybe poke, nope some are into that too. I guess maybe "status" port? Kindof like having an away message. It could be a fixed buffer as to not overlflow. Of course that could be accomplished in DNS using TXT.
Honestly I am too lazy to make an RFC. Maybe if enough people make a finger.domain.tld text record it would catch on. [1]
or replace the finger binary with a shell function: [2][1] - https://www.whatsmydns.net/#TXT/finger.nochan.net
[2] - https://blawg.nochan.net/b/Internet-Crap/20260527-DNS-A-Repl...
Your point is valid, but how do you feel telling your wife today I fingered Alice, and guess what she was up to?
Well that depends on the marriage. She might want to smell what Alice is up to.
radar? Since it's an active request response protocol.
Wait until you hear about USB condoms.
In my electronics class in high school we learned to strip and do joints.
We also learned the resister color codes via mnemonics.
"Bad Boys Rape Our Young Girls But Violet Gives Willingly, Get Some Now" Curious if they still teach that one. [1] Wikipedia says it is outdated / offensive but it was back then too.
[1] - https://en.wikipedia.org/wiki/List_of_electronic_color_code_...
Black Boys, since the first mnemonic letter is for the color black. And we didn't have Get Some Now, that feels redundant since everyone knows gold is better than silver.
Like fist?! Oh wait…
Glove would work
A glove is for the whole hand though. How about thimble?
Like the protection metaphor there, glove would be great for TLS finger!
Fingercot.
Any gopher client can do finger too:
Man, Gopher was part of my first internet experience. It felt so magical to basically explore a (seemingly) infinite file system. Found great servers that had all sorts of interesting stuff, and then would link to other interesting servers.
I still remember a book about the internet I got in the early 90s... it was a couple of hundred pages, and then in the last chapter there was one paragraph in a section about new technology for something called "the World Wide Web".
For years I would be frustrated at people who would conflate the internet and The World Wide Web. I gave up on that years ago, though.
Wrt finger I want to point out https://plan.cat as a nice service in this spirit.
Objections to Gemini that point out that nothing is stopping people from writing simple HTML miss the point.
It's not that HTML forces well-meaning creators to add complexity, size, or user-hostile behavior; it's that an ecosystem that permits such behavior eventually becomes swamped by adtech and other user-hostile content for financial gain. The problem is that this content drowns out organic, human-centric content.
Having said that, while format restrictions (to plaintext, markdown, gemtext, HTML without JavaScript) do help mitigate the damage somewhat by making tracking harder, I doubt they are sufficient: even text-only forums can become overrun with spam, ads, bots, and propaganda if they lack suitable moderation.
Ultimately folks who want to browse a web of authentic human content need to combine format restrictions with blocklists and web-of-trust tools. Browser plugins, reader mode, and customized search engines can already get us partway there, but there are still gaps.
This point gets missed by a lot of people.
You could theoretically have a web that does not bloat. HTML is a very good technology for building clean documents. You are not going to get that, though. What happens instead is that you start on a thoughtfully designed page and are always one click away from a cookie consent banner on top of an email capture modal beside four flavors of ad. "Sure, but you can install adblock/VPN/Pi-hole/reader mode/turn off JS/etc/etc..."
I like Gemini because it actually delivered a lightweight protocol that provides what I was looking for. Additionally, it is not just a technology. It is an ecosystem that gained more traction than the hundreds of other attempts that never went anywhere.
The spec made mistakes, but HTTP has mistakes too.
It's a good point, but I think the counter is that if the only people writing anything available via Gemini would have written nice simple HTML anyway, then not an awful lot is gained.
Sure, authors can adopt Gemini-like restrictions on their own simple HTML pages to gain some of the benefits of publishing with Gemini.
But this ignores the benefit for readers. Simple HTML pages are one link, search, or change of management away from a sea of enshittified internet slop. But Gemini capsules never have banners, unwanted sounds, intrusive ads, popups, etc, making browsing gemspace a qualitatively different experience.
To use a metaphor, a gardener can plant the same flowers alongside a loud, busy, trash-strewn highway as they can in a quiet garden. Many more people will see the flowers along the highway and it's a wonderful contribution. But wandering amongst the flowers in a peaceful garden is a qualitatively different experience than doing so alongside a busy highway.
Thats a big assumption. As Michael Goldhaber put it in the early days of the Internet - people have limited capacity to give Attention to anything but unlimited capacity to receive Attention. Scientists and technologists are not immune. And it shows up in what they cook up.
> Mozilla, which still maintains one of the only independent rendering engines (Gecko), is the only viable competitor. Everything else is Blink and Google.
Notably missing Safari and WebKit
WebKit isn't really independent - while it is technically opensource, it is effectively controlled by Apple. In fact, Apple were the ones who originally forked it from KHTML. They continue to be majority contributors and drive the product roadmap.
On the other hand, there's Ladybird, Servo and Chawan which are indie, and although they're still in alpha - depending on the sites you browse daily (like HN - which works fine), you might be able to use one of these as a daily-driver.
I was surprised by that omission in this blog as well.
https://gs.statcounter.com/browser-market-share
Safari makes up a sizeable percentage of the market share so skipping WebKit here is a strange choice.
I’d love to see CoAP/wg play a part here. It’s similar enough to HTTP to be familiar, but not supported in any browser. It supports content types and server sent events. It can be implemented in far less memory and uses far less CPU than TLS. It seems like the perfect protocol for this kind of thing.
IMHO Promoting lo-spec computing and text-based is always good, seems limiting but that's what I like about it. I tried fingering as the article says, but I only got a BRENNAN: no such user :(
oh goodness, sorry! I think you need to be SSH'd into tilde.pink
I definitely should have tested, I did not expect this to get on HN lol
edit: finger brennan@omg.lol works :)
I use a modified, "modern" text-only browser that compiles to 1.4 MB static binary after I remove some multilanguage encodings
I've been using this browser since around 2000. I think some HN commnters would be syrprised at how much of the www I can digest using this program. They wouldn't believe it was possible
I use localhost TLS forward proxies for HTTPS. Breaking TLS turns out to be an excellent method for blocking ads and telemetry, in addition to DNS and "ad blockers"
People like to pretend that Google and other so-called "tech" companies have killed off HTTP
It may be true depending on one's www usage, but I see evidence that HTTP still alive
When their "business model" is collecting data from and about unsuspecting computer users, it makes sense for these companies to want the transmissions encrypted. If users saw what is being sent over the wire to these companies they might be upset. If competitors saw it then they might use the data themselves. Too much data collection... I digress
There are bands of vocal "tech" workers who try to drown out any mention of HTTP. Others try to make fun of FTP
But both are still being used in a variety of places, whether it's by CAs themselves^1, Google, e.g., for autocomplete^2 or even the NY Times^3 or MSN
Anyway, the point is that these companies may try to kill off usage of certain protocols where it suits them, e.g., remember FTP in the web browser. But the protocols still survive and people still use them, even if it's only the "tech" workers themselves, and others in small numbers
1.
http://ocsp.globalsign.com/ca/gsatlasr3dvtlsca2026q2
http://secure.globalsign.com/cacert/gsatlasr3dvtlsca2026q2.c...
http://crl.globalsign.com/ca/gsatlasr3dvtlsca2026q2.crl
2.
http://clients1.google.com/complete/search?client=heirloom-h...
3.
via Fastly
https://raw.githubusercontent.com/rezmoss/cloud-provider-ip-...
With HTTP (cf. HTTPS) the user can easily control what is sent over the wire
I can monitor, filter and/or modify egress with a local network foward proxy, for example. I can neutralise or stop traffic I do not want to go to so-called "tech" companies based on its destination and contents, as opposed to "trusting" it simply because it's protected by HTTPS (including "protected" from review by the user)
This level of user control can interfere with the so-called "tech" company data collection, surveillance and ad services "business model"
*forward
The modern web very much goes by the Pareto principle. But what's almost impossible to digest without full-fledged machinery are some News websites. The complexity of running ads and gdpr flows is just out of this world. It even dwarfs social media websites in that regard.
Any specific examples to support this argument
It's a German website but zeit.de. At least the last time I checked. Looking into Firefox reveals almost 8 MB for loading the front page. One could easily skip this as an exception but it's one of the 2 large weekly news magazines in Germany. Also since it's part of a publishing house, I assume other publications of them might be using the same system.
Why is it that every gemini/gopher discussion throws out the baby with the bathwater?
> Chrome alone controls roughly 73% of global desktop browser market share.
> More and more, the webdevs of the world test and develop for Chrome only.
> It doesn't need to be this way. https:// is not the only way to connect and interface with the Internet
These are completely unrelated concepts! Google/Chrome doesn't control HTTP nor HTTPS. There is nothing wrong with the protocols, you can just make your website plaintext file if you like.
Google almost shipped a DRM for the whole internet in 2023, and they will try again
https://en.wikipedia.org/wiki/Web_Environment_Integrity
Yes that's absolute shit thing to do.
It's also on completely different OSI layer.
I don't see the difference between your comment and a statement like "I don't like email so let's stop using TCP".
Yes WEI operated between layer 5 and 7.
But the day your bank and insurance implement WEI, it'll going to be too late to switch to another protocol. Your existence will depend on it.
Honestly, I think at some point we will need something similar to WEI to ensure we’re interacting with other humans in a hostile AI internet.
Just like CAPTCHAs, WEI won't actually prove that you are a human, just that you are using an approved setup.
Before we ever come to this point I hope as a society we take a real swing as dismantling big tech. So much potential is being hoarded by literal dragons of progress.
You may be surprised to find out that the majority of gemini/gopher authors actually do have simple HTTP(S) sites. Some even have very complex HTTPS sites. Gemini and Gopher isn't really about getting rid of the WWW, it's about having a space that's entirely disconnected from it.
Why is it that every criticism of gemini/gopher throws the baby out with the bathwater?
When you browse to a pristine html page containing zero adtech it contains links. Those links you might click on without first thoroughly vetting them for behavioral exhaust.
Hyperlinks are a vector for contagion. A new protocol creates isolation. What's wrong with both existing? Defense in depth at all levels, I say. You think https can't enshittify, maybe you just haven't waited long enough.
> Particularly after Edward Snowden's 2013 revelations about mass surveillance, running an unencrypted protocol started to feel more and more like bad practice.
As far as i understood, NSA has access to the encrypted communication on the internet so all bets are off. They '"collaborate" with certificate issuers, they monitor all big internet nodes in the "west" and all relevant software is produced in their jurisdiction.
The certificate issuer doesn't have access to the underlying private keys, so while getting a fake certificate may be useful for MITM [0], undermining the certificate authorities doesn't actually allow spying on traffic that uses the genuine certs, no matter how corrupt the CA is.
There is such a thing as overestimating the power of the NSA, if the spooks actually had undermined the system to that degree they wouldn't need to lobby for all the surveillance bills that keeps popping up.
[0] And you can't get a fake certificate either without it being visible in the certificate transparency logs, or being an obvious fake since it is absent in those logs.
As a younger person I always see these discussions and I want an alternative to the modern web. But reading this I cant help but think "why are people so focused on building a web with none of the useful features". What use is any of this without a realtime component.
The largest disconnect between then and now, is the degree to which the internet was many things (telnet, ftp, usenet, finger, gopher, http, irc, mail, etc...), and not just webpages. Each with their own specific flavors. The article is trying to recapture that to a small degree.
Over time, almost everything has been compressed into this HTTP/HTML/JScript agglomeration. When the original thought was that there would be dozens of protocols for various uses, and a lot more client applications than the browser.
The best analogy I can think of is, imagine that plays(theaters), movies(bigscreens), novels(books), operas(concert halls), art(galleries), museums, etc... All disappeared in favor of delivering that content through games on your Xbox. All of that experience compressed into one method. Then the next generation says:
"Why would anyone miss physical art galleries? I can see art much faster on the 'Louvre 2026-season pass' on my Xbox? No travel, no walking, no lines."
That would be irc.
Also, the Unix “talk” command is a nice 1-to-1 chat protocol along the lines of finger, ie
$ talk snoopy@dog.house
...because a lot of us remember a web that was very useful already, without needing a realtime component? We did the realtime stuff over other protocols; the web was literally just a web of static hypertext documents.
In fact, even search engines were originally optional; various people and organizations used to simply maintain huge static directory service websites, simply listing out "everything else on the web" (or more often, just the parts the author thinks are cool.)
Yes but all of that sounds horrible to me. Nobody really wants web of static documents and to have everything split out into its own protocol.
Says who? I, for one, don't really like the idea of "everything is http(s)".
After all, dissatisfaction with the status quo is the reasons this space (gopher, gemini, etc.) even exists. If, like you say, nobody wanted this we wouldn't be here discussing it.
I have started to try and always develop Gopher versions of my sites for my research work. I try and promote that version especially to those who live in countries where internet access is costly relative to income or internet access is limited. Usually the key differences are diagrams become ASCII based.
Ugh, the table of gopher search results in this article is like seeing someone take a can of modern expanding spray foam and using it to repair an axle on a horse buggy. ‘We have an excellent old technology and we’re doing our level best to backport our modern torment nexus to it’, sigh. For the first bit of the article I was really excited but of course there’s gopher crawlers now. Still, at least that opens up some ideas for ephemeral-rotating URIs that contaminate scraper databases.
I don't knock Gemini for existing and being a neat project, but even for hobby it seems too restrictive. No cookies means no authenticated interaction with a site, no inline images means it's less informative than a 100 year old encyclopedia.
Perhaps a "Simple Web" spec could be created to audit a site and verify its privacy and simplicity protections. Things like "Cookies only for auth", "No JS" or "low JS", "No ref tracking in or out", "No tracking pixels", etc.
You'd have to prove these things are possible in the face of the ingenuity of the entire adtech industry. The limitations you point out, on the other hand, have easy solutions:
* auth: Look at https://github.com/kr1sp1n/awesome-gemini#services Tons of services support some form of auth.
Edit: https://martinrue.com/station is another service I use that's missing in the above list.
* images: click to load
Janky but doable. Janky is the price you have to pay to avoid adtech.
What makes you think the adtech industry won't just embed ads in text if this becomes popular at all. You don't need any kind of technology for ads, only eyeballs.
Adtech isn't about showing ads. It's about targeting ads. And yes, if Gemini gets wildly popular maybe they'll think of something. Good problem to have! New mistakes instead of same old ones!
> Janky is the price you have to pay to avoid adtech.
I don't understand, unless adtech is holding your family hostage and forcing you to adtech. Can you elaborate?
If you want to support cat pictures that show up without clicking a link, but prevent any behavioral exhaust from tracking pixels, that seems to be an open problem. Every new feature is like this: a risk surface until proven otherwise. So to reduce risk you have to limit features, i.e. jank.
The claim was, "Janky is the price you have to pay to avoid adtech", but adtech cannot prevent you from making a jank-less, universally accessible page or site about your cats or whatever you like. IMHO, one really can't be part of the solution if one's left the protocols mainstream for the digital equivalent of an off-grid cabin in the woods.
You're right from the perspective of a website author, but the original comment I responded to is from the perspective of the protocol designer. There is no known way to design a protocol that can be used to create polished experiences without also letting some ingenious website suck up behavioral data.
> One can still be part of the solution without leaving the modern-standards-based mainstream altogether for the digital equivalent of an off-grid cabin in the woods.
So many judging words there. A new protocol is an off-grid cabin in the woods, but building a non-janky universally accessible website isn't? You'll have to prove you can get a random new website more traffic over https without doing nefarious shit and letting the big adtech companies crawl it.
Astute observation. Gopher is in fact a portal that lets you teleport from one off-grid cabin to another, all around the world. And some people like that.
Authenticated sessions are supported using client certificates.
No inline images is a significant restriction indeed but it also gives you a high degree of confidence that most Gemini pages will be very lightweight. I don't find it that limiting. It all goes back to the point that Gemini is intended to supplement the web and not replace it - if you want image heavy content you can get it elsewhere. Personally I find the lack of inline formatting and links more frustrating.
No inline images is not a restriction of the protocol. It's a restriction of the text/gemini MIME content type, and of the browser implementations. A server can still respond with text/html content over the GEMINI protocol, with embedded <image/> data. The GEMINI protocol specification does not restrict what RFC2045 types can be used.
* https://geminiprotocol.net/docs/protocol-specification.gmi
* https://iana.org/assignments/media-types/media-types.xhtml
What exactly do you think you are proving? It doesn't matter what some spec theoretically allows, if you want to server something to gemini users it can't have inline images.
Nothing prevents a gemini browser from showing inline images (though it might be officially discouraged?). They are just links.
But actually loading images separately can work well. If you are reading for the text content you can save the time and bandwidth to load of all the images, or maybe you want to look at one image in detail, you can load just that one, and zoom or frame that independently of the surrounding text.
I do think it's a shame that Gemini doesn't have images and richer text, but maybe it would be even less popular/successful if it had those. Gemini won't be the last of these simple protocols so it's a useful learning opportunity.
My project at the moment is kind of related to these "simple web" ideas. Instead of giving up on HTML altogether I'm making a simple web browser, to see if there's a way to render even relatively complex existing pages, like Wikipedia or news sites, without needing to implement much or any CSS. A bit like "reader mode". (link if you are interested: https://codeberg.org/kaimac/weaver)
How about:
- no scripts of any kind
- no cookies
- no forms
- all resources (e.g., styles, images) needed for display inlined
- a spacious minimum cap on data URI length
- elaborate the <a> tag a bit to allow a series of content addresses (hashes, IPFS, magnet URIs, etc.) for references
Basically, a "dead" subset of HTML suitable for distributing documents.
I keep writing the same comment every time this is brought up, but browsers need to support text/markdown.
You'll need to be more specific since there are many variants of Markdown and the original explicitly permits arbitrary html.
CommonMark is pretty standard (even if not perfect) and you're in the browser anyway so arbitrary html is not really a problem..
Umm, see what problem this thread is trying to solve using markdown.
Technically depending on the implementation, markdown is a superset of HTML.
Markdown? Terrible "spec".
Browsers already support XML.
You can spin up a HTML-but-restricted XML grammar (with extra stuff even, like footnotes and stuff) and a CSS file in maybe half an hour, and it'll render in your browser just fine.
(Yeah, it'll be missing all the accessibility provisions, but you know, the base to build on is there, whereas "MarkDown in the browser" rendering has been often suggested and never implemented).
Inline images are a client implementation/styling detail. Some clients have it, but most don’t as most users don’t seem to want it. I believe Lagrange (the most “visual” browser) has this feature.
It's https://smolweb.org/
Sooner or later "inline images" == "advertising".
And "tracking pixels".
Keeping them separate was a smart move, and entirely consistent with the underlying philosophy.