💾 Archived View for jsreed5.org › log › 2021 › 202105 › 20210519-gemini-standards.gmi captured on 2023-12-28 at 15:53:22. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-04)
-=-=-=-=-=-=-
---
The Gemini mailing list has recently been full of discussion about possible standards for the protocol--everything from semantics to file integrity checks to microblog formatting. Some of the proposals are quite attractive; others I find rather cumbersome. The discourse, however, has led me to think about the idea of Gemini standards in general.
Gemini as a protocol is extremely loose. Much of the standardization that has arisen in the last two years is community-driven. Users and capsule operators share ideas, and if those ideas have merit, they're replicated and spread organically. This is one of Gemini's strengths as a "small web" protocol; its community is small enough and interconnected enough that its evolution is natural and self-driven.
In Geminispace, if users see a capsule layout or data format they like, they can copy it to their own capsules. If they want to modify it to suit their individual tastes, they're free to do that too. No standards are violated, because there are no standards to violate. That means operators can be creative in how their content is sorted, formatted and displayed. They can make their capsule unique and build something that is truly their own space.
This process is a very human one and I believe helps to make Gemini so approachable to new users. There isn't a "wrong" way to build a Gemini capsule. All a prospective capsule operator needs is a device or service capable of hosting content and serving it with the Gemini protocol. Beyond that, he can write what he wants and host what he wants. That is a kind of freedom long lost in the World Wide Web.
Standards, on the other hand, are quite inorganic. By their very nature, they are not to be violated once implemented. Why? Often the reason is that automated processes rely on content to follow specific constraints, and violating the standard breaks compatibility. This makes the protocol inflexible and requires new users to become familiar with the standards before being able to inter-operate smoothly. Once a protocol is inflexible, creativity is stifled, and the personal feel of the space rapidly disappears.
This is not to say that certain conventions aren't useful. For example, the original specification for Gemini explicitly states that headers in gemtexts are primarily meant to be used for parsing purposes. This makes it easy to implement things such as tables of content and feed generators, but gemtexts are not required to have headers. If an operator were so inclined, he would not violate the specification by refusing to include them. That is his choice and he is free to make it.
Of course, simply because a standard exists does not mean the standard always has to be followed. The practical problem with this is that the very existence of a standard means that operators are implicitly encouraged to follow the standard--and thus discouraged from using a different standard. This is especially true when standards become so widespread that not following them causes one's capsule to be left out of the larger ecosystem entirely. Such a situation makes the prospect of operating a capsule unattractive to new users, which I doubt is what the Gemini community wants.
I see standards as being more useful for machines then for people. Machines, however, are not the focus of the "small web". The small web is meant for people. I believe we as a Geminispace collective should not lose sight of that.
---
[Last updated: 2021-10-28]