# Gemini is Superior to a Web Subset

## Gemini exists. A safe-web subset is only an idea.

(created Sun, Feb 21, 2021)


### SmallWeb, SafeWeb, SubsetWeb

Some ideas and thoughts by others about a web subset:

=> http://blog.danieljanus.pl/2019/10/07/web-of-documents/

Excerpts:

> We don't have a Web of Documents anymore. These days, the WWW is mostly a Web of Applications. An application is a broader concept: it can display text or images, but also lets you interact not just with itself, but with the world at large. And that's all well and good, as long as you consciously intend these interactions to happen.

> ... the more I think about it, the more sense it makes to me to attack the problem closer to its root: to decomplect the notions of a document and an application; to keep the Web of Applications as it is, and to recreate a Web of Documents--either parallel to it, or as its sub-web.

> To do this, we need to take a step back. (Or do a clean start and invent a whole new technology, but this is unlikely to succeed). Fortunately, we don't have to travel all the way back to 1992, when the WWW was still a Web of Documents.

> I think we can base the new Web of Documents on ol' trusty HTTP (or, better, HTTPS), HTML and CSS as we know them today, with just three restraints:

> 1. No methods other than GET (and perhaps HEAD). POST, PUT, DELETE and friends just have no place in a world of documents. They are not idempotent; they potentially modify the state of the world, which documents should not be able to do. (I was also thinking "no forms", but with #1 in place, it seems like an unnecessary refinement. After all, forms that translate to GET requests just facilitate creating URLs: a user could just as well have typed the resulting URL by hand.)

> 2. No scripts of any kind. Not JavaScript, not WebAssembly. Not even to enrich a document, such as syntax-highlight the code snippets. This one may seem too stringent, but I think it's better to err on the safe side, and it's very easy to enforce.

> 3. No cookies. Cookies by themselves aren't interactive, but having them makes it all too easy to abuse the semantics of HTTP to recreate sessions, and on top of them reinvent the app-wheel and eventually forfeit the Web of Documents again.

> How do we achieve this? I don't know, really. I don't have a concrete proposal. Perhaps we could have dedicated browsers for the WoD; perhaps we could make existing browsers prominently advertise to the user whether they are browsing a document or an application. On top of all the technical decisions to make, there'll be significant campaigning and lobbying needed if the idea is ever to take off.

The author, Daniel, did not advocate for HTML4, CSS2, nor HTTP 0.9. He wants HTTPS and at least some of today's HTML5 and CSS3 features.

==========

solderpunk launched Gemini in June 2019, but he has expressed his thoughts about a SafeWeb or SmallWeb subset. This is his web server to support his idea of a SafeWeb.

=> https://tildegit.org/solderpunk/shizaru/

> Shizaru is a minimalistic web server whose guiding principle is "serve no evil". Precisely what counts as "evil" can be configured by the user, so perhaps Shizaru is best explained as a webserver for imposing strong opinions. 

> The website obesity crisis is combatted with strict file size limits, to ensure that your website does not end up larger than the major works of Russian literature. Besides being limited to 32 KiB in size, HTML pages are limited to 3 images and HTML tags cannot be nested more than 10 levels deep. This encourages uncluttered and quickly rendering layouts. <audio>, <applet>, <canvas>, <embed>, <iframe>, <script> and <video> tags are prohibited (among others). In other words, your web pages will need to be actual documents, not applications, which means they have some hope of being usable on older machines or without massively bloated browsers. Third-party images, stylesheets and fonts are not allowed, so your users can rest assured that they aren't being tracked indirectly.

> This default configuration of Shizaru is not supposed to be a "retro server". Shizaru supports HTTPS (in fact, the only thing it will serve over HTTP is a redirct to HTTPS) and HTTP/2, and the default ruleset allows the use of many tags introduced in HTML5. The goal is not to remove the new and keep only the old, but to remove the evil and keep only the good. Old and good may be correlated when it comes to the web, but there are exceptions. The Shizaru defaults disallow <blink> and <marquee>, for example.

solderpunk also stressed the idea of documents and not applications. And solderpunk's web-subset server enforces HTTPS, and it uses HTTP/2. That's not a 1990s era web. solderpunk also likes the idea of using some HTML5 tags, probably the semantic ones. 

This line from solderpunk is key to what he and Daniel were probably thinking, regarding a subset of the web.

> The goal is not to remove the new and keep only the old, but to remove the evil and keep only the good. 

I infer that simply using lesser-known limited web browsers to read the current web is not good enough. The web subset is not about using the web as it existed in 1995 or 2000. 

==========

February 2021 Hacker News thread ...

=> https://news.ycombinator.com/item?id=25986378

... that pointed to this post:

=> https://spwhitton.name//blog/entry/geminispace/

Excerpts from one of the HN comments:

> 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). 

SmallWeb proponents like Daniel and solderpunk want modern CSS, HTML, and HTTP. They want the best of today and not to be restricted to using only what existed long ago.

Of course, who gets decide what comprises the good and evil parts of today's web? Good luck getting agreement on that task.

==========

=> http://len.falken.ink/web/perceived-relations-between-gopher-gemini-and-http.txt

> 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.

That last sentence contained a bold claim with one serious malfunction: Len's subset enforcement option does not exist. Ideas are nice, but implementations are better. Gemini exists.

> 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.

But once again, some SmallWeb proponents want more than raw text. The current web offers multiple variations of the SmallWeb experience, along with an unsafe, bloated web while Gemini offers plain text and Gemini text with a much safer, faster, and saner reading experience than the web.

Len concluded his criticism of Gemini with some nonsense:

> 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.

No reason to exist? Gopher still exists after 30 years and little to no changes to the spec. People still use Gopher. Who cares how many use it. It still exists. Gemini is a documented protocol with significant community support in the form of software development and personal publishing. No matter what anyone thinks, Gemini will continue to exist. 

Mind child? I don't know what that means, but I'm guessing that it's a negative comment. Obviously, Len has not read solderpunk's Gemini and Gopher postings.

Here's the problem with the whole web subset idea:

* "How do we achieve this? I don't know, really. I don't have a concrete proposal."
* "There would be less friction if browsers had a "subset" enforcement option ..."
* "As soon as some entity decides to release some HTTP subset enforcement mechanism ..."
* "... hopefully leads to the HTTP subset enforcment ..."

The web subset idea is a fantasy while Gemini exists.

=> gemini://gemini.circumlunar.space/     Project Gemini - docs, software, etc.

Here's the link to the SmallWeb Project:

...  ????

If a lot of technologists desire an HTTP subset enforcement mechanism, then why haven't they created it? My guess is because it would be used by so few people that the project would stop being supported, and site authors would go back to using the modern web. 


### Gemini

My past related ramblings. Quite wordy.

=> gemini://sawv.org/2020/07/23/gemini-vs-small-web.gmi

These were my replies to posts written by others.

=> gemini://sawv.org/2021/02/01/re-perceived-relations-between-gopher-gemini-and-http-len.gmi

=> gemini://sawv.org/2021/02/09/re-can-someone-add-some-more-html-tags-please-dries.gmi

Regarding Gemini, the comparisons to the web should not exist, in my opinion. Mentioning the web in Gemini documentation was probably an early error by solderpunk. Gemini is more closely related to Gopher than the web.

=> https://thedorkweb.substack.com/p/gopher-gemini-and-the-smol-internet

> Gemini isn't a stripped-down web. It's Gopher on steroids. It's lightweight and lightning quick

One of the critiques of Gemini is that Gemini does not support inline linking. Gemini requires links to exist on their own lines, and only one link can exist per line. This does not bother me, since a lot of my lazy web posting through the years has contained raw URLs, posted as one link per line. 

And this one link per line idea in Gemini was borrowed from Gopher, I think. It makes creating Gemini browsers easier. It's not a hardship. It's not a legitimate reason not to try Gemini. 


solderpunk created Gemini in June 2019. In this post, he did a great job explaining why a new application layer protocol is a better idea than using a subset of the web.

=> gemini://gemini.circumlunar.space/users/solderpunk/gemlog/why-not-just-use-a-subset-of-http-and-html.gmi

Excerpts:

> To my mind, the problem with deciding upon a strictly limited subset of HTTP and HTML and slapping a label on it (let's say "SafeWeb") and calling it a day is that it would do almost nothing to create a clearly demarcated space where people can go to consume *only* that kind of content in *only* that kind of way, which is what I think we really want. There's simply no way to know in advance whether fetching any given https:// URL will yield SafeWeb content or UnsafeWeb content. Even a website which claims to be part of the SafeWeb, and which superficially *looks* like it must only be using SafeWeb-approved technologies, could actually be serving you tracking E-Tags or doing other things which are invisible to, but certainly not harmless to, the user. Mainstream browsers like Firefox and Chrome simply do not offer convenient, fine-grained control over what websites can do to you (a constantly shifting ecosystem of a dozen third-party plugins which are prone to compatibility problems is the best you can hope for), so if you ever visit an even slightly UnsafeWeb page, you will suffer the consequences. Do you really want to manually inspect the headers and source code of every alleged SafeWebsite you visit to make sure everybody is playing by the rules? 

> Now, there's nothing stopping people from writing their own web browsers which refuse to implement any particular piece of HTTP or HTML which they disagree with, yielding a guaranteed SafeWeb experience (although such an undertaking would be an order of magnitude more work than writing a fully featured Gemini client). Supposing you had such a browser, what would you do with it? The overwhelming majority of websites would not render correctly on it. How do you find the sites authored by like-minded SafeWeb advocates which are designed to work nicely in such a browser? You certainly can't ask Google to only show you SafeWeb results! A hypothetical SafeWeb community could setup a wiki where people can share links to SafeWeb sites, but even if nobody deliberately submitted UnsafeWeb links to this list maliciously (which they surely would), sites which *were* SafeWebsites at the time of addition could become UnsafeWebsites in the future. Safeweb status is inherently unstable by virtue of being a subset of something greater - people will start off building SafeWebsites but then later decide that "SafeWeb plus just these one or two extra tags that I really want and promise to use responsibly!" is "SafeEnoughWeb". The verification and maintenance burden of providing a list of truly SafeWebsites would be immense. 

> All of this is an *insane* quantity of tedious and error-prone work in order to do a bad job of replicating what simple-by-design protocols like Gopher or Gemini offer at a drastically reduced cost of entry: a clearly defined online space, distinct from the web, where you know for sure and in advance that everybody is playing by the same rules. When you explore Geminispace, you can follow a link to a domain you've never heard of before and there is no matter of worry or trust regarding whether or not that transaction will violate your privacy, or gratuitously waste your bandwidth, or cause your laptop fan to spin up, or start playing music even though you're in a quiet room. You simply know that it won't happen. When all somebody can do to you is send you some text and some links you can choose to follow or not, you can let your guard down. You can cruise around Geminispace freely and fearlessly, reading anything that takes your fancy. This is *tremendously* psychologically liberating compared to surfing the web in a mainstream browser and hoping that a huge pile of plugins will protect you like they're supposed to and wondering which ones it might be safe to temporarily disable when a page you'd really like to read isn't rendering properly because of them. 


gemini://gemini.circumlunar.space/docs/faq.gmi

> 2.5 Why not just use a subset of HTTP and HTML?

Excerpts from that section of the FAQ:

> Many people are confused as to why it's worth creating a new protocol to address perceived problems with optional, non-essential features of the web. Just because websites *can* track users and run CPU-hogging Javsacript and pull in useless multi-megabyte header images or even larger autoplaying videos, doesn't mean they *have* to. Why not just build non-evil websites using the existing technology?

> Of course, this is possible. 

> The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume *only* that kind of content in *only* that kind of way. It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it.

And using either the Links2 or NetSurf web browsers, like I have suggested in the past, may not be a viable solution, since some SmallWeb proponents want to use aspects of modern HTTP, HTML, and CSS. That would require an enhanced version of the NetSurf browser or a new SmallWeb browser or Len's web subset enforcement mechanism. Otherwise readers may view slightly broken SmallWeb sites when using limited-featured web browsers, which occurs now when reading the modern web. 

SmallWeb readers could use large, bloated web browsers like Chrome to view the SmallWeb, but then what's the point? 

More from the Gemini FAQ:

> Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render. 

> Alternative, simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions. You know for sure when you enter Geminispace, and you can know for sure and in advance when following a certain link will cause you leave it. While you're there, you know for sure and in advance that everybody else there is playing by the same rules. You can relax and get on with your browsing, and follow links to sites you've never heard of before, which just popped up yesterday, and be confident that they won't try to track you or serve you garbage because they *can't*. You can do all this with a client you wrote yourself, so you *know* you can trust it. It's a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web. 

In under two years, Gemini probably has more browser diversity than today's web, which has existed for 30 years. In other words, I can use any Gemini browser to READ Gemini content, but the same cannot be said for the web. 

Unfortunately, some websites that are meant for READING are designed to require client-side JavaScript in order to view text and images, which is asinine. A limited-featured GUI-based web browser like NetSurf displays blank pages when viewing such sites. 

Links2 is an excellent simple web browser for viewing the web quickly when the focus is on reading. It's amazing how fast the web is when using Links2. I don't need any web browser extensions when using Links2, since it's limited by default. From a typography standpoint, all websites look the same to me when using Links2 because it permits me to control basic typography settings. This is how Gemini works when using the Castor and Kristall browsers. I control the typography. 

On Gemini, authors focus on creating content and not creating user experiences. On Gemini, I control my reading experience. This makes Gemini superior to the web for reading. Even when using Links2, it's amazing the amount of cruft that exists in web pages that I have to scroll past before finally seeing the content. 

If every web of documents website was designed like Len's plain text approach or like text.npr.org, then I would agree that Gemini might be unnecessary. But too much of the web contains design abominations, such as toledoblade.com, which is a potentially nefarious advertising network with some journalism buried in it somewhere.

My solution for reading the Toledo Blade (our local "newspaper") in a safe, humane, reader-friendly manner.

=> gemini://sawv.org/tb/

In my opinion, the modern web is so bad that I don't see how a SmallWeb project could help. But if someone creates a SmallWeb specification, a browser, a server, and a best practices, then I will follow such a project. But until then, it's only talk. Gemini, however, is real.


### Etc.

=> https://drewdevault.com/2020/11/01/What-is-Gemini-anyway.html

> Gemini is a network protocol for exchanging hypertext documents -- "hypertext" in the general sense of the word, not with respect to the hypertext markup language (HTML) that web browsers understand. It's a simple network protocol which allows clients to request hypertext documents (in its own document format, gemtext). It is, in some respects, an evolution of Gopher, but more modernized and streamlined.

> Gemini is very simple. The protocol uses TLS to establish an encrypted connection (using self-signed certificates and TOFU rather than certificate authorities), and performs a very simple exchange: the client sends the URL it wants to retrieve, terminated with CRLF. The server responds with an informative line, consisting of a numeric status code and some additional information (such as the document's mimetype), then writes the document and closes the connection. Authentication, if desired, is done with client certificates. User input, if desired, is done with a response code which conveys a prompt string and a request for user input, followed by a second request with the user's response filled into the URL's query string. And that's pretty much it!

A web subset specification would still be significantly larger than Gemini's specification.

More from Drew's post:

> My disdain for web browsers is well documented. Web browsers are extraordinarily complex, and any attempt to build a new one would be a Sisyphean task. Successfully completing that implementation, if even possible, would necessarily produce a Lovecraftian mess: unmaintainable, full of security vulnerabilities, with gigabytes in RAM use and hours in compile times. And given that all of the contemporary web browsers that implement a sufficiently useful subset of web standards are ass and getting assier, what should we do?

> The problem is unsolvable. We cannot have the "web" without all of these problems. But what we can have is something different, like Gemini. Gemini does not solve all of the web's problems, but it addresses a subset of its use-cases better than the web does, and that excites me. I want to discard the parts of the web that Gemini does better, and explore other solutions for anything that's left of the web which is worth keeping (hint: much of it is not).

> Some people argue that what we should have is "the web, but less of it", i.e. a "sane" subset of web standards. I don't agree (for one, I don't think there is a "sane" subset of those standards), but I'll save that for another blog post. Gemini is a new medium, and it's different from the web.

==========

This next post is not Gemini-related, but this post highlights a problem with the modern web.

=> gopher://dataswamp.org:70/0/~lich/musings/links-browser.md

or

=> https://dataswamp.org/~lich/musings/links-browser.html

Excerpts:

> Many browsers today are gigantic resource hogs, which are basically VMs for various web applications. On the other hand, Links is a HTML browser. It is not able to do everything. It allows me to avoid most distractions and control the content-experience. 

> First, I want to focus on 'destruction' of CSS. As Links does not support modern CSS it renders most of the internet as-is, and will only contain images (on which I will write later). CSS causes the internet to become a baroque set of arbitrary design decisions, and does not contribute positively to the general experience. Links (after 2.19) allows me to pick my own font, my own background/foreground/url color. Thus, I have a uniform experience. In that I already visibly save time/energy/brain processing power, etc. To deal with senselessly complex sites (news pages with >1 MB JS, I am looking at you) I use and tedu's miniwebproxy. It delimits the content even more, and removes elements that are not of interest for me (top,bottom,side bars, recommended content, etc.).

In my opinion, a SmallWeb or a SubsetWeb would not need CSS. It would need some kind of markup language, which could be tag-based or something like Textile, CommonMark, AsciiDoc, etc. The SubsetWeb browsers would display the content, according to the typographical settings established by the browser users. 

What's the point of CSS in a Web of Documents? We can control the typographical settings within eBook readers. Kindle users are not beholden to the typography set by the publishers.

More from lich's post:

> JS is the main cause for the way internet changed, for better or worse. It changed content into dissimilar applications. It allowed for measurement of attention and penalization of the experience. I am critical of that, and Links has no JS support. Perfect. Nothing more to be spoken of. If I need JS I will use another browser which emulates anything Google considers good internet experience. But, that currently is not my goal.

A SubsetWeb/SmallWeb/SafeWeb/WoD should not support client-side scripting.

> Now, going from a little controversy to a giant controversy. Images (in the modern web) are uninformative, but are simply advertisements of content. They are made to take over your attention and again, make the experience less uniform. Links does not force you to disable images (as there are cases when they are useful - i.e. Wikipedia), but has a function to not load them. Again, as with everything it allows for more uniformity.

I like the fact that Gemini does not support the display of embedded images. It is possible to link to images that exist on Gemini servers. Depending upon the Gemini browser, the images will be displayed within the browser, the images will appear within the default image viewing app for the reader's operating system, or the images will be available for download to be viewed in another app.

Gemini pages get downloaded faster than web pages, which contain too many useless, huge images. It's amazing how media orgs pollute their article pages with irrelevant, large images, causing slower download times. If every word should count, then why not make every image count? And why do images need to be huge if most people read the web on mobile devices?

Some of the biggest abusers of the web are media orgs that maintain live blogs for breaking news events. These live blog pages are massively bloated with heavy content, such as embedded images, videos, and social media crap.

Sometimes, live blogs serve people who live in an area hit by a natural disaster that has caused power outages and maybe reduced cell coverage. To make live blog pages easier to access, the media orgs should LINK to the heavy content and focus their live blog pages on helpful text. Users with limited cell connections or low battery life can choose whether to access the heavy content. But this kind of empathy is lost with the modern, bloated web.

Again, this makes Gemini superior. It's sane, safe, and empathetic by design. It takes too much effort to get the same experience on the web, and in many cases (modern websites), it's impossible to achieve.

=> https://sawv.org/2019/05/13/complex-bloated-web-design-described-in-13-words.html

That post excerpted a Hacker News comment that said:

> I love how browsing the web now is like gearing up for war.


In January 2019, I posted my thoughts for a sane, safe, and small web.

=> https://sawv.org/2019/01/22/markdownonly-web-browser.html

And I created a test site.

=> http://md.soupmode.com/home.md

The only HTML page on my test site is the index.html page for document root that is meant to explain my silly experiment. 

Since I don't have a Markdown-only web browser, I rely on web browser extensions that convert my .md pages into an easier-to-read display. And the browser extensions permit me to upload my own CSS settings, which means that I'm in control of the typography. All Markdown sites would appear the same to me.

My Markdown-web idea was not far off of Project Gemini. That's why when I discovered Gemini in May 2020, I was fascinated by it immediately. It never occurred to me to create a new application layer protocol.

I like my Markdown SmallWeb idea better than Len's plain text web, although I like Len's web design better than modern web design. For reading. I'm not talking about applications.

Len's homepage is his XML RSS file, which works fine in my main daily web browser Pale Moon, which is a fork of an older version of Firefox. Pale Moon is actively developed, and it still contains the RSS/Atom viewer, unlike Chrome and Firefox.

=> http://len.falken.ink/

When I visit Len's homepage with Pale Moon, I see a list of clickable links. But when viewed in other web browsers, I see plain text XML or the primary text areas minus the XML. I don't consider either very user-friendly, but it's still better than nearly all media websites.

For most people, Lens' homepage is best viewed within a feed reader, which is great for people who like to use feed readers. I have never been a big user of feed readers. I go through periods when I use theoldreader.com as my main feed reader, but most of the time, I don't use it. 

I created my own simple web-based feed reader that I adapted to work on Gemini, and I use it sometimes. Eventually, I may use feed reading more for Gemini.

Len discussed his publishing philosophy and method in this post.

=> http://len.falken.ink/misc/writing-for-the-internet-across-a-human-lifetime.txt

I admire Len's plain, raw text approach to publishing, but it seems as equally niche as using Gemini. Maybe more so, since his plain text approach exists on the web.

If Gemini is viewed as being only accessible to tech-savvy or internet-savvy people, then that applies to Len's plain text publishing method. 

Most people, even me, prefer some basic formatting of text pages, such as headings, bullet points, and most importantly, links. The web, Gopher, and Gemini support linking. 

I would prefer that Len's plain text pages be written in Markdown. I could still view his content as plain text in Links2 or Pale Moon, but if I desired some basic formatting, then I could view his content in web browsers that supported Markdown viewing extensions.

text/markdown is a known MIME type, although it's probably not official. By default, most web browsers will display the content as plain text. Unfortunately, Pale Moon prompts me to download the page when the MIME type is text/markdown. The safe alternative is to use the text/plain MIME type for .txt and .md files. 

The Kristall internet browser, however, will format the Markdown content for easier display. Kristall can access the Gopher, Finger, Gemini, and HTTP/HTTPS protocols.

At my test Markdown website, I created a copy of Len's post, and I added a smidgen of Markdown (CommonMark) to the post. 

=> http://md.soupmode.com/test-postwriting-for-the-internet-across-a-human-lifetime.md

In plain text mode, the two versions look nearly the same. A couple pound signs and the greater-than and lesser-than symbols surrounding links are about the only differences. Markdown permits organizing the plain text markup in whatever column width desired. The HTML conversion of Markdown ignores the newline char, unless two spaces are added at the end of the line.

It took almost no effort to add the few Markdown commands to make his page optionally display better on someone's computer that supports rendering Markdown. It displays fine within a Markdown editor like Typora on my Linux laptop. 

As a reader, maybe I don't want to see a monospace font, except when text is contained within a pre/code block. Maybe I want to see the text color and the background color displayed differently. Maybe I want more line and paragraph spacing. A Markdown browser or web extension permits me to read the content my way.

Even now when viewing Len's posts with Chrome and using the Markdown Preview Plus extension, I see his .txt pages displayed my way. 

Markdown Preview Plus can convert more than .md files. The extension provides a list of popular file extensions to include in the formatting. When I add .txt to the list of files to be formatted, then Len's text/plain pages get converted, according to the custom CSS settings that I added to the browser extension. I see a larger font size, text centered in a narrow column, more line and paragraph spacing, a sans-serif font (system fonts), etc. It's easier for me to read. 

When I backup my sawv.org website, I don't backup the HTML files. I only save the text markup files, which consist of either Textile or Markdown. I agree with Len about plain text being sturdy, and in my opinion, Textile and Markdown pages are easy to read as is.

From my website:

=> https://sawv.org/a-few-words-about-my-dad.html

But this is the file that I backup:

=> https://sawv.org/a-few-words-about-my-dad.txt

My web-based static site generator saves the markup file to the server in addition to creating the HTML version of the post.

A key difference with how I write text files is that I create paragraphs as one long line of text. I don't break my lines at 70 to 80 characters per line. On Gemini, the line breaks are preserved.

Anyway, Textile, Markdown/CommonMark, and especially Gemini Text provide lightweight plain text options for creating content that can be read many years later.

This is my preference for a small internet of documents:

* Gemini - text/gemini
* Markdown web like md.soupmode.com - text/markdown
* Smidgen of HTML and maybe CSS like https://text.npr.org
* RSS and raw text like http://len.falken.ink - text/plain
* Gopher - text/gophermap

The math geeks will interrupt and ask what about embedding math formulas? I'll defer to what Len suggested: URLs. 

Why does everything have to be embedded within a single page? Authors can link to images, videos, and complicated math formulas that can exist on the same server in their own file types that can hopefully be consumed by readers.

I assume that math people would use familiar software to create specialized documents that contain their formulas, and these documents would be read by applications that other math people will have installed on their computers. A SmallWeb or Gemini text page could contain a link to a LaTex file.


All of this SubsetWeb talk may encourage me to think even more about it. I would focus on MIME types text/plain or text/markdown, probably the former to be safe. The Markdown viewing browser extensions do not go by MIME type. They seem to operate only by file extension. Unless I somehow create my own Markdown-only web browser, which is unlikely, then I will rely on web browser extensions, which eliminates using browsers, such as Links2 and Netsurf. 

That's rich irony. I need to use massive modern web browsers, such as Chrome and Firefox to view my SmallWeb idea. Not really. I can read the text/plain content, like Len's site, in any browser. To get a formatted display according to my customized settings, then I will need to use Chrome or Firefox with the browser extensions.

Kristall, however, is a small internet browser. It will render web pages served with a MIME type text/markdown, according to the style settings that I established within Kristall. This might be the best option for a SmallWeb browser.

The even better option is to use Gemini. No need to think about this SmallWeb idea anymore. No need to create software, specifications, diatribes, and manifestos to support and promote the SmallWeb. 

Gemini offers a clear choice. solderpunk said about a creating a web subset:

> All of this is an *insane* quantity of tedious and error-prone work in order to do a bad job of replicating what simple-by-design protocols like Gopher or Gemini offer at a drastically reduced cost of entry: a clearly defined online space, distinct from the web, where you know for sure and in advance that everybody is playing by the same rules.

==========

Good post from a long-time Gopher user. It's interesting that he made the post on the web. His blog site, however, is focused on vintage computing.

=> https://oldvcr.blogspot.com/2020/11/a-gopher-view-of-gemini.html

> In this environment of unchecked splay, the [web] browser has since metastasized to an operating system running on an operating system (you could even argue that simplified document presentations like Reader View are browsers themselves running on this browser-as-operating system), web services drive browser technology to facilitate greater monetization of users rather than greater ability to access information, and the entire client stack has reached the level of baseline bloat such that many operating systems and older systems are cut off completely. 

> As a consequence I think one of the biggest reasons for the Gopher protocol's return is as a reactionary backlash against the excesses of the Web. 

> Really, Gopher isn't a direct ancestor of the Web either; at most it can be argued to be an influencer. Gopher actually originated as an attempt to put a friendlier frontend onto FTP.

> Gemini finds Gopher too limiting and the Web too big, so it tries the Goldilocks approach. Rather than Gopher's strong menu-document hierarchy, Gemini lets you have documents with (horrors) inline links and formatted text, but the way in which you specify that document is intentionally bowdlerized compared to HTML so people can't keep adding features. 

> Gopher has a trivial open wire protocol where the selector and a handful of item type characters do all the work, while heavy HTTP has a header and method for every kink and everything is encrypted, so Gemini splits the difference by requiring TLS 1.2 with SNI and MIME types but doesn't cache, compress or cookie. It's a vision of the web where if you want to view an image, you click on a link, scripting is for playwrights, and if you want to track a user across visits, it's hard and imprecise. 

> And that's the core difference, philosophically, between Gopher and Gemini: Gemini truly is a descendent of the Web, it's just one with an eye on the Gopher renaissance that happened inbetween.

>  Just like it won't displace the Web, Gemini isn't going to displace Gopher -- though in fairness nor does it try -- because it just simply doesn't scratch the same itches. 

> I've observed before that the Web and Gopher can coexist, and I don't see why Gemini and Gopher can't either. Despite their superficial similarities and some overlap in motivations, they don't really serve the same purposes and that's absolutely a-okay. From my view on port 70, anything that gets us to a point where people start thinking about alternatives to an increasingly out-of-control Web is a positive, and I'm glad both Gemini and Gopher are doing that. 


-30-
``` dir : 2021/02/21
```