Gemtext雜感
English version: Thoughts on Gemtext
プロトコルとマークアップ言語
まづ、GeminiプロトコルとGemtextマークアップ言語は別物 である事を明確にしたい。確かにGemtext文書はGeminiのネイティヴ應答フォーマットで、プロトコルやユーザと密接に關はつてゐるが、ユーザにGemtext文書で配信する義務は無いし、他のフォーマットで文書を公開する事は可能である（例へば、HTML）。
一方で、Geminiプロトコルで參照できるコンテンツの殆どがGemtext文書のため、コンテンツの質に影響を與へる事は必至である。そのため、兩者の評價は非常に混同され易い。
私はプロトコル、マークアップ言語、いづれにも疎いが、一HTML文書作成者として、Gemtext言語／文書の直感的な感想を書く。
WebプロキシサービスでGemtext文書を見てみた雜感
アスキーアートが多い
幅（行間）が取られる
本文までスキップしなければならない
讀むのが遲くなる
フォントによつては崩れて意味を爲さない（環境に依存する表現 ）
非表示にできない
代替テキストが無い
文字による藝術的表現を否定はしない。だが、單純にテキスト情報を參照しに來たユーザにとつて、煩はしい（場合によつては、明確に障碍となる）。視覺表現を受容するとしても、確實な表現ではない（フォント・文字幅字間 ・行間に依存）。畫像やスタイルシートの方がましだ。なぜなら、（ユーザエージェントが對應してゐれば）いづれも無效にできるからだ。その上代替テキストがあるか、そのままテキストが參照できるからだ。
2022年4月30日：仕樣はフォントの種類を定めてゐるだけだ。ユーザは字間・行間を調整してゐるかも知れない（特にコードを讀む場合）。
Speculative specification 、5.4.4 Preformatted text lines より：
Preformatted text lines should be presented to the user in a "neutral", monowidth font without any alteration to whitespace or stylistic enhancements.
もし配置されたAA に意味 が無いとすれば（HTMLであればalt屬性値が空、つまり缺落しても參照に支障の無い表現）、それは裝飾 だ。
視覺が望めない場合においては、整形濟テキスト（HTMLであればpre要素に當る）がコードなのか、藝術性／裝飾性の高い表現なのか判斷が附き難い（文脈を判斷材料にできるとしても）。致命的な問題は、重要な情報をAAで置換へてしまふ事だ。例へば著者の名前 や聯絡先 、見出し がAAの中でしか表現されてゐない場合、ユーザが情報を得る事は困難になる。
2022年4月30日：ユーザが必要とする情報（文書のタイトルや見出しなど）は、單純なテキストにすべきだ。
著者は、AAが意味不明な記號の羅列になるリスク を負つてゐると自覺すべきだ。
文書をどのやうに描畫するかはクライアント／ユーザに依存する、とProject Geminiは定めてゐるが、アスキーアート乃至《ないし》 整形濟テキストのアクセシビリティや代替表現については、何ら觸れてゐない 。
2022年4月25日：整形濟テキストの代替テキストを設定する事は可能だが、著者に用ゐる義務は無く 、クライアントにも描畫する義務は無い 。Speculative specification 、5.4.3 Preformatting toggle lines より：
Any text following the leading "```" of a preformat toggle line which toggles preformatted mode on MAY be interpreted by the client as "alt text" pertaining to the preformatted text lines which follow the toggle line. Use of alt text is at the client's discretion, and simple clients may ignore it. Alt text is recommended for ASCII art or similar non-textual content which, for example, cannot be meaningfully understood when rendered through a screen reader or usefully indexed by a search engine. Alt text may also be used for computer source code to identify the programming language which advanced clients may use for syntax highlighting.
義務化されたとしても、手動でマークアップする人間がゐる以上、代替テキストの設定を徹底する事はできない（エラーとして處理しない限り）。
なぜ私は畫像の代りにAAを見なければならないのか ？
2022年4月30日：日本のAAは、等幅フォントで表現されるとは限らない 。テキスト行 に現れる可能性は充分にある。その場合、囘避策は無い。
2022年4月30日：畫像が文書の補完に適切なら、畫像を選ぶべきだ。リンクするだけで良い。
繪文字
顏文字
裝飾記號
ナビゲーション（戾る リンクとかパンくづとか）、署名、ライセンスが無い／有る
本當に初期のWebみたい
コンテンツにメタ情報を追加できない 。最低でも以下は利用したい：
タイトル
公開日
改訂日
署名（作成者、著作權者）
責任者の聯絡先
ライセンス
HTMLであれば、title要素、meta要素、address要素、footer要素など
コンテンツ間の關係性を示せない 。（HTMLであれば、link要素、rel屬性）
見出しレベルが3しかない 事から、Gemtext言語は單純で短い文書 の作成を意圖してゐる。
クライアントを利用した事は無いが、外觀の制御が貧弱なら、Webプロキシからの參照が無難だらう（Webブラウザからユーザスタイルシートを利用できるため）。私はプロキシサービスが生成するソースに不滿があるが、それは又別件だ。
ここで判るのは、どんなに規格や仕樣を簡素にしたところで、著者に文書と裝飾を分離するといふ意識が無ければ、アクセシビリティの高い文書は作れない といふ事だ。何人の著者がスクリーンリーダ（讀上げ）でのアクセスを想定しただらう？
普及 したとしてもだ、繪文字や記號、AAを多用した視覺的 な文書が氾濫し、アクセシビリティが破壞される事は目に見えてゐる。既にその豫兆があるのだから。
著者がスタイルシートを持て ない——その期待、想定、前提 はかうだ、文書に裝飾は一切無い 。だからGemtext文書の著者は、情報（アクセス）を破壞しないやう注意する必要がある（と言つて、普通に文書を書くだけで良いのだが）。
仕樣書にはアクシビリティに關して警吿も、ガイドラインも無い 。
HTML 4.01仕樣書 と比較しても良い。HTMLは著者の自由度が高い分アクセシビリティを壞し易いとも言へるが、同時に配慮した構成も可能で、各章の註釋は實用的な助言を含んでゐる。
アクセシビリティの低下を招く表現に對し、何の解決策、代替案、指針を示さない。
著者からすると：メタ情報や關係性の明示、アクセシビリティを削ぎ落してまで頒布するコンテンツつて何だ？
マークアップ言語を簡素化すると、文書が弱くなる（情報量が少なくなり、アクセシビリティ・ユーザビリティが下がる）。
なぜ仕樣は狙ひ通りに運用されないか：ヒューマンエラー
文書を構造化できる仕樣があつても、人間が構造的な文書の書けない事が問題 なのだ。だから、敎育 するか强制 するしかない。仕樣は後者を請負ふ。前者は人間（社會）的問題で、人間が一番引受けようとしない部分だ。
例へば、HTMLの仕樣書は、どの要素・屬性がどういつた場面でなぜ （非）推奬されるか說明する事によつて、著者に一定の注意を與へてゐる。
著者（ユーザ）の自主性に依存するのは無責任である。人間は常に仕樣よりも賢いか愚か だからだ。仕樣設計者は、ユーザに望ましい振舞を示すべきである。
ネイティヴ應答フォーマットであるなら尙更、設計者の責任は大きい。流通コンテンツの質に影響するからだ。そのため、Gemtextはプロトコル自身の評價と同一視される傾向にある。又、流通コンテンツに不滿がある人々は、Gemtext仕樣を改訂する事によつて、コンテンツの質を制御しようとする。
Gemtextのやうな貧弱なマークアップ言語は、HTMLを再評價する切つ掛けになる。如何に人間を統制できないかも判る——さう、仕樣とは人間の統制 なのだ。殆どの著者は、プレーンテキストかHTMLで事足りる。どの程度のアクセス性を望んでゐるかでフォーマットは決る。
FAQは、Gemini is a new application-level internet protocol for the distribution of arbitrary files, with some special consideration for serving a lightweight hypertext format which facilitates linking between files. と始まる。プレーンテキストを整形した文書、ぞんざいに言ふなら、プレーンテキストよりまし といつたものを配信するためにGeminiは存在するのだ。文書をアクセシブルにしたいなら、HTMLを利用するべきだ。
Gemtextのアクセシビリティが低い事を考へれば、役に立つ リソースがGeminiに進出しないのは當然 である！
單純に、Gemtext言語は收容できる情報量でHTMLに劣る 。
スクリーンリーダ（讀上げソフト）のユーザに視覺表現と同等の情報を與へたい著者は、HTMLを選擇するだらう（例へば、インラインレベルでの强調は、强意のあるアクセントで讀まれる）。
文書にメタ情報（聯絡先、ライセンスなど）を與へたい著者も、やはりHTMLを選擇するだらう（Gemtext言語はリンクを含むが、文書との關聯性は示唆しない）。
そのうちHTTPで提供された文書をGeminiでミラーする（Wayback Machine のやうな）サービスが現れるかも知れないが：
本文に限定しないと煩雜になる（サイドバー などの排除。丸々のコピーであれば、テキストブラウザで參照するのと大差無い）。
h4以降の見出しはどうするか？ #### 見出し ？
輕量なハイパーテキスト言語での頒布は決して無駄ではないが、餘りにも機能的に貧弱である（そして今の所、クライアントが普及するかも分らない）。私は、それが萬人 に價する文書であれば、HTMLで提供して欲しいと思ふ。インラインマークやメタ情報などが、多くの環境から利用できるからだ。HTML Living Standard が肥大化してゐると言ふなら、HTML 4.01でもISO-HTML でも良い。Geminiで宣傳したいならリンクするだけだ。恐らく、HTTPとGeminiとの共存はそのやうに働く。人々は安全 な場所でローカル（分野特化的）な情報を取得し、有意義なHTTPコンテンツを見附け る。
私がGemini空間に參加するとしても、HTML文書を提供するだらう。なぜなら、私の書く文書はHTMLに適してゐる からである（インラインレベルでの强調があり、ユニバーサルアクセスを志向し、メタ情報を與へたい事などから）。
Geminiプロトコルは良いアイディアだと思ふが、Gemtextが流通コンテンツを制限してゐる。それが仕樣設計者の狙ひで、日記程度のものを配信する事が目的だつたと言ふなら、私は構はない。ただ、人々が愚直なまでにGemtext文書を書く理由は無いといふだけで。（私は日記でさへGemtext言語では滿足できない）
バランス。仕樣の要約：週末の時間で書けるクライアントは、單純なテキストしか扱へない。その結果、連續した空行、アスキーアート、記號で裝飾された見出し、Gemtextには適さない文書形態に耐へねばならないとしたら、私はGemini空間を選擇はしないだらう。構造の徹底された文書が讀み易いのは言ふまでもない。私はGemini空間でさへ、コンテンツフィターを必要とする。
2022年4月30日：HTMLとの差は、主にセマンティクス的なもの——上記で述べたやうに、收容できる情報量である。例へば、文書との關係性を示すrel屬性や、引用元のURIを示すcite屬性など。Gemtextは、各行に對して情報の關聯附けができない（意味を持たせられない）。
だから、ホスティングサービスが時折提供するHTMLへの自動變換 は、Webから參照できる意義はあるけれども、文書自體の情報量が增えるわけではない。
單一の行が單一の役割しか持たない、といふのは構文處理の負擔が少ないのだらうが、その（セマンティクス的な）可讀性は人間のみ が有してゐる。
クライアントは引用文を認識できるが、引用元を判別・取得する事はできない。
署名やライセンスの書き方一つにしろ統一 されてをらず、著者の表現に依存してゐる。書式を定めてゐれば、人間も機械もどこに何があるのか すぐ判る。アクセシビリティ／ユーザビリティの向上が望めるのである。
アグリゲータや檢索エンジンの處理も樂になるだらう。例へば、ライセンスの書式を統一してゐれば、特定のライセンスが適用されたコンテンツの檢索が容易になる。
2022年4月30日：なぜ引用行に對して、引用元の明示を省いたのだらう？ さう難しい實裝ではないと思ふが。
同じくGemtextに見苦しさを感じた人はゐたやうだ：
Stepping away from Gemini - Drew DeVault's geminispace ：
I like to read medium- to long-form technical content. All of my favorite authors for this post only on HTTP
中・長篇の技術文書がGemtextに向かない事くらゐ、仕樣を見れば分り切つた事ではないか。
2022年5月2日：仕樣設計者は、流通コンテンツの質を保證する事はできない 。コンテンツの流通を保證するのみである。
質は人間的（社會的）な問題である。Webに優れたコンテンツが存在するやうに、Geminiにも粗惡なコンテンツは存在する。質はコンテンツに關はる一人一人の責任 である。
であるからして、私が期待できるのは、自分が書く整然とした文書である。フォーマットに適したコンテンツを提供する事である。
中途半端な文書と外觀の分離
私の心配は、Web黎明期《れいめいき》 に起つた事、今尙（プレーンテキストで投稿する形式の）揭示板 で起きてゐる事に起因する。連續した改行、空白による字間の調整、記號の罫線、アスキーアート。これらはスタイルシートでもつても排除する事ができない（改行はbr要素であれば可能）。
これは實際 HTMLで起つてはゐるが、大半のWebサイト制作者はHTMLと CSS（外觀を制御する手段）を知つてをり、文書と裝飾は何とか 分離できてゐる。未だに記號やアスキーアートで裝飾してゐるのは、プレーンテキストでしか投稿できないサイト（揭示板やSNS）か、CSSの知識が乏しい制作者だけだ。要するに、著者のエゴを發散できる場所がある事で、適切な（專らテキストのみの）情報提供が逹成されるのである。讀者は制作者スタイルシートを無效にし、そのエゴを囘避できる。
Gemtextは裝飾の手段を持たない。それは文書と外觀の分離を實行 してゐるからだ。問題はその原則を理解してゐないか、抵抗 してゐる著者がゐる 事で、彼らは自らが裝飾を施す事で、著者／讀者のアクセシビリティ／ユーザビリティを改善しようとする。クライアントに任せよう と言ふ事はできる。だが、外觀を高度に制御できるクライアントが流行するまでは、著者が態度を改める事は無いだらう。Webがさうであつたやうに。
逆に言ふと、裝飾を行ふ著者は、Gemtext文書の參照にアクセシビリティ／ユーザビリティの障碍（讀み辛さ）を抱へてゐる 可能性がある。文書の確實な 讀者が著者自身である事を考へれば、障碍を緩和しようとする工夫は實に自然である。
私は仕樣設計者に聞きたいのだ。著者が記號や繪文字でマーカーを再現したり、章の區切りに記號を用ゐたりする事は、分離の原則に反してゐないのかと。HTMLとCSSが上手く分離できてゐるために、私は氣になるのだ。
アスキーアートは認められない 。なぜなら、畫像とは異なり、機械が處理できるデータ形式 ではないからだ。確實に無視（抽出）したり、代替表現に置換へたり、リンクするといつた事はできない。
アスキーアートは論理的表現ではない。アスキーアートの展示 を目的にしてゐない限り、全てのアスキーアートは、缺落しても文書の參照に支障を來さない。支障を來すとしたら、何らかのデータ形式の代替として用ゐてゐるからだ（特にテキスト、畫像）。
なぜ文書のタイトルをアスキーアートで表現しなければならないのか？ 必然性は無い。データとして處理できない限り、アスキーアートは確實に ユーザの障碍になる 。
データ形式ではないため、仕樣で排除する事もできない 。存在は著者の判斷に依存するのである。
空行
段落・章・話題の區切りは論理的文書構造 だが、仕樣ではテキスト行・空行はそのやうな意味を持たない。
空行は、度が過ぎれば裝飾表現だ。無意味な空行（空間）がどれだけ不便か理解してもらへるだらうか。
英語圈ではどうか知らないが、日本では、間 を表現するために過剩な改行をする著者が一定數存在する。これは變らない人々、變らないWeb でも述べた參照の先延ばし であり、ユーザが情報にアクセスする事を妨害してゐる。場面轉換や章區切りは文書の構造 として示されるべきであり、著者が 見出しと本文で文書構造（章）は示されてをり、著者は空行を必要としない 。
HTMLではソースの空行は外觀に影響を及ぼさないが、Gemtextでは影響が出る。
文書構造と外觀が分離されるとしたら、連續した空行 とは一體何なのか。そこに文書構造 は存在するのか。なぜクライアントは連續した無意味な 。仕樣はその理由を說明してゐない。10行も50行も改行する著者が存在しない とでも言ふのか（HTTP/HTMLに前例があり、Gemtext文書で可能 だから私は恐怖してゐるのだ！）。
Speculative specification 、5.4.1 Text lines より：
Consecutive blank lines should NOT be collapsed into fewer blank lines.
行數に制限が無い 。仕樣に準據したクライアントは、100行でも1000行でも空行を描畫する。著者やエディタのエラーを考慮してゐない。
2022年4月30日：なぜ著者は行間を制御できるのか ？
空白文字
整形濟テキスト以外の行の空白文字の處理について、仕樣は何ら述べてゐない。
言語の文法を再現する以外で、連續した空白文字を描畫する正當性 は何か。
もし文法が單一の空白文字のみで成立つなら、2つ以上の空白文字は1つに纏められるべきである。
文書構造と外觀が分離されるとしたら、連續した空白文字 とは何なのか？
連續した空白文字の描畫を容認すると、著者が空白文字で餘白、字間の調整をする可能性がある。
タブ文字はどう處理される？
クライアントが連續した空白文字を描畫するなら、文書全體が整形濟テキスト と言つて差支へ無い。空行と同樣に、連續した空白文字を利用した外觀の制御はHTTP/HTMLで起つてゐる事で、Gemtext文書でも可能である。
HTMLでは半角の空白文字は外觀に影響を及ぼさないが、Gemtextでは影響が出る。
HTMLでは全角の空白文字が外觀に影響を及ぼし、日本ではこれを利用して外觀を制御してゐる著者がゐる。
字數に制限が無い 。仕樣に準據したクライアントは、100字でも1000字でも空白文字を描畫する。著者やエディタのエラーを考慮してゐない。
インラインマークの意義
Gemtextは、インラインレベルのマークを一切持たない 。
Project Gemini FAQ 、2.10 Why doesn't text/gemini have support for in-line links? より：
Because text/gemini is an entirely new format defined from scratch for Gemini, client authors will typically need to write their own code to parse and render the format from scratch, without being able to rely on a pre-existing, well-tested library implementation. Therefore, it is important that the format is extremely simple to handle correctly. The line-based format where text lines and link lines are separate concepts achieves this. There is no need for clients to scan each line character-by-character, testing for the presence of some special link syntax. Even the simplest special link syntax introduces the possibility of malformed syntax which clients would need to be robust against, and has edge cases whose handling would either need to be explicitly addressed in the protocol specification (leading to a longer, more tedious specification which was less fun to read and harder to hold in your head), or left undefined (leading to inconsistent behaviour across different clients). Even though in-line links may be a more natural fit for some kinds of content, they're just not worth the increased complexity and fragility they would inevitably introduce to the protocol.
Speculative specification 、5.1 Overview より：
The format permits richer typographic possibilities than the plain text of Gopher, but remains extremely easy to parse. The format is line-oriented, and a satisfactory rendering can be achieved with a single pass of a document, processing each line independently.
インラインマークの價値は、アクセシビリィの向上 にある。
著者は注意書きを目立たせる事ができない 。檢索エンジン（例：geminispace.info ）は檢索語の强調すらできない 。そのため、人々は空白、記號、繪文字などを使つて讀者の氣を惹かうとする。既に述べた通り、裝飾的な表現はアクセシビティに影響を與へる。一つには著者が不注意な事もあるが、マークアップ言語に必要なマークが缺けてゐても、このやうな場當り的な代替表現は起る 。
檢索エンジンに關しては、Gemtextの用途ではないだらう。他の言語で實裝すべきだ。
マークの意義は、單に意味を與へられるといふだけでなく、書式（情報提供の手段）が統一 できるといふ事だ。
言語／文化／文󠄁體／アクセス環境に依存せず 情報提供ができる。（ユニバーサルアクセス！）
ブロックレベルの引用が提供できて、インラインレベルの引用が提供できない道理は何か。
インラインマークが無い事で、クライアントは構文解析が容易になる（開發自體が容易になる）、といふ事が理由らしい。つまりクライアント開發者の都合が優先されてゐる。開發者・ユーザの自主性は尊重されるが、流通コンテンツの質に與へてゐる影響は妥當なのか。
週末の時間でクライアントが書ける事は、情報量／アクセシビリティの低さに見合ふメリットなのか ？
アスタリスクで圍まれたテキストが常に强調であるとは限らない。引用符で圍まれたテキストが常に引用であるとは限らない。マークアップ言語は、人々に情報を傳逹するための、共通の目印 として機能する。Gemtextが省いたマークは、餘りにも日常的 、實質的、實用的だ。
附錄：プロトコルに關してのメモ
Geminiには商業的な價値は無いから、（簡素な實裝を貫けば）コミュニティ主體でゐられる、といふ意見：Gemini is Useless - Alex's space
弘吿（テキスト、リンク）やプロパカンダを插入する事は可能である
弘吿附きのホスティングサービスが存在してもをかしくはない
TLSの義務化は隱れサービスを考慮してゐない、といふ意見：kill-9 - harmful - software - gemini
サービスやマークアップ言語ではなく、プロトコルを實裝する意義は、コンテンツが安全で簡素だと保證する 事にある。
例へば、輕量サイトのリンク集には、サイトが方針轉換するリスクがある（スクリプトや弘吿の追加など）。
Project Gemini FAQ 、2.5 Why not just use a subset of HTTP and HTML? より：
The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume *only* that kind of content in *only* that kind of way. It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it. It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user. It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you'll pay the consequences. Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render.
2022年5月1日：これは參照してゐる文書が 安全だといふ話
どうにもそこに矛盾といふか、無意識の期待 といふものがあつて、私は居心地惡く感じる。ハイパーリンクのURIも、送受信するフォーマットも自由 にも拘らず、Geminiのメリット （非複雜空間、輕量テキスト）を指向する人々は、Geminiプロトコルによる、Gemtext文書の相互リンクを期待してゐる HTTPだつてHTTPのHTMLを期待してゐるわけだが、讀者の殆どはコンテンツが讀み易く整形されてゐれば（つまりユーザエージェントがプロトコルを處理できて、コンテンツが人間向きのフォーマットであれば）、實際にはどんなプロトコル／フォーマットであらうと氣にしない。
著者は適切に文書を補完する必要（欲求）がある。仕樣で可能にしてゐるにも拘らず、プロトコルやフォーマットを制限する（壓力を掛ける）なら、檢閲にもなりかねない。
例へばPDFや壓縮形式へのリンクには配慮 が必要だと思ふけれども、文書にそのやうな配慮はしたくない。要するに、クライアントの處理が躓《つまづ》 くかどうかが心配なのだ。
クライアントが外部プロトコルを檢知、制御する のが望ましい。既にさういつた機能を實裝したクライアントは存在するが、仕樣書を見る限り、この動作は義務ではない。クロスプロトコルの處理については、別途文書で言及されるのみである（仕樣はこの文書について言及せず、リンクもしてゐない）。
Best practices for Gemini implementations 、Cross-protocol redirects より：
Cross-protocol redirects (i.e. redirects from Gemini to something else, like Gopher) are possible within Gemini, but are very heavily discouraged. However, misconfigured or malicious servers will always be able to serve such redirects, so well-written clients should be ready to detect them and respond accordingly.
技術に特定の狙ひがあるために、讀者にはハイパーリンクを內部 に限定できない不滿がある。ダークネットと同樣に。
スクリプト、トラッカーが無い世界の構築
コンテンツがユーザを判斷 して空白ページを返したり、內容を差換へたり、人間かテストする（例：Captcha）といつた事は無い
2022年5月1日：低電力コンピューティング
普及してゐるコンテンツが（情報量的、アクセシビリティ的に）貧弱なマークアップ文書
HTML文書を頒布する事もできるが、クライアントが對應してゐるとは限らない 。
2022年4月30日：私には無い視點での捉へ。私は基本的にクライアントから讀む 事しか考へてゐない：Articles - Privacy.flounder.online
コンテンツの本文のみGemtextへ變換 する事は需要があるだらうな。
マニュアルや小說をGemtextとして發行する事は何ら問題は無いが、著者として氣になるのは、プロトコル・文書の持續可能性である。10年後、50年後に讀めるかどうか、對象讀者が容易にアクセスできるか（クライアントの普及）。
2022年4月30日：ダークネットは高度な匿名性を持つが、HTMLとCSSで構成されたWebサイトが殆どで、複雜な仕樣に準據したユーザエージェントが必要だといふ事實は變らない。
變らない人々、變らないWeb で指摘したやうに、ダークネットの（プライバシーを尊重してさへゐる）サイト制作者が、アクセシビリティ／ユーザビリティやHTMLに熟知・配慮してゐるとは限らない。
附錄：既に存在するサービス（2022年5月14日時點）
HTTP/Geminiプロキシ
ホスティング
投稿プラットフォーム
檢索エンジン（リンク集）
アグリゲータ（フィード配信）
コメント
スキ ボタン
揭示板
SNS
マイクロログ
リング（リンクシステム）
後書
自家製プロトコル 。設計者の手に負へる範圍に留めてゐるのだらう。
Webの置換へでも問題解決の手段でもないとしたら、Geminiプロトコルとは何なんだらう。ただの配信手段か。でも何 を配信するんだ？
本當に（非常に地域的な）輕めの日記くらゐしか用途が浮ばない。それもマイクロWeb日記 （序列リストで思考の經過を綴る日記）の方が私は好きだ：
マークアップ言語に疎い人、マークアップが面倒な人、に向くか。
日本語文書が增えない事には何とも。定期的に書いてゐる人はゐるのだらうか。
Geminiに觸れたばかりでこんな事を書いて平氣か。いや、思想には共感できても、私には必要なマークが無かつたんだ。强意の無い文章なんて書けない。小說ですら强調はある。
HTMLで書く、といふのが私の妥當な 答へだ。下手にHTMLを模倣するよりも、成熟した、實績のある 、ユニバーサルアクセスを志向したHTMLそのものの方が無難に文書を提供できる。
どこかの時點で、HTML 4.01 Strict文書、もしくはHTML 4.01ベースのマークアップ文書を提供する人々が增えるのではないか。
HTTPに對するWebもさうだが、Gemini空間に關はる全ての人がアクセシビリティについて考へなければ、流通コンテンツの質は保てない。特に畫像の代替 として用ゐられるアスキーアートは害惡實驗的 で無慈悲だと感じる。讀者は相變らず無力だ。仕樣かクライアントが賢くなるのを待つしかない（人間は賢くならない）。一定の複雜さはユーザに對する投資である。ある時點で、クライアントは快適さのために複雜にならねばならないだらう（アスキーアートや繪文字、見出しに含まれた記號を無視するなど）。
Project Gemini FAQ 、2.5 Why not just use a subset of HTTP and HTML? より：
Alternative, simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions. You know for sure when you enter Geminispace, and you can know for sure and in advance when following a certain link will cause you leave it. While you're there, you know for sure and in advance that everybody else there is playing by the same rules. You can relax and get on with your browsing, and follow links to sites you've never heard of before, which just popped up yesterday, and be confident that they won't try to track you or serve you garbage because they *can't*. You can do all this with a client you wrote yourself, so you *know* you can trust it. It's a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web.
いいや、ごみ（garbage）を見る羽目になつてゐる から私は抗議してゐるのだ。HTML/CSSはごみを收容・隔離する事が幾らか容易にできる。だから私はまだ HTTPを利用してゐる。
人間の 複雜さに對して、Gemtext言語は脆弱だ。
コンテンツの質は、クライアント開發者の動機にも影響する。開發者はコンテンツを參照したいから開發するのであつて、目的のコンテンツが流通してゐなければ、開發しない（既存のクライアントで濟ます）だらうからだ。設計の複雜さに對して、苦勞を拂ふ價値（リターン）があるかどうか、だ。複雜さが合理的だと判斷すれば、開發者は仕事を始めるだらう。
逆に言へば、Project Geminiは、スクリプトやトラッカーなどに加へ、メタ情報やインラインマークについて、苦勞する價値が無いと判斷したのである。
そのくせ、無制限 の空行や繪文字、アスキーアートの價値は認めた。
2022年4月25日：
Gemini人口の低さには、文書構成の違ひ も關係あるだらう。他のマークアップ言語同樣、Gemtext言語には獨自の書き方、それに伴つた讀み方がある。Webサイトの慣習に親しんだ人からすると、Gemtext文書は讀み難い かも知れない。
仕樣そのものよりも、アクセシビリティに關するガイドラインが無い 事に不滿がある。HTML程高機能になれと言ふでもなく、萬能なマークアップ言語は存在しない。ただ、アクセシビリティは非常に倫理的な問題で （情報格差を生み出すからだ）、仕樣には社會的責任がある。社會には規範が必要なのだ。
限界。仕樣は常に人間に敗北する。だから必要な欲求は滿たしてやらねばならない。人間が獸《けだもの》 にならないやうに。
簡素な仕樣に（Project Geminiが擧げた以外の）利點があるとすれば、私のやうな素人でも感想を書ける事だ。
2022年4月30日：
ホスティングサービス：
全體的に言つてGemtextは寛容であり、アスキーアートが蔓延《はびこ》 つてゐる現狀を鑑《かんが》 みるに、人口が增えればあつと言ふ間に荒れ る。人間の良識にかなり依存した仕樣だと感じる。それはマークアップ言語共通の事實だが、敢へて脆弱になる事はないのだ（空行、空白文字の處理）。
プレーンテキストでサイトが作れる。流行らない筈がない。私はGeminiが大衆化する前に、警吿を與へておきたかつたのだ。
處理も測定もできない。書いたり讀んだりするだけ。書きつぱなしの私には向いてゐるかも知れないが、公開 といふスタンスは外せない。
書くのが止らなくなる。推敲してそのままアップロードするだけだから。メモ、日記向き。
Geminiを必要とする人は確實にゐるだらう。課題は著者（リソース）を引つ張つてくる事である。クライアントの普及も重要だ。情報 が必要なのだ。
2022年5月1日：
私がGeminiに感じてゐる魅力は、（營みが）民主的なところだ。低電力コンピューティングにも惹かれる。確かに商業的な價値は無いが、コメントやボタンが可能なら（既に實行してゐる著者がゐる）、競爭は免れないかも知れない。
一定のスタイルの自由が利かないのはやきもきする。フッタの外觀くらゐ變へられないか。認識 性の向上に限界がある。
（一つのサイトのやうな感じで）書式を統一して、クライアントからメタ情報の位置（スクリーンリーダの場合は讀上げ順）を上部・下部・見出しリストから選べたら良かつたのに。加へて配色も設定できれば、文書もすつきりしてより讀み易かつたらう。
HTMLには、footer要素やaddress要素がある。
人間は讀む ためにプロトコルを利用してゐるのだから。
ユーザが確實に抽出できる情報——セクション（アウトライン）は見出しでのみ明示可能 だ。だから注意事項とか、メタ情報とかは見出しのあつた方が良い。
ページが簡單に作れると感動する。ダブルホスト（クロスポスト）するか惱む。
私は自分で讀む時はHTMLを利用するけれども（讀み易く整形できるので）、HTTP/HTML以外で讀みたい人もゐるだらう。
本質的に、Geminiはプレーンテキスト を送受信する事にしか關心が無い。だからインライン（行內）のマークも無い（行頭3字で行種を判別できるやうにしてゐる）。私の擧げた事は的外れかも知れないが、縱の餘白が行單位 といふのは本當に厭だし、アスキーアートの省略（整形濟テキスト行內の配置）は義務ではない。日本では必ず テキスト行にアスキーアートをぶち込んでくる著者が出る。
讀み易い構造。簡潔な內容を心掛ける。私は、長文はHTMLに向いてゐると考へてゐる。細かな文書構造で槪要を摑み易いから。何より、讀者が スタイルを操作できるのが良い。私は私自身に讀み易くするためにCSSを利用してゐる。
文量が多い時は、章立てした方が良い。
連續した改行ではなく、章立てを檢討する（なぜ改行するか？ ）。
2022年5月7日：
Gemtextは機械の アクセシビリティは高いが、人間のアクセシビリティは低い。一部の著者は讀み辛さ を文章 として參照できないテキスト限界 だと言ふなら仕方無いが、著者は作成する文書の性質を考へてフォーマットを選擇すべきだ。
カプセル（サイト）を作つた。私がGemini空間に參加するとしても、HTML文書を提供するだらう 、と言つたが、實驗も兼ねてGemtext文書で公開した。Geminiプロトコル／Gemtext文書に明確なメリットがあるとすれば、コンテンツがテキスト であるといふ點だ。
死ぬまでの書庫 ファイルの複製・變換は面倒なので、代替フォーマットすら持ちたくない（管理したくない）。HTML/CSSがどれ程複雜になつても、私はHTMLのアクセシビリティと、外觀の分離の嚴格さに滿足してゐる。
一方で、單純なフォーマットを持つてゐた方が便利な事もある（特に小說）。利用の當ては無いが。
Gemtextの書き方は、サイト を作るやうに書かなければならない（ハイパーリンクの配置）といふ點で、プレーンテキストとは異なる。
WebサイトとGeminiカプセルの書き方は變へるべきだらう。より簡潔に、形式張つた方が讀み易い（情報利用の自由度が無いために）。サイトを模倣する必要は無い のだ。
HTMLとGemtextの比較
Gemtextの書き方
2022年5月14日：
殆どの人はGeminiプロトコルで公開するものを持つてゐない。ホスティングサービスのユーザページを見て廻つても、挨拶の一行やHTTP(S)リンクのみのページが多い事に氣附く。
HTTP(S)リンクのみのページがあつても良いが、著者を信賴 するには、確たる情報があらねばならない。アクセスする必然性があるか。
單色の文字を讀まねばならないなら、私は紙の本を讀む。私がディスプレイ越しに期待してゐるものは、讀み易く（餘白、配色、ボーダーなどによつて）整形された文書なのだ。このやうな期待を持つ人間はGeminiに向かない。Gemini關聯の記事を見ていくと、逆に裝飾された文章が讀めない人がゐる 事を知り、良い學びになつた。Geminiは制限が多い故に、特定のケースに向く。
SNS、マイクロログ：
WebリングならぬGemリング：
How We Should Grow
どのやうなコミュニティにしろ、どうやつて 成長していくか、に明確に言及してゐる事は殆ど無い。人々が成長し、人口が增えるなら、既存の方法は通用しないにも拘らず。そこへいくとSoviet のアプローチは嚴格、簡素、無難であり、コミュニティが人 で成立つてゐるなら、當然持つであらう限界 足元 について多くのコミュニティは言及してをらず、私はどこか噓臭く感じるのだ。成長を促し、自分たちで世界を切開く。人は變化する。貢獻のための機會をもらへるのは、本當に貴重で、有難い事だ。
Geminiを知らない人にとつてGeminiが特別 なのは、Webブラウザがプロトコルに對應してゐないから だ。對應すれば、多くの人々はGeminiをWebと大差無く扱ふ 。1カラムのシンプルなサイト として。スムースに橫斷が爲されるなら、誰がプロトコルの違ひなど氣に掛けよう ？ 誰がコンテンツの違ひ などに氣附かう？ アマチュアの開發者が週末の時間でクライアントを構築できるなら、大規模な集團が本業のついでに 實裝する事は容易だ。さうした場合、クライアントのシェアはWebブラウザに傾く――なぜなら、HTTP(S)に（その空間で展開されるコンテンツに完璧に ）對應してゐるから、そして便利 だからだ。高度なタブ管理、マウスジェスチャ、キーアサイン、UIの設定、ブックマークや履歷管理、檢索機能（ハイライト）、畫像のプレビュー、擴張機能 。かういつたものの無い、不便な 專用クライアントを利用する理由は、殆ど無い。
するとどういふ事が起るかと言ふと、HTMLで文書を書く著者が增える。HTMLに對應したクライアントでの參照がほぼ確實といふ狀況 であれば、著者はさうする（決斷には統計が必要だが、少なくともユーザから利用狀況を受信してゐるクライアント開發者は統計が可能だ）。
私はGeminiプロトコル自體の仕樣は知らないのだが、もし外部リソースの呼出しを禁じてゐたとしても、ユーザはユーザスタイルシートを使へるし、高度なクライアントはGeminiプロトコルのHTMLをHTTPとは異なつた外觀で描畫するかも知れない。著者にはWebと書き方を變へなくて良いといふメリットがあり、インラインリンクを始めとして、行內の强調が可能だ。私が擧げたメリットもある（メタ情報の明示など、情報の應用）。
WebとGeminiを兩立してゐるユーザが多くなる程、つまりWeb上にGeminiへのリンクが增えていくと、Web檢索エンジンは對應を檢討する 。Geminiが――人々にとつて重要になる程――情報の厚みが增せば增す程、檢索エンジンはその中に入り、インデックス化したいと考へる。檢索エンジンが情報を抽出できるなら、讀者はプロトコル／フォーマットに對應したユーザエージェントを利用しなければならない。檢索エンジンとWebブラウザの對應は同じタイミングかも知れないが、兩方を實裝できるプロバイダ が競爭で有利なのは確かだ。
Gopher/Gemini空間をプライベート（私的な空間） だと考へてゐる著者は、クライアントや檢索エンジンの整備が進むと、文書を削除する。
スモール・インターネット：
Spring's gopherspace
より嚴密には、個人 による自助1人か2人の人間が手に負へる組織 である。と言ふのも、規模が大きい組織程、その最小値は大きくなるからだ。構成人數によつては、200人でさへ最小 の域かも知れない。スモール・インターネット を揭げてゐる人の殆どは、さういつた（民主的であつても）大規模な組織を想定してゐない。
商業を頑《かたく》 なに否定するユーザもゐるが、生活（インフラ）に金錢が掛る以上、避けては通れない。結局の所、サーバをホストする（コンピュータを入手し、起動する）にも、何かを書くにも、生活の基盤があつて、大抵の人々は職業――つまり經濟活動――に就いて生活を成立たせてゐるのだ。物々交換 で世界が成立つてゐるならともかく、商業の毛嫌ひは現實逃避も良いところだ（商業に持込んではならない領域がある、といふなら解る）。物々交換は需要と供給が釣合つた時に成立つが、經濟社會と同じやうに、提供するものがコミュニティに無益と判斷されると、何も得られなくなる。
だから、經濟活動にしろ物々交換にしろ、人は自分を必要としてゐるコミュニティを見附けねばならない。あるいは、コミュニティを作るか、コミュニティに迎合するかである。
商業化：
ホスティングサービス。1000人、1萬人がホスティングを希望するとして、誰も提供できないとしたら、それは商賣になる。今は個人が金錢を受取るのも簡單になつた。個人にしろ零細企業にしろ、一定の需要が見込めるなら誰かが商賣にする。欲望を金錢で解決する 事に、人々は抵抗を持たない。そして軌道に乘つたなら、大企業がプランを作る。今流行りのGopher/Geminiもいかがですか？ 、讀者に安全なGeminispaceを提供しませう 、といつた具合に。CMS のインストールなどと同じやうに。
既にgemlog.blueやFlounderといつたプロバイダが實踐してゐるやうに、Webインターフェースは知識の乏しいユーザを惹き附ける。
Gemini空間でインターフェースの提供やホスティングの手續を行ふ事も可能。參考：Making Gemini Easy - tomasino@tilde.team
對して、人々の參入に障碍を殘す事でコミュニティを守らうといふ抵抗 がある。だが、Geminiに對象ユーザはゐない のだ。不便さ（不親切さ）で何者かを排除しようといふ動きは、不健全である。Geminiが一つのコミュニティなら良い。だが、Geminiはプロトコルだ。ただの仕樣、インフラである。インフラは政治的な意嚮を受けるべきではない （それは、商業化を嫌ふ人々がWeb/HTMLに對して主張してゐる事である）。
プロプライエタリクライアント。上記で述べたやうに、既に優秀なWebブラウザを抱へてゐる開發者は、プロトコルを實裝するだけで良い。
檢索エンジン。WebにしろGemini空間にしろ、このサービスの需要は高い。リンク が無ければ、目的のコンテンツを見附けられないからだ。そして、良質な文書を探す といふ行爲は、厖大な時間と勞力が要る。
弘吿。トラッキングができないので參入する業者は少ないかも知れない。私が懸念してゐるのは、メルマガ的なコンテンツである（內容が淡白で、裝飾、改行が多い）。寄附や購讀者數を氣にする著者は、文書とは無關係なリンクを導入する。
Webを經由するサービス 。プロバイダはユーザに關する情報を取得できる。
Web民が雪崩込んでくる前に、良いソースを見附けておく事。手遲れかも知れないが。
英語を學ぶ意欲すら無い人間はPubnix に相應しくない、と考へ、參加してゐない（私の英語はプロプライエタリなコードに依存してゐる）。そもそも何 をやつてゐるか分らないし、交流も面倒だ。共同體 の一員では在りたいと思ふものの。提供できるものが無い。
medusae.space Gemini directory に自薦《じせん》 する事もできるし、geminispace.infoに登錄する事もできる。しかし性的コンテンツ がある點で、どこにも宣傳すべきではない。パブリックドメインが惜しいと言ふなら、既にWebで傳播してゐるわけだし。
Webと異なり、日本語のリソースは缺乏してゐるため、Gemini空間に來た日本語話者が眞つ先に見附ける可能性がある。注目を引き易い。
Newest Gemini Hosts - geminispace.info を見てゐると冷え冷えとする。さう、ここは天國ではない。人間がやりたい放題 する場所だ。どこにも天國なんて無い。
cinni's corner ：私が懸念してゐるやうなサイト。繪文字とアスキーアートの裝飾、連續した空白行（例：whisper into the void - cinni's gemlog ）。
GeminiにもGemtextにも關心が無い。
檢索エンジンのユーザビリティが壞滅的に低い。文書のタイトルも檢索語のハイライトも無い つて冗談だろ？ スローとかスモールとかさういふ（思想的な）問題ではなく、これは人間に苦勞を强ひる致命的な不便さ。
情報の應用を期待する著者は、Webで書くべき （總論）。Gemini空間／Gemtext文書は主要フォーマットの代替 として採用すべき。
Gemtext文書の讀み書きは苦痛を伴ふ。なぜなら、文書構造の明示を缺いてゐるからだ。外觀が單純なために、マークアップの粗 が見えてしまふ。その度に私は苛々する――プレーンテキストもさうだ。これはアクセシビリティが低い と、さう判斷してしまふのだ。まだ氣にしないで濟む（捨置ける）Webの方が氣が樂だ。とかく、私は公開文書としてのプレーンテキスト／Gemtextが大嫌ひで、Gemini空間が羨ましいのは最初だけだつた。
Gemtextは、HTMLのやうに文書構造を明示するのではなく、プレーンテキストを讀み易く整形するための言語 と捉へた方が良い。
プロトコルやフォーマットを變へただけでは、人間の問題は解決しない。
私は昔のWeb を見たいわけではない。
私は單色の文字列やセクションが見難い。
プレーンテキストやGemtextは、文字の水平方向 の利用ができない。（段組表示など）
私がインターネットで見たいものは殆ど無い。必要 とする情報はWebに存在し、Web/HTMLで表現すべき情報である。
The Small Internet - Spring's gopherspace
GopherやGeminiは仕樣的にはスモール かも知れないが、問題は多くの人が手輕さや利便性に慣れきつてゐて、自分で 何かをする事に關心が無い擬似的な（テキストのみの）Web と捉へてゐる人――私を含め――は澤山ゐる。
Gopher/Gemini空間で棲み分け する事になるんぢやないかな。GNU/Linuxディストリビューションのやうに。ディストロ（OS）はインフラだが、設計思想によつて分裂する事で、設計者とユーザの軋轢《あつれき》 を少なくしてゐる。氣に入らなければ他のディストロに移行するか、新しく立上げるだけである。
思想を實現するため、プロトコルの亂立が起きてもをかしくない。
一般人が運營するWeb。
HTTP/Gopher/Geminiが共存するとしたら、どう使ひ分け、何を期待すれば良いか。
なぜ私は私自身にとつて 親密でも讀み易くも無い プレーンテキストは私の本音を書く場だが、公開 物は違ふ。きちんと仕上げたものだ。誰かが痛みを伴はないやうに。
自分の書いた文章が讀み易いのは當り前。他人が書いたプレーンテキストが讀み易い ものか。（構造の明示は著者に依存する）
人類が築いた狂氣を止める事はできない。我々は、親しみ易い個人を見附ける事でしか、親密さを共有できないのだ。