Réflexions autours de Gemini

• https://gemini.circumlunar.space/
• gemini://gemini.circumlunar.space/

Gemini est avant tout décrit comme un protocole internet, mais nous allons voir qu’il est déjà bien plus que ça. Et ceux, même s’il n’est pas encore version 1.

Le protocole Gemini

• https://gemini.circumlunar.space/docs/specification.gmi
• gemini://gemini.circumlunar.space/docs/specification.gmi

Ce protocole est de type client-serveur et est construit sur le protocole TLS lui-même reposant sur TCP/IP. Avantage : ce sont des briques de l’internet maîtrisé depuis de nombreuses années.

Au hasard de mes lectures sur le Fediverse, j’ai lu quelqu’un qui écrivait quelque chose du genre : “Gemini use TLS so it’s already bloated.” Remarque assez peu constructive, probablement du troll (difficile à correctement interpréter quand ce n’est pas dis dans notre langue maternelle, par une personne random sur un réseau social. Surtout dans un monde ou la sécurité / confidentialité des échanges, même si elle se normalise, est encore loin d’être un acquis.

La philosophie du projet Gemini est de proposer un protocole simple à comprendre et à implémenter que ce soit côté client ou serveur. Adapté à la lecture et l’écriture sans se soucier de la mise en forme.

De ce point de vue c’est un succès. Il m’est difficile de quantifier la popularité de ce projet. Mais ce qui est sur c’est qu’en moins d’une semaine de nombreuse personne que je suis ce sont subitement mise à en parler et ça m’a intéressé.

Pour synthétiser ce protocole (déjà très court et simple) :

• Le client demande une ressource (pas de verbe, seulement l’URI)
• Le serveur lui retourne un code de statut, un mimetype suivis de la ressource.

La réponse serveur est donc très simple, car il n’y a pas de header à parser (contrairement à HTTP)

Le protocole est tellement simple que j’ai vu des exemples de gens navigant sur gemini simplement avec la commande netcat “nc”, ce devait être quelque chose de ce genre.

echo -n "gemini://purexo.mom/\r\n" | nc -c purexo.mom 1965

Malheureusement ma version debian étant vielle, netcat ne supporte pas TLS et donc je ne peux pas vérifier cette commande. J’ai finalement trouvé comment faire requeter du gemini sans passer par nc ou coder l’utilitaire :

echo 'gemini://gemini.circumlunar.space/' | openssl s_client -crlf -ign_eof -quiet -connect gemini.circumlunar.space:1965 2>/dev/null

• -crlf car une requete gemini c’est url suivis de et non
• -ign_eof sinon le temps que la co ce fasse le stdin de openssl c’est fermé.
• -quiet sinon openssl affiche le certificat dans la console et d’autres log
• 2>/dev/null pour masquer les info de vérification

C’est assez archaique mais c’est suffisant pour le contenu du gemini space ^^.

On est ici face à un protocole de transfert de fichier extrêmement simple. Adjoint à ce protocole viens un nouveau type de fichier texte, privilégié de-fato sur ce réseau (mais n’est nullement une obligation): text/gemini

Pour faire court, c’est inspiré de markdown. avec beaucoup moins de possibilité.

• 3 niveaux de titre
• des listes a puces
• des paragraphes et saut de ligne
• des liens (une ligne par lien, pas d’inline)

Expérimentation

N’arrivant pas à tester la commande netcat et ayant un environnement Node.js installé sur le PC sur lequel je travaille. J’ai fait un utilitaire pour envoyer une requête à un serveur gemini et afficher sa réponse dans la console.

gemcat.js

const tls = require("tls");
const { URL } = require("url");

// https://stackoverflow.com/a/60020493/5774156
process.env["NODE_TLS_REJECT_UNAUTHORIZED"] = 0;
// C'est pas bien de faire ça, il faudrait au moins appliquer le principe du TOFU
// Ou simplement s'appuyer sur le mécanisme de vérification déjà présent, mais pour le moment la majorité des sites sont auto-certifiés y compris le site officiel de gemini :/
// mais flemme pour un test rapide

const url = new URL(process.argv[2]);

const PORT = url.port ? Number(url.port) : 1965;
const HOST = url.hostname;
const options = { port: PORT, host: HOST };

const socket = tls.connect(options);

socket.setEncoding("utf8");
socket.pipe(process.stdout);

socket.end(url.toString() + "\r\n");

Simple et efficace :

• On accepte les certificats non-autorisé. Gemini étant truffé de certificat auto-signé et letsencrypt il faudrait au préalable télécharger le certificat du serveur et le stocker dans les certificats de confiance de la machine. Pour un test de réalisation on va se contenter de faire confiance quoi qu’il advienne.
• On parse l’URL pour récupérer l’hostname et le port (par défaut on met 1965 si non renseigné)
• On initie une connexion TLS et on envoie la requête au serveur.
• Le serveur envoi sa réponse et on l’affiche dans la console.

> node gemcat gemini://gemini.circumlunar.space/
20 text/gemini
# Project Gemini

## Overview

Gemini is a new internet protocol which:

Le texte est tronqué pour éviter de surcharger la page. On retrouve le statut “20” voulant dire OK. Équivalent du “200” en HTTP. Suivis du mimetype text/gemini pour indiquer au client le type de fichier retourné afin qu’il puisse choisir de l’afficher, le mettre en forme, ou le télécharger dans un fichier. Tout ce qui vient après cette ligne est le contenu / fichier retourné.

Ce que je pense de cette spécification.

Pour commencer elle en regroupe 2. le protocole de communication et le format de text/gemini. Tout cela incite à faire penser que gemini est un réseau textuel. C’est bien la philosophie du projet et malgré tout ce que je pourrais dire plus bas je trouve que c’est une bonne chose.

Mais il n’en est rien à mes yeux. Seul l’usage déterminera ce qui sera partagé sur ce réseau.

• Ce que veulent comme contenu les utilisateurs
• Ce que produiront comme contenu les auteurs.

Techniquement, vous êtes libre d’offrir au réseau n’importe quel contenu.

L’usage a fait que HTTP sers à transmettre du HTML, du CSS, et du JS majoritairement. Le HTML permettant d’intégrer de l’image, et de la vidéo. Mais HTTP sers à bien plus que cela. Des services sont construits simplement autour de transmission de données formatés et non de contenu à afficher et mettre en forme. Par exemple :

• REST avec un usage plus ou moins standardisé des verbes HTTP et transmettant majoritairement du JSON
• SOAP orienté XML

Conclusion

Vous avez avec Gemini un protocol de communication extrêmement simple (en gros, juste du HTTP GET) à appréhender que n’importe quel codeur peut s’approprier rapidement. Sa seule réelle limite étant l’impossibilité de transmettre du contenu au serveur en dehors de l’URI (reste toujours la query-string, mais à 1024 bytes on est vite limité).

Bon au final, qu’est-ce qui empêche de faire une application client-serveur-serveur-client : le serveur veut permettre à des utilisateurs de transférer des fichiers :

• une route /upload qui retourne “10 Ou se trouve votre document\r\n”
• Le client créé un serveur avec la ressource qu’il souhaite transmettre
• le client réponds /upload?
• le serveur télécharge le fichier et réponds quand il à terminé
• le client ferme son serveur.

Je n’ai pas parlé du code de statut 10 (INPUT) car il est peu utilisé. Le seul usage que j’ai rencontré est pour faire une recherche sur le moteur de recherche gus.guru.

• Page de recherche de GUS

Et voila, on a créé un protocole par-dessus Gemini, pour se rapprocher d’un protocole type pair-a-pair au lieu d’un client-serveur.

L’usage actuel est de fournir du contenu statique car simple et rapide. Mais si vous souhaitez faire un serveur retournant du contenu dynamique : Allez-y, c’est possible. Si vous vous sentez trop limité par le text/gemini. Fournissez d’autres fichiers :

• text/plain
• text/markdown
• text/x-rst (reStructuredText)
• De l’audio
• Des images de chatons mignons
• De la vidéo
• Des pdf ou des epubs

Pensez juste que la vaste majorité des clients existants ne supporteront pas ces formats mais que si l’usage devient courant ça finira par le devenir. Pensez aussi que la philosophie ici est de rester sur du texte et peu de mise en forme (Il faut que ce soit simple à afficher dans un terminal) donc ne vous attendez pas à ce que vos images et vos vidéos soient intégrés dans une page mais diffusé dans un autre logiciel en supportant l’affichage.

Écrire et lire sans se soucier du placement des éléments est un réel confort et c’est à mon sens ce que recherche toutes personne publiant et consultant ce réseau. L’absence de liens inline n’est pas une fatalité. Certains se plaignent de l’absence de RSS, publiez votre fil rss dans gemini et faites en sorte que votre lecteur RSS supporte gemini. Comme montré en exemple, récupérer du contenu gemini est excessivement simple, l’affichage de text/gemini l’est tout autant.

Ploum, si tu me lis, tu souhaitais publier Printeurs 2 sur Gemini. De mon côté j’aime lire sur ma liseuse. Donc si je trouve le temps et la force : J’aimerais faire un navigateur gemini pour ma pocketbook afin de te lire directement dessus ! Si je manque de temps ce sera un script qui dl les pages gemini pour les transformer en un fichier txt.

Les outils qui me manqueront

Si je veux continuer à bloguer sur gemini.

• un générateur de site statique pour du contenu gemini (l’idée étant d’ajouter un pied de page pour gérer la navigation automatiquement)
• un serveur dynamique pour proposer de la recherche fulltext dans le blog
• un serveur dynamique pour fournir un index des dossiers / fichiers

J’ai déjà accès à tout ceci sur le web, nginx et apache incluant l’index, ayant du CGI / reverse proxy les possibilités sont infinis. Tant que l’on a pas des outils de ce genre (qui ont eu bien des années pour arriver à maturation) ça nous sera difficile d’avoir la même souplesse tout en proposant du contenu textuelle.

Tout ce que je peux dire, c’est que le confort et le plaisir que j’ai à écrire sur pour ce réseau : C’est que j’ai seulement à me soucier du fond et non de la forme.

Pour un développeur web, qui passe ses journées à coder des interfaces web en React, à interconnecter avec des listes Sharepoint. C’est reposant ! Tout en apportant l’excitation de la découverte ^^.