Threadsの連合ユーザーのusernameが変更されても反映されない

[tai-cha]

💡 Summary

Instagramのusernameらしきものを変更するとthreadsのusernameも変更される、しかしMisskey上ではそれが反映されない

usernameを変更直後、ユーザーの照会を行なったところ同一のユーザーが表示されることは確認できた（Instagramが14日間はユーザー名を元に戻せるので2週間だけの措置？詳細不明）

おそらくuriは変わらないがurlは変更され、usernameも変更される？（詳細な仕様は調査の必要がありそう）

🥰 Expected Behavior

usernameの変更が反映される

🤬 Actual Behavior

usernameの変更が反映されない

📝 Steps to Reproduce

1. threads.netでアカウントを作成し、Misskeyからフォローや照会する
2. usernameをinstagramで変更する
3. Misskeyから再度照会を行う
4. 特にusernameが変わったように見えない

💻 Frontend Environment

* Model and OS of the device(s):
* Browser:
* Server URL:
* Misskey: 2024.3.1

🛰 Backend Environment (for server admin)

* Installation Method or Hosting Service:
* Misskey:
* Node:
* PostgreSQL:
* Redis:
* OS and Architecture:

Do you want to address this bug yourself?

• Yes, I will patch the bug myself and send a pull request

[tai-cha]

Threadsがオープンソースではないので中の人に聞くか飛んできたActivityなどから類推するしかなさそう

[tai-cha]

とりあえずusername変更後に行ったノートも同一のユーザーのノートとして扱われてはいるので同一のacctとして扱えてはいそう

[kakkokari-gtyih]

（usernameが変更できる仕様はどっちかといえばThreads側に問題がありそうな気がしなくもないけどどうなんだろう）

[mei23]

おそらくuriは変わらないがurlは変更され、usernameも変更される？（詳細な仕様は調査の必要がありそう）

を解釈すると

現状のリモートユーザーを特定するIDの内

1. いわゆる@username@host
   AP.preferredUsername ⇔ DB.usernameLower ([usernameLower, host] でUniq制約)
2. いわゆるhttps://example.com/users/:id
   AP.id ⇔ DB.uri (※本来Uniq制約を付けるべきだがv11-で消えてる)
3. いわゆるhttps://example.com/@username
   AP.url ⇔ DB.url (Uniq制約なし)

このうち、usernameを含む1, 3が変更されている可能性があるって感じかしら

それで

現状のupdatePersonでは2をキーにして更新するけど、1, 2, 3のカラムはいずれも更新しない。
ここで、1, 3も更新するようにすればいちおう更新されるようになるかもだわ。

:

（usernameが変更できる仕様はどっちかといえばThreads側に問題がありそうな気がしなくもないけどどうなんだろう）

https://www.w3.org/TR/activitypub/#actor-objects
そもそも username (preferredUsername) の一意制は保証されてないので、AP的にはこれを完全な一意的なIDとして扱う実装が良くないとなる。
もちろんユーザーはusernameが途中で変わったら困ると言うのはあるが、ある程度適切な冷却期間があればusernameの変更は否定される物でもないと思う。
Misskey実装的には、username変更時に本文のメンションを変更するのはキツイが、メンションしたという情報自体はDBの固有IDなのである程度は対応できると思う。

Related: #11372

[nanikamado]

preferredUsernameを変わらないIDとして扱うべきでないのであれば、本文（などの色々な場所）に含まれる@username@hostをそのままの形で保存すべきではないと思う。内部的には本文の中の@username@hostをAPのidを使った形式に書き換えておいて、外部に配信したりレンダリングしたりする時に@username@hostに戻すようにするべき。

[mei23]

preferredUsernameを変わらないIDとして扱うべきでないのであれば、本文（などの色々な場所）に含まれる@username@hostをそのままの形で保存すべきではないと思う。内部的には本文の中の@username@hostをAPのidを使った形式に書き換えておいて、外部に配信したりレンダリングしたりする時に@username@hostに戻すようにするべき。

理想的にはそうなのかもしれないけど、既存データを考えると現実的に無理。
usernameが変更されたことと、どの投稿でメンションされてたかはわかるので、そのタイミングで投稿引っ張って置換するくらいかなと。

[acid-chicken]

user_username テーブル作って
id, userId, username, host
で userId 重複ありで保存していくのが丸そう

[tai-cha]

user_username テーブル作って id, userId, username, host で userId 重複ありで保存していくのが丸そう

変更履歴を残すのであればcreatedAtといつ失効したかも持っていたほうがいい可能性がある

Misskeyでの仕様はまた別になるがMisskeyの仕様も変えるならused_username周りの仕様も変える必要がありそう？

[tesaguri]

そもそも username (preferredUsername) の一意制は保証されてないので、AP的にはこれを完全な一意的なIDとして扱う実装が良くないとなる。

ActivityPub and WebFinger community group reportに次のようにあるので、WebFingerにおけるusernameはActivityPubのアクターを一意に指すべきと考えられます。

[…] the link to the actor associated with a given WebFinger address will have the following qualifiers:

• rel MUST be self
• type MUST be either application/activity+json or application/ld+json; profile="https://www.w3.org/ns/activitystreams"

Publishers SHOULD include only one such link.

ActivityPub自体はpreferredUsernameとWebFingerの関係について言及していませんが、同reportとしてはMastodonが行なっているような（Misskeyは行なっていない；#7922）reverse discoveryによってアクターとWebFingerのusernameとの紐付けを確認することでusernameをIDとして確立するのが正しい方法であるという立場のようです（swicg/activitypub-webfinger#15 (comment)）。

ただ、同reportには次のようにもあるので、usernameを（共時的に）一意として扱えたとしても不変として扱うべきでないという結論には変わりなさそうです。

Implementers SHOULD NOT treat usernames as stable identifiers that will always map to the same actor

[tamaina]

個人的な意見

• MisskeyのプログラムはuserId/uriで処理するものがほとんどなので、MFM文中のメンションさえどうにかできればなんとかなるのではと思っている
• MFM文中のメンションを投稿/読み込みの際に都度読み替えるのは実装も計算もコスト高そう
• usernameは再利用不可として、古いusernameをエイリアスのように扱うのがよさそう?
  • 他の実装で再利用を許容するものがあるとつらそうだがインスタがどうなのかは知らない
  • ｴｯｸｽは再利用できるよね…
• Misskey側のusername変更可能化やその制限はここでは扱うべきではない?
  • ロールで制限するみたいな話があるとリモートにも絡んでくるのだが、整合性や悪影響が少ないのを考えると、リモートはロール制限の範囲外にしてもよさそう

[tamaina]

（usernameが変更できる仕様はどっちかといえばThreads側に問題がありそうな気がしなくもないけどどうなんだろう）

Misskeyがusernameの変更をサポートしてないのはリモートの対応含めて面倒だしそんなに需要がないから実装してないぐらいの感覚だと思ってる(しゅいろの意見は知らない)