Groupアクターを扱えるようにする #5739
Groupアクターを扱えるようにする #5739
Conversation
|
Misskey にはすでにグループ機能かあるので、ユーザーをグループとして扱ってグループアクターを実装するよりはグループ機能を連合させたほうが良さそうですね。 |
|
Related to #3218 |
最初、AP Group のマップ先はUserテーブルで大丈夫か？Groupじゃない？と思ったけど あと、PersonだかGroupだからわからないURIで表記されたAP Actorを解決する際に でも、Groupフラグ付きでUserテーブルに入れるだけだと、あちこちでUser扱いで出てきちゃうと思うので悩みどころ。 また、gup.peの言うGroupが、type=Groupになっている同報してくれるユーザーに過ぎないのでは かなと。 |
|
そもそもAPのGroupがMisskeyのユーザーをぶら下げられるGroupと違うのかもしれない |
|
ふむ、なかなか難しいですね……。 |
|
Mastodonは |
|
Pleromaも普通に通るのでMisskeyも通しちゃっていいかなと思ったんですが、まぁあせらずいきましょう。 |
|
他にGroupを普通のユーザーとして扱う実装がある時点で 過去に Group, Organization までは通そうかどうかとしていた気がします。 |
src/server/api/endpoints/i/update.ts
Outdated
| @@ -191,6 +198,7 @@ export default define(meta, async (ps, user, app) => { | |||
| if (ps.bannerId !== undefined) updates.bannerId = ps.bannerId; | |||
| if (typeof ps.isLocked == 'boolean') updates.isLocked = ps.isLocked; | |||
| if (typeof ps.isBot == 'boolean') updates.isBot = ps.isBot; | |||
| if (typeof ps.isGroup == 'boolean') updates.isGroup = ps.isGroup; | |||
There was a problem hiding this comment.
一般ユーザーが自分をGroupとして名乗ることを許しちゃうので
isGroupが変更できるとまずい気がします。
src/server/api/endpoints/i/update.ts
Outdated
| @@ -94,7 +94,7 @@ export const meta = { | |||
| carefulBot: { | |||
| validator: $.optional.bool, | |||
| desc: { | |||
| 'ja-JP': 'Botからのフォローを承認制にするか' | |||
| 'ja-JP': 'BotとGroupからのフォローを承認制にするか' | |||
There was a problem hiding this comment.
AP Groupが何を表すかが実装によって違う可能性があって
AP Groupが必ずしも自動だとは限らないのと、
これはオプション的な機能で、直近でGroupにそのままフォローされて困るという事象はなさそうなので
なしでいいかもと (私は) 思いました。
There was a problem hiding this comment.
AP Groupによるフォローを保留・拒否されると、機能として自動化されたフローを阻害することがあるため、Botと同等扱いしない方が安全ということもありました。今はまだBotとみなさなくても大丈夫そうですし、削除します。
|
おそらくこのプルリクエストには
が含まれていますが、とりあえず2は入れないほうがいいのではと思いました。 1 は https://github.com/syuilo/misskey/pull/5739#issuecomment-576738327 みたいな理由もあるので、入れちゃっていいのではと思いました。 また、Groupを許可するくらいならOrganizationも許可したいかなと思いました。 (誰がいつやるかはともかく) |
自分もこれ結構議論したような記憶があるのですが、それっぽい Issue/PR はないですね……。一旦 twista で試してみた上で実装方針を提案するとかだったかもしれません。（twista では標準の Actor をひとまずフラグだけつけて受け入れるのと、Organization Actor から Activity を配信するといった実装を現状適用しています。） |
ん、ではMisskey上でアカウントをGroupとして設定したい場合はどうするのかしら |
|
isGroupとisBotだと |
あ～ |
This comment has been minimized.
This comment has been minimized.
何かありましたっけ？ |
む、どういうことかな |
|
isGroup && isBot 問題はv12のついでに解決しても良さそう |
|
解除されるのはさすがにあれだしマイグレーションしてほしい |
面倒そう |
|
個人的には Bot が Service 名乗らなくなるケースが発生するのはマイグレできないならやめてほしいレベル |
現状でもBotなのにBotフラグ立ててないケースは目立つのでそこまで問題ではない気もしてる |
twista.283.cloud に認識された Bot 系ユーザーをチェックして Service を名乗っているか確認しているのですが、Misskey の Ghost を除けばほとんどの Bot が Service をちゃんと名乗っているので、状況は悪化してほしくないです……。 |
なるほど |
|
Misskey の Ghost が isBot ついてないケースが散見されるのに関してはまた別で Issue 立てて議論すべき案件かも（他サーバーから迷惑がられるケースも観測しているので）。 |
|
Ghost に関しては設定時に自動でisBotにするようにします |
今のところ一般ユーザーにGroupを名乗らせるのを許可する必要はないのかなと思います |
なるほど |
Misskey側に該当するものがない (トークのグループはすんまりマップ出来ない気がする) |
|
現在Groupのような運用をしているアカウントも存在するのでGroupを名乗れるようにしても良いかと思ってます |
あーこれはGroupというよりOrganizationかも |
Person <=> isBot=false, isGroup=false でも、そもそもActor typeでbotを識別する設計が良くない気がする。 |
|
Misskey上でGroupの扱いをどうするかは後回しにして、とりあえず export const validActor = ['Person', 'Service', 'Group']; // とOrganization？だけでもマージしてしまいたい |
|
これ結局どうするんだろう |
|
Group Actor自体はもう扱えるようになってるので、 |
|
Groupバッジはそんなに重要じゃないので、このまま閉じちゃいます。 |
Summary
Group Actorを受け付け、扱えるようにします。
https://github.com/syuilo/misskey/pull/5733 の変更とあわせて、gup.peなどグループ機能を提供するActivityPubサーバや、ハッシュタグリレーなどのGroupタイプのActorとやり取りができるようになります。