ATProtocol(Bluesky)のサポート

[takecchi]

要望/アイデアの概要

ATProtocol(Bluesky)連携のサポート

利点

タイムラインやフォローを共通化することでSNSを横断する手間を減らすことができる。

その他

No response

[takecchi]

アプリパスワード使って連携できそう。(ID+パスワードでもいいけど非推奨)

https://bsky.app/settings/app-passwords

[takecchi]

本来的にはPDSをcuculusドメインで立てたいと思っているけど、ATProtocolの仕様が決まっていない現状ではリスキー。
当面はアプリパスワードを使用したアカウント連携程度に留めておくのが良さそう？

[takecchi]

PDSを自前で建てるメリットもあまり思い浮かばない。
カスタマイズしたりモデレーション出来ることかな？(真偽不明)
ユーザーデータのPDS間移動は出来るようなので、必要に応じて考える。

[takecchi]

Cuculus未登録のBlueskyユーザーの扱い

Blueskyでのみ登録されてるユーザーをCuculusに取り入れてしまうと、
後で登録しようとした際にユーザーの重複が発生するのでどうしようという話。

案1. Fediverse非連携の仮ユーザーを発行する

PDSからCuculusにデータの取り込みを行いdidが紐付いた状態にしておく
後にアプリ連携した際、既にいるdidだった場合Cuculusアカウントとデータを統合する

ただし連携時に投稿データを移行したり、フォロワーを統合したり手間はかかる。
→ 非同期実行でOK
→ 後述の案2でも手間は発生するので良いアプローチかも？

案2. タイムラインの取得はクライアントに頑張って貰う

タイムラインを統合するのはクライアントの仕事にしてCuculusへの取り込みは行わない。
フォローは専用ページを作っておき、Blueskyでのみフォローを行う。

Bluesky連携時にBluskyのフォロワーをチェックして、Cuculus登録者が含まれていた場合は自動的にフォローさせる仕組みが必要
→ BlueskyのAPI叩いてフォロワー全件チェックするのでコストは高そう

[takecchi]

案1のほうが良さそう。

案2と比べてクライアントの負担を減らせるし、共通の画面やAPIを使用可能。

移行コストも、投稿データとフォローしてるuser_idを変えるだけなので安い。
(フォローの重複は削除する)

Blueskyからサーバーに都度取り込むコストはかかるけど

[takecchi]

https://docs.bsky.app/docs/advanced-guides/firehose

この仕組みを使えばリアルタイムで投稿を取り込めそう

[takecchi]

投稿

投稿の取り込みについて

原則としてフォロワーががいる状態だった場合に取り込みを行う。
リポストとメンションについては例外的に取り込みを行うものとする。

投稿種別

• リポスト
• 引用リポスト
• メンション
• リンク付き
• 画像付き

ざっくりとこの辺りが対応できれば良さそう