Remote Feature Flags

🎯 The objective

The aim of this project is to support safer, more maintainable, and remotely adjustable feature delivery by replacing duplicated per-app and per-build feature flag factories with a declarative feature flag catalogue, then extending that foundation to support remote feature flag updates. Success will be measured by shipping catalogue-backed feature flag resolution that preserves the existing feature flag API and debug override behaviour, removes duplicated factory definitions, validates known flag keys and overrides, and provides privacy-preserving remote updates with clear fallback behaviour.

🎒 Resources

🦮 Rules of the Road

🟢 In Scope

• Introduce one declarative feature flag catalogue shared by Thunderbird for Android and K-9 Mail.
• Define per-app and per-build type default overrides in the catalogue.
• Replace duplicated FeatureFlagFactory definitions with catalogue-backed resolution.
• Preserve the existing FeatureFlagProvider / FeatureFlagResult app-facing API.
• Preserve the current debug settings UI and local debug override precedence.
• Add schema validation and/or generated typed key validation so catalogue entries and overrides cannot drift silently.
• Define and implement remote feature flag updates.
• Define privacy, security, hosting, integrity, staleness, and fallback requirements for remote updates.

🔴 Out of Scope

• Multivariate feature flags, unless explicitly accepted by a later RFC.
• Managed feature flag vendors, unless explicitly accepted after privacy and security review.
• Experiments or rollout targeting beyond the scope accepted in the remote updates RFC.
• Changes to feature flag consumer call sites beyond what is required for migration.
• Any telemetry, analytics, ads, tracking, or logging of PII, credentials, message content, email addresses, or raw rollout identifiers.

🚧 Technical and/or Business Requirements

• Feature flag resolution must preserve local debug overrides as the highest-precedence source.
• The expected remote-capable precedence is: local debug overrides, accepted remote overrides/defaults, bundled app/build-type overrides, bundled defaults, then unavailable for unknown keys.
• Unknown or invalid override keys must be caught by validation or generation.
• Supported app and build type values must be validated.
• Defaults must remain explicit and reviewable for both Thunderbird and K-9 Mail.
• Remote catalogues must be integrity-protected and must fall back to bundled defaults when unavailable, invalid, unsigned, expired, or malformed.
• Any rollout identifier or evaluation context must be reviewed for privacy impact before use.
• The implementation must not send user-identifying data, message data, credentials, or email addresses to a remote feature flag service.

Start by reviewing the existing FeatureFlagFactory, FeatureFlagProvider, and FeatureFlagResult APIs against the in-scope requirements. The work is done when catalogue-backed resolution preserves debug override behavior, validates keys and app/build types, and remote updates have privacy, integrity, expiry, and bundled-fallback behavior defined and implemented.