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.
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) :
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
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é.
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 :
> 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é.
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.
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 :
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 :
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.
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 :
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.
Si je veux continuer à bloguer sur gemini.
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 ^^.