Mutable Metadata group name Part 3 #677
Conversation
|
I just noticed in the MLS spec that Commits are considered invalid if they have more than one Group Context Extensions Proposal (https://www.rfc-editor.org/rfc/rfc9420.html#section-12.2-2) I'm going to take a closer look at what the conditions are that might lead to us having multiple proposals in a commit, and make sure we handle multiple GCE Proposals in the queue properly. |
| @@ -294,29 +552,78 @@ impl PolicySet { | |||
| }) | |||
| } | |||
|
|
|||
| // In case group creator is on future version of libxmtp, we can validate | |||
| // metadata policies on new unknown fields | |||
| fn evaluate_metadata_policy(&self, change: &MetadataChange, actor: &CommitParticipant) -> bool { | |||
There was a problem hiding this comment.
This function enables users to validate metadata updates for metadata fields that might not exist in their version of libxmtp
|
@neekolas I think this latest commit d9c26d5 incorporating the proto update to use mappings will achieve the functionality of allowing group members to validate metadata updates for fields that do not exist in their version of libxmtp (see function here #677 (comment)). Since permission policies are still only in immutable data, this would only apply to being invited to a new group by someone on a future version of libxmtp. But if we move mutable permission policies to mutable metadata, this will could enable adding new metadata fields to existing groups. I'll spend some time today looking for spots to make the code cleaner, more intuitive, but any feedback is welcome 🙏 |
cameronvoell
force-pushed
the
cv/mutable-metadata-part-3-fixed-commits
branch
from
5c71e20 to
8baeabf
Compare
This PR adds the Validation that group names obey the
update_group_name_policyset upon creating a group.See #548 for more info.
Previous PR's:
PR's related to this change:
Before merging this to
main:Cargo.tomlto commit onxmtp/openmlsmainbranchxmtp-protorepomainbranch