サークル機能

[1673beta]

Summary

チャンネルを廃止した代わりにサークル機能を作る

Purpose

利便性向上

Do you want to implement this feature yourself?

• Yes, I will implement this by myself and send a pull request

[1673beta]

大雑把に把握しているkmyblueにおけるサークルの流れ

配信の場合

1. まずサークルが作られる
2. サークルのデータベースにユーザーが追加される
3. 投稿が作成される
4. 投稿が作成されると投稿に基づいたConversation IDが作成される
5. Conversation IDを用いてcontexts/:idを作成する
6. 投稿のトークンを用意し、それを専用のテーブルに追加する
7. 6で生成したトークンと元投稿のURLを元にbearcaps URIを生成する
8. JSON-LDのtoにcontexts/:idのURLを、objectに7で生成したURLを入れて配信する

[1673beta]

受信の場合

1. まずリモートからbearcaps URIを含む投稿が送られてくる
2. Createとして一旦処理
3. bearcaps URIを解析
4. 3で得られた情報を元に送信元にリクエスト
5. 送信元でトークンが有効か検証する
6. 有効ならそれがcontextsに含まれるメンバーか確認する？
7. メンバーが存在するならJSONを返す？

[1673beta]

これ別にcurl -H 'Accept: application/activity+json' -H 'Authorization: Bearer <token>'でjson帰ってくるからメンバーの検証はしていない？

[1673beta]

あとサークルの場合はlimitedScopeがCircleになってる

[1673beta]

あー、要は各ユーザーのinboxに配信するから、実質的にそれがメンバーであることの検証を兼ねてるってこと？

[1673beta]

それはそれとしてcontextのURLをkmyblue上から叩くとRecord Not Foundが帰ってくるのは何

[1673beta]

fedibirdのサークル関連のお話
https://fedibird.com/@noellabo/104790010646886043

[1673beta]

内部的には最初のサークル投稿に紐付いていて、このcontextのinboxにリプライを配送することで、contextのメンバーに転送されるという動作をします。

?

[1673beta]

contextsはActorのサブセット的立ち位置で、設立者のinboxをcontextsのinboxにして、toにcontextが指定されていたら設立者のinboxを経由して他のサークルメンバーに転送しているらしい？よくわからない

[1673beta]

ただ設立者のinboxをcontextsのinboxにするとサークル設立者のアカウントが消えた時にサークルにアクセスできなくなるわけだけど、これはどうするつもりでいるんだろう