Mutable admin permissions

[nplasterer]

Task Tracking:

1. Protos update - PR: Mutable Group Permissions proto#175
2. libxmtp updates - PR: Added new Permissions Extension #724
   1. Move Permissions from Immutable Metadata to GroupMutablePermissions Extension
   2. Add new admin list and super admin list to Mutable Metadata Extension
   3. Add new default permissions set "Admins only"
   4. Add functions for reading Admin List, Super Admin List, and each permission policy
   5. Add validation functions that correctly evaluate admin/super admin policies
   6. Add functions for add/remove admin+ super admin
   7. Add function for updating permissions
   8. add tests showing admin only permissions applied to add/remove group member, update metadata
   9. Add tests showing superadmin permissions for add/remove admin.
   10. Add a test showing how to add a new Permission Policy to an existing group
   11. BONUS - Add a test showing how to upgrade to a new Permissions Extension
3. SDK Updates
   1. Android
      1. Functions for reading admin list, super admin, permission policies
      2. add/remove admin function and super_admin function
      3. update permission function
      4. Add tests
   2. iOS
      1. Functions for reading admin list, super admin, permission policies
      2. add/remove admin function and super_admin function
      3. update permission function
      4. Add tests
   3. React Native
      1. Functions for reading admin list, super admin, permission policies
      2. add/remove admin function and super_admin function
      3. update permission function
      4. Add tests
      5. Example UI

Background on Groups Permissions

Currently in groups beta we have the following Permissions Policies:

1. add member policy
2. remove member policy
3. update metadata policy

Each of those policies can have one of the following Permission Options:

A. unspecified
B. allow
C. deny
D. creator only

Mutable Admin Permissions Update Specification

After the Mutable admin permissions change we will have the following new Permission Policies:

4 add admin policy
5. remove admin policy
6. update permissions policy

We will also add the following new Permission Options:

E. allow if admin or super admin
F. allow if super admin

To enable the two new permission options the following will be added to Mutable medata proto:

message GroupMutableMetadataV1 {
...
  AccountAddresses admin_list = 2;
  AccountAddresses super_admin_list = 3;
}

// Wrapper around a list of repeated EVM Account Addresses
message AccountAddresses {
  repeated string account_addresses = 1;
}

Upgradability and Backwards Compatibility

In addition to adding the new Permission Policies, the new Permission Options, and making Permission Updatable, we will also make the permission system itself upgradable in the following ways:

1. libxmtp can be updated so that existing groups can add new Permission Policies via the proto map<string, PermissionsUpdatePolicy> extensible_permissions_policy. This means that if later on we would like to add a new Permission Policy to groups like "The Ability to Mute Group Members", we would be able to add that without breaking any existing groups.
2. Deprecation and upgrade of the Permissions or Metadata Extensions in an existing groups Group Context - Existing groups would not be able to include an entirely new Permissions or Metadata Extension until all members of the group updated to a new version of libxmtp and performed a "leaf node update" commit they updated their "supported capabilities". For existing groups, the only way I can think of to do this would be to have a generous grace period , say of weeks/months, after which, any group member who has not been upgraded could be removed by an admin. At that point the group could be updated to enable new Permission / Metadata Extensions. The hope is that this type of upgrade might never have to happen, or could be very rare, less than once a year and even less frequent as time passes.

Questions

Some previously posed questions are answered below:

Do we want different groups of admins. Like admins that can add people versus admins that can change the group name.

The happy medium here seems to be three tiers of permissions: members, admins, and super admins, with group creators defaulting to being the only admin/super_admin, with the ability to add new admin/super admins over time. The super_admin - admin distinction feels needed as it allows group creators to delegate admin responsibilities without risking themselves being removed as an admin from the group. When a creator feels comfortable passing on or sharing highest level admin access, they are enabled to do that.

What other metadata would users want on a group like color? or description?

Similar to the upgradable permissions described in the section above, the Permissions and Metadata Shared Context Extensions have updatable mappings that can be used to add new Group properties, and permissions for updating those properties over time. So for example, libxmtp has already implemented Group Name, but a future libxmtp update could add group description or group url for existing groups without breaking anything for existing groups.