💾 Archived View for uscoffings.net › gemini-notes.gmi captured on 2023-09-28 at 15:55:03. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-03-20)
-=-=-=-=-=-=-
[date: 2022-03-27 .. now]
These are my notes, discovering best practices while sharing and exploring in Geminispace.
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:
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...
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:
Headers:
Gemini clients honor blank lines. My evolving standard:
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.
DirectoryTitles = true
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.
What is best practice when serving large files?
What is best practice for attaching metadata to files?
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`:
" Handle long lines: " show wrapped lines, not "@" set display=lastline " go up/down more intuitively through long lines nnoremap j gj nnoremap k gk
geminid
molly-brown
amfora
AV-98
castor
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.