My Gemini Pod Notes

[date: 2022-03-27 .. now]

These are my notes, discovering best practices while sharing and exploring in Geminispace.

Context

The first thing I notice about Gemini (keep in mind I haven't touched Gopher in 20+ years) is the lack of subtle contextual cues, to which I have grown accustomed with with the web. At first, it makes me feel lost. It's similar to reading a bare-bones epub. Rip the cover off a physical book, erase the formatting, tear out the copyright page. The content is what matters... and yet if you just start reading words with no context, it is more difficult to quickly know if the content _does_ matter.

Consider the non-content cues you get while on the web. The lack, or presence, or type of each of these immediately set up a mental frame in which you parse the content:

style sheets

image styling

ads

date

content density

Linkedin link, Facebook link, Google login prompt, etc.

favicon

...etc...

If the site has a political bent, you might be able to place it on the spectrum by image styling alone. A prominent Linkedin link might indicate a humble-brag site by a software engineer. Dense current content, old-school HTML with no CSS, manually maintained links, could be worth learning from, because the author is clearly values the topic far more than the medium (du jour). Excessive ads with disjoint Q/A format is an auto-generated garbage AI site. You know these patterns as well as I do.

With Gemini, I can't immediately categorize sites.

But maybe that's the pleasure of Gemini. We need to drop the stereotyping, slow down, and read, and take the chance that it may be worthwhile. For this (brief?) wonderful moment, we are once again all human. Remember the joy of discovery that the textual internet once offered.

Since the reader has put forth the effort to be here, I believe that puts some onus on the writer, to make the content meaningful.

So next, let's think about...

Content

Gemini seems better than HTTP/HTML/Markdown for sharing knowledge, because it forces focus with the constrained design. When I cannot refashion my older notes into this limited format, I usually realize that's because my notes aren't enough to be worthy of sharing. Gemini drives quality up, due to being deliberately constrained.

Here are the guidelines I follow when converting content:

Formatting

Headers:

For small documents, the title is H1 and the content starts at H2. For large documents which need more nesting, the content can use H1 also.

Gemini clients honor blank lines. My evolving standard:

Paragraphs are separated by blank lines.

First- and second-level headers are followed by blank lines.

Third-level headers are not followed by blank lines.

Bullet lists usually followed by (but are not preceded by) blank lines.

Naming

How should files and directories be named? Naturally with capitalization, spaces, etc? Or a more command-line friendly scheme?

Gemini supports URL encoding. Passing those URLs around is ugly but functional. Creating URLs by copying from the command line into gemtext is simpler if URL encoding is not needed.

Molly Brown has an option to use the first title in a document as its name in a directory listing. This is nice, but inconsistent with direct linking, unless I name files to match their H1 titles.

The trade-offs here are probably no different than with HTTP. So why am I considering this now? I suspect because creating content via Gemini feels more permanent than via HTTP. With HTTP, there were multiple layers separating me and my content from the user (static site generators, etc.) Furthermore, the sands were constantly shifting due to generator/framework/CSS updates. As soon as I nearly had a site, the static site generate changed incompatibly, and forced me to reorganize my content. (Lesson: less is more.)

Currently no clear winner re: naming.

File Size

What is best practice when serving large files?

Serving links of more than a few MiB via Gemini without a notice is probably unfriendly.

molly-brown serves up directory listing links with the size. Perhaps similar could be done for explicit local file links.

Possible to use http for larger links.

Better to stick with Gemini if possible, and reconsider the division and size of the download. Break up downloads if appropriate, or recompress images (eg: the native compression of cameras is terrible). This effort is worthwhile, because (as noted above in `Naming`), putting content on Gemini feels more stable and long-term than HTTP.

Metadata

What is best practice for attaching metadata to files?

Date ranges (created, modified, ...). I could have a convention to note dates within gemtext documents.

Tools

Editor

The long lines of Gemini might be challenging for some editors.

I prefer vim, but the default configuration of vim does not handle long lines intuitively. In particular, display and navigation treat long lines as a single unit. For example, if you navigate "down" while the cursor is somewhere on a long line, the cursor will jump down to the _next_ line (logical line, not visual line), perhaps scrolling the screen a lot. I find that strange behavior for a "visual" editor.

Here are changes I use in my `~/.vimrc`:

Servers

geminid

seems to not parse the path

molly-brown

just works...

parent link of automatically generated directory listings don't work when the parent link has a space in it? TODO research this...

Clients

amfora

good!

I would prefer that preformatted blocks were somehow visually distinguished

AV-98

might grow on me...

castor

GUI

less functionality: no bookmarks, etc

does not indent wrapped bullet points

significantly slower handling large number of links

crashes on some certs (maybe I had no CN?)

Old machines

Technically possible to do TLS in FreeDOS. I think I read that Links maybe has it? Real question is how slow it is (especially the handshake?) on old physical hardware. I have an interest in creating a Gemini client for ELKS (Linux for ancient 16-bit x86), but TLS is the problem. Other people have created proxies that strip TLS. Maybe functional but not satisfying.

I work on ELKS occasionally, and would like to start focusing on Gemini.

https://github.com/ccoffing/elks