# Re: Perceived Relations Between Gopher, Gemini, and HTTP (Len) ## My waste-of-time rant (created by jr@sawv.org on Mon, Feb 1, 2021 and updated on Mon, Feb 8, 2021) I need to stop wasting time pondering the thoughts of people who criticize Gemini, since their arguments will not persuade Gemini users from ending their usage of the protocol. In fact, their discussions of Gemini may introduce new people to the protocol who may become interested in using it. This is the positive of criticisms. The complaints about Gemini seem to focus on two main topics: The Gemini spec is too small and rigid, and why not use a subset of http and HTML instead of creating a new protocol? Today, I read the following post, and initially, I created my post as a reply to Len's comments, but I've gone off the rails again. => http://len.falken.ink/web/perceived-relations-between-gopher-gemini-and-http.txt Excerpts from Len's post: > https://gemini.circumlunar.space/docs/faq.html > > This website is declared to be the HQ of the "movement". I say movement because that's what it feels like to me when people talk about it. I want to heavily emphasize that this is my *perception*. I've asked others and it appears this perception is accurate. When it comes to Project Gemini, that's a new word for me: "movement." Of course, I only discovered Gemini in May 2020. I consider Gemini to be a new document-based, application layer protocol, which it is. That's all that it is. It's an application layer protocol to be used or ignored. More from Len about what he read on the Gemini FAQ page: > I have a problem with this because it turns a technical idea into a manifesto, attaching a political tone to what's just a hobbyist protocol at the end of the day. It's off-putting to those who want to explore a technology, and I believe this is what hurts Gemini the most, other than the fact it's currently niche. Those are more new words for me when it comes to Gemini: "manifesto" and "political." Like "movement" above, I have never observed anything political or manifesto-ish about Gemini. I would use words like fascinating, interesting, curiosity, passionate, useful, and easy. One person's interesting passion is another person's political manifesto. Many people who became curious about Gemini decided to use their skills to create Gemini servers, clients, and tools in many different programming languages. If people enjoy hacking on personal projects, then that's usually a good thing. > As technologists, and humans, it's important to consider our moral obligations. So if the expressions above are not politically focused, but morally focused, what about the statements where the technology is actually accessible by the public, the non-tech savvy? I suppose that all non-mainstream protocols and concepts are considered movements, manifestos, and political in tone, such as the IndieWeb, Scuttlebutt, ActivityPub, Mastodon, IPFS, Solid, etc. Passionate users of those ideas may annoy others who are disinterested. Was TBL's new web project viewed this way 30 years ago? solderpunk announced Project Gemini in June 2019. The web was created around 1990, give or take a year. How accessible was the web to non-tech savvy people in 1991 or 1992? It should not be a surprise that Gemini supporters are trying to create ways to make it easier to create and update content. Last fall, I started on my own project that I call Kranz. It's my own set of custom client and server apps that let me edit locally on my laptop and push to the server. I need to do more work this winter and spring, especially on creating a GUI-based desktop client. At the moment, my Kranz client app is a command-line utility. For now, however, I continue to manage my Gemini content by using the web. I use one of my web-based static site generator apps to create .gmi files. No rule exists that says Gemini users cannot use the web. I modified my Sora web-based SSG to work better with Gemini. I'm creating this post by using this setup. I'm using my JavaScript editor and my web-based API that my Sora-Gemini app provides to update the content on the server. I would like to replicate this simple JavaScript writing environment as a desktop GUI for my Kranz client-server setup. Others have also created web-based CMS tools to manage Gemini content. In my opinion, for an application layer protocol that has only existed for 1 year and 19 months, a lot of programming activity has occurred. Personal web publishing today still contains an admin tax that deters many from maintaining their own websites. Domain name leasing, CMS hosting or server hosting, moderating comments if accepting comments, etc. If server-hosting, then that requires securing the server, installing and updating a CMS, possibly installing a database and a caching server. Most non-tech people have no interest in being sys admins, database administrators, security gurus, computer programmers, nor web designers. How many non-tech people could use Amazon Web Services to manage domain names and DNS, setup an S3 bucket or an EC2 server and cache their content with CloudFront? Other easier-to-use setups exist for managing personal websites with a unique domain names, but again, most people have no interest in taking this route on the web. Len glossed over the very real admin tax that exists with personal web publishing. => https://sawv.org/2019/04/01/the-admin-tax.html => https://indieweb.org/admin_tax From that indiweb.org post: > Examples of admin tax: > > * DBA tax > * renewing your domain names > * renewing https certificates > * paying bills (for web hosting, domain registrars) > * updating software > * removing spam > * blocking spammers Even some tech people don't want to incur an admin tax at home when publishing personal content to the web. This is why most people prefer to use the siloed platforms, since the silos made it easy to post content. The admin tax is nearly non-existent when using the silos. The platforms manage the technical details. Obviously, people who want to publish on their own personal websites could skip leasing domain names and use free CMS-hosting services. Some people still maintain their personal websites with URLs like https://myname.blogspot.com. The IndieWeb.org community started around 2010. Their main concept is to encourage people to maintain their own personal websites, post new content to their websites first, and then optionally syndicate their content elsewhere, such as to the silos. The IndieWeb acknowledged years ago that some of the newer IndieWeb concepts were difficult to implement by non-tech savvy people. => https://indieweb.org/generations > Generations in the context of the IndieWeb refer to clusters of potential IndieWeb adopters in a series of waves that are expected to naturally adopt the IndieWeb for themselves and then help inform the next generation. Each generation is expected to lower barriers for adoption successively for the next generation. From the graphic: * Generation 1 = Development Leaders * Generation 2 = Journalists and Bloggers * Generation 3 = Personal Domains Managed by 3rd Parties * Generation 4 = People Using Social Networks The number of people contained within each generation increases with each succeeding generation. Obviously, the people discussing, building, and promoting IndieWeb tech concepts is a lot smaller than the people who use siloed platforms. Ideally, each generation makes it easier for the next generation to use the IndieWeb/open web ideas. People can choose how many, if any, of the IndieWeb concepts to implement, such as Webmentions, Micropub, IndieAuth, and more. But those tech ideas are not required. Maintaining a personal website and doing nothing else supports the IndieWeb. => https://indieweb.org/IndieWeb > The IndieWeb is a community of individual personal websites, connected by simple standards, based on the principles of owning your domain, using it as your primary identity, to publish on your own site (optionally syndicate elsewhere), and own your data. But that basic idea still requires an admin tax, such as leasing a domain name, maybe DNS management, funding a CMS-hosting provider, fiddling with CSS or themes, and maybe more. That does not sound like much to me, but it's too much for most non-tech people. The IndieWeb or the open web has not made personal publishing as simple as posting to Facebook, and the web has existed for 30 years. Why would anyone expect personal publishing on Gemini to be accessible to non-tech people when Gemini has existed for only 19 months? Feb 5, 2021 Hacker News comment: => https://news.ycombinator.com/item?id=26035536 > Can't a person write interesting stuff on Medium/Blogspot/Wordpress? Telling a person, who wants to blog about fruit preserves, to learn php and selfhost is a bit too much. I like Len's text-based personal website setup, but telling someone who wants to write about fruit preserves to manage the site by running command line scripts on Linux to create plain text files like Len does is a bit too much. Again, I have no issues with reading plain text .txt files over the web or Gemini, but Len and I are in a minority of a minority of a minority, so small that we don't register. More from Len's post: > How can I trust a Gemini link won't serve me some malicious binary, or an HTML page (requiring a web browser once again), or the, Gemini server won't track my IP? The answer is you can't guarantee any of these. The following section will explore this further. For Gemini, I mainly use the Kristall Gemini browser, and it informs me if a link points to a different protocol. In a Gemini post, if I dropped in a link that pointed to my website, Kristall adds the "[HTTPS]" text. Creating the link with Gemini text: ``` => https://sawv.org My sawv.org website ``` Kristall displays it like this: ``` -> My sawv.org website [HTTPS] ``` When using a command-line Gemini browser that only supports the Gemini protocol, a link that points to another application layer protocol does not work. BTW, the Kristall INTERNET browser also supports Gopher, Finger, and HTTP/HTTPS, although Kristall only supports basic HTML, which is nice. Kristall could be used as a "Small Web" browser. > How can I trust a Gemini link won't serve me some malicious binary ... I have not read any statements about Gemini that claim that the protocol is foolproof against careless people installing malicious code on their desktop and laptop computers. A user would have to click the link on the Gemini site and then decide whether to save the file locally and then decide to execute the file. With Kristall, I can mouse over the link and view the URL at the bottom of the Kristall browser, like what occurs with most web browsers. In recent days, I installed the latest version of the Molly Brown Gemini server that I have been using since last spring. I needed to update my config file to work with the new server. When I tried to execute one of my CGI apps, Kristall said that MIME type was application/octet-stream, instead of text/gemini. After I modified the Molly Brown config file, then my CGI app worked. With MIME type application/octet-stream, Kristall said that I had to safe the file my file system, which I did not do. This seems like an adequate protection against executing binary files locally, assuming the files will work locally. I made this test. I created a hello-gemini.c file and compiled it into an executable that I renamed to hello-gemini.gmi. I placed the file in docroot at my gemsite. => gemini://sawv.org/hello-gemini.gmi When executing that program from the command line on the server, I see the following. ``` $ ./hello-gemini.gmi Hello, Gemini! ``` Results from executing the "file" command. ``` $ file hello-gemini.gmi hello-gemini.gmi: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xf98bfde80630641142224d3d1a3c80843fac1bf6, not stripped ``` When I access gemini://sawv.org/hello-gemini.gmi within the Kristall internet browser, Kristall displays nearly the same jibberish as seen when executing the "cat" command on that file from the command line. More from Len: > ... or the, Gemini server won't track my IP? I think that every server will know or could know the IP address of an incoming connection. If IP tracking by servers is a concern, then it will be nearly impossible to use any client-server setup on the internet, unless some kind of client-side IP address masking is used. Cookies, client-side JavaScript, and browser fingerprinting don't exist in Gemini, making Gemini much safer for READERS to use than the web, especially since Gemini requires TLS while it's still an option with the web. Sure, solutions exist to make reading on the web more secure and private, such as disabling JavaScript, blocking third-party cookies, blocking other crapware, or by using browser plug-ins and extensions to restrict the nefarious actors. I always think of that great comment that I read in a Hacker News thread that said: > I love how browsing the web now is like gearing up for war. => https://sawv.org/2019/05/13/complex-bloated-web-design-described-in-13-words.html When using the web, how many non-tech savvy web users "gear up for war" to provide themselves the best protection? The best solution, at least for web reading, is to use the Links2 web browser. If sites fail to function with Links2 for READING, then those sites are not worth using. Web apps is a different story. I choose Links2 over other limited web browsers that are text-based because Links2 provides an adequate graphical interface, working easily with a mouse. And Links2 can show embedded images if the reader desires. When I read a Gemini post that contains a web link, I will check to see how the website functions within Kristall. If the website is too complicated for Kristall,then I will open the site with a "real" web browser, such as Pale Moon. That's not a difficult process for me, but I agree that it could be too much effort for non-tech users. How many silo users maintain accounts on multiple social media platforms and use mobile apps for each of those services? Is it possible to view Tik-Tok content within SnapChat? Can people use Twitter to reply to Facebook posts? A Gemini browser is one more app. What percentage of internet users have more than one web browser installed on their computers, including mobile devices? > On the technical side, Gemini is presented as a do-it-yourself, high power-to-weight ratio, privacy conscious, simple protocol. After personally reviewing the protocol, my professional opinion is yes, it is, minus the fact you need TLS (secure connection). Len's website does not support TLS. I like that Gemini requires TLS. If personal site publishers do not wish to incur the admin tax of managing certificates, then they can use the web or Gopher. Web-based CMS-hosting providers will probably manage the certificates for the users, removing that admin tax. Recently, I switched from using the Let's Encrypt cert for my Gemini site, since the Let's Encrypt cert expires every three months. For my Gemini site, I chose to create a self-signed cert that is set to expire in 10 years. Within the Gemini community, self-signed certs are suggested over relying on certificate authorities. The Kristall internet browser warns me when a certificate for a website or a gemsite has changed, and in order to view the content, I need revoke the old cert and refresh the page. This is all done within Kristall's point and click menu system. It's easy to do, but it's a step that I prefer not to do. The self-signed certs with long expiration dates will prevent this small annoyance. Len discusses Gemini's alleged shortcomings. > The most glaring is that the Gemini specification itself is not stable. Again, Gemini started in June 2019. From what I have seen, the spec has changed little, since I discovered Gemini in May 2020. They added the blockquote feature to Gemini text. A couple things were changed on the server-side, I think. Over the past several months, many people have requested new features be added to the Gemini spec, and I'm glad that solderpunk has rejected most of the suggestions. I don't understand why people want to make a new document-based application layer protocol more like the web when the web already exists. If people desire a Small Web, then they should create a movement with a manifesto and a political tone where they instruct people to build websites that work in Links2, meaning no CSS, no JavaScript, and no HTML5. Think of the browser diversity the Small Web would enjoy. I also like to use the GUI-based NetSurf web browser. It does not support JavaScript. It supports CSS2 and HTML4 and maybe a smidgen of CSS3 and HTML5. That's Small Web with some aesthetics if that kind of thing is desired. All websites look the same to me when I use Links2. I wish that NetSurf had an option to disable CSS for specific sites, since some sites display blank with JavaScript disabled, but their content will display if CSS is disabled too. Frigging modern web design is ruining the web reading experience. Len describes how user tracking can occur with Gemini, and to be honest, I don't understand his example. Excerpts from Len's User-Tracking section: > The user bookmarks any of the preceeding Gemini URLs. The user is being tracked each time they visit the URL, and can be across Gemini domains. Across different Gemini websites? I don't understand the ID thing and how it gets attached to each link on one's server, unless every Gemini page is dynamically created. I possess enough technical knowledge to create my own client-server app for managing Gemini content, but I cannot understand how Len's user-tracking example works on Gemini. First of all, gemini://google.com does not exist, and it's not a leap to say that it never will. Because of Gemini's self-imposed limitations, Gemini will be unattractive to corporations. Anyway, I have to be overlooking something obvious, regarding Len's user-tracking URL example. I do know that ads.txt is not a "thing" on Gemini, like it apparently is with the web. => https://sawv.org/2020/05/18/til-adstxt.html > As of March 2019, a minor version update to the IAB Tech Lab's ads.txt specification version 1.0.2 is available for industry adoption. Ads.txt specifies a mechanism for publishers to list their authorized digital sellers, in order to fight against fraud and misrepresented domains. Version 1.0.2 now details how publishers can indicate if they do not authorize any sellers. More excerpts from Len's post: > After taking a good look at Gemini and Gopher a few months ago, to finally inform myself what all the talk was about, I was left with feeling that all this is just a pointless, feel-good, righteous endeavor. I wonder if anyone thought the same thing about TBL's little web invention 30 years ago. And again, couldn't every hacking project in the beginning be ridiculed by someone else as being a pointless, feel-good, righteous endeavor? When a hacking project generates enough interest from people who build Gemini-related software, manage Gemini sites, and hold discussions on the listserv, how is that bad? Who is harmed by this activity? Gemini ankle-biters seem to resent the fact that some people find a new application layer protocol fascinating. What's wrong with having more choices for hosting content on the internet? I don't understand why some people seem to believe that we should have only one document-based application layer protocol that is basically managed by huge businesses for their own interests. From a hacking perspective, this kind of anti-diversity thinking is unfortunate. > Gemini is essentially Gopher, minus the cool search request feature, with yet *another* Markdown variant nailed onto the side of it, and a grating of HTTP flakes on top. That's a disingenuous observation of Gemini. In my opinion, Gemini is easier to use and nicer to read than Gopher. It's more secure than the web, and that's a fact, despite Len's user-tracking example, since far worse can be done with the web. Most or nearly all Markdown variants extend Markdown. Gemini text is much smaller and more limiting than Markdown. Despite it's smallness, Gemini text works perfectly for me, since I realized that on a regular basis, I only used a small amount of Markdown's features on the web. From a technical perspective, I don't understand Len's statement about "a grating of HTTP flakes on top." More from Len's post: > Finally HTTP is the most flexible of the bunch: it can be made to do all the above and more. Obviously it's the heaviest. The web is the heaviest. That's an understatement. > The argument which is then made (and acknowledged by the FAQ) is: *why not just use a subset of HTTP?* And the reason was answered well in the FAQ. More from Len: > It seems the answer boils down to enforcement. I don't see why this is a problem though, because people need to force themselves to use Gemini clients. There would be less friction if browsers had a "subset" enforcement option, which takes advantage of the fact HTTP / HTML is everywhere. On day one there would be thousandfold more users of the "HTTP subset" than the entire Gemini user-base. Uh, okay. Who would use this HTTP subset? Me, Len, and a handful of other HN users. That's about it. Even IndieWeb.org users like to use more web than that. I doubt that a subset-web would attract a huge audience. It might have some initial, curiosity interest, but then after a while, people would drift back to the normal, bloated web. And like many have suggested elsewhere, nothing stops us now from using the Small Web (HTML 4.x, no JavaScript, and little to no CSS). The problem is still discovery, and most non-tech people prefer silos, instead of writing on their own personal websites. It's easier to create a new application layer protocol with new clients and servers than petition Google to add Small Web support to Chrome. Google dropped its beloved feed reading app years ago. Why would Google do anything that does not help them earn more revenue? Len: > The system I host this blog on uses a subset of HTTP / HTML so simple that it basically mimics exactly what Gopher does: the main page is a directory listing done with RSS / Atom, and each entry is something to download. I've opted to stick to plain text for most of my content, but if I wanted to, I could serve svgs or pdfs or anything. This means the entire system just boils down to HTTP GET, some basic XML, and nothing else. It's as simple as Gemini without being Gemini, and structured as Gopher without being Gopher. From another post by Len: => http://len.falken.ink/misc/writing-for-the-internet-across-a-human-lifetime.txt > This is MY writing platform. Mine. Me. There is no way to censor or revoke my power. > http://len.falken.ink is an RSS feed of my writing which never has to be visited twice. With an RSS reader, readers only need my URL to begin receiving my posts, and at any time, can revoke their subscription on their terms. I like Len's website and his thinking behind it. Len's homepage is his RSS feed, which is a unique setup. Could Len's text-based approach to web design be considered a pointless, feel-good, righteous endeavor? Yep. For Len, his site design is a righteous endeavor. And since it's his personal website, then he's in control, and opinions from others about his design don't matter. With my old iPhone, however, I cannot view Len's homepage, since iOS wants to launch Apple News, which won't permit me to enter feeds. I would have to use a native feed reading app or create an account with a web-based feed-reading service to view Len's homepage. That seems like a lot of friction. Why not create a simple homepage of ... LINKS? Linking was one of the web's best early features. In Len's above post about Gemini, Len said: > ... people need to force themselves to use Gemini clients ... Yet his personal website shuns a basic, Small Web-like convention of providing links. What if people don't want to use feed readers? Why force people to use feed readers? Gopher offers more features than Len's web design. Gopher provides plain text but with linking. More from this other post by Len about his publishing method, which I do like a lot. > Now maybe you wonder what this system is composed of. No problem I say, check this list: ASCII, sh, awk, grep, find, cd, mkdir, head, tail and editor. That does not sound very accessible to non-tech savvy people who might want to maintain their own simple websites. My post about Len's publishing method. => https://sawv.org/2020/11/04/using-plain-text-for-internet-publishing.html I would choose Len's plain text approach to web publishing over modern web design, which is probably a reason why so many of us are interested in Gemini. Gemini is a slightly more enhanced and more secure version of what Len uses. Len's conclusion about Gemini: > As soon as some entity decides to release some HTTP subset enforcement mechanism (browser extension, browser update, whatever), Gemini has no reason to exist. I think Gemini is the mind child of someone who just had some time on their hands to create a "what-if" scenario, and you know what, I'm glad they did create it. It has led to conversations like this, and hopefully leads to the HTTP subset enforcment a lot of us technologists desire! So thank you Gemini for that. Gemini would have no reason to exist??? Why couldn't Gemini and Gopher continue to exist even after the great HTTP subset is released? And wouldn't critics ask why the HTTP subset enforcement thingy needed to be created when the normal web already exists? In my opinion, the Subset Web, Small Web, Safe Web, modern web, Gopher, Gemini, etc. could all exist at the same time. I applaud people for creating new ideas, regardless of the number people who use the tech. > As soon as some entity decides to release some HTTP subset enforcement mechanism (browser extension, browser update, whatever) ... But that's the problem. This HTTP subset with an enforcement mechanism does not exist, and it probably won't exist. The best idea is the one that gets implemented. Gemini wins over Len's HTTP subset fantasy. Others will say that this HTTP subset with enforcement can be achieved now by "gearing up for war" by using modern web browsers with uMatrix and other extensions or by using a limited web browser, such as Links2. It's amazing how fast our internet connections are and how fast the web is when reading the web with Links2. When the Small Web and the Slow Web Movement catch on, then I might be excited about the web again. For now, Gemini has my attention. Corporations and professionals can continue to own the web, while Luddite-leaning amateurs and hackers who want to read and write can use Gopher and Gemini. That sounds like a win-win. On the web, why should a community site like Ravelry exist when Facebook, Reddit, and Instagram exist? Ravelry caters to the fiber arts and crafts, such as knitting and crocheting. Why should Ello continue to exist when Instagram exists? Ello is used mainly by graphic artists. I hope Len not advocating for the homogenization of the internet. ### Etc. Also posted today, Feb 1, 2021, at Hacker News. "gemini:// space (spwhitton.name)" => https://news.ycombinator.com/item?id=25986378 => https://spwhitton.name//blog/entry/geminispace/ The HN thread now has over 150 comments. From the spwhitton.name post: > Recently I have become curious about the Gemini Project and the content that people have made available to be retrieved over the gemini:// protocol. I'm not convinced by the arguments for not just using http, and mostly it's just that I typically find more things that I am interested in casually reading through on people's gemlogs than I would on, say, reddit, and similar aggregators. That might be the biggest hangup that I see for some critics of Gemini: Why not use a subset of http and HTML? The answer is probably because nobody or hardly anyone is using a subset of http and HTML. And what would the subset be? Is Google's Accelerated Mobile Pages a subset of the web? Regardless of what web subset was chosen, people would want more features added to http and HTML. Then more features would be requested. HTML 4.x might not be good enough. People might clamor for some HTML5 features. No CSS could be too restrictive. The community would decide to use CSS2, but many could view this as unacceptable. Some people might demand some CSS3 features. And so on. As I mentioned earlier in this post, it seems easier to create a new, small, document-based application layer protocol from scratch than it is to get agreement on what defines a subset of http and HTML to support the Small Web. Using the Links2 web browser creates a Small Web browsing experience immediately, at least for most web reading. More from the post: > I'm remaining open minded about the possibility that having a completely separate protocol is important, and not just an annoyance because rss2email doesn't work and I had to spend time writing gmi2email. I don't understand how Gemini can be an annoyance if people choose to ignore it. The author created a program to work with Gemini content. Isn't that called hacking? Since when did hacking on new things become an annoyance? It sounds like the author suffered some kind of hardship because the author wants to read content on Gemini, but the author got perturbed because the author had to create a script to permit the author to consume content in a desirable manner. The author shared the code, which may be useful for other Gemini users. This sounds like open source hacking, which is great. Kudos to the author. I agree with this statement from the author of that post. > There is, perhaps, a positive psychological effect induced by making the boundary between text/gemini and the web as hard as it is made by using gemini:// rather than http. Yep. I like the separation. I also like how it's easier to control the typography on the client side with Gemini than with the web. On Gemini, site authors focus on creating content and not creating user experiences. Most document-based websites built with modern web designs offer hostile reading experiences. It's not the 1990s anymore. I'm no longer interested in quirky web designs on personal websites. I'm interested in the content. Gemini focuses on content more than the web. More from the author: > Something about which I find myself much more sceptical is how the specification for gemini:// and text/gemini is not extensible. Good. That's a feature of Gemini. If people disagree, then they can choose not to use Gemini and continue to use the web, or they can build their own document-based application layer protocol. I'm thankful that solderpunk is keeping Gemini small and not webifying Gemini by adding too much cruft. As mentioned by many, Gemini is closer to Gopher than the web. Maybe the comparisons to the web should end, since it's truly an apples-oranges comparison. Gemini is a slightly enhanced version of Gopher, and Gemini has no similarities with the web. If the Gemini documentation removed references and comparisons to the web, then maybe this would eliminate the boring, over-used suggestion of using a subset of http/HTML. Gemini is like Gopher and not the web. The conclusion of the author's post: > Advocates of Gemini have this idea that they can't include, say, a version number in the protocol, because the extensibility of the web is what has led to the problems they think it has, so they want to make it impossible. Now on the one hand perhaps the people behind Gemini are in the best position that anyone is in to come up with a spec which they will finalise and render effectively unchangeable, because a lot of them have been using Gopher for decades, and so they have enough experience to be able to say exactly what Gopher is missing, and be confident that they've not missed anything. But on the other hand, Gemini is one technological piece in attempts to make a version of the Internet which is healthier for humans - the so-called "small Internet" movement - and maybe there will be new ideas about how the small Internet should be which would benefit from a new version of the Gemini specification. So it seems risky to lock-in to one version. People "think" that the web has problems??? Yes, solderpunk, the creator of Gemini, is also a Gopher user. I setup a test Gopher site back in 2016. => gopher://sawv.org But I did not continue to use it. I preferred a lightweight web over Gopher. But Gemini, however, is a different story. In January of 2019, I created a test site that only used Markdown and not HTML, except for the homepage. Web browser users would need a Markdown viewer extension to view the site. => http://md.soupmode.com/home.md The Markdown viewer browser extensions permit users to choose a theme, or users can upload their own custom CSS. I became fascinated with Gemini the first time that I read about it. I never thought to create a separate application layer protocol. And I'm fine with the Gemini spec being finalized as is. I don't see what else is needed for reading. On Gemini, creating and updating content requires more effort than blasting a senseless thought on social media, but maybe we should slow down. Gemini supports the Small Internet and the Slow Internet Movement. And once again, the people who disagree with solderpunk should take inspiration from Project Gemini and apply their own ideas toward creating a new application layer protocol. I like simple HTML forms, such as the text area box, text input fields, checkboxes, radio buttons, select-pulldowns, and the default buttons for HTML forms. In olden times, browser users completed the forms, clicked the submit button, and the data validation was done by server-side code that returned a dynamically-created HTML page. Actually, I still use this setup in my web apps because it's easy for me to build. Today, entering a username and password for logging into a website is its own sophisticated web application that cannot function without JavaScript. How is this progress? 20-plus years ago, we didn't need client-side JavaScript to accept user input. I think that servers are more powerful today than in 1996. I think that our internet connection speeds are faster today than in 1996 for most people. And I think that our personal computers are faster today than in 1996 for most people. How is server-side processing less desirable today when it was the norm in the mid to late 1990s for web applications? The two things that I miss the most about Gemini are the lack of simple form fields and the POST request, but since reading will occur more often than writing, then I'm fine with the Gemini limitations, and I don't want to see the Gemini spec webified. I can create content on my local laptop computer with Vim or Typora, and then I can SFTP the content to my Gemini server. That's the drop-dead simple, lo-fi approach. I may end up doing this if I don't like using my Kranz client-server setup. Or I may continue to use the Gemini-flavored version of my Sora web-based SSG to manage my Gemini site. It's not like I'm going to stop using web browsers. Obviously, this approach requires both a web server and a Gemini server, but it enables me to edit on nearly any computer device. I continue to edit this post by using my JavaScript editor within the Gnome Web browser and by posting my content to my Gemini-Sora SSG. Maybe some Gemini users believe that they will never use the web again, but that's not me. It's possible that I could start posting new content to my Gemini site first and then copy it to my website. Or maybe I stop posting to my website and only post to Gemini. In the future, my website could contain a note and a link about visiting my Gemini site. But I will continue to use the web for other functions, and I will continue to read the web too. More of my reading time, however, could be consumed by Gemini. Here's the top comment in that HN thread: > I really like the idea of having a more bare-bones text-only web, but I can't get onboard with Gemini until it offers the same support for screenreaders as HTML. (For example, an equivalent of span lang=XX tags is missing, so if you quote a foreign-language word(s) in your text, you can't let screenreaders know what language to read it in). The visually impaired should not be second-class citizens in any new internet community. Supporting multiple foreign languages within a single post. Did the web offer that support in 1991 or 1992? Multiple foreign languages on the same page is obviously useful for some people and some applications, but that seems like a strange reason not to investigate Gemini more. Maybe if the person got involved in the Gemini community, then his or her ideas on this subject could get implemented. I guess that it's better to run away and complain than to get involved and try to implement the desired change. Here's a reply comment, located well down in the thread. > As a screen reader user, automatic language switching is the first thing I disable. A lot of HTML templates just include 'lang="en"', and developers rarely notice that, even if their website is in another language. > I find Gemini pretty accessible overall. There are no images, so including alt descriptions isn't even a concern. There's no CSS, so you can't make controls that visually look like check boxes, but are much less accessible. In fact, it's way harder to make an inaccessible Gemini site than to make an inaccessible website. The only gripe I have is the possibility to introduce ASCII diagrams, which usually aren't accessible. Naturally, some in that HN thread promoted the idea of using a subset of http/HTML, instead of creating a new application layer protocol. And the comparisons to the web were mentioned. But this comment was helpful: > A big part of the reason is Gemini was developed by people interested in Gopher, acknowledged the short comings of Gopher, then thought of solutions in the context of Gopher. Gopher does not support TLS. solderpunk wanted a slightly enhanced and more secure version of Gopher. I'm more convinced now that the Gemini docs should remove comparisons to the web. One HN user refused to accept the realities and rationale for Gemini, regardless of how often other users tried to explain why Gemini was created. The stubborn HN user kept promoting some kind of web subset. > I do not buy it. Just use gemini:// rather than https:// to refer to that specific subset of https html. Maybe also add a header to the server response that says x-gemini: true or whatever. > Just do not use mainstream browsers then. Make your own like you do for gemini. > http 1.0 is actually easier to implement than the gemini protocol. Why doesn't that HN commenter or any of the Gemini critics launch a Small Web project that uses subsets of http and HTML and also uses Len's enforcement mechanism concept? And then somehow, this Small Web/Subset Web project will magically vaporize Gemini land. It's almost as if people are bothered by the existence of something that they will never use. Maybe they are bothered by people who enjoy using something different. In the sport world, I like the saying, "The best ability is availability." It's a reference to good players who are injured a lot and don't play in most games versus less-talented players who play every game and contribute. Project Gemini exists now, and it's being used. The web subset that people clamor about does not exist, unless it involves using Links2 and creating simple HTML-only web pages or plain text pages like Len. Back to the one commenter in that HN thread: > I don't understand why the gemini people don't just use http 1.0 ( host) with html (or plaintext/markdown/whatever even, without js/css). We have to stop viewing Gemini from a web perspective. We need to view Gemini from a Gopher perspective. If people have never used Gopher, then it will be hard for them to formulate an opinion about Gemini. The web will continue to get bloated and more complex. With Gemini's spec nearly frozen and closer to Gopher than the web, then the corporatification of Gemini won't happen. Regarding http 0.9 and http 1.0, how long until so-called modern web browsers either won't work with http 1.0 websites or display huge warning messages about accessing an outdated protocol version? The Project Gemini software page lists the following projects for browsers, servers, utilities, tools, etc. This seems like good activity for a project announced in June 2019. Gemini appears to be more than a pointless, feel-good, righteous endeavor. The naysayers are wasting their time, like I am by responding. Gemini users who read the critics' feeble explanations won't suddenly stop using Gemini. If anything, the critics make me more interested in Gemini, and I'm even more grateful to solderpunk for keeping Gemini's spec small and nearly frozen. => gemini://gemini.circumlunar.space/software/ I'm just copying the text from that page and not including the links below. Again, the Kristall browser attaches the protocol name next to the link text if the link points to something outside of Gemini. Servers * A Gemini server written in Go [HTTPS] * Agate, a Gemini server written in Rust * Blizanci, a Gemini server writen in Erlang [HTTPS] * Dezhmnsrv, a Gemini server written in Racket * GeGoBi, a Gemini server for Gemini-Gopher bi-hosting [HTTPS] * Geminid, a Gemini server written in C [HTTPS] * Gemini-PHP, a Gemini server written in PHP * Gemserve, a Gemini server written in Rust * Germinal, a Gemini server written in Common Lisp [HTTPS] * GLV-1.12556, a Gemini server (in fact, the first!) written in Lua [HTTPS] * gmnisrv, a simple Gemini server written in C11 [HTTPS] * Jetforce, a Gemini server written in Python [HTTPS] * (The Unsinkable) Molly Brown, a Gemini server written in Go [HTTPS] * Net-Gemini, a Gemini server written in Go [HTTPS] * Northstar, a Rust library for Gemini servers [HTTPS] * Pollux, a Gemini server written in Rust [HTTPS] * Space Age, a Gemini server written in Clojure [HTTPS] * Twins, a Gemini server written in Go * Vger, a simplistic and secure Gemini server in C targetting OpenBSD [HTTPS] Clients * A bare-bones but usable Gemini client in 100 lines of Python [HTTPS] * A bare-bones but usable Gemini client in 100 lines of Lua [HTTPS] * A bare-bones but usable Gemini client almost 100 lines of Go [HTTPS] * A Gemini client library in Guile Scheme [HTTPS] * A Gemini client for Android [HTTPS] * A Gemini client library in Go [HTTPS] * A more recent fork of the above library [HTTPS] * A rich Gemini client library in Nim [HTTPS] * Agregore, a "distributed web" browser supporting Gemini [HTTPS] * Amfora, a very feature-rich Germini client for the terminal [HTTPS] * Astronaut, a terminal Gemini client written in Go [HTTPS] * Asuka, a ncurses-based Gemini client [HTTPS] * AV-98, an experimental Gemini client derived from VF-1 [HTTPS] * Bombadillo, a multi-protocol client handling Gemini since 2.0.0 [HTTP] * Castor, A graphical Gemini client written in Rust [HTTPS] * Diohsc, a terminal Gemini client written in Haskell * Dragonstone, a simple GTK Gopher/Gemini client written in Vala [HTTPS] * elpher, a emacs-based Gopher and Gemini client [GOPHER] * Fafi, a graphical, tabbed client written in Racket [HTTPS] * gacme, a Gemini client for plan9's Acme [HTTPS] * gcat, a `cat`-like Gemini client [HTTPS] * Gemget, a command-line Gemini downloader ala wget [HTTPS] * GemiNaut, a user-friendly GUI client for MS Windows [HTTPS] * gurl, a `curl`-like Gemini client [HTTPS] * Gusmobile, a Gemini client library in Python [HTTPS] * gmni, a combined CLI and line-mode client for POSIX/C11 [HTTPS] * Kristall, a graphical Gemini client using Qt [HTTPS] * Lagrange, a beautiful graphical Gemini client written in C * majc, a curses client for Gemini written in Rust * McRoss, a graphical Gemini client written in Python/Tkinter [HTTPS] * Moonlander, a very fancy graphical Gemini client written in Rust [HTTPS] * ncgopher, a Gopher and Gemini client written in Rust [HTTPS] * Rhapsode, an "auditory web browser" which supports Gemini [HTTPS] * Spwash, a bare-bones Gemini client written in C# [HTTPS] * Twin Peaks, a graphical Gemini client written in C# [HTTPS] * Tinmop, a distraction free terminal client for Gemini (and Pleroma!) [HTTPS] * Zain, a graphical Gemini client written in Tcl/Tk [HTTPS] Browser plugins * dillo-gemini, a Gemini plugin for the Dillo browser * cute-gemini, a Gemini userscript for Qutebrowser [HTTPS] Syntax highlighting for editors * text/gemini syntax highlighting for emacs [HTTPS] * text/gemini syntax highlighting for kakoune [HTTPS] * text/gemini syntax highlighting for Kate * text/gemini syntax highlighting for nano [HTTPS] * text/gemini syntax highlighting for vim [HTTPS] CGI applications * gemlikes, a liking and commenting system [HTTPS] * git.gmi, a Gemini git frontend * GMIToAtomFeed, a CGI tool to produce Atom feeds from Gemini index pages [HTTPS] * Twinwiki, a Gemini wiki edited with sed commands [HTTPS] Other * A Go library for implementing both clients and servers [HTTPS] * Agena, a Gemini-to-Gopher proxy [HTTPS] * Agunua, a Python library for the development of Gemini clients * Atomini, a Ruby script to generate an Atom feed from a Gemini map [HTTPS] * CAPCOM, an Atom feed aggregator that outputs text/gemini [HTTPS] * Gemfeed, a tool to generate Atom feeds for a directory of text/gemini files [HTTPS] * Gemgit, a tool to generate static Gemini pages for git repos * gemini-fetch, a simple Node JS module to fetch Gemini content [HTTPS] * gemini-to-html, a simple Node JS module to convert text/gemini to HTML [HTTPS] * Gig, a Gemini application framework in Go [HTTPS] * git-remote-gemini, a Git remote helper to clone git repositories over Gemini [HTTPS] * gmi, a text/gemini parsing library [HTTPS] * gmisub, a tool to aggregate content from subscribable Gemini pages * gmitohtml, a command line tool and daemon for converting txt/gemini to html [HTTPS] * html2gmi, a command line application to convert html to text/gemini [HTTPS] * html2gemini, a Go library package to convert html to text/gemini [HTTPS] * Ignition, a Gemini client library for Python [HTTPS] * md2gemini, a Markdown to text/gemini converter [HTTPS] * Spacewalk, a moku-pona style aggregator for Gemini [HTTPS] * Vostok, a protocol-agnostic framework supporting Gemini [HTTPS] * Xenia, a Gemini web proxy for Android [HTTPS] -30- ``` dir : 2021/02/01 ```