4.5 KiB

Raw Permalink Blame History

MSC4246: Sending to-device messages as/to a server

When implementing RFC 9420 MLS, a need arises for a client to be able to send "messages" to a specific server. Other features, like message franking during reporting, could also use the ability to send ephemeral-ish data to a server without the need for a whole room to be spun up. These communication channels may also need to be bidirectional to allow servers to reply or send information back to the client.

This proposal suggests an approach on how to accomplish that.

Proposal

An empty string localpart is reserved for a user ID representing the server itself, alongside an empty string for a device ID. The current user ID grammar is modified to allow user_id_localpart to be zero characters long, as is any grammar for device IDs. This should be possible because rooms still use the historical user ID grammar, which means clients shouldn't explode when they see such identifiers. Servers should already be declining to allow new registrations from the historical user ID grammar, however.

This translates to the following when a client wishes to send a to-device message to a server, using the /sendToDevice endpoint:

PUT /_matrix/client/v3/sendToDevice/org.example.whatever/whatever123
{
    "messages": {
        "@:example.org": {
            "": { "example_content": "value" }
        }
    }
}

The * notation for sending to all device IDs is automatically converted to "" by the local server, instead of looking up a device list for the "user". This prevents servers from having multiple devices (a restriction which may be removed in a future MSC).

Over federation, if applicable, the associated m.direct_to_device EDU looks as follows:

{
    "edu_type": "m.direct_to_device",
    "content": {
        "message_id": "<generated by sending server>",
        "sender": "@alice:remote.example.org",
        "type": "org.example.whatever",
        "messages": {
            "@:example.org": {
                "": { "example_content": "value" }
            }
        }
    }
}

When a server is sending a to-device message to another user, it would produce the following m.direct_to_device EDU (if applicable) and resulting to-device event in /sync (and applicable future synchronization APIs):

{
    "edu_type": "m.direct_to_device",
    "content": {
        "message_id": "<generated by sending server>",
        "sender": "@:example.org",
        "type": "org.example.whatever",
        "messages": {
            "@alice:remote.example.org": {
                "AAAABBBB": { "example_content": "value" }
            }
        }
    }
}

{
    "sender": "@:example.org",
    "type": "org.example.whatever",
    "content": { "example_content": "value" }
}

Alternatives

A new API for sending to/from a server could be introduced, with a complementing set of EDUs. This ends up feeling quite a bit like to-device messages already, and looks eerily similar, and is therefore discounted in favour of just using to-device as-is.

Potential issues

Servers may already have users which are registered as @:example.org, or may have them registered after this MSC is published. Servers should consider taking over such user IDs for purposes defined by this MSC. At the time of writing, it does not appear that any human or bot users occupy the empty string namespace in the public federation.

Security considerations

Servers should not build an inbox for to-device events directed at the server. They should be delivered to the relevant subsystem directly, and processed as soon as possible. If the event type or EDU is unknown to the server, it should be left to the pleasantries of /dev/null.

Dependencies

This MSC is not dependent on any other MSCs. MSC4244 relies on the functionality introduced by this proposal. Others may additionally exist.

Unstable prefix

This proposal does not require an unstable prefix as it doesn't materially change any APIs. Instead, dependent MSCs should use unstable prefixes when communicating with the "server" user, and note that it may be an actual account rather than the server itself for the time being (per Potential Issues section).

4.5 KiB Raw Permalink Blame History