As folks use this library more, they will run into use cases that are not covered by the base MLS functionality. For example, #170 describes a use case for a new Replace proposal. While these features are not standard, we should somehow isolate them from the main code base, and probably allow consumers to opt out of them.
Solution:
There are a few tools available here:
Isolating new features in submodules
Creating an extensions sub-module that captures behavior that goes beyond RFC 9420
Using feature flags to enable / disable extension features
It seems to me that feature flags are a good option regardless of where the code goes, so that consumers can manage whether extension features are enabled. I don't have a very strong feeling about where the code should go. Given that some extension functionality might need visibility into protocol internals (as #170) does, it might be simplest to have it in place, though judicious use of pub(crate) could make it feasible to have it in a sub-module.
Requirements / Acceptance Criteria:
What must a solution address in order to solve the problem? How do we know the solution is complete?
RFC links: N/A
Related Issues: #170 is an example of extension functionality
Testing: N/A, this is just a process / code structure decision
Hey @bifurcation . I'm definitely a fan of the feature flag approach. There can be an experimental feature that enables individual features for each extension we want to add
Problem:
As folks use this library more, they will run into use cases that are not covered by the base MLS functionality. For example, #170 describes a use case for a new Replace proposal. While these features are not standard, we should somehow isolate them from the main code base, and probably allow consumers to opt out of them.
Solution:
There are a few tools available here:
extensions
sub-module that captures behavior that goes beyond RFC 9420It seems to me that feature flags are a good option regardless of where the code goes, so that consumers can manage whether extension features are enabled. I don't have a very strong feeling about where the code should go. Given that some extension functionality might need visibility into protocol internals (as #170) does, it might be simplest to have it in place, though judicious use of
pub(crate)
could make it feasible to have it in a sub-module.Requirements / Acceptance Criteria:
What must a solution address in order to solve the problem? How do we know the solution is complete?
Out of scope:
N/A