This feature makes breaking changes to the management of leaf node extensions (LNE) in mls-rs by moving LNEs outside of the Client config.
Use case:
The current implementation of leaf node extensions (LNE) requires the Client to be initialised with the extensions, typicaly by configuring them on the Client Builder. This comes with the following drawbacks:
Making changes to a member's LNEs requires either reinitializing the entire client or making the LNE itself a stateful reference type rather than a plain data structure. Neither approach is particularly developer friendly
Commit operations automatically update the LNEs of the member making the commit. Whilst this is likely desirable for some extensions, it puts an undue burden on consumers who don't want to make updates to the LNEs implicitly. Such consumers must ensure they preserve the data previously configured as the LNE in some form of external storage so that it can be passed to the Client upon initialisation. Failure to do so would result in LNEs being wrongly overwritten when making commits.
I believe breaking the existing API is necessary to ensure we avoid some of the undesirable behaviours in the discussion section
Allow leaf_node_extensions to be passed as parameters when executing the following operations:
Creating a group (ie, setting the LNEs for the member that creates the group)
Generating a KeyPackage
Making Commits (via a property in CommitBuilder)
If the property is not passed, then the commit code should be modified to preserve whatever value is currently set in LeadNode.extensions rather than overwrite it
Making update proposals
If the property is not passed, then the commit code should be modified to preserve whatever value is currently set in LeadNode.extensions rather than overwrite it
Description of feature:
This feature makes breaking changes to the management of leaf node extensions (LNE) in mls-rs by moving LNEs outside of the Client config.
Use case:
The current implementation of leaf node extensions (LNE) requires the Client to be initialised with the extensions, typicaly by configuring them on the Client Builder. This comes with the following drawbacks:
Implementation discussion (Optional)