Gemini
en lettvekts internettprotokoll for å servere hypertekst
Hva det er
Gemini, også kalt Gemini-protokollen, er en applikasjonsprotokoll for å hente dokumenter der hele
utvekslingen er én kryptert tilkobling: klienten sender én adresse, serveren sender ett svar
tilbake, og så lukkes tilkoblingen. Adressene begynner med gemini://, et nettsted som leveres over
protokollen, kalles en kapsel, og nettverket av slike kapsler heter Geminispace.
Prosjektet startet i juni 2019 under grunnleggeren Solderpunk, som fortsatt har rollen som
prosjektets «Benevolent Dictator». Spesifikasjonen, nå i versjon 0.24.1, er frigitt under CC0 uten
forbehold om opphavsrett, og den beskriver protokollen som en forbedring av Gopher i små steg, slik
Gopher er beskrevet i RFC 1436, og ikke som en nedstrippet utgave av HTTP. Prosjektets FAQ gjør
sammenligningen fra motsatt kant: protokollen ligner noe midt mellom HTTP 0.9 og HTTP 1.0, med én
eneste type forespørsel, omtrent som en GET.
En klient kobler seg til TCP-port 1965, et tall som minner om den første bemannede Gemini-ferden, i mars 1965, og fullfører et håndtrykk i TLS; begge sider må støtte TLS 1.2 eller nyere. Så sender klienten den absolutte adressen fulgt av vognretur og linjeskift, og den URL-en kan være på høyst 1 024 byte. Serveren svarer med én enkelt hodelinje: en tosifret statuskode, et mellomrom og en kort tekst som betyr noe forskjellig etter hvilken kode den står bak. Kodene faller i seks grupper: 10–19 ber om inndata, 20–29 betyr suksess, 30–39 er omdirigeringer, 40–49 er midlertidige feil, 50–59 er varige feil, og 60–69 gjelder klientsertifikater. Ved suksess er teksten en MIME-type, og innholdet følger som rå byte, uten komprimering og uten å bli delt opp i biter underveis. Deretter lukker serveren tilkoblingen med TLS-meldingen close_notify, og det er slik klienten vet at den har fått alt.
Protokollen kan frakte alle slags filer, men den ble utformet sammen med et eget dokumentformat,
gemtext, som leveres som text/gemini.
Hvorfor det er viktig
Det virkelige valget handler sjelden om å flytte et nettsted over til Gemini. FAQ-en sier at protokollen ikke er ment å erstatte weben eller Gopher, og den har et eget navn på det å publisere det samme innholdet på to eller tre av dem: bihosting eller trihosting. Spørsmålet for eieren er om det er verdt å holde en ekstra inngangsdør åpen.
Det Gemini gir, er personvern som følger av selve konstruksjonen. Ifølge FAQ-en har Gemini ikke, og
vil heller aldri få, noe som tilsvarer headerne Cookie, Referer eller User-Agent. En
forespørsel er en URL og ikke noe mer, så serveren har svært lite å registrere selv om den som
driver den, skulle ønske det, og leserens klient kjører ikke skript som kan rapportere tilbake.
FAQ-en regner «defensive non-extensibility», en bevisst motstand mot utvidelser, blant
prioriteringene bak utformingen: formatene for forespørsel og svar har ikke plass til et nytt
headerfelt, så en senere versjon har ikke noe sted å smugle sporing inn igjen. For den som
publiserer ren tekst, er det nettopp dette som frister.
Prisen er mye av det weben har vokst seg til siden HTTP 1.0. Protokollen kjenner ikke informasjonskapsler, så en kapsel som må kjenne igjen en leser som kommer tilbake, ber om et klientsertifikat i stedet, og leseren må selv lage og ta vare på det. Det finnes heller ingen sertifikatutsteder som standard: spesifikasjonen anbefaler sterkt Trust on First Use, eller TOFU, der klienten godtar det sertifikatet serveren viser første gang, og deretter låser seg til det, slik at serverens sertifikat blir et løfte som skal holde lenge. Krypteringen skjuler siden, men navnet på serveren reiser i TLS-utvidelsen Server Name Indication (SNI), og FAQ-en innrømmer at vertsnavnet fortsatt lekker ut. Leserne trenger en egen Gemini-klient i stedet for en nettleser, så publikummet er lite. Store filer egner seg dårlig, fordi et svar verken oppgir størrelse eller sjekksum.
Et team som trenger interaktive skjemaer, kontoer med passord, webanalyse eller et rikt sideoppsett, hører hjemme på weben. Et team som publiserer dokumenter og vil ha en kanal som ikke kan spore leserne, kan legge til Gemini for en liten kostnad, så lenge innholdet allerede finnes som filer.
Slik ser det ut i praksis
Dette nettstedet, engineer.company, er selv en kapsel, på gemini://engineer.company.
Kolofonen oppgir Agate som programmet som svarer på Gemini-forespørsler, ved siden
av Caddy for weben, Gophernicus for Gopher og Tor for onion-tjenesten. Agate henter kapselen fra den
samme mappen som de tre andre programmene leser, så Gemini-utgaven blir oppdatert av den samme
produksjonssettingen som weben og kan ikke komme i utakt med den. Det er FAQ-ens bihosting utvidet
til fire kanaler og gjort på den billigste måten som finnes: kapselen er bare enda en leser av en
mappe som hver produksjonssetting fyller uansett, og ikke et nytt nettsted som må holdes i takt med
det gamle.
Samme side er åpen om begrensningen som er beskrevet ovenfor. Den sier at Gemini og Gopher vil ha hver sin klient i stedet for en nettleser, og at Gopher sender i klartekst hvilken side du leser. Gemini krypterer dette, men nettverket du leser fra, ser likevel hvilken adresse du ba om. Det er lekkasjen av servernavnet som FAQ-en innrømmer, fortalt fra leserens ståsted i stedet for konstruktørens.
Personvernsiden viser hva så tynne forespørsler betyr for driften. Den sier at Gemini- og Gopher-kopiene av nettstedet ikke har noen tilgangslogg i det hele tatt, og at nettstedet siden september 2026 teller hvor mange forespørsler de besvarte hver dag, og ingenting annet: ingen adresse, ingen side, ingen besøkende.
Hvor det går galt
Første linje i et svar avslører det meste av det som går galt med Gemini, og den linjen er lett å lese for hånd med bare OpenSSL:
printf 'gemini://engineer.company/\r\n' |
openssl s_client -quiet -connect engineer.company:1965 \
-servername engineer.company
Den første linjen som kommer tilbake, er hodelinjen, for denne kapselen 20 text/gemini;lang=en, og
siden følger etter den.
Faste lesere får beskjed om at kapselen kan være under angrep. Klienter som følger spesifikasjonen, lagrer fingeravtrykket og utløpsdatoen til det første sertifikatet de ser. Et annet sertifikat før den datoen er passert, regnes som et mulig tegn på et mellommannsangrep. Den som lager et nytt sertifikat ved hver produksjonssetting, eller flytter kapselen til en ny maskin uten nøkkelen, utløser denne advarselen hos hver eneste faste leser. Ta sikkerhetskopi av nøkkelen og sertifikatet sammen med resten av serveren, utsted sertifikatet for en lang periode, og bytt det først etter utløpsdatoen klientene allerede har lagret.
Et søkefelt svarer med status 59. Et svar med status 10 ber leseren om en linje inndata, og
klienten sender den tilbake som spørredelen av den samme URL-en, prosentkodet. URL-en har et tak på
1 024 byte, og serveren skal avvise alt som er lengre, som en ugyldig forespørsel. Et langt svar
fyller den grensen fort, og tekst utenfor ASCII fyller den enda fortere: en ø er to byte i UTF-8 og
seks byte når den er prosentkodet, %C3%B8. Be om korte svar, og bruk status 11 for følsomme
inndata som en passfrase, slik at klienten lar være å vise det som tastes, på skjermen.
Leserne blir logget ut mellom sidene. Protokollen har ikke informasjonskapsler, så økttilstand som holdes slik weben gjør det, lever ikke videre fra én forespørsel til den neste. En kapsel som må vite hvem som spør, svarer med status 60, leserens klient lager et sertifikat, og serveren kjenner det igjen ved senere forespørsler. Spesifikasjonen begrenser sertifikatet til verten og porten som ba om det, og til den forespurte stien med alt under den, så legg alle sider som trenger identiteten, under én sti. Skriv på siden hva sertifikatet skal brukes til, fordi leseren må godta det.
En stor nedlasting stopper halvveis uten at noen legger merke til det. Et svar oppgir verken lengde eller sjekksum, så en overføring som stopper midt i, kan se nesten ut som en som ble fullført, bortsett fra at close_notify mangler. Veiledningen for beste praksis foreslår at filer større enn 100 MiB helst leveres på en annen måte. Legg store filer på HTTPS og lenk til dem fra kapselen; en Gemini-side kan lenke til et hvilket som helst URL-skjema.
Les mer
- Gemini network protocol specification — forespørsler, alle statuskoder, bruken av TLS og hvordan klienten låser seg til et sertifikat, samlet i ett kort dokument.
- Project Gemini FAQ — prosjektets mål, sammenligningen med HTTP og Gopher, og prosjektets eget svar til dem som mener at TOFU er svakt.
- Best practices for Gemini implementations — navngiving av filer, store filer, grenser for omdirigeringer og innstillinger for TLS.
- History of Project Gemini — hvordan en idé fra Gopherspace i 2019 vokste til et eget nettverk, fortalt av prosjektet selv.