戻る
プロジェクトジェミニFAQ
最終更新日 2021-02-28
1. 概要
1.1 Geminiとは何ですか？
Geminiは、任意のファイルを配布するための新しいアプリケーションレベルのインターネットプロトコルであり、ファイル間のリンクを容易にする軽量のハイパーテキストフォーマットを提供するために、いくつかの特別な配慮がなされています。Geminiを「ウェブの本質に立ち返ったもの」と考えるか、「Gopherを少し改良して現代的にしたもの」と考えるかは人それぞれです（おそらく後者の方がより正確な見方でしょう）。Geminiは、次のような人たちの興味を引くかもしれません。
・ウェブのユビキタスなユーザー追跡に反対している。
・煩わしいポップアップ、不快な広告、自動再生ビデオ、その他現代のwebの期待していない動作にうんざりしている。
・低電力コンピューティングや低速ネットワークに興味がある。
Geminiは、シンプルであることを意図していますが、必ずしも可能な限りシンプルである必要はありません。その代わりに、処理速度を許容範囲内に抑えつつ、処理能力を最大化することを目指した設計になっています。また、Geminiは、プライバシーを非常に重視し、将来における規格の拡張を難しくし（つまり、シンプルでプライバシーを重視したまま）、「自分でやる」コンピューティング精神と相性がいいことも意図しています。この最後の理由から、Geminiは技術的に非常に親しみやすく保守的です。伝統的なクライアント－サーバーのリクエスト－レスポンスパラダイムにおけるプロトコルであり、URI、MIMEメディアタイプ、TLSなどの成熟し標準化された技術に基づいて構築されています。
1.2 Geminiは何歳ですか？
プロジェクトGeminiは2019年6月に開始されました。プロトコル自体はほぼ完成していますが、利用可能なソフトウェア、リソース、コミュニティはまだ比較的初期の（といっても盛んですが！）開発状態です。
1.3 Geminiの担当者は誰ですか？
Geminiプロジェクトは、もともとSolderpunk によって始められ、彼は今でもこのプロジェクトの「慈悲深い独裁者」です。しかし、プロトコルは、電子メールやGopherの「phlogosphere」への投稿、Fediverseのトゥートを通じて、多くの関係者からなる緩やかで非公式なコミュニティと共同で設計されてきました。多くの人々がプロトコルの重要な部分を形成してきました。したがって、一人のリーダーがいるにもかかわらず、Geminiは一人の人間の仕事であると考えるべきではないのです。
2021年2月、長年のGemini貢献者であるSean Connerは、Solderpunkがプロジェクトに必要な時間とエネルギーを割くことができない時期に、Gemini仕様を確定するための意思決定権を付与されました。
1.4 「ジェミニスペース」の大きさは？
正確に知ることは困難です。Geminiサーバーのユニークなホスト名をカウントすると、空間の大きさが誇張される可能性があります。一方、ユニークなIPアドレスをカウントすると、Geminiは同じIPから複数の異なるドメインを提供することができるため、規模を過小評価する可能性があります。いずれにせよ、2021年初頭の時点で、約20万件のGemini URLが知られており、約750の「カプセル」（Geminiコミュニティの「サイト」に対する用語）、500のドメイン、600のIPアドレスに分散しています。しかし、このスペースは急速に拡大しています。最新の統計は、以下のリンクからご覧になれます。
Geminispaceの統計は、Stéphane Bortzmeyerの「Lupa」クローラーによって提供されています。
1.5 プロジェクトのライフサイクルのどの段階にあるのですか？
現在のプロトコルの仕様（非公式）は、曖昧さをなくし、エッジケースに対応するための小さな変更を加えただけで、ほぼ凍結されています。プロトコルは機能的に完成していると考えられるので、新しい機能についての提案は考慮されません。今後、このプロジェクトの主な焦点は、プロトコルを取り巻くコミュニティを成長させることと、既存の仕様をより正確で正式なものに翻訳し、IETFやIANAなどのインターネット標準化団体に提出することを検討することです。
1.6 本当にウェブに取って代われると思っているのか？
とんでもありません。また、Geminiに関わる誰もが、Gopherspaceを破壊したいわけではありません。Geminiは、GopherやWebを置き換えることを意図しているわけではなく、人々が自分に合うものを自由に選択できるもう一つの選択肢として、それらと平和的に共存することを目的としています。現在、ある人々がGopherとWebを介して同じコンテンツを提供しているのと同じように、人々は、彼らの技術的、哲学的、美的要求と彼らの意図する読者の要求に最もマッチすると考えるプロトコルの組み合わせでコンテンツを二重提供または三重提供することができます。
1.7 この名前は何ですか？
これは、シャトル以前のアメリカの有人宇宙飛行の時代、3つのプロジェクトから構成されていたことにちなんでいます。最初のプロジェクトはMercury計画で、かなりミニマルな「コンセプトの証明」であり、人類を最も早く宇宙に送り出す競争（ソ連はボストーク計画でこれに勝利しました）の一部でした。Mercuryは1人用のカプセルで、打ち上げ後に軌道を調整する能力はなく、1日以上飛行したのはMercury1回だけでした。最後はApollo計画で、大きく、重く、複雑で高価なものでしたが、もちろん3人の人間を月に往復させることができました。
現代の人々にはあまり知られていませんが、Gemini計画は、中間のものでした。すなわち、軌道上で他の船とランデブーおよびドッキングでき、宇宙遊泳を容易にするために軌道上で減圧および加圧が可能で、その最長飛行はほぼ2週間で、Apollo計画のどのプロジェクトよりも長かったのです！サイズ、重量、コストの点で、GeminiはApolloよりもMercuryに近かったのですが、能力の点ではその逆でした。
GopherはMercuryに、WebはApolloに似ているのです。Geminiは、この2つの間に位置し、より少ないものでより多くのことを成し遂げたいと考えています。
Geminiは、Gopherや他の齧歯類、あるいは他の動物に関係するような名前を意図的につけなかったのです。最終的にプロジェクトGeminiに成長した、初期のphlogベースの議論では、注意深い文章がなかったために、人々がGopherを完全に置き換えることについて話しているのか、それとも既存のGopherクライアントやサーバに非公式で互換性を破壊するようなアップグレードを追加しようとしているのかが時々不明瞭になりました。無為な議論が実際のプロジェクトになったとき、より明確なメッセージを送ることが賢明であると思われました。
1.8 もっと知りたいのですが?
プロジェクトGeminiの公式ホームは、gemini.circumlunar.spaceサーバーです。このサーバーは、このFAQ文書の最新版、プロトコル仕様、推奨ベストプラクティス、その他の公式文書を、Gemini、Gopher、HTTPSを介して、IPv4とIPv6で提供します。
Geminiに関する公式の議論は、メーリングリスト上で行われています。
メーリングリストを購読し、Web上でアーカイブを見ることができます。
Gemini経由でメーリングリストのアーカイブを見る
Geminiサーバを運用している人、Geminiクライアントやサーバソフトウェアを実装している人は、ぜひメーリングリストを購読してください。
Geminiに関するカジュアルな議論は、IRCサーバ tilde.chat の #gemini チャンネルでも行われています。
GeminiでIRCログを見る
2. プロトコル設計
2.1 Geminiの設計基準とは？
以下の基準は、プロジェクト開始時に非公式に設けられたものです。これらの目標がどれだけ忠実に達成されているかは議論の余地がありますが、一般的にはGeminiはこの目標にかなり近いと言えます。
2.1.1 シンプルさ
特に、Geminiはクライアントの実装をシンプルにすることに努めています。最近のウェブブラウザは非常に複雑で、非常に大規模で高価なプロジェクトでしか開発できません。これは当然、ごく少数の独占に近いブラウザにつながり、革新と多様性を抑制し、これらのブラウザの開発者がウェブの進化の方向を決定することを可能にします。
Geminiはシンプルであることを目指しますが、あまりにシンプルすぎるのは良くありません。Gopherはプロトコルレベルではよりシンプルですが、その結果、クライアントは、このテキストはどのような文字エンコーディングなのか、それとも意図されたコンテンツなのか、といった不確実性を常に抱えています。このテキストは意図された内容なのか、それともサーバーからのエラーメッセージなのか？このバイナリデータはどのようなファイルなのか？堅牢なGopherクライアントは、欠落している情報を推測する必要があるため、単純ではなくなってしまいます。
初期のGeminiの議論では、単純化に関して3つの明確な目標がありました。
プロトコルの設計に全く関与していない人でも、よくできた説明を1、2回読めば、プロトコル仕様全体を正確に頭に叩き込むことができるようにすることです。
基本的で使える（そして過酷な訓練を必要としない）クライアントは、現代の高級言語による50行程度のコードで快適に収まるはずです。もちろん、100行以上にはなりません。
あらゆるプロトコルの機能を実装した、日常的に使えるクライアントは、一人の開発者が日曜大工的なプログラミングで開発できるものであるべきです。
この目標がどの程度達成されたかは議論の余地があります。実験によると、非常に基本的な対話型クライアントは最低でも100行のコードを必要とし、快適にフィットし、適度な機能が実現されるには、200行程度は必要なようです。しかし、Geminiはこれらの目標の予想範囲内にいるようです。
2.1.2 プライバシー
Geminiは、現代のWebがプライバシーを侵害し、インターネットが平文にとって安全な場所ではないことを強く意識して設計されています。ブラウザのフィンガープリントやEtagベースのsupercookieのようなものは、重要な教訓です。ユーザートラッキングは、それを促進するために設計されていないプロトコル機能を使用して、バックドア経由で忍び込むことができ、そうなるでしょう。したがって、プロトコルの設計者はトラッキング機能を設計しないようにするだけでなく（これは簡単です）、積極的な悪意を想定し、効果的なトラッキングを提供するために覆すことができるものを設計することを避けなければなりません。この懸念は、Geminiプロトコルの多くの部分で意図的な非拡張性という形で現れています。
2.1.3 一般性
Geminiの第一級アプリケーションは、主に書かれたものを人間が消費するものです。gopherspaceのようなもの、またはリーズナブルなwebスペース（例えば、LynxやDilloで快適に使用できるもの）のようなものを促進するために。しかし、HTTPがHTMLを提供するよりもずっと多くのことに使うことができ、また使われているように、Geminiは上記のシンプルさとプライバシーの基準を損なうことなく、できるだけ多くの他の目的のために使うことができるようにすべきです。これは、非テキストファイルや非人間的なクライアントを中心に構築される可能性のあるアプリケーションを考慮に入れることを意味します。
2.2 GeminiはGopherのどの欠点を克服していますか?
Geminiは以下を可能にします。
・任意の非ASCII文字セットの曖昧さのない使用。
・バイナリコンテンツを、時代遅れの小さなアイテムタイプの集合ではなく、MIMEタイプを使って識別する。
・成功したトランザクションと失敗したトランザクションの明確な区別
・他のプロトコルで提供されるリソースへのリンクは、醜いハッキングをせずに単純なURLで行う。
・コンテンツが移動したり再配置されたりしたときにリンク切れを防ぐためのリダイレクト機能
・ドメインベースのバーチャルホスティング
Geminiドキュメントのテキストは、改行文字を含む〜80文字で「ハードラップ」されるのではなく、デバイスのビューポートに合うようにクライアントによってラップされます。これは、携帯電話、タブレット、ラップトップ、デスクトップで、コンテンツが同じように表示されることを意味します。
Geminiは、Gopherの厳密なディレクトリとテキストの二項対立を解消し、散文にリンクを挿入することができます。
GeminiはTLS暗号の使用を義務付けています。
2.3 Gopherのディレクトリとテキストの二項対立は*本当に*欠点なのでしょうか?
phlogosphereでの最近の使用例を見ると、多くの人がそう思っているようです。そのため、他のGopherコンテンツへの比較的少数の「インライン」リンクを挿入することができ、HTMLのハイパーリンクのようなものを提供することができます……これは完全に合理的で無害なことです。このアプローチを取らない場合、Gopherコンテンツの作者にできることは、読者が手動でコピーしてクライアントに貼り付けるように、URLのリストを文書の一番下に貼り付けることです。これは、決して快適なユーザー体験ではありません。なぜなら、有効なGopherメニューを作るためには、すべての行に「i」というアイテムタイプと、偽のセレクタ、ホスト名、ポートを送信しなければならないからです。Gopherが主張するシンプルさと美しさは、これによって崩れ去りました。Geminiは、テキストコンテンツに好きなだけリンクを挿入できるというシンプルなアプローチをとっており、オーバーヘッドが非常に少なくなっています。これは、改善以外の何物でもないと思います。
もちろん、Gopherのやり方が本当に好きなら、Geminiはそれを複製することを止めるものは何もありません。アイテムタイプ0のコンテンツをMIMEタイプtext/plainで提供することもできますし、text/geminiドキュメントで一行一行をリンク行にして、RFC1436を意識したGopherメニューのルック＆フィールを、あの厄介な非標準「i」アイテムタイプなしで再現することができます。
2.4 Geminiはウェブのどの欠点を克服していますか?
GeminiはUser-AgentやRefererヘッダーに相当するものを含んでいません。また、リクエストフォーマットは拡張可能ではないので、後でこれらを組み込むことはできません。実際、GeminiのリクエストはリクエストされたリソースのURL以外には何も含みません。これはユーザー追跡を防ぐのに非常に大きな役割を果たします。
Geminiの「ネイティブコンテンツタイプ」（HTTP（S）のHTMLやGopherのプレーンテキストに相当）は、追加のネットワークトランザクションを必要としません（インラインイメージ、外部スタイルシート、フォント、スクリプト、iframeなどは存在しません）。このため、低速の接続でも素早く閲覧することができ、接続先のホストを完全に把握し、制御することができます。
Geminiのネイティブコンテンツタイプは、スクリプトの機能を持たない厳密なドキュメントであり、プロセッサ速度やメモリの限られた古いコンピュータでも簡単に閲覧することができます。
2.5 HTTPとHTMLのサブセットを使えばいいのでは？
多くの人は、Webのオプション的で本質的でない機能に関する認識された問題に対処するために、なぜ新しいプロトコルを作成する価値があるのかについて、混乱しています。ウェブサイトがユーザーを追跡し、CPUを占有するJavsacriptを実行し、役に立たない数メガバイトのヘッダー画像やさらに大きな自動再生ビデオを取り込むことが*できるからといって、それが「必要」であることを意味するわけではないのです。なぜ、既存の技術を使って邪悪でないwebサイトを作らないのか？
もちろん、これは可能です。 「Gemini」とは、リクエストヘッダが「Host」だけ、レスポンスヘッダが「Content-type」だけのHTTPと、タグだけがあるHTMLにほぼ相当します。
<CR><LF>
タグも<p>, <pre>, <a>, <h1>から<h3>まで, <ul>、<li>、<blockquote>に限定されます。 https://gemini.circumlunar.space のサイトで、これらを体験できます。既存の技術を使って邪悪でないwebサイトは可能なのです。
問題は、HTTPとHTMLの厳密に限定されたサブセットを決定し、レッテルを張って区別することは、人々が「その種類のコンテンツだけを」その種類の方法で消費するために行くことができる、明確に区分された空間を作ることにほとんど何の役にも立たないということです。https:// URLの向こう側にあるものが、サブセットの中にあるのか外にあるのか、事前に知ることは不可能です。避けたい機能の多くはユーザには見えない（しかし無害ではありません！）ので、サブセットだけを使うと主張するウェブサイトが実際にそうであるかを検証するのはとても面倒です。
主流のブラウザですべての不要な機能のサポートを無効にするのは難しいか不可能なので、誰かが規則を破れば、あなたはその結果を支払うことになります。不要な機能をすべて潔く無視するようなダブダブのWebブラウザを書くことは、Geminiクライアントをゼロから書くよりはるかに困難です。たとえそれができたとしても、それがレンダリングできるごく一部のウェブサイトを発見するのは非常に困難でしょう。
GopherやGeminiのような代替のデザインによる単純なプロトコルは、明白な境界と厳しい制限のある代替のデザインによる単純な空間を作り出します。Geminiスペースに入るときは確実にわかるし、あるリンクをたどるとそこから出るときも確実に、前もってわかるのです。そこにいる間は、そこにいる全員が同じルールで行動していることが、事前に確実にわかるのです。リラックスしてブラウジングを続けることができ、昨日現れたばかりの聞いたこともないサイトのリンクをたどっても、そのサイトがあなたを追跡したり、追跡「できない」ためにあなたにゴミを出したりすることはないと確信することができます。自分で書いたクライアントでこれだけのことができるのですから、信頼できることは間違いないでしょう。これは、ウェブの小さな、目に見えない下位のスペースを切り開こうとするのとは、まったく異なり、はるかに解放的で、はるかに力を与えてくれる経験です。
2.6 Gemini独自の欠点はありますか？
もちろんあります。
Geminiは、キャッシュ、圧縮、中断されたダウンロードの再開をサポートしていません。そのため、ネットワーク接続の速度と信頼性に影響を受ける大きなファイルの配布にはあまり向いていません。
2.7 TLSを使用しているのに、どうしてGeminiはシンプルだと言えるのですか？
TLSが必要だということは、Geminiのコードを書くのにTLSライブラリを使わなければならないということです。一方、例えばGopherでは、自分たちでゼロからすべてを書くことによって完全にコントロールすることができます。
もちろん、「ゼロから」のGopherクライアントでさえ、実際には、機能するIPスタック、DNSリゾルバ、ファイルシステムを提供するために、他の人が書いた何千行もの複雑なコードに決定的に依存しているのです。信頼できる暗号の実装を提供するためにTLSライブラリを使うのも、ほとんど同じことです。
Geminiはまた、TLSクライアント証明書（ウェブ上では非常に稀ですが）を、要件を備えた一級市民に変えます。これにより、Geminiリソースへのアクセスを特定の相手に制限したり、サーバーサイドのアプリケーションと自発的に「セッション」を確立したりすることが可能になり、クッキーやパスワード、認証トークン、その他あなたが慣れているものを受け渡しする必要がありません。これは、SSHの「認証キー」の概念に近く、実際、ユーザー認証のアプローチとしてはよりシンプルなものです。
2.8 なぜNoiseプロトコルのような最新のものでなく、TLSを暗号に使うのですか?
TLSは確かに欠点がないわけではありませんが、しかし
ほとんど全てのプログラミング言語でTLSライブラリのバインディングが利用可能です。
多くの開発者はすでにTLSを部分的にでも知っているので、Geminiを実装するために新しいことを学ぶ必要はありません。
多くのユーザはすでにTLSを信頼してWeb閲覧や電子メールを利用しているので、Geminiを使い始めるにあたり、見慣れない技術を信頼するかどうかを決める必要はありません。
TLSは深く浸透した業界標準であり、その定義と実装はどちらもセキュリティの専門家によって精査され、改良され続けるでしょうし、その作業はGeminiとはまったく関係なく行われるでしょう。
2.9 text/geminiを定義する代わりに、なぜMarkdownを使わなかったのですか？
text/geminiマークアップはMarkdownから多くを借りています。そのため、「なぜGeminiのデフォルトのメディアタイプとしてMarkdownを使用しないのか」と思う人もいるかもしれません。確かに、実装は複雑ですが、TLSのように、すべての主要な言語で利用可能なライブラリがたくさんあります。このルートに進まない理由は以下の通りです。
実際に多くの微妙に異なる、互換性のないMarkdownの亜種が存在します。したがって、TLSとは異なり、すべての異なるライブラリが同じように動作することは保証されていません。
Markdownライブラリの大部分はMarkdownをHTMLに変換するだけで、実際には何もしません。Geminiクライアントにとって、これはオリジナルよりも重い、不必要な中間フォーマットです
多くのMarkdownの亜種はGeminiのために望まれない機能、例えばインライン画像を許可しています。
Gopherの「1行に1つのリンク」という要件を維持したいという願いは、それが非常に明確なサイトデザインを促進するという理由からです。
もちろん、Gemini上でMarkdownを提供することは可能です。応答ヘッダーにtext/markdownメディアタイプを含めることで、より高度なクライアントがそれをサポートできるようになります。
2.10 なぜtext/geminiはインラインリンクに対応していないのですか？
text/geminiはGeminiのためにゼロから定義されたまったく新しいフォーマットなので、クライアント作成者は、既存の十分にテストされたライブラリ実装に頼ることができず、そのフォーマットをパースしてレンダリングする独自のコードをゼロから書く必要があるのが普通でしょう。したがって、フォーマットは正しく処理するために非常にシンプルであることが重要です。テキスト行とリンク行を別々の概念とするラインベースのフォーマットは、これを実現する。クライアントが各行を1文字ずつスキャンして、特殊なリンク構文があるかどうかをテストする必要がありません。最も単純な特別なリンク構文であっても、不正な構文の可能性があり、クライアントはそれに対して堅牢である必要があり、その処理はプロトコル仕様で明示的に対処する必要があるか（読むのが楽しくなく、頭に入りにくい、より長く退屈な仕様になる）、未定義のままにするか（異なるクライアント間で一貫した動作しないことになる）でなければならない限界事例も存在します。インラインリンクは、ある種のコンテンツにはより自然にフィットするかもしれませんが、プロトコルに必然的にもたらされる複雑さと脆弱性の増加に見合うだけのものではありません。
確かに、1行に1つのリンクという書き方に慣れるには、少し考え方を変える必要がありますが、時間が経てば簡単にできるようになります。また、このスタイルには利点もあります。最も重要なリンクや関連するリンクだけを含めること、リンクを関連するリストに整理すること、各リンクに最大限の説明的なラベルを付けることが奨励され、そのラベルが本文の流れに自然に合うかどうかを気にする必要がありません。
2.11 なぜtext/geminiはスタイリングをサポートしないのですか？
GeminiにCSSのようなものを求める声もあります。確かにCSSよりもずっとシンプルで軽量なものを設計することは容易ですが、Geminiはその代わりに、Geminiコンテンツのビジュアルスタイリングは書き手ではなく、読み手の唯一かつ直接的なコントロール下にあるべきだという立場をとっています。すべての人が同じ色やフォントを好むわけではありませんし、すべての読者、すべてのデバイス、すべての照明条件に対して最適なスタイリングの方法はありません。明るい背景に暗い文字、またはその逆を好むという古くからある対立以上に、ここで問題になっていることは多いのです。例えば、ディスレクシアのような読字障害を持つ人は、特別にデザインされたフォントを使うことで多大な恩恵を受けるかもしれません。コンテンツがどこでも同じに見えるような単純な「ワンサイズ・フィット・オール」のスタイリング・システムは、多くの人にとってパフォーマンスが低下することが保証されています。デバイスや文脈によって異なる外観を指定できる、より複雑なスタイルシステムは、個々の作者に、自分のカプセルがどこでも使えることを確認する仕事を負わせることになります。Webでの経験から、アクセシビリティの問題は、せいぜい後回しにされることが多いようです。コンテンツはコンテンツらしく、スタイリングはクライアントに任せるほうが、はるかにシンプルで、実際、コンテンツの作者にとってはずっと自由なことなのです。Geminiクライアントの中には、退屈でつまらないと思われる人もいるかもしれませんが、そうでなければならない理由はありません。高品質のフォントレンダリングと美しいタイポグラフィを備えたクライアントに対する需要があれば、そのようなクライアントはいずれ開発されるでしょう。そうなれば、そのようなものを重視するユーザーは、スタイリングをまったく気にしない作者が書いたコンテンツを読むときでさえ、Geminiスペースのあらゆる場所でその読書体験を楽しむことができるのです。
2.12 なぜHTTPのContent-lengthヘッダーに相当するものがないのですか？
プロトコルの非拡張性は、Geminiの主要な設計原則でした。クッキー、Etag、その他のトラッキングツールのようなものは、HTTPのオリジナルデザインには存在しませんでしたが、HTTPレスポンスフォーマットがオープンエンドで、新しいヘッダを簡単に含めることができるため、後からシームレスに追加することができます。Geminiが徐々にWeb的なものに変化していくリスクを最小限にするために、成功したリクエストの応答ヘッダーに1つだけ、正確に1つの情報を含めることが決定されました。指定されたデリミターで2つの情報を含めることは、後で3つ目の情報を追加するための非常に明白な道筋を提供します……ちょうど同じデリミターを再び使用します。1つの情報と任意に多くの情報の間に安定した位置は基本的にありません。したがってGeminiは、たとえそれがいくつかの素晴らしい、一見無害な機能を犠牲にしなければならないことを意味しても、前者の選択肢に懸命にこだわります。この制限を考えると、Content-lengthの等価物だけを含むよりも、Content-typeの等価物だけを含む方が明らかに有用に思えました。同じことが、Last-Modifiedのような、他の無害で有用なHTTPヘッダにも当てはまります。
GopherにはContent-lengthヘッダーに相当するものもなく、これはGopherスペースでは実用上の障害にならないことが証明されています。
このヘッダーがなくても、（Gopherとは異なり）クライアントは、TLS Shutdownメッセージの有無によって、正常に完了したGeminiトランザクションと、ネットワーク障害や悪意のある攻撃のために転送の途中でドロップアウトしたトランザクションを区別することが可能です。
大容量ファイルのダウンロードがあとどのくらい必要かをクライアントがユーザーに伝え、その時間を見積もることができないため、Geminiが大容量ファイルのダウンロードに非常にユーザーフレンドリーな体験を提供できないことは事実です。しかし、これはContent-lengthが指定されたとしても同じことで、そのような体験は、中断されたダウンロードを再開する機能など、プロトコルに追加される他の複雑さも必要とするからです。Geminiドキュメントはもちろん、HTTPS、BitTorrent、IPFS、DATなどを介してホストされるリソースに直接リンクすることができ、これは非常に大きなファイルのための最良の選択肢であるかもしれません。
2.13 なぜリクエストやレスポンスにプロトコルのバージョン番号が含まれていないのですか?
これは、将来的に「Gemini 2.0」にスムーズにアップグレードする計画がある場合にのみ有用でしょう。Geminiは、ウェブブラウザやサーバがあまりにも複雑で強力になりすぎたことに対する「less is more」反応です。Geminiに後から機能を追加する計画は意味がありません。その代わりに、可能な限り「最初から正しくする」ことを計画し、その後、アップグレードや拡張、機能追加を行わずに、プロトコル仕様を永久に凍結します。
これは過激に見えるかもしれませんし、賢明ではないかもしれませんが、私たちは慎重に楽観視しています。Gopherの仕様は約30年間変更されておらず、その仕様に対するごく少数の非常に小さな非公式の変更が、今日のGopherスペースで一般的に使用されているだけで、実際にその人気は高まっているのです。Geminiは、URI、MIMEメディアタイプ、TLSといった成熟したユビキタスインターネットプリミティブを非常にわかりやすく組み合わせており、何でも可能にするために遭遇したときにそれぞれの制約を取り除くのではなく、慎重に選択した制約の中で作業し、さらにはそれを受け入れる文化を育成しようと試みているのです。Geminiは、今現在も有用で得意なことがたくさんありますし、数十年後も同じように有用で得意でないと考える理由は何もないでしょう。
2.14 なぜレトロコンピューティングのサポートにこだわらないのですか?
Gopherはとてもシンプルなので、80年代や90年代のコンピュータでも簡単にプロトコルを実装することができ、人によってはこれがGopherの大きな長所の1つとなっています。GeminiのTLSの要件は、より現代的なマシンに限定しています。
古いマシンは素晴らしいものであり、それらを可能な限り長く稼働させ、オンラインにし、有用にしておくことは、素晴らしいことだと思います。しかし、大多数のインターネットユーザーにとって、これを容易にするために、あらゆるプライバシー保護を犠牲にするのは筋が通りません。しかし、GeminiはGopherを置き換えることを目的としていないため、レトロ互換性のあるインターネットがそれによって直接危険にさらされるわけではないことを忘れてはなりません。実際、現在Gopher経由でコンテンツを提供している人々は、同じコンテンツを同時にGemini経由で提供し始めることを強く推奨されています。レトロコンピューティングのファンはGopher経由でコンテンツにアクセスし続けることができ、一方、現代のコンピュータユーザーはGeminiに切り替えて何らかの利益を享受することができるのです。
3. Geminispaceを始める
3.1 Geminiスペースに興味があるのですが、どうやって調べればいいですか？
Geminiスペースを探索する最も簡単な方法は、以下のようなWebプロキシやポータルサイトを使用することです。
mozz.us Geminiポータル
vulpes.one Geminiポータル
これにより、通常のwebブラウザでGeminiスペースを探索することができるようになります。もし気に入ったものがあれば、専用のGeminiクライアントをインストールすることを検討してもよいでしょう。クライアント（およびその他のソフトウェア）の一覧は、以下のリンクでご覧いただけます。AndroidやiOSのようなモバイルプラットフォーム用のクライアントもあります。
Geminiソフトウェアリスト
sshクライアントがインストールされている場合、インストールせずにいくつかのターミナルクライアントを実行することで試すことができます。
ssh kiosk@gemini.circumlunar.space
この Gemini キオスクは bitreich.org にある Gopher キオスクに触発されました!
3.2 さて、クライアントを手に入れましたが、コンテンツはどこにあるのでしょうか？
今のところ、Geminiスペースはまだ十分に小さいので、そこにあるものを発見する方法としてディレクトリを使用することは可能です。以下にそのいくつかを紹介します。
medusae.spaceのジェミニ・ディレクトリには、テーマ別のカテゴリーに分けられたカプセルのリストがあります。
geminispace.infoの検索エンジンの既知のジェミニホストのリスト
最初の50台のジェミニサーバーの歴史的なリスト
もしあなたが何か特別なものを探しているなら、Geminiには1つの検索エンジンがあります。
geminispace.info、Geminiサーチエンジン
Geminiスペースには、最近更新されたものを見つけやすくするために、2つの公開アグリゲータがあります。
CAPCOM：ジェミニコンテンツのAtomフィードを集約しています。
Spacewalk: 新しいコンテンツを見つけるために変更検出を使用します。
3.3 Geminspaceに自分自身のコンテンツを置くには？
VPSや自宅のコンピュータに自分のGeminiサーバを立ち上げるのも一つの方法です（RaspberryPiのような小さなSBCはGeminiサーバとして完全に機能します）。サーバーソフトウェアは、様々な種類から選ぶことができます。
Geminiソフトウェア一覧
また、コンテンツをホスティングしてくれるところを探すこともできます。Geminiホスティングは、以下のプロバイダーからも提供されています。
idf.looting.jp
SourceHut (カスタムドメインのサポートを含む!)
「pubnix」または「tilde」コミュニティ（ユーザがsshでログインし、ローカルの電子メール、チャット、BBSアプリケーションを使ってやりとりするマルチユーザunixシステム）の多くもGeminiホスティングを提供しています（通常はウェブやGopherホスティングと並行して提供されます）。以下のコミュニティのアカウントを取得することができるかもしれません。これらのコミュニティのほとんどはGemini自体よりも古く、他のサービスに集中していたり、特定のテーマや興味に特化している場合があることに注意してください。これらの素晴らしい小さな世界を自分のものを捨てるための自由空間として扱うのではなく、選択肢を慎重に調査し、全体としてうまく適合できそうなところに参加するようにしてください。
Ctrl-C.club
envs.net
Tanelorn City, 作家を中心としたサーバーです。
tilde.pink
Raw Text Club、別名RTC
Breadpunk.club、パン作りをテーマにしたサーバー
もしあなたがGeminiホスティングを提供していないpubnixコミュニティに所属しているなら、このサービスを追加することに興味があるかどうか、管理者に聞いてみても損はないですよ。
もしあなたがpubnixホスティングを利用するために必要な技術（sshやsftp、ターミナルテキストエディタ、unixファイルパーミッションなど）に不安を感じるなら、以下のサービスで無料のアカウントを取得し、ウェブアプリケーションを介してカプセルを管理することができます。
Gemlog Blue：cookiesやJava scriptを使わない、超軽量なインターフェイスが特徴です。
Flounder：あなたのコンテンツはGeminiとWebで同時に利用可能です。
3.4 自分のGeminiサーバを立ち上げたのですが、何かすべきことはありますか？
メーリングリスト（質問1.3参照）に参加することを検討してください。そうすれば、あなたの新しいサーバをコミュニティに発表したり、サーバソフトウェアやGeminiプロトコル自体の更新などの最新情報を入手したりすることができます。
以下のリンクから、geminispace.infoの検索エンジンにあなたのサーバーのURLを送信して、クロールされるようにすることができます。
geminispace.infoにURLを登録する
4. Geminiプロジェクトに貢献する
4.1 Geminiプロジェクトの音が好きなんですが、どうしたらいいですか？
Geminiはすでに驚くほど多くのクライアントとサーバーの実装が存在しています……これ以上歓迎されないというわけではありませんが、今本当に不足しているのは、ソフトウェアではなくコンテンツだということです。Geminiスペースでより面白くエキサイティングなものを見つければ、より多くの人が自分自身のコンテンツを追加したくなることでしょう。ですから、あなたがこのプロジェクトにできる最大の貢献は、このプロセスの一部になることです。Geminiスペースにあなたのコンテンツを取り込む方法の詳細については、上記の質問3.3を参照してください。
もしあなたに必要な技術的スキルがあるならば、人々がコンテンツを公開するために利用できるホスティングサービスを提供することで、Geminiスペースの発展に大きく貢献することができます。これは、VPS に sftp 専用のユーザーアカウントを設定するのと同じくらい簡単なことです。ホスティングを提供することは、必ずしも大きなコミットメントである必要はありません。提供されている最も安価な VPS サービスを使用すれば、十数人のユーザを非常に快適にホストすることができます。多数のホストがそれぞれ比較的少数のユーザのコンテンツを提供することは、少数のサーバがそれぞれ数百または数千のユーザをホストするよりも、はるかに堅牢で持続可能な生態系となります。
Gemlog BlueやFlounderサービス（質問3.3を参照）のようなものですが、Mastodonインスタンスのように、人々が自分のマルチユーザーサイトを簡単に展開しカスタマイズできるようにパッケージされ文書化されたものです。
また、公式サイトやドキュメントの修正・追加・翻訳を行うことで、プロジェクトを支援することができます（以下の質問4.2および4.3を参照してください）。
4.2 Geminiの公式サイトやドキュメントに貢献するにはどうすればいいですか？
今読んでいるFAQを含め、gemini.circumlunar.spaceでホストされているすべてのドキュメントは、単一のgitリポジトリにあり、読み取り専用で一般に公開されています。このリポジトリは、以下のようにしてクローンすることができます。
git clone git://gemini.circumlunar.space/gemini-site
それから、関連するファイルに変更を加えてください（URLの構造はリポジトリの構造を正確に反映しているので、例えばgemini://gemini.circumlunar.space/docs/faq.gmiはレポのdocs/faq.gmiに存在することになります）。意味のあるコミットメッセージ（誰があなたの仕事をしたのかがわかるように、名前とメールアドレスを必ず設定してください！）で、1つの概念の変更につき1つのコミットで、変更をコミットしてください。次に、あなたの作業を上流に送るためのオプションが二つあります。
gitのsend-emailコマンドが設定されている場合（チュートリアルのリンクは以下を参照）、コマンド一つであなたのコミットを含むパッチをにメールすることができます。そうでなければ、単に実行するだけでよいのです。
git format-patch origin
を実行してパッチファイルを作成し、それを普通のメールソフトを使って手動でメールに添付することもできます。
git send-email を設定するための親切なチュートリアル
4.3 Geminiのドキュメントを私の母国語に翻訳したいのですが、どうすればいいですか？
ありがとうございます。ドキュメントの翻訳をボランティアで行うことは、プロジェクトを支援する素晴らしい方法です。
これを行うには、まず、上記の質問4.2で説明したように、gitリポジトリをクローンしてください。リポジトリの「doc」ディレクトリに移動し、あなたの言語の ISO 639-1 コード 2 文字で新しいサブディレクトリを作成します。例えば、フィンランド語の翻訳は「doc/fi/」に、日本語の翻訳は「doc/jp/」に、といったようにです。コードの完全なリストは、以下のリンク先のウィキペディアで見ることができます。例えば、ポルトガルやブラジルで話されているポルトガル語は「pt-PT」や「pt-BR」といった具合です。
ウィキペディアの言語コード一覧
「doc」にある英語のファイルを翻訳するために、あなたの言語のサブディレクトリに対応するファイルを作成します。例えば、ドイツ語に翻訳した「doc/specification.gmi」は 「doc/spezifikation.gmi」というファイル名になります。「doc」に含まれるファイルは、時間と労力の許す限り、いくつでも翻訳することができます。部分的な翻訳を提出することを恥ずかしがらないでください。あなたの言語を話す他の誰かがあなたの努力を見たら、残りの作業の一部または全部を提供してくれるかもしれません。翻訳されたコンテンツがあるに越したことはありません。
翻訳が終わったら、「doc/index.gmi」ファイルをコピーして、翻訳したファイル名とドキュメントのタイトルに合うように修正し、まだ翻訳していないオリジナルのドキュメントへのリンクを削除してください。
最後に、新しいサブディレクトリへのリンクを含めるために「doc/translations.gmi」を更新してください。
翻訳をリポジトリにコミットし、上記の質問4.2で説明したように、Solderpunkにパッチを送信してください。
（原典）gemini://gemini.circumlunar.space/docs/faq.gmi
（2022年12月13日 初版）
戻る