-
Notifications
You must be signed in to change notification settings - Fork 433
MSC4401: Publishing client capabilities via profiles #4401
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 1 commit
dfb76d7
2fac16c
308cf75
adc413e
b2790ab
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,91 @@ | ||
| # MSC4401: Publishing client capabilities via profiles | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like the concept of client capabilities and wish we had it for MSC4428 / MSC4430 so clients could advertise "I support room versions 1-12" such that servers could filter out unsupported rooms in I'm not convinced using profiles is the right place for this data though. I see your use case with needing other clients to have visibility on the capabilities, but profiles are per-user data structures (so you've got book-keeping in this MSC to namespace by device ID, which feels inelegant).
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, proper per-device profiles would be better, agreed. It's the same problem with device-specific features that build on account data such as #3890. |
||
|
|
||
| Matrix allows clients to exchange both built-in and custom events with other clients in rooms. There | ||
| is, however, no way for a client to determine what types of events other clients are able to | ||
| understand. For human users, this can usually be addressed to a sufficient extent by including | ||
| fallback representations in the event, for instance via [MSC1767]. Fallbacks don't work well when | ||
| communicating with bots, however. These usually expect to receive data in a defined format and are | ||
| often unable to fall back to alternative representations such as free text. | ||
|
|
||
| As an example, imagine a bot operated by a health insurance that is designated to process settlement | ||
| statements from caregivers. To process such statements automatically, the bot needs them to be sent | ||
| in a predefined format, for instance, by using a custom Matrix event. The caregiver obviously needs | ||
| to know about this format beforehand so that they can transmit their statements correctly. While the | ||
| bot could simply communicate the expected format via its documentation or through help messages, it | ||
| would be much more useful if the bot could declare its format(s) in a machine-readable way. This | ||
| would allow clients to implement auxiliary features such as automatically converting a data source | ||
| to the correct format. Additionally, this would also facilitate data exchange in scenarios where | ||
| both communication partners are bots. | ||
|
|
||
| This proposal addresses this problem by defining a way in which clients can advertise their support | ||
| for events via profiles. | ||
|
|
||
| ## Proposal | ||
|
|
||
| A new set of profile keys `m.client_capability.{DEVICE_ID}` is introduced. The value of these keys | ||
| is an object with the following properties: | ||
|
|
||
| - `events` (array, required): A list of objects containing details about the events this device | ||
| supports. | ||
| - `type` (string, required): The type of the event. | ||
| - `content` (array): An optional list of objects describing additional requirements for properties | ||
Johennes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| inside the `content` of the event. | ||
| - `key` (string, required): The dot-separated path of the property (analogous to `key` in | ||
| `event_match` [push rule conditions]). | ||
| - `value` (string, required): The exact value of the property. | ||
|
|
||
| As an example, here is a profile that advertises support for processing medication statements using | ||
| the FHIR event from [MSC4302] on a device `ABCDEFG`. | ||
|
|
||
| ``` json5 | ||
| { | ||
| "m.client_capability.ABCDEFG": { | ||
| "events": [ | ||
| { | ||
| "type": "de.gematik.msc4302.fhir", | ||
| "content": [{ | ||
| "key": "m\.fhir\.structure_definition.url", | ||
| "value": "http://hl7.org/fhir/StructureDefinition/MedicationStatement" | ||
| }, { | ||
| "key": "m\.fhir\.structure_definition.version", | ||
| "value": "4.0.1" | ||
| }] | ||
| } | ||
| ] | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ## Potential issues | ||
clokep marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| Profiles are currently limited to 64 KiB in size which may be reached through excessive usage of | ||
| this feature. | ||
Johennes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ## Alternatives | ||
|
|
||
| [MSC4301] defines online capability queries using in-room messages. These use a similar data format | ||
| but introduce the problem that both parties need to be online at the same time. | ||
|
|
||
| Client capabilities could be stored separately from profiles on the server. This would require new | ||
| APIs for reading and writing the data, access rules, etc. though. | ||
|
|
||
| ## Security considerations | ||
|
|
||
| Exposing client capabilities via profiles leaks metadata. Servers that are worried about users | ||
| misusing this feature can limit profile queries to users that have rooms in common or reside in | ||
| public rooms. Users that don't wish to expose their clients' capabilities, can simply *not* put them | ||
| into their profiles. | ||
|
|
||
| ## Unstable prefix | ||
|
|
||
| While this MSC is not considered stable, `m.client_capability.*` should be referred to as | ||
| `de.gematik.msc4401.client_capability.*`. | ||
|
|
||
| ## Dependencies | ||
|
|
||
| None. | ||
|
|
||
| [MSC1767]: https://github.com/matrix-org/matrix-spec-proposals/pull/1767 | ||
| [push rule conditions]: https://spec.matrix.org/v1.16/client-server-api/#conditions-1 | ||
| [MSC4302]: https://github.com/matrix-org/matrix-spec-proposals/pull/4302 | ||
| [MSC4301]: https://github.com/matrix-org/matrix-spec-proposals/pull/4301 | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation requirements: