protocol-ja

This article is a stub. You can help the IndieWeb wiki by expanding it with relevant information.

IndieWebにおけるprotocols（プロトコル）（Webmention、IndieAuth、Micropub、WebSub、Microsubなど）は、サイトやサービスが相互にやり取りしたり、ウェブ上のユーザーインターフェースやネイティブアプリと通信したりするための標準的な手法です。技術者の中には、提案段階の標準、フォーマット、APIなどあらゆるものを誤って「プロトコル」と呼ぶ人もいますが、別の文脈では、スクリプト、チェックリスト、レシピのような「従うべき一連の手順」を指すこともあります。

IndieWebで広く使用されているプロトコルの一覧については、仕様書（Specifications）を参照してください。

ブレインストーミング

効率性と社会的文脈

Tantekは、非公式なチャット（2021-06-28深夜の独白）の中で、プロトコル設計の傾向についていくつか言及しました。以下は読みやすく編集・補足したものです：

IRCはSMTPと同じ時代の産物であり、設計者や考案者たちは参加者の「善意」を前提としていました。これは、発明者たちが自分たちの特権的な環境（高度な信頼関係がある狭い世界）に浸っていたために、それ以外の状況に無自覚だったからです。
もちろん、彼ら（IRCの考案者・実装者）は後付けで各種 *SERV や人間のモデレーターなどで取り繕おうとしましたが、それらはすべて、人間性の欠陥を想定していなかったアーキテクチャ設計を修正するための「パッチ」に過ぎませんでした。
しかし、その時代の産物であるからこそ、IRCやSMTPは「モデム時代」の思想も持っていました。1バイトの重みが重要だったため、プロトコルが（善意のユーザーによって）「正しく機能」したときは、極めて効率的で、高速かつ信頼性が高かったのです。少なくともバイトレベルでは、低速で不安定なネットワーク接続上でも動作・復旧するように設計されていました。
XMPPに関する私の初期の記憶は、接続やログオンといった基本的な動作の実装がいかに��遅（おそ）い」か、そしてメッセージ送受信のレイテンシがいかに大きいかということでした。基本的な相互運用性（画像、ファイル転送など。これらはSMTPですら正しく実現していました）の欠如については言うまでもありません。
Matrix（のクライアント経由）は、さらに「遅い」です。多くのチャンネルを持つMatrixサーバーのタブを開きっぱなしにしようとしましたが、他のどのウェブアプリケーションよりもひどいメモリリークを起こし、少量のテキストを動かすためのJSの使い方としては、これまで見た中で最も非効率なものでした。
これほど少量のテキストをやり取りするのに、あそこまで遅くする言い訳は通用しません。Matrixが1文のテキストを送るのに、どれほどのオーバーヘッド（いや、何倍のコスト）をかけているのか、知りたくもありません。
現代のプロトコルには、「社会システムにおいて人間がデフォルトでいかに悪い行動をとりうるか（権力の非対称性、トロールなど）」という現代的な��識と、「少量のテキストを極めて効率的に（低レイテンシで）やり取りするプロトコルを設計・実装した経験」の両方の組み合わせが必要です。
さらに言えば、効率的な（1バイトを大切にする）プロトコルを設計する経験や意欲を持つ人がいないだけでなく、全く「逆」の状況にあります。
多くの人々がICO（暗号資産による資金調達）によって、「操作を実行するために途方もない電力と時間を浪費する、極めて非効率なプロトコル」を設計するという、間違ったインセンティブを与えられています。これは最悪の状況です。暗号通貨やブロックチェーンの推進派は、自分たちの口座の安全以外（それすらSMSの悪用で危ういものですが）を完全に無視し、軽視するような行動や提案を行っているように見えます。

FAQ

「フォーマット vs プロトコル」に関する質問は、フォーマットのFAQを参照してください。

ブレインストーミング

効率性と社会的文脈

FAQ

関連項目