Services not allowed in MLS - Timeline for MLS Service Support

Services not allowed in MLS - Timeline for MLS Service Support

Current Behavior

When attempting to add a service to a team with MLS as the default protocol, we receive the error "Services not allowed in MLS". This is enforced by the guardMLSNotDefault check in the service whitelist update logic.

Expected Behavior

We would like to understand:

1. Is this a temporary limitation or a permanent design decision?
2. If temporary, what is the timeline for supporting services in MLS conversations?
3. Are there any technical challenges preventing services from supporting MLS protocol?

Technical Context

From the codebase, we can see this limitation is explicitly implemented:

guardMLSNotDefault = lift . liftSem $ do
  feat <- GalleyAPIAccess.getFeatureConfigForTeam @_ @Feature.MLSConfig tid
  let defProtocol = feat.config.mlsDefaultProtocol
  case defProtocol of
    ProtocolProteusTag -> pure ()
    ProtocolMLSTag -> throw UserSubsystemMLSServicesNotAllowed
    ProtocolMixedTag -> throw UserSubsystemMLSServicesNotAllowed

Impact

This limitation affects our ability to:

1. Use services in teams that have migrated to MLS
2. Maintain consistent service functionality across different protocol versions
3. Plan our migration strategy to MLS

Questions

1. Is there an official roadmap for MLS service support?
2. Are there any workarounds we can use in the meantime?
3. Will there be a migration path for existing services when MLS support is added?

Additional Context

• We are currently using Wire Server version: 5.16.0

Thank you for your time and consideration.

The issue points to guardMLSNotDefault in the service whitelist update logic; begin there and inspect the MLSConfig access through GalleyAPIAccess. Determine whether services are intentionally blocked for MLS and what roadmap or workaround applies. No file, test, implementation scope, or definition of done is named, so the issue needs clarification before work can begin.