概要
以前投稿した「GNU social v2でのMisskeyとの通信問題 | GNU social JP」で、Misskeyとの通信問題を取り扱いました。この問題はマージされて解決したのですが、これとは別に、GNU social (GS) からMisskeyをフォローしても、投稿が流れてこず、Misskeyからフォローされた後に、[PROFILE]-[FOLLOWERS] からフォローし返すとフォローできて、投稿が流れてくるという問題がありました。
こちらの問題はよくわかっていなかったのですが、先日Misskeyユーザーがgnusocial.jpに登録してこの挙動について調べてくださって、原因が判明したので整理します。なお、この問題は「Cannot follow follow request enabled Misskey. – NotABug.org: Free code hosting」に登録しました。
会話
まず元となった会話を以下に抜粋します。
mewl_hayabusa@gnusocial.jp’s status on Wednesday, 07-Sep-2022 19:56:19 JSTmewl_hayabusa gnusocialjp@gnusocial.jp さんのプロフィール見る感じだとFollowingに @mewl があるけどフォローリクエスト来てないし被フォローにもなっていないな
めうるみ (とけた) (mewl@mewl.me)’s status on Wednesday, 07-Sep-2022 20:00:31 JSTめうるみ (とけた) “`
WARN 7 [queue inbox] failed(QueryFailedError: value too long for type character varying(128)) id=12069090 attempts=1/8 age=79ms activity=https://gnusocial.jp/follow_from_https%3A%2F%2Fgnusocial.jp%2Findex.php%2Fuser%2F1_to_https%3A%2F%2Fmewl.me%2Fusers%2F5b6bb2cada8b912b16218d34
“`
なるほど。
めうるみ (とけた) (mewl@mewl.me)’s status on Wednesday, 07-Sep-2022 20:59:34 JSTめうるみ (とけた) @gnusocialjp@gnusocial.jp
まず、 (おそらく) GNU Social側に「フォローを送ったがまだ未承認である」という状態がないために「フォロー済み」と表示されているけれど、実際にはMastodon / Misskey側では承認されていない = フォローできていない状態のことがあると思います
(Pleromaは未確認だが、確かそちらにも被フォローに承認が必要な設定が存在したはず)
(mstdn.jp上の承認制アカウントをフォローしてみたが、mstdn.jp側では「フォローリクエストが送られてきた」だけの時点で、gnusocial.jp側では既フォロー表示になった)
その上で、Misskeyの場合、おそらくこんな挙動をしていそう:
* フォローが承認制でないとき
* そのまま通る (misskey.io宛で確認)
* フォローが承認制であり、フォロー中アカウントからのリクエストを自動承認する設定で、該当アカウントがフォロー中であるとき
* そのまま通る (mewl.me宛で確認)
* フォローが承認制であり、上記の例外に該当しないとき ← 今回
* フォローリクエストをDBに保存するためクエリを投げるが、GNU Socialからの場合`requestId`が長すぎてエラーになる
(Misskeyのソースを眺めていたが、`requestId`に何が入るのかはまだ読めてない)
GNU social JP管理人 (gnusocialjp@gnusocial.jp)’s status on Wednesday, 07-Sep-2022 22:05:53 JSTGNU social JP管理人 ありがとうございます。よくわかりました。承認設定の有無が原因のようですね。
Misskey側のrequestIdは通常何が入っているのでしょうかね。
GS側でそこを短いものに変えたら解決、あるいはMisskey側でrequestIdの文字数を長くする (DB定義なので難しそう…) で解決しますかね。
めうるみ (とけた) (mewl@mewl.me)’s status on Wednesday, 07-Sep-2022 22:37:48 JSTめうるみ (とけた) @gnusocialjp@gnusocial.jp
おそらくそのどちらかで解決するはずです
テーブルを眺めた感じだと
Mastodonから: `https://example.com/<UUID>`
Misskeyから: `https://example.com/follows/<元ユーザID>/<宛先ユーザID>` (インスタンスの設定によるが、それぞれ10文字か24文字の英数になるはず)
Pleromaから: `https://example.com/activities/<UUID>`
が入っているようなので、 `https://gnusocial.jp/follow_from_https%3A%2F%2Fgnusocial.jp%2Findex.php%2Fuser%2F1_to_https%3A%2F%2Fmewl.me%2Fusers%2F5b6bb2cada8b912b16218d34` が`requestId`となるようです
`https://example.com/follow_from_<actorのURI>_to_<actorのURI>`というわけで、これは基本的にかなり長くなっていそう…
動作
ここから重要な部分を抜粋して整理します。
まず、GSにはフォロー時の承認設定がそもそもありませんが、Mastodon/Misskey/Pleromaには承認設定があります。そのため、GSからフォローを試みると、承認されず実際にはフォローできていない状態が存在します。
Misskeyの場合、フォローの承認設定によって以下の挙動をしているようです。
- 承認設定なし: フォロー。
- 承認設定ありで、フォロー中アカウントからのフォローを自動承認ありで、フォロー中の場合: フォロー。
- 1、2以外 (承認設定あり、または承認設定ありで自動承認ありかつ未フォロー): フォローできるが投稿を受信できない。
GSからMisskeyをフォローしておかしくなるのはこの3のケースのようです。要するに、フォローリクエストが有効な状態でフォローをかけると発生します。
Misskeyからフォローされるとフォローできるというのは2の条件だったようです。
そして、この3のケースの場合、Misskeyが受信するrequestIdが長すぎて、Misskey側で以下のエラーになります。
WARN 7 [queue inbox] failed(QueryFailedError: value too long for type character varying(128)) id=12069090 attempts=1/8 age=79ms activity=https://gnusocial.jp/follow_from_https%3A%2F%2Fgnusocial.jp%2Findex.php%2Fuser%2F1_to_https%3A%2F%2Fmewl.me%2Fusers%2F5b6bb2cada8b912b16218d34
このMisskeyのrequestIdは分散SNSによって以下のような値が渡ってくるようです。
- Mastodon: `https://example.com/<UUID>`
- Misskey: `https://example.com/follows/<元ユーザID>/<宛先ユーザID>` (インスタンスの設定によるが、それぞれ10文字か24文字の英数になるはず)
- Pleroma: `https://example.com/activities/<UUID>`
- GS: `https://example.com/follow_from_<actorのURI>_to_<actorのURI>`
MisskeyではrequestIdが最大128文字を想定したカラム設定になっていますが、GSの場合 `https://gnusocial.jp/follow_from_https%3A%2F%2Fgnusocial.jp%2Findex.php%2Fuser%2F1_to_https%3A%2F%2Fmewl.me%2Fusers%2F5b6bb2cada8b912b16218d34`のようなかなり長い文字列になるため、受け付けられなかったようです。
したがって、Misskey側でカラムの文字数を増やすか、GS側でrequestId相当の文字列を128文字以内に収めれば解決しそうです。Misskeyのカラムの文字数変更は構造的に少々ハードルが高いので、GS側で直すのが現実的になりそうです。
おそらく、この問題が解決すれば、Misskey側で承認され次第投稿が流れてくるのではないかと思われます。
Misskeyの承認設定は [Settings]-[Privacy]-[Follow requests require approval] で行えます。
ひとまず、「Cannot follow follow request enabled Misskey. – NotABug.org: Free code hosting」に課題を登録しておきました。
結論
フォローリクエスト・承認設定が有効な場合のMisskeyフォロー時の問題について記しました。
フォローの承認設定がなければ、またはあっても相手からフォローされれば問題ないのですが、管理人の感覚としてはMisskeyユーザーの大半がフォローリクエスト設定をしており、この問題に頻繁に遭遇します。
ひとまず、親切なMisskeyユーザーの調査のおかげで問題のコア部分が解明しました。後は該当コードを特定して直せれば解決するでしょう。いずれ落ち着いたら取り組みたいところです。それまでいったん保留にします。
MastodonやPleromaにも似たような承認設定に関する問題がありそうです。
詳細プロフィール。SNS: X Twitter/GS=gnusocialjp@gnusocial.jp/WP=gnusocialjp@web.gnusocial.jp。2022-07-17からgnusocial.jpとweb.gnusocial.jpのサイトを運営しています。WordPressで分散SNSに参加しています。このアカウントの投稿に返信すると、サイトのコメント欄にも反映されます。
Comments