Circle Group @circledev@fedibird.com

これってあれか、別にグループの外からでも @circledev って置いとけば届いちゃうのか？

現状

現在、グループを作成したい場合は、QOTOの提供するグループサーバか、GuppeGroups、Fedibirdのグループ開発用のサーバを利用する必要があります。

QOTO https://groups.qoto.org/

GuppeGroups https://gup.pe/

Fedibird グループ開発サーバ https://gdev.fedibird.com/

Fedibirdのグループ機能開発は、私が主導しているもので、Mastodon本家は関係していません。 諸問題を勘案・解決しながら、ゆっくり進めているところです。

関連リソース

サークル機能について、日本語で話している公開グループアカウントがあります。

公開グループですので @circledev をフォローすればグループの投稿を受け取れるようになります。また、メンションすればグループに投稿できます。公開の他、未収載で投稿しても大丈夫なので、ローカルタイムラインの投稿と区別したい方はご活用ください。

遊び場（グループ実験場） @playground という、お試し用のグループもあります。

サークルの知見、まだあったら @circledev に書いておいて

@circledev
QT: https://mstdn.y-zu.org/@Yohei_Zuho/105508334035184917

@circledev
QT: https://fedibird.com/@noellabo/105508285467367620

@circledev
QT: https://fedibird.com/@noellabo/105508256453425668

@circledev
QT: https://fedibird.com/@noellabo/105508246027351668

@noellabo @circledev おおそうなのですねw ありがとうございます。

@yamako サークル、現状ちょっと使いにくいです。対応サーバが実質Fedibirdしかありませんw

詳しくは @circledev の投稿を漁ってみてください。

@circledev これまでの成果を本家にPRしてきました（随時やってます）
https://github.com/tootsuite/mastodon/pull/14384#issuecomment-687586597

サークルのアイコンを変更したことと、返信の際に公開範囲やサークルの宛先を変更できるようにしたこと、サークルメンバーの確認方法をメニューに移動したぐらいかな。

@circledev 相互にフォローしているメンバー同士であれば、気軽にメンバー指定して話を始められるので便利かと思います。

ただし、メンバー指定された人は、誰が参加しているかわからないので、そういう用途で使う場合は最初に宣言しちゃうと良いです。

サークルのメンバーをあとから増やしたり減らしたりしても、既存の投稿を見られるメンバーは替わりません。

ある程度、発信する人と、受け取って読むだけの人に分かれている場合に便利です。

対等にやりとりしたい場合は、グループの方が適しています。

たぶん向いているのは、飲み会の幹事からの連絡とか、支援者向け投稿のような特別コンテンツ配信チャンネルとか、特定メンバーでちょっと秘密の打ち合わせをしたいときとかかな。

@circledev 新しい方のサークル機能、動くようになってます。

Fedibirdの他、実験用のサーバ（時期が来たら爆破します）も用意しておいたので、適当に試してみてください。
https://circle-dev.fedibird.com/

1. 新規のサークルを作って、自分のフォロワーを追加します

2. 公開範囲をサークルにして、作ったサークルを選択して投稿します

3. サークルの投稿に返信すると、サークルのみんなに投稿が配送されます

*メンションなしで届きます

* サークルの投稿は、サークルのメンバーに指定された人だけがみられます

* サークルのメンバーを知ることができるのは、メンバーリストを作成した最初の投稿者だけです

* サークルの投稿はホームに表示されます

* 返信は、サークルメンバーのうち自分をフォローしている人のホームに表示されます

* 返信がホームに表示されなくても、サークルの最初の投稿を詳細表示すると、そこに繋がって表示されます

* サークル機能に対応していないMastodonや他のFediverseサーバは、サークルの投稿をみることができません

@circledev そういえば肝心なことを言うの忘れてたけど #fedibird は最新の実装に切り替えて、UIも更新したんだけど、まだバグがあって相手に届かなかったり、互換性のあるサーバ同時じゃないと話せないので、すっかり機能しなくなっています！（だめじゃん）

@noellabo @circledev

昔たった一人だけのサークルを作って、そこに投稿したポストをリプライ(コメント)のメンションだけで、公開範囲を広げていった遊びをしたことがありますw

@nacika @circledev なるほど。

現在の方向性としては、投稿を見ることが出来る人はトークンを持っている＝サークルのメンバーっていう扱いになっているから、メンションを禁じる可能性もあるね。

これ、本当に試行錯誤している感じで、まだどうなるかわかりません。

UIは私が勝手に提案していますが、そちらの検討もこれからです。

@noellabo @circledev

Google+では、サークル外の人にメンションを飛ばした場合は、その投稿だけみえるようになってた。

@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

@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 サークル機能は、新しい仕組みの導入に踏み切って、次の段階に入っています。

サークルは、最初の投稿者が、自分自身で作成したサークル（フォロワーの中から選んだメンバーリスト）に向けて投稿します。

このメンバーリストは、最初の投稿者以外は誰も知ることができません。

サークル投稿への返信は、サークルのメンバーに配送したいのですが、これは最初の投稿者（のサーバ）にしかできません。

そこで、サークルへの返信は、最初の投稿者のサーバに委譲する仕組みを導入することとなりました。

通常のリプライはリプライを行う投稿者のサーバから発信されますが、サークルへの返信では、これをスレッドの先頭の投稿のサーバへ預けて、そこからメンバーに配送する仕組みとなります。

これを実現するために、いくつかの拡張が行われています。

--
ここから先はちょっと難しい話になります。一応、ざっと説明しますので興味のある方は読んでみて下さい。

新しい仕様で、試行錯誤している最中ですので、まだ、誰もわからなく大丈夫ですw