Proposal: `mls://` schema for internal MLS IDs and `ap-mls://` for external deep-linking

The current spec draft recommends uri:uuid: for the id field of encrypted content objects:

“This should be a unique URI, but not an HTTPS URL. A UUID, for example, provides a reasonably unique value…”
Example: "id": "uri:uuid:C52C4A75-0EE2-4E2B-BDFA-3BEAC534A24D"

While this ensures uniqueness, they are opaque and lack semantic meaning and usefulness.

This proposal introduces two distinct URI schemes:

• mls:// → internal-only identifiers (opaque, non-leaking, confined to encrypted content)
• ap-mls:// → external/deep-link identifiers (derived from ActivityPub objects, safe for deep-linking and cross-client navigation)

1. Internal IDs: mls:// (non-leaking)

Used only inside encrypted MLS content.

Properties:

• Opaque or semi-structured
• MUST NOT be exposed outside encrypted payloads
• Can include UUIDs or similar
• Can be used for internal navigation

Examples:

mls://group/<group-id>
mls://g/<group-id>
mls://message/<message-id>
mls://m/<message-id>
mls://group/<group-id>/message/<message-id>

This replaces or supplements uri:uuid: as a recommended scheme that is explicitly scoped to MLS.

2. External / deep-linking URIs with ap-mls://

Used for mapping ActivityPub objects into E2EE addressable resources, by enabling clients to transform a public ActivityPub ID like:

https://social.example/user/example1/create/1

Into:

ap-mls://social.example/user/example1/create/1

Properties:

• Safe to expose outside encryption
• Does not leak encrypted content
• Acts as a handoff/deep-link mechanism to E2EE-capable clients

Example use case:

Deep linking from non-E2EE context: when a web UI with no E2EE support encounters an encypted payload:

→ replace https with ap-mls in the ID
→ open that URL
→ OS opens E2EE client app which has registered as a handler for this custom schema
→ client resolves it to the corresponding MLS message

Open questions

• Should mls:// be required for internal IDs, or just recommended or presented as an option?
• Should ap-mls:// be strictly defined as a transformation of ActivityPub IDs?
• Should path formats (eg. /group/.../message/...) be standardized for interop?

Start with the current spec draft's recommendation of uri:uuid: for encrypted content object IDs. Resolve whether mls:// and ap-mls:// should be required or optional, whether the external scheme must transform ActivityPub IDs, and whether path formats need standardization. Done means the proposal's open questions are settled in an interoperable specification.