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