-- Leo's gemini proxy
-- Connecting to geminiprotocol.net:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
Ultimo aggiornamento: 2021-02-21
Gemini è un nuovo protocollo internet a livello dell'applicazione per la distribuzione di file di genere arbitrario ma, in special modo, per fornire un formato per ipertesti semplice che semplifica il collegamento tra file. Potete pensare a Gemini come "il web, ridotto alla propria essenza" o come "Gopher, rinverdito e leggermente modernizzato", secondo la vostra prospettiva (l'ultima è probabilmente più accurata). Gemini potrebbe interessare alle persone che:
Si oppongono al tracciamento pervasivo degli utenti sul web
Sono stanche di fastidiosi pop-up, pubblicità odiose, video che si avviano automaticamente ed altre caratteristiche nefaste del web moderno
Sono interessate nella computazione a basso consumo e/o su reti a bassa velocità, sia per scelta che per necessità
Gemini è semplice ma non punta ad essere il più semplice possibile. Invece il suo impianto si sforza di massimizzare il suo "rapporto forza peso", mantenendo il peso all'interno di limiti accettabili. Gemini cerca anche di tutelare il diritto alla riservatezza, cerca di essere difficilmente estensibile in futuro (cosicché possa *rimanere* semplice e rispettoso della privacy) e, infine, di essere compatibile con un attitudine "do it yourself" alla computazione. Proprio per quest'ultima ragione gemini è tecnicamente molto familiare e conservatore: è un protocollo che si mantiene nel solco del tradizionale paradigma client-server e richiesta-risposta ed è costruito sulle fondamenta di tecnologie mature e standardizzate come: URI, tipi di media MIME e il TLS.
Il progetto gemini è iniziato nel 2019. Sebbene il protocollo in sé è completo per la maggior parte, il software disponibile, le risorse e la comunità sono ancora in uno stato di sviluppo embrionale (ma in crescita!).
Il progetto Gemini è stato inizialmente avviato da Solderpunk <solderpunk _at_ posteo _dot_ net>, che rimane il Dittatore Benevolo del progetto. In ogni caso il protocollo è stato progettato in collaborazione con una comunità, larga ed informale, di parti interessate attraverso email, post su Gopher (la cosiddetta "phlogosphere") a toot nel fediverso. Molte persone hanno aiutato a plasmare parti significative del protocollo, cosicché gemini non può essere considerato come il lavoro di una sola persona.
Difficile dirlo con esattezza. Il conto dei nomi di host unici probabilmente ne esagera la dimensione. D'altra parte, Contare gli indirizzi IP unici la sottostimerebbe, dato che Gemini permette domini differenti serviti dallo stesso indirizzo IP. Ad ogni buon conto, all'inizio del 2021 ci erano circa 200.000 URL gemini conosciuti, spalmati su circa 750 "capsule" (i "siti" nel gergo di Gemini), 500 domini e 600 indirizzi IP. Lo spazio si sta, comunque, espandendo velocemente. Potete trovare le ultime statistiche al seguente link.
L'attuale specifica informale è perlopiù congelata, tranne per alcuni piccoli cambiamenti per risolvere ambiguità e considerare casi limite. Suggerimenti di nuove funzionalità non verranno presi in considerazione perché il protocollo è completo da quel punto di vista. Il focus principale del progetto d'ora in poi è sul far crescere la community attorno al protocollo e tradurre la specifica attuale in una versione più precisa e formale che possa essere considerata per l'invio agli enti degli standard internet come IETF e IANA.
(Nota: la traduzione letterale sarebbe "pensi davvero che possa rimpiazzare il Web?", ma volevo tenere il discorso impersonale.)
Neanche per sogno! E nemmeno distruggere il "Gopherspace". Gemini non è pensato per rimpiazzare Gopher od il Web, ma per coesistere accanto come un'altra possibilità che le persone possano liberamente scegliere se le aggrada. Esattamente come alcuni servono gli stessi contenuti attraverso Gopher o il Web, chi desidera sarà in grado di "bi-servire" o "tri-servire" contenuti su qualunque combinazione di protocolli pensa offra loro, o al loro pubblico, la miglior combinazione di requisiti tecnici, filosofici ed estetici.
È una citazione ad un'era di voli spaziali pre-Shuttle con equipaggio umano, composta da tre progetti. Il primo, Progetto Mercury, fu un tentativo minimale, parte della corsa nel mandare l'Uomo sullo spazio, poi vinta dall'Unione Sovietica con il progetto Vostok. "Mercury" era una capsula per un solo pilota, senza possibilità alcuna di correzione dell'orbita dopo il lancio, che collezionò un solo volo di durata maggiore alla giornata. L'ultimo fu il grande, pesante, complesso e costoso Progetto Apollo, che riuscì però a far volare e tornare indietro tre uomini sulla luna.
Meno noto al pubblico moderno, il Progetto Gemini fu il "figlio di mezzo": una capsula per due piloti in grado di incontrare ed attraccare altri oggetti in orbita, capace di de-pressurizzarsi e ri-pressurizzarsi per facilitare le passeggiate spaziali, il cui viaggio più lungo fu di quasi due settimane - più di qualunque missione Apollo! In termini di grandezza, peso e costo Gemini fu più simile a Mercury che ad Apollo, ma in termini di capacità fu tutt'altra cosa: ci furono addirittura piani, mai realizzato, di un volo circumluminare.
Si auspica che l'analogia sia ovvia: Gopher è simile a Mercury, mentre il Web è come Apollo. Gemini spera di posizionarsi tra i due, rendendo di più con meno.
Gemini, deliberatamente, ha un nome che non ha *nulla* a che fare con geomidi (n.d.t. "geomida" è la traduzione di "Gopher") od altri tipi roditori, e nemmeno altri animali. Durante le discussioni iniziali attraverso i "phlog", e che sfociarono eventualmente nel Progetto Gemini, la mancanza di una scrittura attenta rese a volte poco chiaro se si stesse parlando di rimpiazzare Gopher o di estenderlo in modo non ufficiali e che rompesse la retro compatibilità con i client e server Gohper esistenti. Quando le inattive discussioni si trasformarono in un vero progetto, sembrò saggio mandare un messaggio chiaro.
La pagina principale del Progetto Gemini è sul server gemini.circumlunar.space. Contiene l'ultima versione di questo documento ed anche la specifica del protocollo, le "best practice" raccomandate e altra documentazione ufficiale, attraverso Gemini, Gopher ed HTTPS, su IPv4 e IPv6.
Le discussioni ufficiali riguardanti Gemini avvengono nella mailing list:
Chiunque mantenga un server Gemini, o stia implementando un programma client o server, è fortemente incoraggiato ad iscriversi alla lista.
Discussioni più informali su Gemini avvengono anche sul canale IRC #gemini sul server tilde.chat:
I criteri, di seguito riportati, sono stati redatti, in maniera informale, all'inizio del progetto. Se questi siano stati rispettati o meno potrebbe essere oggetto di dibattito ma, in generale, Gemini è ancora sufficientemente aderente ai propri obbiettivi.
In particolare, Gemini si sforza di mantenere la possibilità di implementare client semplici. I browser moderni sono così complicati da poter essere sviluppati esclusivamente attraverso progetti grandi e costosi. Tale situazione inevitabilmente porta all'esistenza di un ristretto numero di browser esistenti, che li porta a trovarsi in una condizione di quasi monopolio, ciò frena l'innovazione e la diversità e permette agli sviluppatori di questi browser di poter imporre la propria opinione sull'evoluzione di tali programmi.
Gemini aspira ad essere semplice, ma *non più del necessario*. Gopher è più semplice a livello di protocollo ma, come conseguenza, il client si trova in una situazione di costante incertezza: "con quale codifica dei caratteri è stato scritto questo file?", oppure: "Qual è il formato di questo file binario?". A causa di questa incertezza un client Gopher efficiente è reso *complesso* dal fatto di dover inferire tali informazioni che il protocollo non fornisce.
Le prime discussioni discussioni su Gemini includevano tre obbiettivi chiari rispetto al suo livello di semplicità:
dovrebbe essere possibile per qualcuno che non abbia partecipato alla definizione del protocollo riuscire ad averne un chiara visione complessiva dopo aver letto le specifiche una volta o due
Un client semplice ma utilizzabile (non super spartano) dovrebbe essere implementabile con 50 righe di codice o giù di li (usando un linguaggio moderno e ad alto livello) o, comunque, non superare le 100 righe
un client per un uso quotidiano ed abituale dovrebbe essere poter scritto come progetto per il tempo libero da un singolo programmatore
Si potrebbe discutere a lungo se tali obbiettivi siano stati, o meno, raggiunti. L'esperienza porta a pensare che un semplice client interattivo possa essere scritto in circa 100 linee di codice come minimo, un client completo intorno alle 200. (Nota: da tradurre) But Gemini still seems to be in the ballpark of these goals.
Gemini è progettato con la profonda consapevolezza che la rete moderna è un disastro in termini di diritto alla riservatezza e che internet non è un luogo sicuro per i protocolli in chiaro. Pratiche come il fingerptinting dei browser e i cosiddetti "supercookies" invitano alla cautela: il tracciamento degli utenti potrà (e lo farà) infiltrarsi usando caratteristiche che non erano state progettate per facilitarle. Quindi, non soltanto i progettisti del protocollo devono evitare di progettare caratteristiche che rendano semplice il tracciamento (cosa in se non difficile), ma anche assumere che vi saranno attori con intenti malevoli ed evitare -quindi- quelle caratteristiche che potrebbero essere sovvertite per permettere un tracciamento degli utenti efficace. Questi timori si manifestano nella deliberata ricerca di una resistenza all'estensibilità in molte parti del protocollo.
L'applicazione di "prima classe" di gemini è l'utilizzo, da parte degli esseri umani, di materiale scritto, per facilitare la creazione di qualcosa simile al Gopherspace o ad un "webspace ragionevole" (p.es. qualcosa che possa essere usato comodamente con Lynx o Dillo). Tuttavia, proprio come l'HTTP potrebbe essere (ed è) usato per molto più che servire pagine HTML, Gemini dovrebbe essere in grado di essere usato per più scopi possibile senza compromettere con questo i princìpi di semplicità e rispetto della riservatezza summenzionati. Ciò si esplica prendendo in considerazione le possibili applicazioni costruite attorno a file non di testo e client non istruiti da esseri umani.
Gemini permette:
l'utilizzo non ambiguo di set di caratteri arbitrari
identificazione dei file binari tramite l'utilizzo dei tipi MIME invece di un ristretto e obsoleto insieme di tipi item
di avere una distinzione chiara tra transazioni fallite o completate con successo
il collegamento a risorse servite attraverso protocolli differenti usando semplici URL, senza soluzioni raffazzonate
la redirezione per impedire link rotti quando il contenuti sono stati spostati o riorganizzati
il virtual hosting basato sul nome del dominio
Il testo, nei documenti gemini, è giustificato dal client per adattarsi alle esigenze degli utenti, piuttosto che essere forzato ad una giustificazione imposta dal protocollo di ~80 caratteri, incluso il carattere di terminazione di linea. Ciò significa che i contenuti si visualizzeranno convenientemente sia sui telefoni, sui tablet, sui portatili o sui desktop.
Gemini si è sbarazzato della dicotomia directory/text e permette di inserire i link all'interno del testo.
Gemini obbliga all'utilizzo della cifratura tramite TLS.
Le abitudini moderne di uso della phlogosfera sembrerebbero suggerire che molte persone pensano che lo sia. Un numero crescente di utenti veicolano contenuti esclusivamente testuali come "tipi item 1", ciò per permettere loro di inserire un piccolo numero di hyperlink "in line" ad altri contenuti presenti sul Gopher, fornendogli così una certa somiglianza con i link HTML; una pratica ragionevole e inoffensiva. Senza aver intrapreso questo approccio, il meglio che gli autori di contenuti su Gopher potrebbero fare sarebbe incollare una lista di URL in coda ai loro documenti, affinché i loro lettori possano copiarli ed incollarli nei propri client. Non esattamente una esperienza utente piacevole. Ma forzare gli hyperlink in Gopher usando questa tecnica non è solo un abuso della semantica del protocollo, è anche una maniera sorprendentemente inefficiente di veicolare del testo; dato che ogni linea trasmessa deve avere un "tipo item i", un selettore fittizio, il nome dell'host e della porta, tutti elementi che vanno trasmessi anch'essi perché si possa comporre un menu Gopher valido. Tutti i proclami di semplicità e bellezza di Gopher sono difatti distrutti attuando queste pratiche. Gemini segue l'approccio più semplice di permettere agli utenti di inserire quanti più link gli aggradano all'interno del testo, con poco sforzo ma mantenendo la limitazione di avere un solo link per linea di testo come in Gopher; in questo modo il risultato è una chiara organizzazione dei contenuti in una struttura simile ad una lista. E difficile obbiettare che questo non sia un miglioramento.
Naturalmente, se voi preferite la modalità di organizzazione di Gopher, nulla in gemini vi vieterà di replicarla. Potete veicolare oggetti "tipo item 0" con un tipo MIME di tipo text/plain; e potete scrivere documenti text/gemini dove ogni singola linea è un link replicando, in tal modo, l'aspetto di un menu Gopher rispettoso dell'RFC1436 senza usare il problematico, e non standard, "tipo item i".
Gemini non contiene nulla nel protocollo che possa essere assimilabile alle intestazioni "User-agent" o "Referer" [dell'HTTP ndt.], inoltre il formato della richiesta non è estensibile cosicché queste non possano essere dirottate nei propri fini nel tempo. Questi accorgimenti dovrebbero impedire efficacemente il tracciamento degli utenti.
Il contenuto cosiddetto "nativo" di Gemini (analogo all'HTML per l'HTTP(S) o testo semplice, per Gopher) non richiede mai richieste di rete addizionali (non ci sono immagini in-linea, fogli di stile esterni, font o script, niente iframe ecc.). In questo modo si dovrebbe permettere una navigazione veloce anche con connessioni lente nonché piena consapevolezza e controllo rispetto a quali host vi state connettendo.
Il contenuto nativo di Gemini è strettamente un documento, senza caratteristiche che ne facilitino l'aggiunta di script e che permette una navigazione efficace anche su computer vecchi con limiti evidenti in termini di velocità del processore o nella memoria disponibile.
Molte persone hanno difficoltà a comprendere perché valga la pena progettare un nuovo protocollo per superare caratteristiche del web che sono percepite come opzionali o non essenziali. Solo per il fatto che i siti web abbiano la *possibilità* di tracciare gli utenti e far girare programmi esosi di risorse tramite Javascript, scaricare immagini o intestazioni con estensioni di Megabyte, o persino grandi video che vengono riprodotti automaticamente, non significa che essi *debbano* farlo. Non sarebbe possibile semplicemente costruire siti web non "malevoli" usando le tecnologie già disponibili?
Ovviamente la riposta alla precedente domanda è "sì". L'"esperienza Gemini" è grossolanamente equivalente all'HTTP dove, però, la sola intestazione ammessa è "Host" e quella di risposta è "Content-type" e all HTML dove i soli tag ammessi sono <p>, <pre>, <a>, dall'<h1> fino all' <h3>, <ul>, <li> e <blockquote>. Il sito presente all'indirizzo https://gemini.circumlunar.space website offre sostanzialmente questo tipo di esperienze. Siamo coscienti, quindi, che la strada che riutilizzi tecnologia esistente possa essere percorsa.
Il problema è che stabilire un sottoinsieme dell'HTTP e dell'HTML, appiccicargli sopra un nome e sostenere di aver raggiunto i propri propositi non avrebbe nessun effetto rispetto al proposito di costruire una chiara linea di demarcazione dove le persone possano consumare *solamente* quel tipo di contenuti *solamente* attraverso il sottoinsieme delle specifiche summenzionato. È impossibile conoscere in anticipo se, dall'altra parte di un indirizzo "https://" ci sarà una risposta che aderisce a questo sottoinsieme delle specifiche oppure no. Sarebbe veramente un impresa faticosa verificare che un sito che dichiari di aderire a queste specifiche lo faccia veramente, dato che molte delle caratteristiche che vogliamo editare sono invisibili (ma non innocue!) per l'utente. È altrettanto difficile, se non impossibile, disattivare il supporto per tutte le caratteristiche non volute nei browser più diffusi, quindi se qualcuno rompesse le regole voi ne paghereste le conseguenze. Scrivere una versione semplificata di un browser è più difficile che scrivere un client per gemini da zero. E anche se voi lo faceste avreste difficoltà a scoprire la minuscola frazione del web che tale browser potrebbe renderizzare.
Protocolli alternativi come Gopher o Gemini creano spazi alternativi semplici per progettazione con limiti ovvi e vincoli stringenti. È facile capire che siete entrati nel Geminispace e altrettanto facile capire che ne state uscendo se seguite un certo tipo di link. Mentre siete nel Geminispace potete essere sicuri che tutti stiano giocando secondo le stesse regole. Potete rilassarvi e proseguire l'esplorazione seguendo link a siti che non avete mai visto prima, che sono appena comparsi, fiduciosi che non proveranno a tracciarvi o servirvi spazzatura solo perché *possono farlo*. Inoltre potete fare tutto questo con un client che che avete scritto da voi, cosicché siate *sicuri* che potete fidarvi del programma che usate. Queste è un esperienza molto più liberatoria e che concede agli utenti molti più spazi di manovra che provare a scavarsi un piccolo, invisibile, sotto-sotto-sotto-sotto-spazio dell'intero web.
Naturalmente!
Gemini non ha supporto per il caching dei contenuti, per la compressione o per la possibilità di riprendere una connessione dal punto dove si era, eventualmente, interrotta. Quindi non è molto adatto a trasferire file di grandi dimensioni, per valori di "grandi" che dipendono dalla velocità e dall'affidabilità della vostra connessione di rete.
Alcuni sono contrariati dal fatto che richiedere TLS significhi il dover usare una libreria TLS per scrivere codice per Gemini, quando ad esempio Gopher permette un controllo totale permettendo di scrivere tutto da zero.
Ovviamente, anche un client Gopher "scritto da zero" comunque dipende crucialmente da centinaia di righe di codice complesso scritto da altre persone per fornire uno stack IP funzionante, un DNS resolver e un filesystem. Usare una libreria TLS per fornire un'implementazione fidata di crittografia non è molto diverso.
(Nota: qui sotto, "segnalazione in banda del loro requisito" non mi convince per nulla, ma non so come rendere meglio "[...] into first-class citizen with in-band signalling of their requirement.")
In oltre, Gemini considera i certificati cliente, raramente visti nel Web, in cittadini di prima classe con segnalazione in banda del loro requisito. Questo permette di restringere l'accesso a delle risorse Gemini solo ad alcuni soggetti, oppure stabilire delle "sessioni" volontariamente con applicazioni server-side, senza dover passare in giro cookie, password, token di autenticazione o qualunque altra cosa si sia abituati. È molto più simile al concetto di "chiave autorizzata" di SSH e, in fatti, un approccio molto più semplice all'autenticazione utente.
TLS di certo non ha i suoi svantaggi ma:
(Nota: tradurre "binding" in modo soddisfacente; "freeride" -> "scroccare"?)
Ci sono binding per le librerie TLS disponibili per quasi ogni linguaggio di programmazione esistente
Molti sviluppatori sono al meno in parte familiari con TLS e quindi non devono imparare nulla di nuovo per implementare Gemini
Molti utenti si fidano già di TLS per proteggere le loro navigazioni Web ed email e quindi non devono decidere o meno se vogliono fidarsi di una tecnologia a loro sconosciuta per iniziare ad usare Gemini
TLS è uno standard dell'industria profondamente radicato, la cui definizione ed implementazione continuerà ad essere esaminata e migliorata da esperti di sicurezza per il prevedibile futuro, e che questo lavoro continuerà ad accadere per ragioni completamente diverse da Gemini - ha molto senso per un piccolo progetto "scroccare" in questo modo.
text/gemini è fortemente ispirato da Markdown, cosa che può spingere a chiedersi perché non usarlo direttamente come media type di default per Gemini. Certo, è complesso da implementare, ma come per TLS ci sono molte librerie disponibili per tutti i linguaggi principali. Le motivazioni per non farlo includono:
Ci sono diverse diverse ed incompatibili varianti di Markdown, quindi invece che con TLS non è garantito che le varie librerie si comportino similmente
La maggior parte delle librerie Markdown non fanno altro che convertirlo in HTML, che per un client Gemini è uno scomodo formato intermedio più pesante dell'originale!
Molte varianti di Markdown permettono funzionalità che non sono volute per Gemini, come ad esempio immagini in linea.
Il desiderio di preservare il requisito di Gopher del "link per linea" con la premessa che incoraggia un design estremamente pulito dei siti
Ovviamente è possibile servire Markdown tramite Gemini. L'inclusione di un media type text/markdown nell'header della risposta permetterà a client più avanzati di supportarlo.
Dato che text/gemini è un formato completamente nuovo pensato appositamente per Gemini, gli autori dei client devono tipicamente scriversi il codice per leggere e renderizzare il formato da zero, senza potersi affidare a implementazioni pre-esistenti e testate. È quindi importante che il formato sia estremamente semplice da gestire correttamente. Il formato basato su linee dove linee di testo e linee link sono concetti diversi lo permette. Non c'è alcun bisogno per i client di scansionare ogni linea carattere per carattere, controllando la presenta di qualche sintassi speciale per i link. Anche la soluzione più semplice introduce la possibilità di sintassi malformate alle quale i client devono essere preparati, e comporta casi limite la cui gestione deve essere risolta esplicitamente nella specifica del protocollo (portando a una specifica più lunga e tediosa che sarebbe meno divertente da leggere e difficile da tenere a mente), o lasciata non definita (portando a comportamenti inconsistenti tra client diversi). Nonostante link in linea possano essere più naturali per alcuni tipi di contenuti, non valgono l'aumento di complessità e fragilità che inevitabilmente introdurrebbero nel protocollo.
È vero che bisogna cambiare il modo di pensare un po' per abituarsi a questo stile di scrittura, ma diventa più semplice col tempo. Ci sono comunque altri vantaggi perché incoraggia a includere solo il link più importanti o rilevanti, ad organizzarli in elenchi correlati e a dare ad ogni link una descrizione completa senza preoccuparsi che s'incastri o meno naturalmente nel flusso principale del testo.
(Nota: non mi piace tradurre "to perform poorly" con "scarso rendimento", ma non mi viene in mente nulla di meglio)
(Nota: ho tradotto "issues will often be an afterthought at best" con "un ripensamento, nel migliore dei casi", non è completamente corretto ma non ho idee migliori)
Alcuni hanno espresso il desiderio per qualcosa di simile a CSS per Gemini. Nonostante sia possibile progettare qualcosa di molto più semplice e leggero di CSS, Gemini invece prende la posizione che lo stile visuale del contenuto debba essere sotto solo e diretto controllo del lettore e non dello scrittore. Non tutti hanno gli stessi gusti in fatto di colori e di font, e nessun singolo stile delle pagine è ottimale per tutti i lettori, su tutti i dispositivi e con tutte le condizioni di luce. C'è molto di più in gioco della vecchia divisione di preferenze tra testo scuro su sfondo chiaro e viceversa. Per esempio persone con disabilità di lettura come la dislessia potrebbero beneficiare tremendamente dall'usare font progettati appositamente. Un semplice sistema di stile "taglia unica per tutti" dove il contenuto sembra uguale ovunque sicuramente è garantito abbia uno scarso rendimento per molte persone. Un sistema di stili che permetta di specificare aspetti diversi per dispositivi e situazioni diverse andrebbe a pesare sui singoli autori, obbligandoli a controllare che la loro capsula sia usabile ovunque. L'esperienza con il Web suggerisce che i problemi di accessibilità sono spesso un ripensamento, nel migliore dei casi. È molto più semplice, ed effettivamente più liberatorio per gli autori di contenuti, di lasciare che il contenuto sia solo contenuto e che dello stile se ne occupino i client. Alcuni client Gemini potrebbero sembrare monotoni e noiosi, ma non c'è nessun motivo per il quale debbano. Se c'è richiesta per client con del rendering dei font di alta qualità e tipografia curata, verranno eventualmente sviluppati e, quando lo saranno, gli utenti a cui stanno a cuore queste funzionalità potranno godere quell'esperienza di lettura in tutto il Geminispace, anche quando leggono contenuti scritti da autori a cui non importa per nulla lo stile.
(Nota: ho tradotto "open-ended" con "aperto", ma manca qualche sfumatura del significato originale forse)
La non-estensibilità del protocollo è stato un fondamento della progettazione di Gemini. Cookie, Etag e altri sistemi di tracciamento non erano presenti nel design originale di HTTP, ma è stato possibile aggiungerli in seguito perché il formato delle risposte HTTP è aperto e permette la semplice inclusione di nuovi header. Per minimizzare il rischio che Gemini muti lentamente in qualcosa più di più simile al Web, è stato deciso di includere una ed una sola informazione nell'header delle risposte con successo. Includere due informazioni con un delimitatore specifico permetterebbero un modo abbastanza ovvio in seguito per aggiungere un terzo pezzo: basta riutilizzare lo stesso separatore di nuovo. Fondamentalmente, non c'è una posizione stabile tra un frammento d'informazione ed un numero arbitrario di essi, quindi Gemini si rifà fermamente alla prima opzione, anche se significa sacrificare qualche funzionalità carina e apparentemente innocua. Data questa restrizione, includere solo un'equivalente del Content-type è sembrato più utile di includere solo un equivalente del Content-length. Lo stesso è vero per altri innocui e utili header HTTP, come Last-Modified (ultima modifica.)
Neanche Gopher ha un equivalente dell'header Content-length e non si dimostrato un vero ostacolo nel Gopherspace.
Persino senza questo header è possibile, a differenza di Gopher, per i client distiguere tra una transazione completata correttamente e una interrotta a metà per un problema di rete o di un attacco attraverso la presenza, o assenza, del messaggio di chiusura di TLS.
È vero che l'impossibilità per i client di informare gli utenti di quanto ci sia ancora da scaricare di un file di grandi dimensioni per stimare quanto tempo manchi significa che Gemini non può fornire una buona esperienza per download di grandi dimensioni. In ogni caso, sarebbe la stessa cosa anche nel caso fosse nota la dimensione, in quanto sarebbe necessario aggiungere anche altre complicazioni al protocollo, come ad esempio la possibilità di riesumare scaricamenti interrotti. I documenti Gemini possono fornire link a risorse disponibili su HTTPS, BitTorrent, IPFS, DAT, ecc. e potrebbe essere l'opzione migliore per file molto grandi.
Sarebbe utile solo se ci fossero dei piani per passare gradualmente ad un "Gemini 2.0" nel futuro, e non ci sono! Gemini è una reazione "meno è più" ai browser e server Web che stanno diventando troppo complessi e troppo potenti. Non ha senso pianificare di aggiungere più funzionalità a Gemini in futuro: il piano è invece "riuscire bene la prima volta" il più possibile per poi congelare la specifica del protocollo per sempre, senza aggiornamenti, migliorie od estensioni.
Potrebbe sembrare radicale o poco saggio, ma siamo cautamente ottimistici. La specifica di Gopher non è stata cambiata in circa trent'anni, e solo un piccolo numero di cambiamenti non ufficiali alla specifica sono d'uso comune nel Gopherspace odierno, che sta effettivamente crescendo in popolarità. Gemini unisce primitive Internet mature e onnipresenti come gli URI, i MIME type e TLS in modo semplice, e cerca di promuovere la cultura di lavorare all'interno, ed anche abbracciando, limitazioni scelte con attenzione invece di rimuovere ogni limitazione incontrata per rendere tutto possibile. Ci sono molte cose per le quali Gemini è utile e un buon strumento oggi, e non c'è nessuna ragione di pensare che non potrà essere utile e buono per queste stesse cose decadi nel futuro.
Gopher è talmente semplice che i computer degli anni '80 o '90 possono implementare il protocollo e per alcuni questo è una sua grande virtù, mentre la dipendenza su TLS di Gemini lo limita a macchine più moderne.
Le vecchie macchine sono fantastiche e mantenerle in funzione, connesse e utili quanto più a lungo possibile è una cosa meravigliosa da fare ma non ha senso per la maggior parte degli utenti di sacrificare qualche od ogni protezione della privacy per facilitarlo. Si ricordi comunque che Gemini non punta a rimpiazzare Gopher, quindi l'internet retro-compatibile non è direttamente messo in pericolo. Infatti, le persone che servono contenuti attraverso Gohper sono fortemente incoraggiati ad iniziare a servire lo stesso contenuto simultaneamente anche su Gemini. I fan del retrocomputing possono continuare ad accedere ai loro contenuti via Gopher mentre gli utenti di computer moderni che vogliono possono passare a Gemini e godere di alcuni benefici.
La maniera più semplice per esplorare il Geminispace è usare un web proxy o "portale", come quelli qui di seguito elencati:
Questi proxy vi permetteranno di usare il vostro usuale browser per esplorare il Geminispace. Se vi dovesse piacere ciò che vi troverete potreste prendere in considerazione l'idea di installare un client Gemini dedicato, che comunemente offre una migliore e più completa esperienza di navigazione. Potete trovare una lista di client (e altro software) al link di seguito. Sono disponibili anche client per piattaforme per dispositivi mobili, come Android o iOS!
Se avete un client SSH installato potete provare alcuni client da terminale senza necessità di installarli facendo con la seguente linea di comando:
> ssh kiosk@gemini.circumlunar.space
Questo (Nota: "chiosco"? E' corretto?) chiosco Gemini è ispirato al chiosco Gopher che si trova presso bitreich.org!
Per il momento il Geminispace è ancora piccolo abbastanza da poter essere esplorato usando delle raccolte pubbliche di capsule. Alcune sono elencate più sotto:
Se cercate qualcosa in particolare, Gemini possiede due motori di ricerca:
Esistono, poi, due aggregatori che tentano di rendere più semplice trovare documenti aggiornati recentemente nel Geminispace:
Una possibilità sarebbe quella di mettere in piedi il proprio server Gemini su un VPS [Virtual Private Server ndt] o su un computer di casa tua (piccoli SBC [Single Board Computer ndt] come il raspberryPi sono perfettamente in grado di essere usati come server Gemini). È disponibile una vasta gamma di software per server tra i quali poter scegliere:
In alternativa, potete trovare un altro luogo dove i vostri contenuti possono essere ospitati. Hosting per gemini è disponibile presso i seguenti fornitori:
Un certo numero di comunità "pubnix" o "tilde" (sistemi unix multiutente dove le persone interagiscono tra loro usando SSH, email locali, programmi per chat e BBS) offrono hosting per Gemini (tipicamente insieme a hosting per web e/o Gopher). Potete ottenere un account su una delle comunità elencate di seguito. Tenete presente, però, che la maggior parte delle comunità elencate sono più vecchie di Gemini e potrebbero essere indirizzate verso altri servizi, o ruotare intorno ad uno, o più, temi o interessi specifici. Controlla accuratamente e unisciti alla comunità che senti più adatta a te, invece di trattare queste incredibili piccoli mondi come il luogo dove semplicemente affidare le tue riflessioni.
Se appartenete ad una comunità pubnix che non offre hosting gemini, non sarà dannoso chiedere agli amministratori/rici se sono interessati ad aggiungere questo servizio!
Se non vi sentite a proprio agio con il tipo di tecnologie usate dall'hosting pubnix (SSH, SFTP, editor di testi da terminale, permessi unix ecc.) potete ottenere un account presso i servizi di seguito elencati che permettono di mantenere una capsula attraverso un programma web.
Potreste prendere in considerazione la possibilità di unirti alla mailing list (vedi il punto 1.3) cosicché voi possiate annunciare il vostro nuovo server alla comunità e tenere aggiornato lo stato del vostro server oppure informarvi sui cambiamenti apportati al protocollo vero e proprio.
Potete annunciare l'indirizzo del vostro server al motore di ricerca GUS, cosicché venga esplorato, al seguente indirizzo:
Gemini ha già un numero notevole di implementazioni client e server esistenti. Questo non significa che non ne siano benvenute altre, ma quello di cui c'è più bisogno al momento sono i contenuti e non il software. Quante più cose interessanti ed entusiasmanti le persone troveranno nel Geminispace, maggiori sono le possibilità che vorranno contribuire con propri contenuti. Quindi il contributo più importante che potete dare al progetto è partecipare a questo processo. Potete trovare nel punto 3.3 sopra maggiori informazioni su come mettere i vostri contenuti nel Geminispace.
Se avete le capacità tecniche necessarie, potete dare un contributo eccezionale alla crescita del Geminispace creando un servizio di hosting che altre persone possono usare per pubblicare i propri contenuti. Questo può significare anche qualcosa di semplice come la creazione di utenti SFTP su un server virtuale (VPS). Offrire hosting per altre persone non deve essere necessariamente un grande impegno: potete ospitare almeno una dozzina di utenti sui server virtuali più economici. E un grande numero di fornitori, ognuno in grado di servire i contenuti di pochi utenti, significa un ecosistema molto più robusto e sostenibile rispetto a pochi server dove sono ospitate centinaia o migliaia di utenti.
Se volete comunque scrivere del software, uno strumento di grande potenziale per espandere il Geminispace potrebbe essere un programma unico per consentire contemporaneamente il funzionamento di un server e un modo per più utenti di gestire i propri contenuti su questo server, per esempio tramite una interfaccia web oppure tramite l'invio di email. In altre parole, qualcosa di simile ai servizi Gemlog Blue e Flounder (vedi la FAQ 3.3), ma pacchettizzato e ben documentato in modo che sia semplice per chiunque installare e personalizzare un proprio sito multi-utente, un po' come avviene per una istanza Mastodon.
Potete aiutare il progetto anche inviando correzioni, aggiunte o traduzioni del sito ufficiale e della documentazione (vedi le FAQ 4.2 e 4.3 di seguito).
Tutta la documentazione ospitata su gemini.circumlunar.space, incluse le FAQ che state leggendo ora, vive in un repository git singolo, con accesso pubblico in sola lettura. Potete clonare il repository in questo modo:
> git clone git://gemini.circumlunar.space/gemini-site
Una volta clonato il repository, effettuate le modifiche che volete apportare ai file interessati (la struttura delle URL rispecchia esattamente quella del repository, quindi es. gemini://gemini.circumlunar.space/docs/faq.gmi si trova nel file docs/faq.gmi nel repository). Fate il commit delle vostre modifiche con messaggi chiari e un singolo commit per ogni modifica concettuale (ricordatevi di impostare il vostro nome e indirizzo email così le altre persone potranno vedere chi è stato ad apportare le modifiche!). A questo punto ci sono due possibilità per inviare le vostre proposte al progetto.
Se avete configurato il comando git send-email (vedi sotto il link a un tutorial), potete inviare le patch con i vostri commit a <solderpunk _at_ posteo _dot_ net> con un singolo comando. In alternativa, potete semplicemente eseguire:
> git format-patch origin
per creare un insieme di file patch, da inviare manualmente come allegati a una email, usando il vostro normale client di posta elettronica.
Anzitutto grazie! Offrirsi di tradurre la documentazione è un modo fantastico per aiutare il progetto.
Come prima cosa, clonate il repository git come descritto nel punto 4.2 sopra. Spostatevi nella directory `doc` del repository, e create una nuova sotto-directory con il codice ISO 639-1 di due lettere della vostra lingua, ad esempio le traduzioni in finlandese saranno in `doc/fi/`, quelle in giapponese in `doc/ja/` e così via. Potete trovare una lista completa dei codici su Wikipedia (link sotto). Se state traducendo in una variante regionale di una lingua, potete usare codici nello stile RFC4646, ad esempio pt-PT oppure pt-BR per la lingua portoghese parlata rispettivamente in Portogallo o Brasile.
Per ogni file in lingua inglese nella directory `doc` che volete tradurre, create il file corrispondente nella sotto-directory della vostra lingua. Potete cambiare anche il nome del file come parte della traduzione, ad esempio la traduzione di `doc/specification.gmi` in lingua tedesca potrebbe chiamarsi `doc/spezifikation.gmi`. Potete tradurre quanti file desiderate o quanti riuscite, e non vergognatevi a mandare traduzioni parziali! Se qualcuno che parla la vostra stessa lingua vedrà i vostri sforzi, potranno fare la loro parte su quello che rimane da tradurre. Una parte dei contenuti tradotti è molto meglio di niente.
Quando avete concluso, aggiornate il file `doc/translations.gmi` con un link alla vostra nuova sotto-directory.
Fate il commit delle vostre traduzioni e mandate la patch a Solderpunk come descritto nella FAQ 4.2 sopra.
-- Response ended
-- Page fetched on Sat May 4 17:10:35 2024