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: ```haskell 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.