gemini://thfr.info/gemini/gemini-copernican-turn.gmi

Gemini's Unique Opportunity to Return Enlightenment and Democracy to the Internet

Appearing decades after the introduction of Gopher, the Gemini protocol can only be understood as a reaction to the evolution of the World Wide Web (WWW).

While quite a bit has been written about this among Gemini users, YouTuber Brodie Robertson provides one of the best summaries of the direction of the WWW, and how the "Small Web" (or "Smol Web") provides a counter movement. He breaks it down into the 3 axes:

The enthusiastic reception of Gemini may at first seem surprising, given the very constrained nature of the protocol. For example, it intentionally doesn't support staples of Web pages, like JavaScript, inline images, inline links, tables, or even headings below the third level.

To get a sense of the enthusiasm that Gemini is able to generate, take a look at videos from the likes of Chris Were, HexDSL, DistroTube:

Let's take a look at the deeper problems with the WWW and a somewhat philosophical interpretation of Gemini's reaction to it.

The WWW has evolved significantly since its inception. I have outlined Brodie Robertson's three axes characterizing Big vs. Small Web above (functionality vs. speed, design vs. substance, convenience vs. privacy). So why did it evolve this way?

I would argue that the driving forces behind this relate to larger societal issues.

The WWW has made "guardianship" of the user (German: "Unmuendigkeit") a core tenet of its structure:

"Regular users can't be expected to understand how the technology works." - As a consequence, more and more sophisticated technology runs out of sight, like tracking, profiling.

Rather than making your own web presence, use social media. Facebook, Twitter etc. take care of all the design, styling, for you!

YouTube and Twitch even monetize your content for you. You don't need to take care of any of it! (of course they get an even bigger slice of the pie than you; and they get to decide what makes it on the front page and what gets banned)

Even skilled and knowledgeable users will often find it hard to impossible to create webpages that live up to the "state of the art" of webdesign, as this is being pushed by billion-dollar companies with whole departments that work on nothing but that.

The design of this is based on the "Chain of Trust." "Trust" in its common usage is a very personal matter, in many regards. Not only does it tend to extend to another concrete person - a friend, a face. Even if it is not directed at a person (e.g. trust in "science", "the government", "the good in human beings"), it is not a one-size-fits-all, but reflects the individual experience and personality.

The technocratic disposition of the WWW could not be more obvious than in what it does with its fundamental security architecture. HTTPS has been designed to revert to delegate "Trust" to so-called "Certificate Authorities." There is a lot of paternalism in this approach. The equivalent in human relations would be telling someone: "You are unable to know who to trust and who not to. Let me decide that for you - here is a list."

As a consequence, trust on the WWW has turned into a green padlock item (the most commonly used representation of a "secure connection" in popular browsers). Users rely on it when they check their banking websites, for example. They don't realize how it can't represent their trust towards the bank, but only the users' trust in the browser and the WWW's implementation of "Chains of Trust."

The CAs are faceless entities towards the user. Yet they hold the keys to all trust relations on the WWW. As a consequence, they represent formidable targets for attackers, be it rogue criminals or nation states.

The appropriate counter movement to this trend would be for the individual users to reclaim the decision about trust relationships.

All of the above shapes the client-server relationship at the heart of the WWW. Servers are caught up in the double hamsterwheel of design and monetization. This pushes them to deploy more and more behind-the-scenes technology - cookies, webapps, browser fingerprinting are just some examples.

The clients are doomed to serve primarily as mostly passive recipients of this technology firehose. Yes, there are plugins, for example NoScript, Privacy Badger. They curb but the most egregious excesses, and their limited adoption means that they are not in a position to turn around the trajectory of the WWW's evolution.

The user is put in a position of helplessness. Many pages are so complex including their styling and scripts, that even technologically sophisticated users are unable to make sense of the code behind it. Webpages try to impress or further their corporate goals with lots of hidden magic, especially user tracking.

In a word, the WWW is not an internet for the people, but for the servers of a handful of key players on the web.

Taking a little detour into history of philosophy, Immanuel Kant coined the term "Copernican Turn" for a paradigm shift that turned the focus of philosophy from the world to the individual (much simplified, and probably not entirely accurate summary).

This is based on Copernicus' paradigm shift in astronomy that declared that the Sun rather than Earth is at the center of the universe.

Such matters don't always translate well into the realm of technology, but in the case of Gemini, it would appear that it is at least an effort in a paradigm shift compared to the WWW.

The Gemini protocol, while often described as occupying a middle ground between Gopher and the WWW, is actually much closer to Gopher, plus solving a few of its limitations (most notably the lack of encrypted communication).

There is no scripting language, no user agent, no cookies. Awareness of dangers to privacy has been integrated into its design.

Besides logs of connections and requested resources, the server won't have much to leverage to secretly track the user. (Note that client certificates can provide a way to identify a user, but the control over their lifetime and use remains with the user.)

The server is largely restricted to serving the requested resources.

On the other side are the clients. While taking lots of inspiration from Web Browsers, it is interesting to see how client software steps up.

I will take the Gemini client Lagrange as an example, as I'm rather familiar with it and it is an excellent example for what I want to convey.

One of the first things that users of Lagrange are curious about are the "favicons" (not really, but let's go with this term for now) of the different pages. They look kind of like the icons people are used to from the tabs of their web browers. It turns out that this is all client-created to give different domains a distinct visual style, without loading additional non-gemtext files.

Lagrange also applies different background-foreground color schemes to different domains.

Of course this doesn't reach the level of sophisticated design that is possible with server-side stylesheets on the WWW, but the mere fact that clients replace this without subverting the specification of Gemini is an innovation and increases the relative role of the client.

Cryptographic communication on the internet addresses 2 key challenges:

The former one is the easier one, as long as a key exists that is only known to the 2 parties.

The latter one is much trickier, and is at the heart of the ongoing debates in the Gemini project about the "Trust On First Use" model in the current specification of Gemini.

In a nutshell, if you don't have confirmation that the other party is who they claim they are, an attacker can pose as the server that you are trying to connect to, but collect your information and feed you modified data.

How can you _know_ that the other party is who they claim they are?

There are essentially 2 different ways to respond to this, and this goes back to the issue of "guardianship of the user" and the "Copernican Turn" detailed above:

A. You can know the identity of the other party by asking a third-party authority that vouches for it (like a "Certificate Authority", with all its problems of depersonalized trust, see above), or

B. you know because you have another exchange with the other party where you received an unforgeable representation (like what a seal was supposed to provide for letter communication centuries ago). You are the judge if the exchange is sufficient to alleviate doubts about the other party's identity sufficiently. Examples of such an exchange include: receiving it in person, e.g. at a conference, obtaining the key hash on the person's business card, HTML page, or social media.

With public-key cryptography, both of these approaches amount to confirming that the public key (or certificate) that you received belongs to who they claim they are by having another communication "out of band" (that is not via the same connection) where the public key that you received from the server matches the public key sent on that other channel. Approach A resolves this with a third-party that vouches for it. This depends on trust in the third party, and as history has shown, they can be compromised.

Approach B achieves the same thing, but here there is no pre-selected authority like a CA that is the only option, but rather this is open to finding a different way to communicate with the server operator/representative. The main advantage is that you don't need to rely on the trustworthiness of a third-party that may or may not be compromised at some point. The main disadvantage is that the honus of the route of exchange and the decision to trust falls on you as the user.

Note that approach B can be facilitated by the technology at play. This has been shown by software such as the instant messaging client Conversations and the OMEMO protocol, and is the subject of another article of mine:

In summary, I hope to have shown a dichotomy in the use of technology that in some ways parallels themes from the history of philosophy. In many ways, the Gemini protocol has opened up the realm of possibilities, not despite, but because of its restrictions. I think that this is a reason for the sometimes overwhelming enthusiasm for it.

Debates about the specification of the Gemini protocol are still going, and include topics like extensibility (probably a bad idea) and the approach to cryptography. I hope that this article illuminates how Gemini draws much from its appeal from its opposition to a "guardianship of the user" mentality with a concomitant divide between "platforms" and "users". There are unique opportunities to strengthen the focus on the user and her_his immediate extension, the client software, to bring balance to the internet.

Gemini's Copernican Turn

Gemini - A New Beginning

Hierarchism of the WWW vs. Exit out the Guardianship State

The Certificate Authority (CA) Model - the Depersonalization of Trust

All Power to the Server

A Copernican Turn

Gemini: Restrained Servers, Creative Clients

Domain Distinction

Epistemology and Cryptography

Conclusion: Technology at a Crossroads