-- Leo's gemini proxy
-- Connecting to geminiprotocol.net:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; lang=de
zuletzt aktualisiert: 2021-02-28
Gemini ist ein neues Internet-Protokoll auf Anwendungs-Ebene für die Verbreitung von beliebigen Dateien, mit einigen speziellen Überlegungen für ein einfaches Hypertext-Format, welches Links zwischen Dateien erlaubt. Man kann es sich als "das Web, auf seine Essenz heruntergebrochen" vorstellen, oder als "Gopher, aber leicht verbessert und modernisiert", je nach Perspektive (die letztere Ansicht ist wahrscheinlich etwas genauer). Gemini könnte interessant sein für Menschen, die:
dem allgegenwärtigen Tracking des Webs etwas entgegensetzen wollen
genug haben von lästigen Pop-ups, nervigen Werbungen, automatisch abspielenden Videos und anderen Fehlbildungen des modernen Webs
sich für energiesparende Datenverarbeitung und/oder Datenverarbeitung in langsamen Netzwerken interessieren, sei es aus Interesse oder Zwang
Gemini soll einfach sein, aber nicht zwingen so einfach wie möglich. Stattdessen versucht die Gestaltung das "Masse-zu-Leistungs-Verhältnis" zu maximieren, dabei aber die Belastung innerhalb akzeptabler Grenzen zu halten. Gemini soll auch sehr datenschutzbewusst sein, schwer zukünftig zu erweitern (damit es einfach und datschutzbewusst *bleibt*), und kompatibel mit einem "mach es selbst"-Ethos. Aus diesem letzten Grund ist Gemini technisch sehr vertraut und konservativ: es ist ein Protokoll im traditionellen Client-Server- und Anfrage-Antwort-Schema, und es baut auf reifer, standardisierter Technologie wie URIs, MIME-Media-Typen und TLS auf.
Das Gemini-Projekt begann im Juni 2019. Auch wenn das Protokoll selbst finalisiert ist, sind die verfügbare Software, Ressourcen und Gemeinschaft noch in einem sehr frühen, aber gesunden Entwicklungs-Stadium.
Ursprünglich wurde das Gemini-Projekt von Solderpunk <solderpunk _ät_ posteo _punkt_ net> gestartet, der weiterhin der "wohlwollende Diktator" des Projektes ist. Allerdings wurde das Protokoll zusammen mit einer losen und informellen Gemeinschaft aus vielen Interessierten über E-Mails, Posts in der Gopher-"phlogosphere" und Toots im Fediverse gestaltet. Viele Personen haben erhebliche Teile des Protokolls mitgestaltet, man sollte sich das Protokoll also nicht als die Arbeit einer einzigen Person vorstellen, auch wenn es eine zentrale "Führungsperson" gibt.
Im Februar 2021 wurden Sean Conner, der selbst bereits viel zu Gemini beigetragen hatte, einige Entscheidungs-Privilegien übertragen, um trotz fehlender Ressourcen seitens Solderpunk die Finalisierung der Spezifikation vorantreiben zu können.
Genaue Zahlen zu ermitteln, ist schwierig. Zählt man eindeutige Hostnamen von Gemini-Servern, kommt man wahrscheinlich zu einer aufgeblasenen Zahl, da einige Mehrbenutzer-Systeme jedem Benutzer eine Subdomain zuteilen. Auf der anderen Seite würde das Zählen von eindeutigen IP-Adressen die Größe wahrscheinlich unterschätzen, da Gemini zulässt, dass mehrere Domains von ein und der gleichen IP bereitgestellt werden. Auf jeden Fall gibt es - Stand Anfang 2021 - etwa 200˙000 bekannte Gemini-URLs, verteilt zwischen 750 "Kapseln" (der Terminus der allgemein statt "Sites" verwendet wird), 500 Domains und 600 IP-Adressen. Allerdings wächst der Geminispace beständig und schnell. Aktuellere Statistiken sind unter dem folgenden Link zu finden:
Die aktuelle (informelle) Spezifikation des Protokolls ist größtenteils eingefroren, abgesehen von kleinen Änderungen, um Uneindeutigkeiten zu beseitigen und Randfälle zu berücksichtigen. Erweiterungen werden nicht mehr in Betracht gezogen, da das Protokoll als vollständig angesehen wird. Das Augenmerk des Projektes liegt jetzt hauptsächlich im erweitern der Gemeinschaft um das Protokoll, wie auch der Übersetzung der bestehenden Spezifikation in ein genaueres und formelleres Format, welches Internet-Standardisierungsgremien wie IETF und IANA vorgelegt werden könnte.
Nicht einen Augenblick! Genauso wenig wie irgendjemand im Projekt den Gopherspace zerstören möchte. Gemini ist nicht als Ersatz für das Web oder Gopher gedacht, sondern soll friedlich mit ihnen zusammen als eine weitere Option existieren, die Benutzer aus freien Stücken wählen können, wenn es ihnen gefällt. Genau so wie einige Inhalte aktuell über Gopher und das Web verfügbar sind, wäre es genau so möglich, Inhalte doppelt oder dreifach zu hosten, auf jeder beliebigen Kombination von Protokollen die den technischen, philosophischen oder ästhetischen Ansprüchen am besten entsprechen.
Der Name ist eine Referenz zur Vor-Shuttle-Ära des bemannten Raumflugs der Vereinigten Staaten, welcher aus drei Phasen bestand. Die erste Phase war Mercury, eine recht minimale Machbarkeitsstudie und ein Teil des Wettlaufs, eine Person in den Weltraum zu bringen (welchen die Sowjetunion mit dem Vostok-Programm gewann). Mercury war eine Ein-Personen-Kapsel ohne Möglichkeiten, die eigene Umlaufbahn nach dem Start zu verändern, außerdem dauerte nur eine Mercury-Mission länger als ein Tag. Das letzte Projekt war Apollo: ein großes, schweres, kompliziertes und teures Unternehmen, welches aber natürlich drei Menschen zum Mond und zurück brachte.
Der heutigen Öffentlichkeit weniger bekannt ist das "Sandwichkind" Projekt Gemini: Eine Zwei-Personen-Kapsel die ein Rendezvous durchführen und an andere Raumfähren andocken konnte. Ebenso konnte der Kapseldruck im Weltraum abgesenkt und wieder erhöht werden, um ein Aussteigen zu ermöglichen. Die längste Mission dauerte fast zwei Wochen - länger als jede Apollo-Mission! Größe, Gewicht und Kosten von Gemini waren viel näher an Mercury als an Apollo, bei der Funktionalität war es aber umgekehrt - es gab sogar Pläne (die nie ausgeführt wurden) mit Gemini-Missionen den Mond zu umfliegen!
Hoffentlich ist die Analogie offensichtlich: Gopher ist wie Mercury, und das moderne Web ist wie Apollo. Gemini möchte zwischen den beiden sitzen und mit weniger mehr erreichen.
Gemini hat absichtlich keinen Namen erhalten, der auch nur entfernt an Gopher (englisch für Taschenratte) oder andere Nagetiere oder überhaupt Tiere erinnert. Während der ersten phlog-basierten Diskussionen die letztendlich in Gemini mündeten, war es aufgrund unvorsichtiger Formulierungen manchmal nicht offensichtlich, ob über das vollständige Ersetzen oder nur das Erweitern von Gopher mit inoffiziellen und inkompatiblen Ergänzungen gesprochen wurde. Als einfache Diskussionen in ein echtes Projekt mündeten, schien es eine gute Idee, eine deutliche Nachricht zu wählen.
Die offizielle Heimat von Projekt Gemini ist der Server unter gemini.circumlunar.space. Er bietet die aktuellste Version dieses FAQ-Dokuments und der Protokoll-Spezifikation, bewährte Vorgehensweisen und weitere offizielle Dokumentation über Gemini, Gopher und HTTPS über IPv4 und IPv6.
Offizielle Diskussionen über Gemini finden sich auf der Mailingliste:
Jede*r, der einen Server betreibt oder einen Gemini-Server oder -Client entwickelt sollte der Mailingliste folgen.
Informelle Diskussionen finden sich auch im Kanal #gemini auf dem tilde.chat IRC-Server:
Die folgenden Kriterien wurden zu Beginn des Projekts informell zusammengestellt. Es ist umstritten, wie gut manche dieser Ziele erreicht wurden, aber generell hat Gemini sie recht gut erreicht.
Gemini erstrebt die Einfachheit der Entwicklung von Clients. Moderne Web-Browser sind so kompliziert, dass sie nur von großen und teuren Projekten entwickelt werden können. Dies führt natürlich zu einer kleinen Anzahl von Browsern die mehr oder weniger ein Monopol besitzen. Dies hemmt Innovation und Diversität und erlaubt es den Entwicklern dieser Browser, die Richtung vorzugeben, in welche sich das Web entwickelt.
Gemini will einfach sein, aber nicht *zu* einfach. Auf Protokoll-Ebene ist Gopher einfacher, dafür können Clients aber nie sicher sein: Welche Kodierung hat dieser Text? Ist dieser Text der gewollte Inhalt oder eine Fehlermeldung des Servers? Welche Art von Datei repräsentieren diese Binärdaten? Deshalb ist ein robuster Gopher-Client dadurch komplizierter, dass er diese fehlenden Informationen ableiten oder erraten muss.
Frühe Diskussionen über Gemini enthielten drei Kriterien zur Einfachheit:
Es sollte für an der Protokoll-Entwicklung unbeteiligte Personen möglich sein, die vollständige Spezifikation im Kopf zu behalten, nachdem sie eine gute Beschreibung des Protokolls ein oder zwei mal gelesen haben.
Ein simpler aber funktionaler (nicht übermäßig spartanischer) Client sollte komfortabel in etwa 50 Zeilen Code einer höheren Programmiersprache passen. Sicherlich nicht mehr als 100.
Ein für den täglichen Gebrauch geeigneter Client, der jede Besonderheit des Protokolls umsetzt, sollte als Wochenend-Projekt einer einzelnen Person umsetzbar sein.
Es ist streitig, inwieweit diese Ziele erreicht wurden. Experimente legen eher nahe, dass ein einfacher interaktiver Client eher mindestens 100 Zeilen erfordert und eher in unter 200 Zeilen passt, wenn er eine moderate Protokoll-Abdeckung erreichen soll. Trotzdem scheint Gemini nicht allzu weit von diesen Zielen entfernt zu sein.
Gemini ist mit einer genauen Kenntnis des Privatsphären-Desasters des modernen Webs entworfen, und weiß genau, dass das Internet ohne Klartext kein sicherer Ort ist. Dinge wie Browser-Fingerprinting und Etag-basierte "Super-Cookies" sind ein wichtiges abschreckendes Beispiel: Nutzer-Tracking kann und wird mit Hintertüren durchgesetzt, die Protokoll-Merkmale ausnutzen, die für etwas anderes gedacht waren. Also müssen Protokoll-Designer nicht nur darauf achten, keine Verfolgungs-Features einzubauen (was recht einfach ist), sonder müssen auch annehmen, dass das Protokoll böswillig ausgenutzt wird. Auch unter diesen Bedingungen sollte kein Feature zur Nutzerverfolgung missbraucht werden können. Diese Besorgnis schlägt sich nieder als bewusste Nicht-Erweiterbarkeit vieler Teile des Gemini-Protokolls.
Die Anwendung "erster Klasse" in Gemini ist die menschliche Wahrnehmung von hauptsächlich schriftlichen Inhalten - in etwa wie das Gopher-Umfeld oder das "anständige Web" (also etwas, was man auch mit Lynx oder Dillo bequem nutzen kann). Aber genau wie HTTP für vieles genutzt werden kann und genutzt wird, für viel mehr als nur HTML zu übermitteln, so sollte auch Gemini in der Lage sein, für viele weitere Zwecke genutzt zu werden, ohne dass dabei die vorangegangenen Einfachheits- und Privatsphären-Aspekte aus den Augen verloren werden. Das bedeutet, dass mögliche Anwendungen berücksichtigt werden müssen, die nicht-textbasierte Inhalte und/oder nicht-menschliche Clients einschließen.
Gemini ermöglicht:
eindeutige Nutzung von Zeichensätzen über US-ASCII hinaus
Identifizieren binärer Inhalte mithilfe von MIME-Media-Typen statt einer kleinen Zahl von völlig veralteten Item-Typen
klare Abgrenzung von erfolgreichen und fehlgeschlagenen Transaktionen
Verlinken von Inhalten, die über andere Protokolle zugänglich sind, ohne umständliche Hacks
Weiterleitungen, um defekte Links vorzubeugen, wenn Inhalte verschoben oder neu angeordnet werden
Domain-basiertes virtuelles Hosting
Text in Gemini-Dokumenten wird von Clients umgebrochen, um der Anzeige des Endgerätes zu entsprechen, statt Inhalte immer bei etwa 80 Zeichen umzubrechen. Das bedeutet, dass Inhalte auf Mobiltelefonen, Tablets, Laptops und Desktops gleich gut dargestellt werden können.
Gemini verwirft Gophers strikter Teilung in Verzeichnis oder Text und erlaubt das einfügen von Links in Prosa-Text.
Gemini erfordert die Benutzung von TLS-Verschlüsselung.
Die aktuellen Gepflogenheiten in der Benutzung von Gopher legen nahe, dass dies viele denken. Eine größer werdende Anzahl von Nutzern stellen Inhalte, die fast ausschließlich aus Text bestehen als Item-Typ 1 zur Verfügung, damit sie einige wenige Links zu anderen Gopher-Inhalten einfügen können, in Anlehnung an Hyperlinks in HTML - ein völlig vernünftiger Wunsch. Ohne diesen Ansatz können Gopher-Autoren höchstens am Ende ihres Artikels einige Links einfügen, die manuell kopiert und in die Navigationszeile eingegeben werden müssen. Das ist nicht gerade das angenehmste Benutzererlebnis. Aber Hyperlinks so in Gopher zu erzwingen ist nicht nur ein Missbrauch der Semantik des Gopher-Protokolls, es ist auch eine überraschend ineffiziente Art, Text zu übertragen, da jede einzelne Zeile einen Item-Typ "i" und einen falschen Selektor, Hostnamen und Port haben muss, die zusammen mit der Zeile übermittelt werden, um ein gültiges Gopher-Menü zu erstellen. Jegliche Ansprüche auf Einfachheit und Schönheit, die Gopher haben könnte, werden damit vernichtet. Gemini nimmt den einfachen Weg, indem es das Einfügen von beliebig vielen oder wenigen Link-Zeilen mitten im Text erlaubt, und zwar mit sehr geringem Mehraufwand. Dabei behält es aber die Beschränkung von maximal einem Link pro Zeile, was sich in saubereren, listenartigen Organisation von Inhalten auswirkt. Es ist schwer, dies als irgendetwas anderes als eine Verbesserung zu sehen.
Wenn man natürlich die Art, die Gopher gewählt hat, besonders mag, kann diese in Gemini problemlos repliziert werden. Inhalte mit Typ "0" werden als MIME-Media-Typ "text/plain" übermittelt, und es können text/gemini-Dokumente verfasst werden, in welchen jede Zeile eine Link-Zeile ist. Damit kann das Aussehen und Gefühl eines RFC 1436-fürchtigen Gopher-Menüs nachempfunden werden, ohne diesen nervigen "i" Item-Typ.
Gemini hat kein Äquivalent der User-Agent- oder Referer-Kopfzeilen, und das Anfrage-Format ist nicht erweiterbar, sodass diese auch nicht nachträglich eingefügt werden können. Tatsächlich enthalten Gemini-Anfragen nichts weiter als die URL der angefragten Ressource. Dies ist schon ein sehr großer Schritt zur Verhinderung von Nutzer-Verfolgung.
Der "native Inhaltstyp" von Gemini (analog zu HTML für HTTP(S) oder Klartext für Gopher) erfordert nie zusätzliche Netzwerk-Anfragen (es gibt keine eingebetteten Bilder, externe Stylesheets, Schriftarten, Skripte, iframes usw.). Dies ermöglicht auch mit einer langsamen Verbindung schnelles browsen, und volle Kenntnis und Kontrolle darüber, welche Server kontaktiert werden.
Der native Inhaltstyp Geminis ist darauf beschränkt, Dokumente abzubilden, ohne Skripte zuzulassen. Dies ermöglicht auch auf älteren Computern mit begrenzter Prozessor-Geschwindigkeit und/oder begrenztem Arbeitsspeicher ein flüssiges Browser-Erlebnis.
Viele sind verwundert, warum es den Aufwand wert ist, ein neues Protokoll zu erstellen, um empfundene Probleme mit optionalen, nicht-essenziellen Teilen des Webs zu lösen. Nur weil Webseiten Nutzer verfolgen, CPU-ausnutzende Javascripte ausführen und unnötige mehrere Megabyte große Bilder oder sogar noch größere, automatisch-abspielende Videos beinhalten *können*, heißt ja nicht, dass sie es auch *tun* oder *müssen*. Warum nicht einfach freundliche Webseiten mit der bestehenden Technologie erstellen?
Natürlich ist das möglich. Das "Gemini-Erlebnis" ist in etwa vergleichbar mit HTTP mit ausschließlich der Host-Kopfzeile in der Anfrage und ausschließlich der "Content-Type"-Kopfzeile in der Antwort; HTML mit ausschließlich den Tags <p>, <pre>, <a>, <h1> bis <h3>, <ul> und <li>, und <blockquote> - und ziemlich genau dieses Erlebnis liefert https://gemini.circumlunar.space . Wir wissen, dass es möglich ist.
Das Problem ist, dass das Erstellen einer streng begrenzten Teilmenge von HTTP und HTML nichts dazu beitragen würde, einen klar abgegrenzten Bereich zu erstellen, in welchem *nur* diese Art von Inhalten konsumiert werden kann. Es ist unmöglich, vorher zu wissen, ob der Inhalt einer bestimmten "https://"-URL innerhalb einer Teilmenge ist, oder nicht. Es ist sehr umständlich, zu überprüfen, dass eine Webseite nicht nur behauptet, diese Teilmenge zu nutzen, sondern dies auch tatsächlich tut. Denn viele der Eigenschaften, die wir vermeiden wollen sind für den Benutzer unsichtbar (aber nicht ungefährlich!). Es ist schwer bis unmöglich, die Unterstützung für alle ungewollten Features in aktuellen Browsern abzuschalten. Wenn also jemand gegen die Regeln verstößt, musst du den Preis dafür bezahlen. Einen vereinfachten Web-Browser zu schreiben, der alle ungewollten Eigenschaften ist viel schwerer, als einen Gemini-Browser von Grund auf zu schreiben. Selbst wenn man es täte, hätte man große Schwierigkeiten, die kleine Menge an Webseiten zu finden, die überhaupt damit dargestellt werden können.
Andererseits schaffen Protokolle wie Gopher und Gemini, die simpel entworfen sind, simple Räume mit harten Grenzen und Beschränkungen. Dagegen weiß man, wenn man den Geminispace betritt, und wann ein Link wieder hinaus führt. Solange man darin ist, kann man sich sicher sein, dass alle die gleichen Regeln befolgen. Man kann sich entspannt umschauen und Links zu Seiten folgen, von denen man noch nie gehört hat, die gestern erst entstanden sind, und trotzdem sicher sein, dass sie dich nicht verfolgen oder dir Müll präsentieren, weil sie es *nicht können*. All dies kann man mit einem Client tun, den man selbst geschrieben hat, und dem man also vertraut. Es ist eine ganz andere Welt, viel befreiender und befähigender, als einen winzigen, unsichtbaren Teil-Teil-Teil-Teil-Bereich des Webs schaffen zu wollen.
Natürlich!
Gemini unterstützt kein Caching, Kompression oder Wiederaufnahme von abgebrochenen Downloads. Somit ist es nicht besonders gut zum Verteilen von großen Dateien geeignet, mit Werten für "groß" die von der Geschwindigkeit und Verlässlichkeit der Netzwerkverbindung abhängen.
Manche Menschen regen sich darüber auf, dass die TLS-Anforderung bedeutet, dass sie eine TLS-Bibliothek benutzen müssen, wogegen etwa Gopher erlaubt, alles zu kontrollieren und von Grund auf zu schreiben.
Natürlich verlassen sich auch "von Grund auf" geschriebene Gopher-Clients auf tausende Zeilen komplizierten Programm-Codes, die von anderen Menschen geschrieben wurden. Etwa für eine funktionierende IP-Schicht, einen DNS-Auflöser und ein Dateisystem. Das Verwenden einer TLS-Bibliothek zur Bereitstellung eines sicheren Kommunikationswegs macht vor diesem Hintergrund auch keinen großen Unterschied.
Außerdem wandelt Gemini TLS-Nutzerzertifikate - im Web sehr selten - zu Mechanismen erster Klasse, einschließlich In-Band-Signalisierung ihrer Erfordernis. Dies erlaubt es, den Zugriff auf bestimmte Ressourcen auf einzelne Personen zu beschränken, oder freiwillig "Sitzungen" mit Server-seitigen Anwendungen zu starten, ohne Cookies, Passwörter, Authentisierungs-Tokens oder irgendetwas anderes, was du kennst, nutzen zu müssen. Es ist viel näher an der Einstellung von SSH zu "autorisierten Schlüsseln" und ist auch ein viel einfacherer Ansatz zur Authentifizierung von Benutzern.
TLS ist sicherlich nicht ohne Nachteile, aber:
Es gibt für fast jede Programmiersprache der Welt eine (oder mehrere) TLS-Bibliotheken
Viele Entwickler sind bereits wenigstens teilweise mit TLS vertraut und müssen zum implementieren von Gemini nichts neues lernen
Viele Benutzer vertrauen TLS bereits, um ihr Web-Browsern und E-Mails abzusichern, und müssen sich so keine Gedanken darüber machen, ob sie einer neuen Technologie vertrauen wollen, wenn sie Gemini benutzen
TLS ist ein tief verankerter Industriestandard, dessen Implementierungen für die überschaubare Zukunft weiterhin von vielen Augen streng überprüft und verbessert werden. Und dies geschieht völlig unabhängig von Gemini - es ist sehr sinnvoll für ein kleines Projekt wie Gemini, so auf dem Trittbrett mitzufahren.
Das text/gemini-Markup borgt einiges von Markdown, was manche auf die Frage stößt, "Warum nicht einfach Markdown als Standard-Medientyp für Gemini? Auch wenn es etwas kompliziert zu implementieren ist, aber wie für TLS gibt es viele Bibliotheken in allen größeren Programmiersprachen." Gründe gegen die Benutzung von Markdown sind unter anderem:
Es gibt viele leicht unterschiedliche und inkompatible Varianten von Markdown und entgegengesetzt zu TLS ist es somit nicht gewährleistet, dass sich alle Bibliotheken gleich verhalten.
Der Großteil von Markdown-Bibliotheken machen nicht mehr, als Markdown in HTML umzuwandeln, was für einen Gemini-Client ein unnötiges Zwischenformat ist, dass dazu noch komplizierter als das ursprüngliche Format ist!
Viele Markdown-Varianten erlauben Dinge, die für Gemini nicht wünschenswert sind, z.B. eingebettete Bilder.
Ein festhalten an der Gopher-Bedingung "ein Link pro Zeile", da dies sehr klare Seiten-Designs fördert.
Natürlich ist es trotzdem möglich, Gemini mit Markdown zu nutzen. Die Verwendung von text/markdown im MIME-Media-Typ der Antwort würde es Gemini-Clients mit erweiterter Funktionalität erlauben, dies zu unterstützen.
Weil text/gemini ein vollständig neues Format ist, welches eigens für Gemini neu entworfen wurde, müssen Autoren von Clients üblicherweise selbst Code schreiben, um dieses Format zu analysieren und darzustellen. Dabei können sie sich oft nicht darauf verlassen, eine bereits existierende, gut getestete Bibliothek vorzufinden. Also ist es wichtig, dass das Format extrem einfach richtig zu verstehen ist. Das Zeilen-basierte Format, dass zwischen Text- und Link-Zeilen unterscheidet, erreicht dies. Ein Client muss nicht jede Zeile Zeichen für Zeichen lesen, um zu Prüfen, ob eine spezielle Syntax für einen Link vorliegt. Selbst die einfachste Syntax für Links eröffnet Möglichkeiten für nicht wohlgeformte Syntax, gegen welche Clients robust sein müssten. Außerdem gäbe es Grenzfälle, deren Behandlung entweder speziell in der Spezifikation behandelt werden müssten (was zu einer längeren und schlechter verständlichen Spezifikation führen würde), oder undefiniert bleiben würden (was zu unterschiedlicher Behandlung durch verschiedene Clients führen würde). Auch wenn eingebettete Links für manche Inhaltsformen passender sein können, sind sie die zusätzliche Komplexität und Zerbrechlichkeit nicht wert, die sie unweigerlich mit sich bringen würden.
Es stimmt, dass man sein Denken etwas umstellen muss, um der "Ein Link pro Zeile"-Maxime zu folgen, aber man gewöhnt sich mit der Zeit daran. Es gibt auch Vorteile dieses Stils. Es wird angeregt, dass nur die wichtigsten oder relevantesten Links angegeben werden, die dann auch in zusammenhängenden Listen organisiert werden. Außerdem entfällt so der Zwang, unpassende Beschriftungen für Links zu verwenden, um an den umgebenden Text angepasst zu sein.
Der Wunsch nach etwas ähnlichem wie CSS in Gemini ist bereits öfter geäußert worden. Auch wenn etwas, was wesentlich einfacher als CSS ist, mit Leichtigkeit entworfen werden könnte, nimmt Gemini die Position ein, dass die Gestaltung von Inhalten in der Hand von Lesern und nicht von Autoren liegen sollte. Nicht jeder hat den gleichen Geschmack für Farben und Schriftarten, und es gibt nicht den einen Weg, der für alle auf allen Endgeräten und unter allen Bedingungen optimal ist. Hier geht es um viel mehr als die alte Trennung zwischen dunklem Text auf hellem Hintergrund oder anders herum. Zum Beispiel können Menschen mit Lese-Behinderungen wie etwa Legasthenie enormen Wert daraus ziehen, eine speziell gestaltete Schriftart zu nutzen. Ein einfaches Format, dass allen übergestülpt wird, kann nicht für alle gut funktionieren und wird im Gegenteil für viele Nachteile haben. Es ist dagegen wesentlich einfacher und viel befreiender für Autoren, den Inhalt einfach Inhalt sein zu lassen, und die Gestaltung einem Client zu überlassen. Manche Gemini-Clients mögen öde und langweilig aussehen, aber es gibt keinen Grund, warum dies der Fall sein muss. Wenn es Nachfrage nach Clients mit besonders guter Schriftarten- und Typografie-Darstellung gibt, werden solche Clients irgendwann entwickelt werden - und wenn dies passiert, können die Inhalte im ganzen Geminispace mit dieser Qualität genutzt werden, auch beim Lesen von Inhalten von Autoren, denen die Gestaltung völlig egal ist.
Nicht-Erweiterbarkeit war ein wichtiges Designprinzip Geminis. Dinge wie Cookies, Etags und andere Verfolgungs-Werkzeuge gab es in der ursprünglichen Fassung von HTTP nicht, aber konnten aufgrund des Formats von HTTP später nahtlos eingefügt werden, da es kein festes Ende hat und die Hinzufügung neuer Kopfzeilen einfach erlaubt. Um das Risiko zu minimieren, dass Gemini langsam zu etwas mehr web-ähnlichem mutiert, wurde die Entscheidung getroffen, nur genau einen Datenpunkt in der Antwortkopfzeile für erfolgreiche Anfragen unterzubringen. Zwei Datenpunkte mit einem Trennzeichen zu wählen, würde zu einer einfache und offensichtlichen Erweiterbarkeit führen, indem einfach ein weiteres Trennzeichen und ein weiterer Datenpunkt hinten angefügt werden. Es gibt quasi keine stabile Position zwischen einer und beliebig vielen Informationen, weshalb sich Gemini streng an der ersten Option festhält, auch wenn dadurch einige hilfreiche und ungefährlich scheinende Möglichkeiten geopfert werden müssen. Mit dieser Beschränkung schien es offensichtlich sinnvoller, nur ein Äquivalent der "Content-Type"-Kopfzeile zu übermitteln, statt der "Content-Length"-Kopfzeile. Das gleiche trifft auch für andere harmlose aber nützliche HTTP-Kopfzeilen zu, wie etwa "Last-Modified".
Gopher hat ebenfalls kein Äquivalent der "Content-Length"-Kopfzeile, und dies hat sich nicht als Hindernis im Gopherspace herausgestellt.
Im Gegensatz zu Gopher ist es in Gemini möglich, auch ohne diese Kopfzeile festzustellen, ob eine Transaktion erfolgreich abgeschlossen oder aufgrund eines Netzwerk-Abbruchs vorzeitig abgebrochen wurde. Dies lässt sich anhand des Vorhandenseins oder Fehlens einer TLS-Shutdown-Nachricht bestimmen.
Es stimmt, dass Gemini keine besonders gute Benutzererfahrung für das herunterladen von großen Dateien bietet, da Clients aufgrund fehlender Informationen nicht bestimmen können, wie weit der Fortschritt beim Herunterladen ist. Das hinzufügen dieser Funktionalität würde dieses Problem allerdings auch nicht unbedingt lösen, da weitere Maßnahmen notwendig wären, etwa die Möglichkeit zum Fortsetzen von unterbrochenen Downloads. Gemini-Dokumente können natürlich auch einfach auf Ressourcen verweisen, die mittels HTTPS, BitTorrent, IPFS, DAT usw. zur Verfügung gestellt werden, was für große Dateien wohl die beste Option ist.
Dies wäre nur dann sinnvoll, wenn es Pläne für eine zukünftige Version 2 geben würde - gibt es aber nicht! Gemini ist eine Reaktion nach Art von "weniger ist mehr" gegen die Aufblähung von Web-Browsern und -Servern zu etwas, was zu komplex und zu mächtig ist. Es macht keinen Sinn, Pläne für die Erweiterung von Gemini zu schmieden. Stattdessen besteht die Planung daraus, es beim ersten Mal richtig zu machen, so weit wie möglich, und dann die Protokoll-Spezifikation für immer einzufrieren, ohne Zusätze, Verbesserungen oder Erweiterungen.
Dies mag radikal oder unklug erscheinen, aber wir sind vorsichtig optimistisch. Die Gopher-Spezifikation wurde seit etwa 30 Jahren nicht verändert, und nur eine sehr kleine Anzahl von inoffiziellen Änderungen an der Spezifikation konnten sich in der Gophersphere durchsetzen, deren Bekanntheit im übrigen wieder zunimmt. Gemini kombiniert bewährte Internet-Primitiven wie URIs, MIME-Media-Typen und TLS in einer sehr einfachen Art und strebt eine Kultur an, die vorsichtig innerhalb von gegebenen - oder gewählten - Beschränkungen arbeitet, statt beim Antreffen jegliche Beschränkung zu entfernen, um alles zu ermöglichen. Es gibt viele Dinge, für die Gemini bereits verwendet werden kann, und es gibt keine Gründe zu Annahmen, dass Gemini auch in Jahrzehnten noch für diese Dinge geeignet sein wird.
Gopher ist so einfach, dass die Computer der 80er und 90er das Protokoll einfach umsetzen können, und für manche ist dies eine der großen Tugenden von Gopher. Die Notwendigkeit von TLS beschränkt Gemini dagegen auf neuere Geräte.
Alte Computer sind toll, und sie so lange wie möglich betriebsbereit, am laufen und online zu halten ist eine tolle Sache. Hierfür aber den Schutz der Privatsphäre aufzugeben, ist für den Großteil der Internet-Nutzenden unverhältnismäßig. Es sei aber auch daran erinnert, dass Gemini nicht Gopher ersetzen will, das Retro-kompatible Internet soll durch Gemini also nicht gefährdet werden. Tatsächlich wird es wärmstens empfohlen, Gopher-Inhalte ebenfalls über Gemini bereit zu stellen. So können Freunde von Retrocomputern weiterhin Inhalte per Gopher abrufen, während moderne Computerbenutzer stattdessen Gemini nutzen können und dabei noch einige Vorteile mitnehmen können.
Der Weg mit dem geringsten Aufwand ist, ein Web-Proxy oder "Portal" zu benutzen, wie etwa eines der folgenden:
Diese Portale ermöglichen, einen normalen Web-Browser zu benutzen, um den Geminispace zu entdecken. Wenn dir gefällt, was du siehst, kannst du auch einen extra dafür gedachten Gemini-Client installieren. Dies wird üblicherweise eine bessere und vollständigere Erfahrung liefern. Eine Liste von verschiedenen Clients (und anderer Software) ist unter dem unten stehenden Link zu finden. Es gibt sogar Clients für mobile Plattformen wie Android und iOS!
Wenn du einen SSH-Client hast, kannst du auch einige Terminal-Clients ausprobieren, ohne sie zu installieren:
> ssh kiost@gemini.circumlunar.space
Dieser Gemini-Kiosk wurde inspiriert durch den Gopher-Kiosk von bitreich.org!
Noch ist der Geminispace klein genug, dass es möglich ist, Inhalte mit Verzeichnissen zu finden. Einige findest du hier:
Das Verzeichnis von medusae.space hat eine kategorisierte Liste von bekannten Kapseln (auf Englisch)
Wenn du etwas bestimmtes suchst, gibt es zwei Suchmaschinen für Gemini:
Es gibt zwei öffentliche Aggregatoren, die versuchen, das Finden von kürzlich aktualisiertem Gemini-Material zu vereinfachen:
Eine Option ist, einen eigenen Gemini-Server auf einem VPS oder einem Computer zu Hause einzurichten (kleine Einplatinencomputer wie der Raspberry Pi sind völlig ausreichend). Es gibt eine große Auswahl an Software für Gemini-Server:
Alternativ kannst du auch jemanden suchen, der deine Inhalte für dich hostet. Gemini-Hosting ist auch von diesen Anbietern verfügbar:
Eine große Anzahl von "pubnix" oder "tilde"-Communities (Mehrbenutzer-Unix-Systeme auf denen Nutzer interagieren, indem sie sich per SSH auf den Servern lokale E-Mails, Chats oder BBSe ansehen) bieten auch Gemini-Hosting an (oft zusammen mit Web- und/oder Gopher-Hosting). Zum Beispiel könntest du bei einer der folgenden Communities einen Account erstellen. Einige der Communities sind allerdings älter als Gemini selbst, und fokussieren sich also auf andere Anwendungen oder Themengebiete, also wähle mit Bedacht, zu welcher Community du am besten passt, statt alle Communities als kostenlosen Platz zu nutzen, auf dem du Zeug abladen kannst.
Wenn du zu einer Pubnix-Community gehörst, die kein Gemini-Hosting anbietet, kann es nicht schaden, den/die Administrator*in(en) zu fragen, ob sie daran interessiert sind, diesen Dienst hinzuzufügen!
Wenn du dich mit den Technologien, die mit Pubnix verbunden sind, nicht wohlfühlst (ssh oder sftp, Texteditoren in Terminals, Unix-Rechteverwaltung usw.), kannst du auch bei den folgenden Anbietern kostenlose Accounts erstellen, welche dir anbieten, eine Kapsel mittels des Webs zu pflegen:
Bitte überlege dir, der Mailingliste beizutreten (siehe Frage 1.3), damit du deinen Server der Community ankündigen kannst und auf dem neuesten Stand bleibst, was etwa Updates deiner Server-Software oder des Gemini-Protokolls angeht.
Du kannst die URL deines Servers der Suchmaschine GUS hinzufügen, damit dein Server gecrawlt wird:
Gemini hat bereits eine überraschende Anzahl von Client- und Server-Implementationen - was nicht bedeutet, dass mehr unerwünscht ist, aber woran es wirklich mangelt ist nicht Software sondern Inhalte. Je mehr interessante Inhalte im Geminispace zu finden sind, umso wahrscheinlicher ist es, dass mehr Menschen selbst Inhalte hinzufügen wollen. Die größte Hilfe wäre es also, wenn du Teil dieses Prozesses wirst. Siehe Frage 3.3 für mehr Details, wie du deine Inhalte in den Geminispace bekommst.
Wenn du die notwendigen technischen Fähigkeiten besitzt, kannst du das Wachstum des Geminispace erheblich fördern, indem du einen Hosting-Service anbietest, den Leute zum veröffentlichen von Inhalten nutzen können. Dies kann einfach nur auf das Anlegen von sftp-Accounts auf einem VPS beschränkt sein. Hosting anzubieten, muss nicht zwingend eine große Verpflichtung sein. Du kannst das billigste VPS-Angebot nutzen, um sehr komfortabel ein Dutzend Benutzer zu hosten. Eine große Anzahl von Hosts, die Inhalte eines kleinen Benutzerkreises vorhalten, ist eine wesentlich robustere und nachhaltige Umgebung als eine Oligarchie von Anbietern, die hunderte oder tausende Benutzer haben.
Wenn du wirklich Software schreiben willst, wäre ein mächtiges Werkzeug zum erweitern des Geminispace ein Stück Software, welches einen Gemini-Server anbietet, sowie eine Möglichkeit zur Bearbeitung der Inhalte auf einem einfachen Weg. Beispielsweise mithilfe einer interaktiven Webseite oder durch das Senden von E-Mails, die die Inhalte enthalten. In etwa so wie die Angebote von Gemlog Blue und Flounder (siehe Frage 3.3), aber so verpackt und dokumentiert, dass es einfach ist, einen solchen Server für mehrere Benutzer zu betreiben, etwa vergleichbar mit einer Mastodon-Instanz.
Du kannst dem Projekt auch helfen, indem du Korrekturen oder Übersetzungen der offiziellen Dokumentation beiträgst (siehe Fragen 4.2 und 4.3).
Die gesamte Dokumentation, die sich auf gemini.circumlunar.space befindet, einschließlich der Übersetzung des FAQ das du gerade liest, lebt in einem einzigen git-Repository, das öffentliche Lese-Berechtigung hat. Es kann mit dem folgenden Befehl geklont werden:
> git clone git://gemini.circumlunar.space/gemini-site
Dann kannst du die entsprechenden Änderungen an den Dateien vornehmen (die Struktur der URLs spiegelt die Struktur des Repositories genau wieder, z.B. befindet sich gemini://gemini.circumlunar.space/docs/faq.gmi im Repository unter docs/faq.gmi). Committe deine Änderungen mit sinnvollen Commit-Nachrichten (stell sicher, dass dein Name und deine E-Mail-Adresse richtig gesetzt sind, damit die Leute sehen können wer deine Arbeit getan hat!), mit einem Commit für jede konzeptionelle Änderung. Um deine Änderungen einfließen zu lassen, gibt es zwei Möglichkeiten.
Wenn du den git-Befehl send-email konfiguriert hast (siehe den Link weiter unten für eine Anleitung), kannst du Patches mit deinen Commits direkt an <solderpunk _ät_ posteo _punkt_ net> senden, mit nur einem Befehl. Sonst führe einfach den folgenden Befehl aus:
> git format-patch origin
Dies erzeugt einige Patch-Dateien, die du dann manuell mit einem E-Mail-Client deiner Wahl als Anhänge versenden kannst.
Danke! Freiwilliges Übersetzen von Dokumentation ist ein wunderbarer Weg, um dem Projekt zu helfen.
Um das zu tun, musst du zuerst das git-Repository klonen, wie unter 4.2 oben beschrieben. Wechsle in das `doc` Verzeichnis und erstelle ein neues Unterverzeichnis mit der Kennung aus ISO 639-1 für deine Sprache, z.B. gehören Finnisch-Übersetzungen in `doc/fi/`, Japanische Übersetzungen in `doc/ja/`, usw. Eine vollständige Liste von Sprachkennungen findest du auf Wikipedia, unten verlinkt. Wenn du in eine regionen-spezifische Sprachvariante übersetzt, kannst du stattdessen Kennungen nach Art von RFC 4646 benutzen, z.B. pt-PT oder pt-BR für Portugiesisch, wie es in Portugal bzw. Brasilien gesprochen wird.
Für jede englische Datei in `doc`, die du übersetzen möchtest, solltest du eine entsprechende Datei im Unterverzeichnis für deine Sprache erstellen. Dabei ist es auch in Ordnung, wenn der Dateiname der Sprache angepasst wird, z.B. in der deutschen Übersetzung von `specification.gmi` zu `spezifikation.gmi`. Übersetze so viele oder so wenige Dateien wie du Zeit und Lust hast. Hab auch keine Angst davor, nur teilweise Übersetzungen beizutragen! Wenn jemand, der auch deine Sprache spricht, deine Bemühungen sieht, könnte er dazu animiert werden, die restliche Arbeit ganz oder teilweise zu übernehmen. Es ist besser, überhaupt einen Teil übersetzt zu haben, als gar nichts.
Wenn du fertig bist, kopiere die Datei `doc/index.gmi` in das Unterverzeichnis für deine Sprache und ändere die Links entsprechend bzw. entferne Links zu Dateien, die noch nicht übersetzt wurden. Schlussendlich solltest du noch `doc/translations.gmi` aktualisieren, sodass auf das neue Unterverzeichnis verlinkt wird.
Committe deine Übersetzungen in das Repository und sende die Patches an Solderpunk, wie bereits in 4.2 beschrieben.
-- Response ended
-- Page fetched on Sun May 5 16:10:12 2024