課題: GNU social v2でのMisskeyのフォロー承認設定時の問題

GNUsocial/issue

概要

以前投稿した「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_hayabusamewl_hayabusa
gnusocialjp@gnusocial.jp さんのプロフィール見る感じだとFollowingに @mewl があるけどフォローリクエスト来てないし被フォローにもなっていないな

めうるみ (とけた) (mewl@mewl.me)’s status on Wednesday, 07-Sep-2022 20:00:31 JSTめうるみ (とけた)めうるみ (とけた)
めうるみ (とけた) (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管理人GNU 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. 承認設定ありで、フォロー中アカウントからのフォローを自動承認ありで、フォロー中の場合: フォロー。
  3. 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にも似たような承認設定に関する問題がありそうです。

コメント

タイトルとURLをコピーしました