@circledev サークル機能は、新しい仕組みの導入に踏み切って、次の段階に入っています。
サークルは、最初の投稿者が、自分自身で作成したサークル（フォロワーの中から選んだメンバーリスト）に向けて投稿します。
このメンバーリストは、最初の投稿者以外は誰も知ることができません。
サークル投稿への返信は、サークルのメンバーに配送したいのですが、これは最初の投稿者（のサーバ）にしかできません。
そこで、サークルへの返信は、最初の投稿者のサーバに委譲する仕組みを導入することとなりました。
通常のリプライはリプライを行う投稿者のサーバから発信されますが、サークルへの返信では、これをスレッドの先頭の投稿のサーバへ預けて、そこからメンバーに配送する仕組みとなります。
これを実現するために、いくつかの拡張が行われています。
--
ここから先はちょっと難しい話になります。一応、ざっと説明しますので興味のある方は読んでみて下さい。
新しい仕様で、試行錯誤している最中ですので、まだ、誰もわからなく大丈夫ですw
@circledev ひとつは、bearcapsという仕組みの導入です。
Mastodonの投稿には公開範囲が設定出来ます。
投稿は固有のURLを持っていてHTTPによって参照できます。
この時、誰がアクセスしてきているのか確認する方法がなければ、公開範囲という機能が実現できません。
そこで、署名付きのHTTPリクエストを行うことで、誰がアクセスしてきているのか、そのアカウントは本物なのか、確認する仕組みが使われています。
サークルでは、参加できるメンバーを確認する、これとは別の仕組みを導入することになりました。
サークルの投稿では、Createアクティビティで投稿本体を配送する代わりに、BearerトークンとURIをセットにしたBearcap URIsをObjectに持たせて配送します。
bear:?u=https://fedibird.com/@noellabo/104787881912364707&t=xxxxxx
bearcapsを受け取ったユーザーのサーバは、指定のURIに投稿本体を取得しにいく際に、このBearerトークンを添えてリクエストします（Authorization: Bearer xxxxxx というヘッダを付ける）
@circledev このモデルが採用されると、サークル機能と互換性のない実装では、サークルの投稿アクティビティを受け取っても内容を取得することができなくなります。
これまでは未対応でもフォロワーのみ（従来のMastodon）・ダイレクト（Pleroma）として認識されていました。
もう一つは、宛先として、ActorやPublicの他に、/contexts/xxxxという表現を追加したことです。contextはActorのサブセット的なもので、idとinboxとtypeだけを公開するtype: Groupのオブジェクトです。
内部的には最初のサークル投稿に紐付いていて、このcontextのinboxにリプライを配送することで、contextのメンバーに転送されるという動作をします。
リプライでは、Noteのtoに指定するだけでなく、contextにも同じIDをそえます。メンバーに転送するNoteの条件として、このcontextをチェックします。
bearcapsについては、こちらに仕様がありますので参照してください。
https://github.com/cwebber/rwot9-prague/blob/bearcaps/topics-and-advance-readings/bearcaps.md
