# SmallWeb
## Spitballing about a web subset
(created Mon, Feb 22, 2021 - updated Mon, Mar 1, 2021)
Inspirations:
Markdown-only web like - text/markdown - my test site created in January 2019:
=> http://md.soupmode.com/home.md
Gemini - text/gemini - launched in July 2019:
=> gemini://gemini.circumlunar.space
Smidgen of HTML and maybe CSS like:
=> https://text.npr.org
RSS and raw text like Len's site where his home page is text/xml and article pages are text/plain
=> http://len.falken.ink
Gopher - text/gophermap
Also:
=> https://sawv.org/2019/01/22/markdownonly-web-browser.html
=> http://blog.danieljanus.pl/2019/10/07/web-of-documents
=> http://len.falken.ink/misc/writing-for-the-internet-across-a-human-lifetime.txt
=> https://sawv.org/2020/07/01/text-gemini-markup.html
=> gemini://gemini.circumlunar.space/docs/gemtext.gmi
Kristall internet browser supports Gopher, Finger, Gemini, and a SmallWeb of HTTP/HTTPS. Kristall will format content based upon MIME type. Web pages served with MIME type text/markdown get rendered accordingly. This would be the ideal SmallWeb browser.
=> https://github.com/MasterQ32/kristall
Markdown Preview Plus browser extension for Chrome. Yeah, Chrome. But this extension permits me to pick other file extensions to render besides .md files. And this extension permits me to upload my own custom CSS to control the display.
Caveat:
=> gemini://sawv.org/2021/02/21/gemini-is-superior-to-a-web-subset.gmi
But I'll mush on anyway. I did not cross-post that Gemini post to my website. Recently, I have started posting new content to my Gemini site only.
A few existing lightweight websites:
=> https://text.npr.org
=> https://www.nhc.noaa.gov/mobile
=> https://lite.cnn.com/en
But I'm going smaller. Instead of HTML, only Markdown ([CommonMark](https://commonmark.org)) markup exists. No other assets get served. Only one web request: the Markdown page.
The rendering and display controls get managed on the client-side by the readers and their browsers or extensions. The publishers have nothing to do with how the content is displayed, at least regarding typography. The publishers focus on creating content.
Publishers can organize their content pages by using heading lines, horizontal rules, and bullet points.
The Markdown Preview Plus Chrome extension will work on .txt, .text, .md, and a few other file extensions. It ignores the MIME type. It will render a .txt file even if the MIME type is text/plain, instead of text/markdown.
The Kristall internet browser, however, will only render Markdown pages properly if the MIME type is text/markdown. A .txt or .text Markdown file that is served over the web as text/plain will be displayed as text/plain within Kristall.
My preference would be to use the Kristall internet browser, but since Chrome is the most used web browser by a large margin, then it might be easier for readers to install the [Markdown Preview Plus](https://chrome.google.com/webstore/detail/markdown-preview-plus/febilkbfcbhebfnokafefeacimjdckgl?hl=en-US) browser extension, instead of installing Kristall.
Kristall provides a user-friendly point-and-click method within the browser to define the typography, which controls how all pages get displayed.
The browser extension provides a few default themes to chose from, but a user can also upload custom CSS. People without CSS knowledge would find this difficult. The default themes contained within the extension are okay, but I like mine better. In my opinion, controlling the display of SmallWeb pages is a primary feature.
From a typography standpoint, these webpages all look the same to me when viewed within Chrome with the Markdown Preview Plus extension enabled.
=> http://md.soupmode.com/2014/05/08/lesscrowded-toledo-area-birdwatching-spots.md
=> https://daringfireball.net/2021/02/unlock_with_apple_watch_with_face_mask.text
=> http://len.falken.ink/misc/writing-for-the-internet-across-a-human-lifetime.txt
The first two are Markdown files. The last one is not. It's a plain, raw text file, but it still gets displayed according to my prefs and not Len's prefs. That's how it should be. The SmallWeb removes content display duties from publishers. Of course with Len's content, he's not creating any display code, since he publishes only in raw, plain text.
I like a sprinkling of linking and formatting with my plain text, which is why I like Gemini and the Markdown-web over Gopher and Len's raw text idea.
text/gemini and text/markdown content are as lightweight as text/plain. It only takes a few more characters to markup Gemini and Markdown pages, and those pages are still as readable and understandable as raw text.
I like Len's publishing philosophy, but a small amount of markup would make those pages display nicer for people who desire a better reading experience, especially the linking.
Thankfully, the Markdown Preview Plus (MPP) extension and Kristall automatically make raw URLs clickable links. No need to surround the URLs with less-than and greater-than symbols to make links. I see clickable links when viewing Len's raw text pages within MPP but not in Kristall, since Len's pages are served as text/plain. Again, Kristall requires the MIME type text/markdown.
That's another drawback to making Kristall the primary SmallWeb client, since it may not be possible for some web authors to configure their web servers to deliver the text/markdown type for .txt or .md files.
This is another one of my test websites:
=> http://scaup.org/rossford-island-view-park-in-the-fall.md
The .md files are hosted on an AWS S3 bucket. I uploaded the files through AWS's clunky web interface. I know that other methods exist to place files at S3, such as using command line tools, but how is that going to work for non-tech users?
None of this is easy for non-tech-savvy people, which is why the social media silos are so popular. They are easy to use.
When uploading the .md files through the AWS web interface, I had to do an extra step of changing the content type to text/plain for the .md files, otherwise the files got delivered in a MIME type that caused web browsers to prompt to save the files to my hard drive. S3 did not offer a text/markdown MIME type.
I created scaup.org to test editing files locally with my favorite Markdown editor Typora and then pushing or uploading the files somewhere to be served as .md files. Instead of saving the files as .md, I could have saved them as .txt, and S3 would have delivered them as text/plain. This would eliminate the step of changing the MIME type each time a file is uploaded.
I would prefer that the files be saved as .md and served as text/markdown and read within Kristall. But for now, the SmallWeb needs to support other text file extensions, such as .txt and .text and accept the MIME type of text/plain.
For my md.soupmode.com test website, I have access to the Nginx config files, and I will continue to save the files as .md and serve them as text/markdown.
For my scaup.org test website, I will upload files with a .txt extension to eliminate that extra annoying step of changing the MIME type. Again, this makes the MPP extension the top choice for rendering Markdown files, since Kristall displays the scaup.org Markdown files as plain text.
### Testing screenshots
=> http://md.soupmode.com/2014/05/08/lesscrowded-toledo-area-birdwatching-spots.md
This image shows how the content looks when viewed in a browser without Markdown rendering support. Obviously, it's plain, raw text.
=> https://live.staticflickr.com/65535/50973496037_0157951d5a_z.jpg
This is how it looks TO ME when viewed within Chrome with the Markdown Preview Plus extension enabled, using my custom CSS that I added to the extension. I'm using a blue background because nothing else that I view uses that color of a background. When the background is blue, I know that I'm seeing content rendered by the Markdown viewer extension.
=> https://live.staticflickr.com/65535/50972702233_e8a2eb1a05_z.jpg
---
=> http://scaup.org/2019/06/24/the-plastic-conundrum.md
Viewed without Markdown rendering support:
=> https://live.staticflickr.com/65535/50973391711_c559c3fcbe_z.jpg
With MPP:
=> https://live.staticflickr.com/65535/50972702278_a1f1989957_z.jpg
---
=> https://daringfireball.net/2021/02/unlock_with_apple_watch_with_face_mask
That's the HTML version of a Gruber post as shown here:
=> https://live.staticflickr.com/65535/50973495857_612e6a5b37_z.jpg
Gruber stores both the HTML and Markdown versions of his posts. He uses the .text extension for his Markdown pages. Here is the Markdown version of the above post viewed as plain, raw text.
=> https://live.staticflickr.com/65535/50973488656_425a2ab0dd_z.jpg
And this is how Gruber's content appears to me when I view his Markdown files with the MPP extension. I prefer viewing Gruber's posts with my typography settings.
=> https://daringfireball.net/2021/02/unlock_with_apple_watch_with_face_mask.text
=> https://live.staticflickr.com/65535/50973431846_166ff9fc14_z.jpg
---
=> http://len.falken.ink/misc/writing-for-the-internet-across-a-human-lifetime.txt
Without the Markdown rendering extension, the content displays at plain, raw text as desired by Len.
=> https://live.staticflickr.com/65535/50973496217_583df2c2c8_z.jpg
Even though Len did not create Markdown text, the MPP extension does not care. It still rendered the page per my preferences.
=> https://live.staticflickr.com/65535/50973391541_66ac7f4804_z.jpg
---
At my personal website, I also store both the HTML and text markup versions of my posts in the same location. My posts go back to 2001. For many years, I used Textile. Over the past several years, I have used Markdown.
Here's a screenshot of this "SmallWeb" post as it looks at my website.
=> https://live.staticflickr.com/65535/50972763388_0348d0119d_z.jpg
Here's the plain text markup version. I'm using Markdown.
=> https://live.staticflickr.com/65535/50973556892_91edbf19b0_z.jpg
And here's how that plain text page looks when viewing it with the Markdown Preview Plus extension.
=> https://live.staticflickr.com/65535/50973452081_4e8fcded03_z.jpg
Obviously, the custom CSS that I added to the browser extension is similar to what I use at https://sawv.org. About the only difference is the background color.
At my personal website, I created CSS to display my site how I wish other websites looked. The problem with this approach is that it's also the look that everyone else sees too, at least initially until readers enable reader mode or some other tool to change the look of my website for themselves.
My Markdown-web idea from January 2019 put the responsibility of site typography into the hands of readers. I believe this was how the web started or had planned to operate. I don't know. But it IS how Gemini functions. Readers control the typography, not the publishers.
This brings me back to my caveat. Gemini is the solution to wanting a SmallWeb.
This SmallWeb idea spotlights another problem. Daniel wants some aspects of CSS3 and HTML5 for his Web of Documents idea.
> 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 ...
But he never explained why HTML and CSS would be needed. I use CSS within the MPP extension, but that's only for me. Why should client apps access CSS that's stored on a server?
I infer that Daniel wants publishers to dictate how readers view WoD sites. How does a website author know my typography preferences? Nobody has asked me.
When viewing Gemini sites within the Kristall and Castor browsers, I prefer a dark theme.
=> https://sawv.org/2020/09/28/my-typography-settings-for-the-kristall-internet-browser.html
Here is a screenshot of one of my Gemini posts, viewed within Kristall.
=> https://live.staticflickr.com/65535/50395525192_1865da84b4_z.jpg
And this is a screenshot of a post, created by solderpunk, also viewed in Kristall.
=> https://live.staticflickr.com/65535/50395587807_a10e9c8c72_z.jpg
Just like using the Links2 browser to read the web and like using the Markdown Preview Plus extension to view plain text files on the web, all Gemini sites look the same to me when using Kristall with my preferred typography settings.
Okay, I think that it's obvious that in my opinion, readers should theme internet sites and not publishers. This eliminates the need for HTML and CSS, which should make SmallWeb browser development a little easier.
At the moment, Kristall has a bug when viewing text/markdown type web pages. It formats fine, except that blank lines get removed. Kristall's Markdown rendering is squishing lines together. It preserves spacing at the end of lines, but paragraph spacing gets eliminated. I should contact the developer. It's probably a simple fix.
When viewing text/html webpages with Kristall, the line spacing or paragraph spacing is preserved.
Below is a screenshot of my SmallWeb HTML page, https://sawv.org/smallweb, displayed within Kristall. It looks decent. Behind the Kristall browser is the Pale Moon web browser, running my simple JavaScript editor that I call Tanager. I'm using Tanager to update this post.
=> https://live.staticflickr.com/65535/50972877278_cacc2fb91b_z.jpg
And here's a screenshot of a post from above. This time, the post was viewed within Kristall. Since my md.soupmode.com test site returns a MIME type of text/markdown, then Kristall applies the Markdown rendering, except for the bug of not preserving line spacing.
=> http://md.soupmode.com/2014/05/08/lesscrowded-toledo-area-birdwatching-spots.md
=> https://live.staticflickr.com/65535/50973672722_f187fd4261_z.jpg
And here's another post from above.
=> http://scaup.org/2019/06/24/the-plastic-conundrum.md
Since the MIME type from that S3 bucket for a .md file is text/plain, this is how it looks within Kristall, despite the .md extension and the Markdown content.
=> https://live.staticflickr.com/65535/50973675907_b68ddf6733_z.jpg
I would like to use Kristall, but text/plain MIME type pages, such as those created by Len and Gruber, will appear in a less-friendly manner while those same pages appear how I desire when viewed in Chrome with the Markdown Preview Plus browser extension.
Should SmallWeb posts only be stored with a .md extension? That breaks existing sites that store text in .txt and .text files.
What about enforcing a MIME type? I would like the SmallWeb to use text/markdown, but once again, that breaks sites that currently serve text/plain.
Maybe a SmallWeb browser functions like this:
1. If the MIME type is text/markdown, then Markdown rendering is applied, regardless of the file extension.
2. If the MIME type is text/plain, and the file extension is .md, then Markdown rendering gets applied.
3. If the MIME type is text/plain, and the file extension is something other than .md, then the browser should let the reader decide how to handle the rendering. Options would exist within the browser to let readers choose which file extensions get rendered by the Markdown viewer.
At the moment, only point 1 applies to Kristall.
Regarding point 3, that's kind of how the Markdown Preview Plus extension works, although it pays no attention to MIME types. The extension permits users to choose which file extensions get rendered by the Markdown viewer.
For example, when I look at the "Advanced Options" section within the MPP extension, I see this text:
Supported file extensions
-------------------------
[X] md [X] text [X] markdown [X] mdown [X] txt [X] mkd [X] rst [X] rmd
I selected all of the file extensions, which is how I can view my .txt files, Len's .txt files, Gruber's .text files, and my test sites' .md files with the same CSS settings.
### Etc.
=> https://sawv.org/2020/06/24/quote-jun-24-2020.html
> Some links and recent HN discussions about a lighter weight web.
Text-Only Websites (sjmulder.nl)
=> https://news.ycombinator.com/item?id=23626929
Rediscovering the Small Web (neustadt.fr)
=> https://news.ycombinator.com/item?id=23326329
=> https://sawv.org/plain-text.html
### Wrap-up
Since I discovered Gemini in May 2020, this is a rare web post where I did not use the Gemini Text method for displaying links. I also embedded images, instead of linking to the images, but the images were on the small side.
I created my test Markdown-only website in January 2019, and in the two years since I started that experiment, Gemini is the only project that I have observed that comes close to representing the SmallWeb idea.
IndieWeb.org is not a SmallWeb project. IndieWeb promotes an open web.
It would be interesting to create a web browser that only rendered user-specified file extensions that contained plain text, but I don't think that I have the technical chops to complete that project. I would like this web browser to provide users with the typography options the way that Kristall does it. This is easier than creating a CSS file and loading the CSS into the browser.
How much plain text content exists on the web in the manner of Len's website? More plain text sites probably exist on Gopher and Gemini than on the web, since website authors like to create HTML.
### Mar 1, 2021
Here at my sawv.org website, I created another version of my site's homepage.
=> https://sawv.org/home.txt
(I also copied the above file to home.md for testing within Kristall.)
home.txt contains Markdown formatting, and the links point to my site's .txt files for each post. As I mentioned above, my web-based SSG saves the text markup to .txt files, and then my code converts the Textile or Markdown/MultiMarkdown markup to HTML, which is obviously saved to .html files.
The .txt file extension implies that the file contents is plain text. Whether that plain text is Textile, Markdown, or Gemini Text markup is not important for long-term storage of the text files on servers or on physical backup storage devices. It would be easier for programs to determine what type of plain text markup, if any, is contained within the file.
At my Gemini site, I use the Molly Brown Gemini server. When a .gmi file served, the server returns a MIME type of text/gemini. When .txt file is served, it's given the text/plain MIME type.
At my Gemini site, this file contains the list of my posts, similar to the homepage at my website.
=> gemini://sawv.org/posts.gmi
I copied that file to posts.txt, and within Kristall, it was displayed as plain text because of the MIME type returned by Molly Brown.
At my Gemini site, I copied the home.md version of home.txt to the root directory of my Gemini site. At my server hosting account, I have the Nginx web server and the Molly Brown Gemini server configured to return a MIME type of text/markdown for .md files.
Kristall displayed the home.md in the same manner, regardless of which site served it.
=> https://sawv.org/home.md
=> gemini://sawv.org/home.md
I modified the Molly Brown config file to tell the server to return a MIME type of text/gemini when serving .txt files. And now these two files look the same when viewed within Kristall
=> gemini://sawv.org/posts.gmi
=> gemini://sawv.org/posts.txt
At my Gemini site, I cannot imagine why I would need to store plain, raw text in .txt files. Maybe I should store my Gemini content as .txt, instead of .gmi. Gemini clients or browsers should base its styling on the MIME type returned and not the file extension.
Gemini supports the Common Gateway Interface. One of my CGI programs dynamically creates Gemini Text content. My CGI app returns a MIME type of text/gemini to make the content display properly within Gemini clients.
When I read Gemini sites, I don't pay attention to the file extensions. I assume that most use the .gmi extension, but it's not a requirement.
Whether writing for the web, Gemini, Gopher, or for the local computer only, saving plain text content in .txt files makes the most sense.
Back to Len's wonderful post:
=> http://len.falken.ink/misc/writing-for-the-internet-across-a-human-lifetime.txt
I created a Markdown and Gemini Text versions of that post.
=> http://md.soupmode.com/test-postwriting-for-the-internet-across-a-human-lifetime.md
=> gemini://sawv.org/2021/03/01/test-post-writing-for-the-internet-across-a-human-lifetime.gmi
For the Gemini version, I made the following markup edits:
* added a single pound sign, followed by a space at the start of the title line.
* added a blank line between the title and the second line that I will call the sub-title or whatever it's called in media land.
* added two pound signs, followed by a space at the start of the sub-title line.
* placed the link to his homepage on its own line per Gemini Text markup instructions, and then I added a blank line after the link, although it was not necessary.
* for the link to the Google image that already existed on its own line, I simply added the equal sign followed by the greater-than sign followed by a space at the start of the line.
* I added three backticks to its own line at the start of the code block.
* I added three backticks to its own line at the end of the code block.
That's it. The original plain text would have display okay without the Gemini Text edits, but the links would not have worked, and the code block would be displayed like the rest of the text.
But maybe that's Len's point with saving content as plain text instead of in some kind of markup text format that could go out of style some day. Len's plain text files could be processed by code and converted to another text format.
Ditto for current text formats. A Gemini user wrote a Python utility to convert Markdown files to Gemini Text files, and I use this script to get most of the editing work done before I go into the file and finish the conversion.
Regardless of where I publish content, I think that I will end the practice of inline linking and resort to placing links on their own lines. I could place the link text above the link, instead of at the end of the link as with Gemini Text.
For longevity sturdiness, typing text in Gemini Text markup will probably be my preferred format over Markdown and plain text. Gemini Text is close to plain text. Now I need to go back edit this post.
I could place a Gemini Text .txt file on the web, and it would display fine within a Markdown viewer web browser extension. And obviously, that same file would work fine at a Gemini site when the server returns text/gemini for the .txt extension.
I copied the Gemini Text version of Len's post and pasted it into Typora, the Markdown editor that I have installed on my Linux laptop, and the content displayed nicely, since Gemini Text is a subset of CommonMark. The heading one and two lines worked.
Also in that test post of Len's content, Typora recognized the three-backtick code block that exists in multiple flavors of Markdown. Typora automatically made the raw URLs clickable links with underlines. I like this default behavior with many Markdown converters where raw URLs are displayed as links, despite the lack of the greater-than and less-than symbols surrounding the URLs.
Typora wants to default to saving files with the .md extension, which is what I did. Then on my laptop, I copied that len.md file to len.gmi, and I opened up with Vim. Thanks to another Gemini user, I added Gemini Text markup highlighting to the Vim editor.
The Gemini Text version of Len's post can be saved as .txt, .md, and .gmi, depending upon what program or application layer protocol is used.
At my Markdown-only test site, I made another test post of Len's content, but instead of using Markdown, I used the Gemini Text version of the post.
=> http://md.soupmode.com/test-post-bwriting-for-the-internet-across-a-human-lifetime.md
And as usual, that post displayed fine when viewed in Chrome and the Markdown Preview Plus extension. It's a slightly enhanced version of Len's original plain text post. And plain, non-markup raw text displays nicely FOR ME and my typography prefs when viewed in Chrome with MPP.
For sawv.org, I should make document root the same for the web server and the Gemini server and let both serve only .txt files. The MIME type would be text/plain for Nginx and text/gemini for Molly Brown. My website would look similar to Len's, except I would have long text lines for the paragraphs. I would suggest people use a Markdown browser. If no such browser exists, then they should use a Markdown viewer extension.
Why don't so-called modern web browsers provide users with typography controls for how text/plain files get displayed? I don't want to see a tiny, monospace font of black text on a white background. If that's what others want to see, then they can control that within their browsers.
More screenshots of the Gemini Text version of Len's plain text post.
Within Typora the Markdown text editor:
=> https://live.staticflickr.com/65535/50993463783_0d0bdcaedd_z.jpg
=> https://live.staticflickr.com/65535/50993463843_96d99598a8_z.jpg
Within the Kristall internet browser with the file served as text/gemini from the Gemini server:
=> https://live.staticflickr.com/65535/50993463913_946bd930e9_b.jpg
=> https://live.staticflickr.com/65535/50993463973_42ed2fab6a_z.jpg
=> https://live.staticflickr.com/65535/50994275392_fff37461d1_z.jpg
Within Vim with the file loaded having a .gmi extension and Gemini Text syntax highlighting added to Vim:
=> https://live.staticflickr.com/65535/50994164101_b1dcc7a473_z.jpg
=> https://live.staticflickr.com/65535/50993464208_c4ea397b00_z.jpg
The Gemini Text markup posted to my Markdown-only test website and viewed within Chrome with the Markdown Preview Plus extension:
=> https://live.staticflickr.com/65535/50994275602_4ca2312374_z.jpg
=> https://live.staticflickr.com/65535/50993464323_f7b44418f8_z.jpg
=> https://live.staticflickr.com/65535/50994164356_8331399ea5_z.jpg
### Maybe my SmallWeb final thoughts
(Probably not)
-------------------
On the authoring, publishing, server side of things, I would support the SmallWeb by starting with Len's approach to web publishing ...
=> http://len.falken.ink/misc/writing-for-the-internet-across-a-human-lifetime.txt
... and, optionally, adding some Gemini Text markup ...
=> https://sawv.org/2020/07/01/text-gemini-markup.html
Len would not use Gemtext markup, but I would, and both posts would display fine, according to the readers' prefs that are stored within a Text Markup Browser, a Markdown Browser, or a browser extension.
The files should be saved with the .txt extension, but if people want to use another extension, such as .text, then that's fine too as long as the text/plain MIME type is returned.
Optionally, the same .txt files could be duel-posted to the web and Gemini by having the respective servers point to the same document root directory. The web server would return a MIME type of text/plain, and the Gemini server would return a MIME type of text/gemini.
For SmallWeb publishing, that's it. Not much. I suppose authors could optionally add some kind of feed file (RSS, Atom, JSONFeed) to their web and Gemini sites. I like the Gemini community's new Gemini feed format, which is a simple text/gemini file.
Anyway, not much is required, in my opinion, to support the SmallWeb on the server or the authoring side. Plain text. No need for converting to HTML. No need for CSS nor client-side JavaScript. A web server serves up text/plain.
Heavy content cannot be embedded within the text/plain pages. Links to the heavy content, however, can point to the images, videos, etc. It's up to the SmallWeb browser developers to decide whether to support heavy content or to other applications load the heavy content.
It's up to authors to figure out how to get their content on their servers. I would continue to use one of my web-based static site generators to store the text markup to the server, like I do now for my web and Gemini sites.
Editing locally on my laptop with Vim or Typora and using SFTP to place the files on the server would work for me too, but that might not work well for non-tech users.
My Kranz system for writing locally and storing the content on my Gemini site could be an option.
=> https://sawv.org/kranz.html
I created small client and server apps to make Kranz, and that means installing an always-running server app on the VPS that I lease.
Those will probably be my three options for authoring content in the future for my web and Gemini sites. If I point both servers to the same document root of .txt files, then I only need to use one of these methods to manage content.
* web-based SSG
* local editor plus SFTP
* Kranz
Currently for Kranz, I edit locally with Vim or Typora, and then I use the Kranz client app to connect to the Kranz server to deliver the content. Eventually, I would like to duplicate my web-based JavaScript editor that I call Tanager and make it a desktop app in Electron or something similar. I would edit and save the content to the server within the desktop version of Tanager.
But local-editor-plus-SFTP requires no code from me. I would not need my web-based SSG app that I call Sora. I would not need Kranz. I would use existing editors and an existing file transfer protocol. It's a lo-file, elegantly simple approach to publishing. I would edit my Gemini feed file and atom.xml files manually.
I like the Gemini feed format, but obviously, it's not used on the web, although why not make it the feed format for the SmallWeb? Since all SmallWeb sites would look the same to readers, then I don't see a need of viewing feed content within feed readers.
On Gemini, the primary content stored within atom.xml and Gemini feed files consists of the post title, date published, and the link to the post. For most Gemini site owners, they don't include a snippet of the post nor the entire post within their feed files.
On the bloated web, feed reading people prefer to read the entire post within a feed reader, since the content will look the same, regardless of the site. But all Gemini sites look the same to readers, and the same would occur on my idea of a SmallWeb.
When feed-reading users click a link to a post within their feed readers, they know that on Gemini and the SmallWeb that they will be in control with how the sites appear to them. They know that the Gemini and SmallWeb sites won't be bloated with crapware and embedded heavy content.
Here's the first part of my Gemini feed file that is served as text/gemini.
```
# Sawv's E/N Gemsite
## Ramblings about Everything and Nothing
=> gemini://sawv.org/2021/02/21/gemini-is-superior-to-a-web-subset.gmi 2021-02-21 - Gemini is Superior to a Web Subset
=> gemini://sawv.org/2021/02/09/re-can-someone-add-some-more-html-tags-please-dries.gmi 2021-02-09 - Re: Can someone add some more HTML tags, please? (Dries)
=> gemini://sawv.org/2021/02/01/re-perceived-relations-between-gopher-gemini-and-http-len.gmi 2021-02-01 - Re: Perceived Relations Between Gopher, Gemini, and HTTP (Len)
```
Within a Gemini browser, the entries of the Gemini feed file would look like this with the following text lines being links to the full posts.
```
-> 2021-02-21 - Gemini is Superior to a Web Subset
-> 2021-02-09 - Re: Can someone add some more HTML tags, please? (Dries)
-> 2021-02-01 - Re: Perceived Relations Between Gopher, Gemini, and HTTP (Len)
```
It's an easy format to parse. The Gemini atom.xml versions are lightweight too. Here are those same entries in my atom.xml file, served as application/atom+xml.
```
gemini://sawv.org/2021/02/21/gemini-is-superior-to-a-web-subset.gmiGemini is Superior to a Web Subset2021-02-21T20:00:16Zgemini://sawv.org/2021/02/09/re-can-someone-add-some-more-html-tags-please-dries.gmiRe: Can someone add some more HTML tags, please? (Dries)2021-02-09T20:00:16Zgemini://sawv.org/2021/02/01/re-perceived-relations-between-gopher-gemini-and-http-len.gmiRe: Perceived Relations Between Gopher, Gemini, and HTTP (Len)2021-02-01T22:29:37Z
```
Link, title, and date, that's it for the feed files. Of course, authors can include more content in their XML feed files, but the Gemini feed format only uses link, title, and date. If the post does not have a title, then obviously some text snippet gets used.
Many Gemini site authors display their homepages in the Gemini feed format, which makes their homepages also their feed files, like Len does with his plain text website, and like some IndieWeb authors who format their homepages as h-feed files. The IndieWeb supports making HTML pages be feed files with the use of Microformats.
I suppose that some kind of dreaded XML format would still be used for the SmallWeb, since every feed reader supports Atom and RSS. It's up to SmallWeb site authors to decide what feed format, IF ANY, that they wish to support. It should not be a requirement for SmallWeb authors to create feed files.
Many people prefer email newsletters and email notifications about new posts over using feed readers. Email newsletters vs feed reading is an argument for another post. I say support both if it's that important.
But I DO think that it's unnecessary to place the entire content of posts within feed files on the SmallWeb, since the SmallWeb will be safer and saner for reading than the normal, bloated web.
On my Gemini site, I lists my posts on a separate page and not on my homepage. But I do not use the Gemini feed format because it's my site, and I prefer to lists my posts according to my preferences. But I maintain another file that uses the Gemini feed format. I limit this feed file to 10 to 20 posts like I do with the atom.xml feed file. But I list dozens of links on my main posts page.
At my Gemini site:
* homepage - index.gmi
* page one of my posts page - posts.gmi
* Gemini feed file - feed.gmi
* Atom feed file - atom.xml
I think that the reason why the Gemini community started supporting its own Gemini feed format was to make it easier for users who may not have software to create RSS or Atom XML files automatically. The Gemini feed format is easier to edit manually.
Here are excerpts from the post about the proposed Gemini feed format:
=> gemini://gemini.circumlunar.space/docs/companion/subscription.gmi
> This document describes a convention whereby Gemini clients can "subscribe" to a regularly updated Gemini page (such as the index page of a gemlog) even in the absence of a full-fledged syndication technology like Atom or RSS. It is intended as a lightweight alternative to such technologies to lower the barriers to publishing serial content in Geminispace which can be easily followed without tedious regular manual checking of bookmarks.
> In particular, it is an explicit goal that a simple, manually-updated, human readable index page of the type content authors would likely create anyway should be able to subscribed to without any special changes being necessary. Obviously, such a convention will be less powerful than more complicated technologies such as Atom and will not work as well as more complicated technologies in all conceivable use cases. Nevertheless, it is expected to function adequately for a wide range of reasonable use cases. Nothing in this convention prevents content authors from simultaneously publishing an Atom feed if they wish to. In fact, this convention can ease the generation of said feeds.
> The primary shortcoming of this convention is that it does not convey a time of day at which posts are made nor a timezone in which the date stamp is valid. This makes lightweight subscription a poor match for applications where multiple updates are expected each day and the relative order of updates (both within and across feed sources) is important, such as following breaking news headlines, weather updates, traffic conditions, etc. Such applications are strongly encouraged to instead implement more robust subscription technologies such as Atom or RSS.
> This shortcoming is not expected to have serious implications for a wide range of common and valuable activities in Geminispace which operate at "human scale". For example, this convention is perfectly viable for an individual reader using their local client to subscribe to ten or twenty hand-picked gemlogs which update every few days with non-time-critical content about people's daily lives, hobbies, opinions on the state of the world, recipes, photos, etc. It is very rarely important to read content like this which was written by Alice on Wednesday morning before that which was written by Bob on Wednesday evening, or to know exactly when each person wrote their posts. If the time of day is relevant to the post content, the author will surely mention it.
Good points by solderpunk.
At my Gemini site, I prefer to edit my Gemini feed file and my atom.xml file manually. I create a lot of noise content, such as weather info about Toledo, that does not need to pollute my feed files. I prefer to include only my worthwhile posts in my feed files. I like the idea of having the atom.xml file generated automatically based upon edits made to the feed.gmi file.
On the SmallWeb, I would make it feed.txt. Aaron Swartz created an RSS3 spec that was text-based. It was a joke, created by Aaron, during the idiotic feed wars of the early aught years.
=> https://sawv.org/2018/08/21/rss-30-jokey-but-useful-spec.html
The Gemini feed format is simpler.
SmallWeb publishing should probably consist of:
* .txt plain text files (Gemtext markup is optional)
* MIME type is text/plain
* at least one feed file format, mainly RSS or Atom
If the SmallWeb also adopted the simplistic Gemfeed format, and if SmallWeb browsers were created, then maybe feed reading support could be added to the SmallWeb browsers.
But feed-reading people already use their favorite feed readers, and they would prefer an Atom or RSS feed file to consume, even if they have to use a SmallWeb browser to read the SmallWeb sites.
On the client side, I think that a SmallWeb browser could borrow ideas from Links2 and Kristall. I would prefer that the typography controls be as extensive and as easy to set as what exists within Kristall.
If SmallWeb browsers add feed-reading support the relies on either the Gemfeed format or an established XML format, that would be a bonus. This could be what differentiates SmallWeb browsers from each other. The built-in feed reading support may not be as adequate as what experienced feed-reading people are accustomed to. I doubt that people would want to use two feed reading apps: one for the bloated web and one for the SmallWeb.
That's why SmallWeb sites should create RSS or Atom files if the authors desire to support feed readers.
On Gemini, the so-called "fancy" Gemini browsers contain different features for power users. The text-based Gemini browsers, however, offer enough features for many other users.
Browser diversity would explode likewise on the SmallWeb, and these browsers could actually be lightweight apps and not mini operating systems nor virtual machines. The Light Phone could probably add a SmallWeb browser to its list of apps.
In my opinion, Gemini defines how a SmallWeb should function. The HTML and CSS fanatics can stick with the normal web. No need for responsive design on the SmallWeb. Not much tech needed on the SmallWeb. The programming activity would occur in SmallWeb server development, SmallWeb browsers, and utilities.
Does a SmallWeb author need to use a web server like Nginx? Depends. Gemini supports a very limited amount of the Common Gateway Interface. Should the SmallWeb do likewise? I don't think so, since the normal web is close by.
Actually, since I use one of my web-based SSGs to maintain my SmallWeb and Gemini sites, then the web server would need to support server-side programming. I like to search for content on my website via a text input form field and server-side programming.
New SmallWeb servers would probably not be needed, since the sites will still use HTTP/HTTPS. It's getting confusing. This is why Gemini is so nice because it's a clean break from the web and not a subset.
If authors prefer a web-based method to maintain their SmallWeb sites, then their CMS would obviously support the modern web and not the SmallWeb. The SmallWeb will probably not define a subset of HTTP. The SmallWeb will focus more on the content, and how it's displayed to readers.
I can use Nginx to run my CMS code that I use to manage content on my web and Gemini sites, and I can use Nginx to serve .txt files to SmallWeb clients.
Most of the SmallWeb programming would occur on the client-side with SmallWeb browsers and extensions for the modern web browsers.
If the SmallWeb DID define a subset of HTTP/HTTPS, then a starting point could be solderpunks "SafeWeb" server.
=> https://tildegit.org/solderpunk/shizaru/
But that's too big for the SmallWeb, since I'm defining the SmallWeb as serving text/plain as its main content. No HTML. Other content types could be served over the SmallWeb like with Gemini, but that content would not be allowed to be embedded within the text/plain pages. Like Len and the Gemini spec suggests, links (URLs) can point to other content, such as images, videos, audio files, and complex math docs.
Markdown provides a method to embed images, but in my opinion, this should not be allowed for the SmallWeb. Authors can link to the images. Readers can decide whether to view the heavy content. The main page should be text, which makes the download lightweight and fast.
After all of this thinking, it IS easier to create a new application layer protocol spec from scratch than trying to create a subset of the web. It will be interesting to see if the entire Gemini spec is smaller than this web post.
-30-