gemini://the.web-is.fail/smol-surprises/

Smol Surprises

Here are a few details on some of the things that you may find surprising about the experience of exploring the Smolnet.

No inline hypertext

The simple SmolNet protocols, Gopher and Gemini, are very simple indeed. One of the features you may be the most surprised to find missing, is that there is no hypertext (links) in the middle of otherwise-ordinary text! Links are always found on a separate line by themselves, apart from any non-linked text.

If a line or paragraph starts out being ordinary text, all of the rest of that paragraph will be ordinary text as well. If a line starts out being a link, the whole line will be a link.

You will find that in practice this isn’t as cumbersome as it may sound, and it may even be a little bit freeing to have all the links clearly marked, with nothing tempting you to click on things before you’re even finished reading a sentence. Or you may find it irritating—either way, it’s an inseparable part of surfing the SmolNet.

No (or little) text formatting

Gopher and Gemini both lack a way to specify that some portion of text should be rendered in bold, or italic, or as any particular kind of font.

Gemini _does_ have a way to specify that a line is a “heading” (section title), or “preformatted text” (typically, displayed in a monospace font). But these formatting notes are still not specific about formatting, beyond these mild clues, and always apply to the entire line/paragraph.

Some sites may occasionally try to insert formatting in the form of terminal escape sequences, which can inject bold, underline, italic, or color into text. However, while some clients can support this, others may render strange characters as part of the text, instead. For this reason, it is generally avoided to do this—the exception is that it is often used as part of displayed “ASCII art” (aka “ANSI art”)

(Does your viewer support ANSI formatting codes? Check the next line!)

A [1mbold[0m word, and a [32mgreen[0m one

(Mostly) no auto-loaded images

This has already been mentioned, but any images that might be linked from a page, are generally not loaded automatically. There’s nothing technological actually preventing a viewing program (client) from doing so... but the SmolNet protocols do not intend for clients to autoload anything, and so in practice, they don’t.

Thus, online art galleries and the like are possible, but you should expect to click on each image individually in order to view them: you won’t generally find a page that already has a pageful of images already displayed for you (because most client programs don’t support it).

When you click on an image, your client may just load it to display directly in the page view that you’re on—or your client may just “follow” the link and show it as a page on its own.

(Gopher and Sparta) Can’t distinguish aborted downloads from completed ones

Neither Gopher nor Gemini (nor Spartan) provide content-length information when sending a resource. In the case of Gopher, this means there is no way to distinguish the case where a download completed successfully, or the case where the connection was lost prematurely. In the case of Gemini, a feature of the TLS encryption layer is used to indicate when the download is complete.

In the case of text-file downloads, Gopher does have a crude means to indicate the end of the download, but it is unreliable. In the case of binary downloads, there truly is no distinguishing the cases at all, unless the site provides the user with direct information about the file's exact size, elsewhere on the page.

Text queries, instead of form submission

On a website, a form can appear within a page, with a number of input fields, buttons, and dials.

On the SmolNet (both Gopher and Gemini), a page can request a single text input from the user. Unlike a web form, this request does not appear as part of page content, but is prompted directly by the client when it is requested to do so (for example, via a popup window, or a special query prompt).

With the Gopher protocol (also Spartan), the link itself will indicate that a query string should be provided, and so the user will be prompted before a request is sent to the server.

With the Gemini protocol, the resource is first requested, and the server then rejects the request with an input prompt. The client then re-issues the resource request, this time with the user’s input included.

Self-signed TLS certificates are permitted

Gemini promotes a Trust On First Use (TOFU) policy for self-signed server TLS certificates. In general, clients will not warn the user when encountering such a certificate (some clients may make this a configurable setting).

However, if the self-signed certificate differs in a subsequent session, from what the client saw the first time, the client will usually refuse to connect until the user acknowledges that it should proceed anyway.

Among the advantages of this approach are:

anyone can host a Gemini server, without the need to pay exhorbitant fees to a Certificate Authority
you can use a certificate with an expiration date set far enough into the future, that it will not need renewing for the lifetime of the site
does not depend on the authority of a centralized system of authority (for TLS certificates, at any rate)
you will notice if a site you’ve used, is subsequently hijacked due to their domain name expiring (and reassigned to someone else’s control)

Some disadvantages include:

if your first encounter with a site suffers from a MITM attack, etc, you are substantially less likely to mmediately discover this event

Logging into Sites/TLS Identities

In general, Gopher sites (often known as “gopherholes”), do not have logins, or any user-specific content. It is not intended for servers to maintain any client state—only to respond to requests and queries.

For Gemini sites (often known as “capsules”, or “gemcaps”), logins do exist on some sites, but logging in with a username and password, though commonplace on the web, is unusual in geminispace. Instead, since Gemini requires TLS-encrypted connections at all times, it is typical for users to identify themselves by using a specific TLS client certificate, often known as “identities”. Many Gemini clients offer the ability to create and manage these.

Just as, if you use an in-browser password manager and try to login using a friend’s or a public web browser, you won’t be able to (unless you remember the password—but memorizable passwords are usually insecure!), in the same way, if you try to log into a gemcap on a different browser (perhaps just even on a different device that you own), you’ll find that you cannot, unless you first transfer your identity’s certificate and private key (never, ever share that to others or to any site!) to the client on the other device.

Understanding Gopher links

With both the HTTP web protocol, and the Gemini SmolNet protocol, you ask for a resource, and when the server sends you that resource, it will also include information about what _kind_ of resource it is (the “Content-Type”).

The Gopher protocol (another SmolNet protocol), does not work this way: the server does not tell you what kind of resource it is, at the time that you are fetching it; instead, the *link* to that resource will contain that information. It is therefore necessary for Gopher _links_ to include information about what kind of thing you will be fetching, _in_ the link.

A typical gopher:// link might look like:

gopher://sdf.org/1/phlogs/

See the “/1” in there? That indicates that this is an “index” page, which is the type of Gopher content that can contain lines of either links, or text. The resource itself is /phlogs/.

The “/1” is never actually sent to the Gopher server - it’s there for the client (browser) to know how it ought to interpret the resource, once it arrives.

The type indicator always comes between the hostname (sdf.org, here) and the resource selector (/phlogs/). Other common types include 0 (plaintext file), 9 (binary file), and either g or I (GIF, or any other type of image, respectively).

The SmolNet is a rather small community

As a consequence, things happen at a slower pace here, and new content is typically at a stream’s trickle, rather than a river’s flood. There may also be less demographic diversity amongst users.

To give you an idea *how* small: at the time of writing, a fairly popular Gemini aggregator found an average of around 4 new gemlog posts per day to include in its feed, over the past week. Cosmos, a super-aggregator (aggregator of feeds from various aggregators), averaged about a dozen a day, maybe a bit more.

“Bongusta!”, a Gopher aggregator, has had an average of 4 or 5 a day in the past week, excepting exactly a week ago there was a sudden influx of a couple dozen or more.

There are hundreds, possibly thousands, of users on smolnet, who could still reasonably be termed “participants”. Not all of them are regularly creating new content. A few are maintaining vital services, and some of these are writing posts on occasion. There are probably people writing gemlogs or phlogs at a once-a-month pace, or even more seldom. And of course, not nearly all capsules are logs of some sort, so there's presumably plenty that's not tracked by aggregators.

In addition, there are, presumably, people who've never bothered to submit themselves to an aggregator, or are deliberately avoiding indexing or aggregation. I know of at least one such.

...Of course, whatever's difficult for an indexer or aggregator to find, is also liable to be difficult for an individual user to stumble across. So the question of whether they exist or not may be immatterial to the question of just how small the “small internet” will feel.

--
Back to the start page

Copyright (C) 2026 Kado <---@---.--->
If you email me about this site, please include "WEBFAIL" in the subject.
This site (the.web-is.fail) is licensed under the CC BY-NC-SA 4.0.