awslabs / mls-rs

An implementation of Messaging Layer Security (RFC 9420)
Apache License 2.0
99 stars 19 forks source link

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

Open bifurcation opened 4 months ago

bifurcation commented 4 months ago

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:

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?

Out of scope:

N/A

tomleavy commented 4 months ago

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