How should of non-standard / pre-standard features be managed?

[bifurcation]

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:

• 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: Add a Replace proposal #170 is an example of extension functionality
• Testing: N/A, this is just a process / code structure decision

Out of scope:

N/A

[tomleavy]

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