ロールポリシーを増やす

[kakkokari-gtyih]

Summary

https://activitypub.software/TransFem-org/Sharkey/-/issues/669 から

ほぼそのまま転載しただけなので、ここでどれが要りそうでどれが要らなさそうかを検討したい

---

主にモデレーション方面で使えそうなロールポリシーを増やして、より柔軟に運用できるようにしたい

原文

I'd like to extend the role permission system to allow for more flexibility. The idea behind this is that for my instance in particular, I would like a light variant of "suspend" that does not deactivate the actor, more-so puts the account in a stasis/hold. I also have a role for new users called "sprout" that restricts some of the things that new users are able to do. I would like to remove new users' ability to DM until after the first week on the instance. There is also the possibility that I want to make an audit role that prohibits changing of password, account deletion. The permissions I would like to be able to have in order to account for this:

Reactions

I would like the ability to restrict a user's ability to react to a post. We have existing functionality (emojis marked as sensitive cannot be used as a reaction to posts with nonsensitive reaction levels). I propose the following permission booleans:

• canReact
• canLike

The reason for keeping "canreact" and "canlike" separate is because I think it's important to allow liking of posts (it's also part of the sensitivity levels - you can set it to allow likes only from remote instances). In the case that CanReact == false the only allowable reactions should be the default reaction inherited by instance settings instead of the user override. CanLike == false just disables the ability to react all together. In the UI, when these permissions are disabled it would be nice to hide the reaction button (and, in the API it would be nice to have a response for 403 that says you're missing the appropriate permissions)

Posting

I would like to have the ability to restrict what a user is able to post.

1. canQuote
   • This should be fairly easy, the api treats quotes/renotes as the same (renoteId is specified with text set to null or something specific)
2. canRenote (I don't care what it's called at the end of the day)
   • Check renoteId
3. canReply
   • Check replyId
   • （注：もうあるかも。canInitiateConversation？）
4. canDirectNote
   • Check Visibility, and check that VisibileUserIds == [] or null
5. canUnlistedNote
   • Check Visibility
   • （注：これは何）
6. canFederateNote
   • Check localOnly
7. canAttachFiles
   • Check (fileIds == null || fileIds == []) && (mediaIds == null || mediaIds == [])

Emojis

1. canUseCustomEmojis
   • During resolution check if there's any emojis (custom, idc about unicode don't waste your time) if so do not resolve them. emojis such as :dabmeup: and others should realistically just show as text (I believe the server actually attaches the emoji urls in the note json but I don't remember for sure)
2. canUseSensitiveEmojis
   • Whether the user can use sensitive emojis at all (if an emoji is marked as sensitive just don't render it using the same code as before)

Pages

1. pageLimit
   • Looking at instance meta, I don't see where the page limit is in policy? Maybe I'm missing something. Either way, the ability to remove users' page creation is something I want implemented.
   • （注：もうIssueがある ページ／Play／ギャラリー／チャンネルの作成上限をロールで制御したい #14212 ）

Channels

1. canNoteToChannel
   • Whether the user can create a note in a channel. Check channelId

Account

1. canDeleteAccount
   • Whether the user can delete their account
2. canChangePassword
   • Whether the user can change their password
3. canRevokeToken
   • Whether the user can revoke i via regenerate-token or revoke-token
4. canChangeEmail
   • Whether the user can change their email
5. canClaimAchievement
   • Whether the user can use i/claim-achievement
   • （注：本流では必要なさそう）
6. canChangeName
   • Whether the user can use i/update to change name
7. canChangeDescription
   • Whether the user can use i/update to change description
8. canChangeFields
   • Whether the user can use i/update to change fields
9. canChangeAvatar
   • Whether the user can use i/update to change avatar
10. canChangeBanner
    • Whether the user can use i/update to change banner
11. CanChangeBackground
    • Whether the user can use i/update to change background
    • （注：Misskeyには存在しない概念のため本流では必要なさそう）
12. canChangeStatus
    • Whether the user can use i/update to hide online status
13. canAutoFollow
    • Whether the user can use i/update to restrict/unrestrict follow requests
14. canPinPage
    • Whether the user can use i/update to pin a page
15. canChangeExplorable
    • Whether the user can use i/update to change their explorable setting
16. canChangeFollowingVisibility
    • Whether the user can use i/update to change their following visibility
17. canChangeFollowerVisibility
    • Whether the user can use i/update to change their follower visibility
18. canFollow
    • Whether the user can follow other users
19. canBeFollowed
    • Whether the user can be followed (just reject follow if not lol)
20. canUnfollow
    • Whether the user can unfollow other users
21. canRejectFollowRequests
    • Whether the user can reject follow requests

Drive

1. canCreateFolders
   • Whether the user can create drive folders
2. canDeleteFolders
   • Whether the user can delete drive folders
3. canDeleteFiles
   • Whether the user can delete drive files
4. canAccessDrive
   • Whether the user can access the drive menu at all.

The reason I did not include canCreateFiles is because you can already accomplish this restriction by setting the upload capacity (in MB) to 0.

Purpose

It would help with provide instance administration much needed granular permissions to better control the interactions they want on their instance. Consider someone who runs a sharkey (misskey) instance but does not like the custom reactions, they can disable them entirely.

（サーバー管理に便利なきめ細かなロールポリシーを提供することで、サーバー上でのインタラクションをよりよくコントロールできるようになる。例えばMisskeyを使いたいがリアクションは好まない…というようなユースケースでも追加の改造無しで対応可能になる）

Do you want to implement this feature yourself?

• Yes, I will implement this by myself and send a pull request

[KisaragiEffective]

canUnlistedNote

多分ホーム投稿できるかどうか？