The idea here is since we type each permission as a string and not a ThreadPermission (see D8391 for the comment why), I want to validate that each permission passed in is indeed a valid permission. So I use the existing threadPermissions, and ensure for each permission to be associated with the new role, it includes one of the threadPermissions.

So know_of and descendant_know_of, for example, will include 'know_of', however something like random_permission will be detected and throw the ServerError

Sure that makes sense

Yeah that makes sense

My approach was to make it possible to set any base threadPermission and any threadPermission with a prefix (see the comment in D8391)

type ConfigurableCommunityPermission = {
  // Type the permissions as `string`, as opposed to `ThreadPermission`,
  // because we open up the permissions to include an optional prefix
  // (i.e. `descendant_`) to propagate certain permissions down the community.
  +permissions: $ReadOnlyArray<string>,
  +title: string,
  +description: string,
};

Once your feedback is addressed on changing configurableCommunityPermissions, I'll check on improving the validation.

I responded to the overall API design comment in your last inline comment

edit_role will be implemented later during that flow, so I can just throw a ServerError for now

The permissions here specifically are the selected permissions passed in from the client-side create roles screen, where the user selects the EnumSettingsOption corresponding to what permissions they want associated for the role (i.e. selecting "Allows members to edit their sent messages" and "Allows members to add reactions to messages" will mean this permissions array is ['edit_message', 'descendant_edit_message', 'react_to_message', 'descendant_react_to_message'].

Separately, my understanding is we want to use the existing thread permissions to build out community roles. The 'user-facing' permissions, to me, were just the way we present the different permissions to users (and how we group different permissions like all of the edit_thread_... permissions). The readability of this will be better when your feedback in D8391 is addressed. On the back-end, it's still the same permissions system of using the thread permissions, but trying to propagate them across the entire community for that one role.

Let me know if I'm misunderstanding your comment however

I don't think we should allow the client this much leeway. It should not be able to pick arbitrary combinations of permissions and prefixes. We need to lock it down to only accept the predetermined combos of permissions that we are showing in the UI.

The best way to address this would be to introduce a different enum to track the various predetermined combos of permissions, and to use that for client/server communication. The mapping from the new enum to the combos of permissions would be done on the keyserver side, and could not be gamed by the client.