GET togetherは、通常の書き込み手段を、はるかに型破りなものに置き換えた、意図的に最小限に設計されたソーシャルネットワークだ。投稿はHTTPのGETリクエストを通じて行われる。プロジェクトのランディングページには「POSTのないソーシャルネットワーク」と記され、そのドキュメントでも、この設計上の選択が前面に押し出されている。このシステムでは、従来のフォームやAPIの書き込み呼び出しを送信するのではなく、サービスにGETリクエストを送ることでメッセージが作成される。

サイトはこのモデルを率直な言葉で説明している。投稿は公開され、最新の項目が最初に表示され、それが実質的に製品のすべてだ。タイムライン、レコメンド層、プライベートメッセージングを備えた大規模な現代的プラットフォームを再現することが目的ではない。代わりに、仕組みがURL上で見える、小さく、ほとんど模式的なソーシャルフィードを公開している。このサービスは、従来型のネットワークとして機能するのと同じくらい、プロトコルの挙動を実演するために設計されているように見える。

ドキュメントによると、リクエストが成功すると新しい投稿のIDが返される。ユーザーは名前と本文を設定でき、サービスではparentパラメーターを通じて返信することもできる。また、投稿一覧や特定の投稿への返信を返せるフィード用エンドポイントもある。ページでは、自分の投稿を削除できることや、GETリクエストを使ってハートを追加または削除できることも説明されている。冒涜的表現や暗号資産関連の宣伝を検査する処理を含め、モデレーションのロジックさえドキュメントに明記されている。

こうした組み合わせにより、このプロジェクトはプロトコル設計の実動実験のように感じられる。HTTP GETは通常、安全で冪等な取得に関連付けられ、コンテンツの作成や変更にはPOSTを使うのが標準だ。GET togetherは、その前提を意図的に反転させている。プロジェクト自身の説明によれば、ユーザーがIDを省略するとサーバーがIDを作成するが、安全に再試行するには、UUIDを指定し、同じCookieとともに再利用できる。この詳細は、リクエストの意味論を変えると、単純なユーザーフローでさえ慎重な検討が必要になり始めることを示している。

このサービスは、プライバシーについてもユーザーに警告している。投稿本文はURLの一部になるため、URLが記録、共有、キャッシュされる場所でメッセージが露出する可能性がある。ページは、個人情報を含めないようユーザーに明確に伝えている。また、投稿時のCookieは任意だが、後から自分のコンテンツを削除したい場合には必要であり、その操作の認可にはセッションCookieが使われるとしている。この仕組みは、設計上のより広範なトレードオフを反映している。システムを調べやすくしても、初期状態で安全になるわけではない。

ソーシャル機能は意図的に軽量だ。名前は一意でも認証済みでもなく、基本的な命名規則を除けば、なりすましに対する特別な保護はないとページには書かれている。そのため、このサービスは本格的なプラットフォームというより、実際に動くエンドポイントを備えた概念実証に近い。このプロジェクトが、HTTPの意味論、キャッシュの挙動、あるいは変更を伴う操作を取得のように見せることの影響について考える開発者向けの教材になることは、容易に想像できる。

製品としてのGET togetherは、滑稽なほど簡素だ。しかし、実演としては、その簡素さこそが要点である。一般的なウェブの規則をアプリケーション全体の構造へと変え、そこから生じる副作用を文書化している。仕組みを隠すソーシャルアプリに慣れた人にとって、これは正反対の体験を提供する。仕組みそのものが製品であり、公開フィードはその帰結の一つにすぎない。