From 038b33ee00dfbd30b918568b59f721e66e554333 Mon Sep 17 00:00:00 2001 From: Catalan Lover Date: Wed, 25 Sep 2024 19:00:57 +0200 Subject: [PATCH 1/9] Initial commit Profiles as rooms v2 --- proposals/XXXX-profiles-as-rooms-v2.md | 235 +++++++++++++++++++++++++ 1 file changed, 235 insertions(+) create mode 100644 proposals/XXXX-profiles-as-rooms-v2.md diff --git a/proposals/XXXX-profiles-as-rooms-v2.md b/proposals/XXXX-profiles-as-rooms-v2.md new file mode 100644 index 00000000000..21e4e0c92e1 --- /dev/null +++ b/proposals/XXXX-profiles-as-rooms-v2.md @@ -0,0 +1,235 @@ +# MSC0000: Profiles as Rooms v2 + +## Introduction + +### Acknowledgements + +This MSC exists to realise the vision that was set out in [MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769) +this vision has served to guide the ecosystem for a long time but its time to finally realise it. + +This proposal aims to provide a pathway to take us from the limitations of today that shaped the competing proposal +[MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133) to the future where we have fed peeking +fully working in the hopeful event that said future happens. + +A thanks has to be issued to everyone who gave feedback on [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133) +as this feedback has helped shape this competing proposal. Also thanks to Tom for the proposal it self as it has inspired parts of this +proposal. + +Thanks to Gnuxie for being the source of the peeking bypass idea as far as Cat remembers. + +### Proposal Introduction + +Profiles as rooms is a long established dream in the matrix ecosystem that has been declared as the solution +to a whole bunch of our problems. This MSC aims to realise that dream via packaging up a idea that has been circulating +in the spec room. Just abuse /profile and the nature of profiles to bypass the Peeking problems. + +This proposal uses profile rooms and state events to define profile information. Profile information +is defined via a `m.profile` state event in your profile room that uses state keys to differentiate values. + +To get around the fact that we do not have federated peeking yet this proposal will use the /profile federation API +to simply ask the users homeserver about their profiles. This proposal supports per room profiles and viewing +restricted profiles. + +Restricted viewing is done via a check of is the person asking in a room where you are pointing to that profile. +Public profiles without viewing restrictions are also considered valid as you want to be able to present +a profile before you share a room if your privacy settings allow for this. + +## Proposal + +This proposal is split into 2 primary categories. Profile room and the APIs. + +Profile Room section deals with the state events that control your profile room and the API section +deals with defining the APIs involved in this process. + +### Profile Rooms + +Profile rooms are special rooms with the dedicated purpose of storing profiles. These rooms will be created +with the `type` being `m.profile` in line with [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772) +established precedent on that specialised rooms like these are what room types are for. + +They are plain old normal matrix rooms except for that they store profile information as their defined +purpose and server implementations or future MSCs are free to provide powerlevel templates that reflect this purpose. + +These rooms contain `m.profile` state events to store profile data as the state key determines the profile key this data is for. +The `m.profile.privacy` event controls the privacy rules for the profile in question. This state event +with a blank state key and contains a `visibility` flag as its initial contents but future proposals are welcome to elaborate. +This `visibility` flag accepts the values of `public` and `restricted`. + +Example of the `m.profile.privacy` event. + +```json +{ + "content": { + "visibility": "restricted" + }, + "sender": "@alice:example.com", + "state_key": "", + "type": "m.profile.privacy", + "event_id": "exampleid", + "room_id": "!alice_profile:example.com" +} +``` + +`visibility` of `public` means that anyone is allowed to look up this profile. This value is primarily intended for your global profile +for when you do not yet share a room with the subject. Like when they are doing a lookup in the user directory when starting a DM. + +`visibility` of `restricted` restricts who can look up a profile to users who are in a room that has a pointer to this profile. +For a pointer to be valid said pointer must be issued by the creator of the profile if the profile is restricted. This means that +invites can only set `public` profiles without causing the server to 404 the request. + +To use a given profile you set a `profile` value in your `m.room.member` event for a given room. The value of `profile` is the room ID +of the profile you want to use in that room. + +`m.profile` events are limited only to all the normal event size rules but clients are allowed to enforce whatever limits they find resonable +on data that they will render when given this data. + +### Client-Server API Changes + +The contents of a profile are accessed via the following endpoints + +
+ Get Profile Endpoint + +- **Endpoint**: `GET /_matrix/client/v1/profile/{roomID}` + - **Description**: Get a profile. If the request body contains a list of keys only those events will be returned. + Omit request body to fetch all profile information. + - **Query Param**: Use `auth_event` query parameter to point to what event grants you access to the profile. + - **Errors**: If the requesting user does not have access to the provided `auth_event` 403 the request. + If a specific state key has empty contents omit returning said profile field. + - **Response**: + +```json +{ + "key_name": "field_value" +} +``` + +
+ +### Server-Server API Changes + +The federation endpoint `GET /_matrix/federation/v1/profile/{roomID}` will mirror the client-server +API endpoint in behaviour except that it also adds a query parameter of `requesting_user` where the mxid +of the requesting user is defined. This is so that the server can verify if the requesting user has +access to a event points to the given profile if its a `restricted` profile. + +As this proposal is avoiding the use of peeking the validity of a profile can not be verified over +federation and therefore we have to just trust the server of the user. Therefore this API can only be called +against the server that the profile was created on for now. + +A federated peeking MSC is free to propose an API that can be used to access this data with less restrictions. + +A profile with `m.federate` set to `false` in its creation event is not allowed to be requested over federation. + +The rules configured in the `m.room.server_acl` event are to be respected for all profile requests. This means that +if a server is ACL banned from a profile room said server is not allowed to request the contents of this profile. +This function exists so that users are able to block servers that they want to not have profile access from having profile access. + +### Limitations + +The completely freeform nature of this proposal raises Trust and Safety Concerns. To mitigate at least +one of these concerns servers are completely welcome to run allow and deny lists on state keys for profiles. + +Servers that wish to guarantee that no disallowed data exists in the room state of a profile are allowed to +under this proposal enforce strict access controls on what events can be sent into the profile room. +This is to ensure that the server can not loose control over the state by allowing remote users in for example. + +Profiles have no size caps set in stone in this proposal as of version 1 of the proposal. This is seen as +acceptable because rooms are currently also unbound and servers are happy with requests like /state on the +matrix.org coc policy list. The policy list in question is of a decent size. + +### Trust and Safety + +To address the T&S question on a room level clients are supposed to display no profile what so ever for a user +if their membership event is redacted as this is the current status quo and this MSC does not wish to disrupt this. + +Homeserver administrators are liberally able to go in and modify users profiles to comply with server policy. + +Its preferred if homeserver admins redact the state events in question that they find disagrees with homeserver policy. + +The omit empty fields policy for the endpoint is to mitigate this specific T&S concern and privacy concern. Empty +state events should be hidden as they are empty for a reason. + +### Field Name Rules + +Homeservers should be very careful about how they enforce profile field rules as to balance their T&S concerns and +the ability for users to access the full power of this proposal and future extensions. + +Spec defined profile fields come with state keys that carry the reserved `m.` prefix. + +User defined profile fields come with the `u.` prefix copied from tags. + +Lastly Clients and Servers and MSCs are ofc allowed to use custom prefixes that follow the Java naming +conventions that we follow in matrix. An example could be `support.feline.cat`. + +Spec defined fields and fields that follow the java naming conventions can have specified validation +rules that go beyond the general rules that this MSC imposes. For example if [MSC4175](https://github.com/matrix-org/matrix-spec-proposals/pull/4175) +is used with this proposal that MSC could define that the `m.tz / us.cloke.msc4175.tz` field it defines +has a maximum size of 50 characters. + +## Potential issues + +This MSC has the problem of that its adding freeform fields and attempting to guarantee wide ecosystem +support for all of them is well hard. But this challenge i think is warranted as this MSC represents +a faithful hopefully version of the vision that the community had for [MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769). + +This MSC is intentionally more complex to allow for a single proposal to do everything that was +dreamed about for [MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769) over the years. + +This MSC on its own is very weakly useful as it needs proposals that build upon it to achieve full potential. + +This MSC is intentionally leaving all the possible fields out of scope as that's not important. The +desire is proven for years in the ecosystem so this proposals job is not to prove that the people want this, +just to provide it. + +This MSC also has no way to broadcast changes to users but that could easily be added in a future proposal. + +Mechanisms to indicate this change include EDUs or timeline events but state events are considered too heavy +for this purpose at this time. + +## Alternatives + +The primary alternative to this MSC is [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). + +This MSC sees it self as the better alternative if perfected because it brings Per room and private profiles +and a path to the original vision of Profiles as Rooms that use Federated peeking. This proposal brings +Trust and Safety as a Nr 1 priority but ofc this is a very hard thing to deal with as we are essentially +bringing something akin to a steam profile with this MSC. That's very intentional as Steam profiles are a +inspiration for this MSC UX wise. + +## Security considerations + +This MSC has covered its various security related aspects throughout the whole MSC but lets boil it down to one +place. + +Privacy of profiles is only loosely enforceable over federation. But so is all of matrix. We simply can not guarantee +that someone is who they claim to be outside of E2EE. This also applies with our profile lookups. But +we do mitigate the abuse aspect by requiring that you not only know the event ID of a event that points +to a profile but have all the validation be done by the server who controls said user. + +Public profiles are a risk that users need to be informed of but its seen as an acceptable risk as its simply +paramount to offer this option. Users are not expected to be happy when told you can not see any profile what so +ever for someone you don't share a room with when trying to invite them. Especially local users on private servers. + +A public profile is not mandatory under this proposal very much on purpose. This is one of the details of this +MSC informed by Steam. They also have rich profile visibility settings and they are very popular, while we are +not copying all of their settings in this proposal with the right use of this proposal you can achieve mostly similar +results. + +The Problems related to that this MSC allows you to essentially ask to be vomited data at are hopefully explained +away to an acceptable degree. + +No further Security considerations not covered elsewhere in this MSC or in this Section are known to the author at this time. + +## Unstable prefix + +While this proposal is unstable the following substitutions are to be made. + +`m.profile.privacy` becomes `support.feline.mscXXXX.profile.privacy.v1` +`m.profile` state event becomes `support.feline.mscXXXX.profile.v1` +`m.profile` room type becomes `support.feline.mscXXXX.profile` + +## Dependencies + +This MSC does not have any unstable dependencies known to the author but does build on the +work in [MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769) From ee674c2ef6fc7923204455b779d32c939efaee7c Mon Sep 17 00:00:00 2001 From: Catalan Lover Date: Wed, 25 Sep 2024 19:24:33 +0200 Subject: [PATCH 2/9] Enforce the 120 character maximum recommendation. --- proposals/XXXX-profiles-as-rooms-v2.md | 53 ++++++++++++++++---------- 1 file changed, 32 insertions(+), 21 deletions(-) diff --git a/proposals/XXXX-profiles-as-rooms-v2.md b/proposals/XXXX-profiles-as-rooms-v2.md index 21e4e0c92e1..dc53faf33c1 100644 --- a/proposals/XXXX-profiles-as-rooms-v2.md +++ b/proposals/XXXX-profiles-as-rooms-v2.md @@ -4,16 +4,18 @@ ### Acknowledgements -This MSC exists to realise the vision that was set out in [MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769) +This MSC exists to realise the vision that was set out in +[MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769) this vision has served to guide the ecosystem for a long time but its time to finally realise it. This proposal aims to provide a pathway to take us from the limitations of today that shaped the competing proposal [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133) to the future where we have fed peeking fully working in the hopeful event that said future happens. -A thanks has to be issued to everyone who gave feedback on [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133) -as this feedback has helped shape this competing proposal. Also thanks to Tom for the proposal it self as it has inspired parts of this -proposal. +A thanks has to be issued to everyone who gave feedback on +[MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133) +as this feedback has helped shape this competing proposal. +Also thanks to Tom for the proposal it self as it has inspired parts of this proposal. Thanks to Gnuxie for being the source of the peeking bypass idea as far as Cat remembers. @@ -50,9 +52,13 @@ established precedent on that specialised rooms like these are what room types a They are plain old normal matrix rooms except for that they store profile information as their defined purpose and server implementations or future MSCs are free to provide powerlevel templates that reflect this purpose. -These rooms contain `m.profile` state events to store profile data as the state key determines the profile key this data is for. +These rooms contain `m.profile` state events to store profile data as the state key determines +the profile key this data is for. + The `m.profile.privacy` event controls the privacy rules for the profile in question. This state event -with a blank state key and contains a `visibility` flag as its initial contents but future proposals are welcome to elaborate. +with a blank state key and contains a `visibility` flag as its initial contents but future proposals +are welcome to elaborate. + This `visibility` flag accepts the values of `public` and `restricted`. Example of the `m.profile.privacy` event. @@ -70,18 +76,20 @@ Example of the `m.profile.privacy` event. } ``` -`visibility` of `public` means that anyone is allowed to look up this profile. This value is primarily intended for your global profile -for when you do not yet share a room with the subject. Like when they are doing a lookup in the user directory when starting a DM. +`visibility` of `public` means that anyone is allowed to look up this profile. This value is primarily intended for +your global profile for when you do not yet share a room with the subject. Like when they are doing a lookup in +the user directory when starting a DM. -`visibility` of `restricted` restricts who can look up a profile to users who are in a room that has a pointer to this profile. -For a pointer to be valid said pointer must be issued by the creator of the profile if the profile is restricted. This means that -invites can only set `public` profiles without causing the server to 404 the request. +`visibility` of `restricted` restricts who can look up a profile to users who are +in a room that has a pointer to this profile. +For a pointer to be valid said pointer must be issued by the creator of the profile if the profile is restricted. +This means that invites can only set `public` profiles without causing the server to 404 the request. -To use a given profile you set a `profile` value in your `m.room.member` event for a given room. The value of `profile` is the room ID -of the profile you want to use in that room. +To use a given profile you set a `profile` value in your `m.room.member` event for a given room. +The value of `profile` is the room ID of the profile you want to use in that room. -`m.profile` events are limited only to all the normal event size rules but clients are allowed to enforce whatever limits they find resonable -on data that they will render when given this data. +`m.profile` events are limited only to all the normal event size rules but clients are allowed to enforce whatever +limits they find resonable on data that they will render when given this data. ### Client-Server API Changes @@ -123,7 +131,8 @@ A profile with `m.federate` set to `false` in its creation event is not allowed The rules configured in the `m.room.server_acl` event are to be respected for all profile requests. This means that if a server is ACL banned from a profile room said server is not allowed to request the contents of this profile. -This function exists so that users are able to block servers that they want to not have profile access from having profile access. +This function exists so that users are able to +block servers that they want to not have profile access from having profile access. ### Limitations @@ -163,15 +172,16 @@ Lastly Clients and Servers and MSCs are ofc allowed to use custom prefixes that conventions that we follow in matrix. An example could be `support.feline.cat`. Spec defined fields and fields that follow the java naming conventions can have specified validation -rules that go beyond the general rules that this MSC imposes. For example if [MSC4175](https://github.com/matrix-org/matrix-spec-proposals/pull/4175) -is used with this proposal that MSC could define that the `m.tz / us.cloke.msc4175.tz` field it defines -has a maximum size of 50 characters. +rules that go beyond the general rules that this MSC imposes. For example if +[MSC4175](https://github.com/matrix-org/matrix-spec-proposals/pull/4175) is used with this proposal that MSC +could define that the `m.tz / us.cloke.msc4175.tz` field it defines has a maximum size of 50 characters. ## Potential issues This MSC has the problem of that its adding freeform fields and attempting to guarantee wide ecosystem support for all of them is well hard. But this challenge i think is warranted as this MSC represents -a faithful hopefully version of the vision that the community had for [MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769). +a faithful hopefully version of the vision that +the community had for [MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769). This MSC is intentionally more complex to allow for a single proposal to do everything that was dreamed about for [MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769) over the years. @@ -219,7 +229,8 @@ results. The Problems related to that this MSC allows you to essentially ask to be vomited data at are hopefully explained away to an acceptable degree. -No further Security considerations not covered elsewhere in this MSC or in this Section are known to the author at this time. +No further Security considerations not covered elsewhere in this MSC +or in this Section are known to the author at this time. ## Unstable prefix From 7f3b4dbfe42d30ea34d3665191666217a028e821 Mon Sep 17 00:00:00 2001 From: Catalan Lover Date: Wed, 25 Sep 2024 19:36:09 +0200 Subject: [PATCH 3/9] Fix profile pointer in membership not being namespaced. --- proposals/XXXX-profiles-as-rooms-v2.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/XXXX-profiles-as-rooms-v2.md b/proposals/XXXX-profiles-as-rooms-v2.md index dc53faf33c1..e5561c579e7 100644 --- a/proposals/XXXX-profiles-as-rooms-v2.md +++ b/proposals/XXXX-profiles-as-rooms-v2.md @@ -85,8 +85,8 @@ in a room that has a pointer to this profile. For a pointer to be valid said pointer must be issued by the creator of the profile if the profile is restricted. This means that invites can only set `public` profiles without causing the server to 404 the request. -To use a given profile you set a `profile` value in your `m.room.member` event for a given room. -The value of `profile` is the room ID of the profile you want to use in that room. +To use a given profile you set a `m.profile` value in your `m.room.member` event for a given room. +The value of `m.profile` is the room ID of the profile you want to use in that room. `m.profile` events are limited only to all the normal event size rules but clients are allowed to enforce whatever limits they find resonable on data that they will render when given this data. @@ -239,6 +239,7 @@ While this proposal is unstable the following substitutions are to be made. `m.profile.privacy` becomes `support.feline.mscXXXX.profile.privacy.v1` `m.profile` state event becomes `support.feline.mscXXXX.profile.v1` `m.profile` room type becomes `support.feline.mscXXXX.profile` +`m.profile` value in `m.room.member` becomes `support.feline.mscXXXX.profile.v1` ## Dependencies From 6f106784a45b7cb78cf00845746bec0e6711ab1e Mon Sep 17 00:00:00 2001 From: Catalan Lover Date: Wed, 25 Sep 2024 19:53:05 +0200 Subject: [PATCH 4/9] Address ACL banning the mods concern. --- proposals/XXXX-profiles-as-rooms-v2.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proposals/XXXX-profiles-as-rooms-v2.md b/proposals/XXXX-profiles-as-rooms-v2.md index e5561c579e7..bfe5bec69af 100644 --- a/proposals/XXXX-profiles-as-rooms-v2.md +++ b/proposals/XXXX-profiles-as-rooms-v2.md @@ -226,6 +226,9 @@ MSC informed by Steam. They also have rich profile visibility settings and they not copying all of their settings in this proposal with the right use of this proposal you can achieve mostly similar results. +There is the concern that users can ACL ban the mods from their profile and this concern is lessened if moderators are +informed of this situation and simply disallow such profiles in their rooms. + The Problems related to that this MSC allows you to essentially ask to be vomited data at are hopefully explained away to an acceptable degree. From 37981f00770e79b991905059e2b4711bc6cbc98a Mon Sep 17 00:00:00 2001 From: Catalan Lover Date: Wed, 25 Sep 2024 22:56:40 +0200 Subject: [PATCH 5/9] Rework Proposal to integrate feedback --- proposals/XXXX-profiles-as-rooms-v2.md | 164 ++++++++++++++----------- 1 file changed, 91 insertions(+), 73 deletions(-) diff --git a/proposals/XXXX-profiles-as-rooms-v2.md b/proposals/XXXX-profiles-as-rooms-v2.md index bfe5bec69af..31f32082102 100644 --- a/proposals/XXXX-profiles-as-rooms-v2.md +++ b/proposals/XXXX-profiles-as-rooms-v2.md @@ -1,26 +1,22 @@ -# MSC0000: Profiles as Rooms v2 +# MSCXXXX: Profiles as Rooms v2 + +- [MSCXXXX: Profiles as Rooms v2](#mscxxxx-profiles-as-rooms-v2) + - [Introduction](#introduction) + - [Proposal](#proposal) + - [Profile Rooms](#profile-rooms) + - [Using and Accessing Profiles](#using-and-accessing-profiles) + - [Limitations](#limitations) + - [Trust and Safety](#trust-and-safety) + - [Field Name Rules](#field-name-rules) + - [Potential issues](#potential-issues) + - [Alternatives](#alternatives) + - [Security considerations](#security-considerations) + - [Unstable prefix](#unstable-prefix) + - [Dependencies](#dependencies) + - [Acknowledgements](#acknowledgements) ## Introduction -### Acknowledgements - -This MSC exists to realise the vision that was set out in -[MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769) -this vision has served to guide the ecosystem for a long time but its time to finally realise it. - -This proposal aims to provide a pathway to take us from the limitations of today that shaped the competing proposal -[MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133) to the future where we have fed peeking -fully working in the hopeful event that said future happens. - -A thanks has to be issued to everyone who gave feedback on -[MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133) -as this feedback has helped shape this competing proposal. -Also thanks to Tom for the proposal it self as it has inspired parts of this proposal. - -Thanks to Gnuxie for being the source of the peeking bypass idea as far as Cat remembers. - -### Proposal Introduction - Profiles as rooms is a long established dream in the matrix ecosystem that has been declared as the solution to a whole bunch of our problems. This MSC aims to realise that dream via packaging up a idea that has been circulating in the spec room. Just abuse /profile and the nature of profiles to bypass the Peeking problems. @@ -38,11 +34,6 @@ a profile before you share a room if your privacy settings allow for this. ## Proposal -This proposal is split into 2 primary categories. Profile room and the APIs. - -Profile Room section deals with the state events that control your profile room and the API section -deals with defining the APIs involved in this process. - ### Profile Rooms Profile rooms are special rooms with the dedicated purpose of storing profiles. These rooms will be created @@ -53,13 +44,13 @@ They are plain old normal matrix rooms except for that they store profile inform purpose and server implementations or future MSCs are free to provide powerlevel templates that reflect this purpose. These rooms contain `m.profile` state events to store profile data as the state key determines -the profile key this data is for. +the profile field this data is for. The `m.profile.privacy` event controls the privacy rules for the profile in question. This state event -with a blank state key and contains a `visibility` flag as its initial contents but future proposals +with a blank state key contains a `visibility` value as its initial contents but future proposals are welcome to elaborate. -This `visibility` flag accepts the values of `public` and `restricted`. +This `visibility` value accepts the values of `public` and `restricted`. Example of the `m.profile.privacy` event. @@ -81,83 +72,86 @@ your global profile for when you do not yet share a room with the subject. Like the user directory when starting a DM. `visibility` of `restricted` restricts who can look up a profile to users who are -in a room that has a pointer to this profile. -For a pointer to be valid said pointer must be issued by the creator of the profile if the profile is restricted. +in a room that has a `m.profile` value set to this profile. +For this value to be legal it must be sent by the creator of the profile. This means that invites can only set `public` profiles without causing the server to 404 the request. -To use a given profile you set a `m.profile` value in your `m.room.member` event for a given room. -The value of `m.profile` is the room ID of the profile you want to use in that room. - -`m.profile` events are limited only to all the normal event size rules but clients are allowed to enforce whatever -limits they find resonable on data that they will render when given this data. +`m.profile` events abide by normal event size rules but clients are allowed to enforce whatever +limits they find reasonable on data that they will render. -### Client-Server API Changes +### Using and Accessing Profiles -The contents of a profile are accessed via the following endpoints +To use a profile you set `m.profile` to the room ID of a profile room in your `m.room.member` event in that room.
- Get Profile Endpoint - -- **Endpoint**: `GET /_matrix/client/v1/profile/{roomID}` - - **Description**: Get a profile. If the request body contains a list of keys only those events will be returned. - Omit request body to fetch all profile information. - - **Query Param**: Use `auth_event` query parameter to point to what event grants you access to the profile. - - **Errors**: If the requesting user does not have access to the provided `auth_event` 403 the request. - If a specific state key has empty contents omit returning said profile field. - - **Response**: + Example membership event with profile set. ```json { - "key_name": "field_value" + "content": { + "avatar_url": "Avatar URL", + "displayname": "Cat", + "membership": "join", + "m.profile" : "!cats_public_profile:feline.support" + }, + "origin_server_ts": 2147483648000, + "sender": "@cat:cat:feline.support", + "state_key": "@cat:cat:feline.support", + "type": "m.room.member", + "event_id": "example_event_id", + "room_id": "example_room_id" } ```
-### Server-Server API Changes +To access a profile you issue a request to `GET /_matrix/client/v1/profile/{roomID}` and provide the following parameters. + +Query Parameter of `auth_event` pointing to a `m.room.member` that has a `m.profile` field that matches the profile +being requested. If the profile is public like in a use case where your presenting profile information before +a room is shared `auth_event` must to be omitted. -The federation endpoint `GET /_matrix/federation/v1/profile/{roomID}` will mirror the client-server -API endpoint in behaviour except that it also adds a query parameter of `requesting_user` where the mxid -of the requesting user is defined. This is so that the server can verify if the requesting user has -access to a event points to the given profile if its a `restricted` profile. +The user making the request must have history visibility for the `auth_event` -As this proposal is avoiding the use of peeking the validity of a profile can not be verified over -federation and therefore we have to just trust the server of the user. Therefore this API can only be called -against the server that the profile was created on for now. +A subset of the profile fields can be requested by putting an array of profile fields a request body. If omitted all +fields are returned. -A federated peeking MSC is free to propose an API that can be used to access this data with less restrictions. +To Access a profile over federation you use `GET /_matrix/federation/v1/profile/{roomID}`. -A profile with `m.federate` set to `false` in its creation event is not allowed to be requested over federation. +The result of a profile inquiry may be cached for a reasonable period of time not exceeding 24 hours. -The rules configured in the `m.room.server_acl` event are to be respected for all profile requests. This means that -if a server is ACL banned from a profile room said server is not allowed to request the contents of this profile. -This function exists so that users are able to -block servers that they want to not have profile access from having profile access. +The federation version of this endpoint mirrors its behaviour mostly with the client server API version of this endpoint. +The federation version of the endpoint adds the `requesting_user` query parameter. This parameter is required when +the `auth_event` parameter is present. Its used to indicate on whos behalf the request is made as this changes if +a profile lookup fails or succeeds, due to that the `requesting_user` must have history visibility for `auth_event`. + +The history visibility check is done from the perspective of the resident server for the profile owner. + +Profile rooms that have `m.federate` = `false` are not allowed to be requested over federation and `m.room.server_acl` +is to be honoured for all profile requests based on profile room. + +Any profile field that is empty is omitted from profile lookups. ### Limitations The completely freeform nature of this proposal raises Trust and Safety Concerns. To mitigate at least one of these concerns servers are completely welcome to run allow and deny lists on state keys for profiles. -Servers that wish to guarantee that no disallowed data exists in the room state of a profile are allowed to -under this proposal enforce strict access controls on what events can be sent into the profile room. -This is to ensure that the server can not loose control over the state by allowing remote users in for example. - Profiles have no size caps set in stone in this proposal as of version 1 of the proposal. This is seen as acceptable because rooms are currently also unbound and servers are happy with requests like /state on the matrix.org coc policy list. The policy list in question is of a decent size. ### Trust and Safety -To address the T&S question on a room level clients are supposed to display no profile what so ever for a user -if their membership event is redacted as this is the current status quo and this MSC does not wish to disrupt this. +To continue to allow for moderation of profiles that are not aligned with policy in a given room, this MSC +keeps the behaviour of that redacting someone's membership event stops profile information from rendering. -Homeserver administrators are liberally able to go in and modify users profiles to comply with server policy. +Homeserver administrators are welcome to redact or modify user profiles to comply with server policy, in accordance +with server policies. -Its preferred if homeserver admins redact the state events in question that they find disagrees with homeserver policy. +Its preferred if homeserver moderators / administrators redact state events that are not aligned with server policy. -The omit empty fields policy for the endpoint is to mitigate this specific T&S concern and privacy concern. Empty -state events should be hidden as they are empty for a reason. +The omit empty fields policy for the endpoint is to mitigate this specific T&S concern and privacy concern. ### Field Name Rules @@ -179,7 +173,7 @@ could define that the `m.tz / us.cloke.msc4175.tz` field it defines has a maximu ## Potential issues This MSC has the problem of that its adding freeform fields and attempting to guarantee wide ecosystem -support for all of them is well hard. But this challenge i think is warranted as this MSC represents +support for all of them is well hard. But this challenge I think is warranted as this MSC represents a faithful hopefully version of the vision that the community had for [MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769). @@ -226,7 +220,7 @@ MSC informed by Steam. They also have rich profile visibility settings and they not copying all of their settings in this proposal with the right use of this proposal you can achieve mostly similar results. -There is the concern that users can ACL ban the mods from their profile and this concern is lessened if moderators are +There is the concern that users can ACL ban the mods from their profile and this concern is lessened if moderators are informed of this situation and simply disallow such profiles in their rooms. The Problems related to that this MSC allows you to essentially ask to be vomited data at are hopefully explained @@ -244,7 +238,31 @@ While this proposal is unstable the following substitutions are to be made. `m.profile` room type becomes `support.feline.mscXXXX.profile` `m.profile` value in `m.room.member` becomes `support.feline.mscXXXX.profile.v1` +Please note that due to the lack of a somewhat stable API format the APIs are NOT recommended to be implemented currently. + +Contributions welcome to resolve this problem. + +`GET /_matrix/client/v1/profile/{roomID}` becomes `GET /_matrix/client/unstable/support.feline.mscXXXX.v1/profile/{roomID}` +`GET /_matrix/federation/v1/profile/{roomID}` becomes `GET /_matrix/federation/unstable/support.feline.msxXXXX.v1/profile/{roomID}` + ## Dependencies This MSC does not have any unstable dependencies known to the author but does build on the work in [MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769) + +## Acknowledgements + +This MSC exists to realise the vision that was set out in +[MSC1769](https://github.com/matrix-org/matrix-spec-proposals/pull/1769) +this vision has served to guide the ecosystem for a long time but its time to finally realise it. + +This proposal aims to provide a pathway to take us from the limitations of today that shaped the competing proposal +[MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133) to the future where we have fed peeking +fully working in the hopeful event that said future happens. + +A thanks has to be issued to everyone who gave feedback on +[MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133) +as this feedback has helped shape this competing proposal. +Also thanks to Tom for the proposal it self as it has inspired parts of this proposal. + +Thanks to Gnuxie for being the source of the peeking bypass idea as far as Cat remembers. From 7858ab70d7f496e3774917509e8f2b5cb61b7595 Mon Sep 17 00:00:00 2001 From: Catalan Lover Date: Thu, 26 Sep 2024 00:02:55 +0200 Subject: [PATCH 6/9] Integrate Review Feedback --- proposals/XXXX-profiles-as-rooms-v2.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/XXXX-profiles-as-rooms-v2.md b/proposals/XXXX-profiles-as-rooms-v2.md index 31f32082102..777f391cf81 100644 --- a/proposals/XXXX-profiles-as-rooms-v2.md +++ b/proposals/XXXX-profiles-as-rooms-v2.md @@ -28,7 +28,6 @@ To get around the fact that we do not have federated peeking yet this proposal w to simply ask the users homeserver about their profiles. This proposal supports per room profiles and viewing restricted profiles. -Restricted viewing is done via a check of is the person asking in a room where you are pointing to that profile. Public profiles without viewing restrictions are also considered valid as you want to be able to present a profile before you share a room if your privacy settings allow for this. @@ -113,8 +112,9 @@ a room is shared `auth_event` must to be omitted. The user making the request must have history visibility for the `auth_event` -A subset of the profile fields can be requested by putting an array of profile fields a request body. If omitted all -fields are returned. +A subset of the profile fields can be requested using the `filter` query parameter type being `string`. + +The response to a `GET /_matrix/client/v1/profile/{roomID}` is a set of Stripped state events responsive to the querry. To Access a profile over federation you use `GET /_matrix/federation/v1/profile/{roomID}`. From 95d4ad520ee0b80d89d19f6c54b52d26a0d782b1 Mon Sep 17 00:00:00 2001 From: Catalan Lover Date: Thu, 26 Sep 2024 00:27:09 +0200 Subject: [PATCH 7/9] Publish MSC --- proposals/XXXX-profiles-as-rooms-v2.md | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/proposals/XXXX-profiles-as-rooms-v2.md b/proposals/XXXX-profiles-as-rooms-v2.md index 777f391cf81..75bf43e5479 100644 --- a/proposals/XXXX-profiles-as-rooms-v2.md +++ b/proposals/XXXX-profiles-as-rooms-v2.md @@ -1,6 +1,6 @@ -# MSCXXXX: Profiles as Rooms v2 +# MSC4201: Profiles as Rooms v2 -- [MSCXXXX: Profiles as Rooms v2](#mscxxxx-profiles-as-rooms-v2) +- [MSC4201: Profiles as Rooms v2](#msc4201-profiles-as-rooms-v2) - [Introduction](#introduction) - [Proposal](#proposal) - [Profile Rooms](#profile-rooms) @@ -233,17 +233,13 @@ or in this Section are known to the author at this time. While this proposal is unstable the following substitutions are to be made. -`m.profile.privacy` becomes `support.feline.mscXXXX.profile.privacy.v1` -`m.profile` state event becomes `support.feline.mscXXXX.profile.v1` -`m.profile` room type becomes `support.feline.mscXXXX.profile` -`m.profile` value in `m.room.member` becomes `support.feline.mscXXXX.profile.v1` +`m.profile.privacy` becomes `support.feline.msc4201.profile.privacy.v1` +`m.profile` state event becomes `support.feline.msc4201.profile.v1` +`m.profile` room type becomes `support.feline.msc4201.profile` +`m.profile` value in `m.room.member` becomes `support.feline.msc4201.profile.v1` -Please note that due to the lack of a somewhat stable API format the APIs are NOT recommended to be implemented currently. - -Contributions welcome to resolve this problem. - -`GET /_matrix/client/v1/profile/{roomID}` becomes `GET /_matrix/client/unstable/support.feline.mscXXXX.v1/profile/{roomID}` -`GET /_matrix/federation/v1/profile/{roomID}` becomes `GET /_matrix/federation/unstable/support.feline.msxXXXX.v1/profile/{roomID}` +`GET /_matrix/client/v1/profile/{roomID}` becomes `GET /_matrix/client/unstable/support.feline.msc4201.v1/profile/{roomID}` +`GET /_matrix/federation/v1/profile/{roomID}` becomes `GET /_matrix/federation/unstable/support.feline.msc4201.v1/profile/{roomID}` ## Dependencies From 0b21bbc1d4fff3d3ad9aa3ba1af4913f5dac0fd8 Mon Sep 17 00:00:00 2001 From: Catalan Lover Date: Thu, 26 Sep 2024 00:28:51 +0200 Subject: [PATCH 8/9] Fix Spellchecker being displeased. --- proposals/XXXX-profiles-as-rooms-v2.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/XXXX-profiles-as-rooms-v2.md b/proposals/XXXX-profiles-as-rooms-v2.md index 75bf43e5479..d46744f8a41 100644 --- a/proposals/XXXX-profiles-as-rooms-v2.md +++ b/proposals/XXXX-profiles-as-rooms-v2.md @@ -114,7 +114,7 @@ The user making the request must have history visibility for the `auth_event` A subset of the profile fields can be requested using the `filter` query parameter type being `string`. -The response to a `GET /_matrix/client/v1/profile/{roomID}` is a set of Stripped state events responsive to the querry. +The response to a `GET /_matrix/client/v1/profile/{roomID}` is a set of Stripped state events responsive to the query. To Access a profile over federation you use `GET /_matrix/federation/v1/profile/{roomID}`. @@ -122,7 +122,7 @@ The result of a profile inquiry may be cached for a reasonable period of time no The federation version of this endpoint mirrors its behaviour mostly with the client server API version of this endpoint. The federation version of the endpoint adds the `requesting_user` query parameter. This parameter is required when -the `auth_event` parameter is present. Its used to indicate on whos behalf the request is made as this changes if +the `auth_event` parameter is present. Its used to indicate on whose behalf the request is made as this changes if a profile lookup fails or succeeds, due to that the `requesting_user` must have history visibility for `auth_event`. The history visibility check is done from the perspective of the resident server for the profile owner. From 27097aa690648e03a8a2cfae4829a9c510013cdd Mon Sep 17 00:00:00 2001 From: Catalan Lover Date: Thu, 26 Sep 2024 00:30:55 +0200 Subject: [PATCH 9/9] Rename MSC to MSC number. --- ...{XXXX-profiles-as-rooms-v2.md => 4201-profiles-as-rooms-v2.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename proposals/{XXXX-profiles-as-rooms-v2.md => 4201-profiles-as-rooms-v2.md} (100%) diff --git a/proposals/XXXX-profiles-as-rooms-v2.md b/proposals/4201-profiles-as-rooms-v2.md similarity index 100% rename from proposals/XXXX-profiles-as-rooms-v2.md rename to proposals/4201-profiles-as-rooms-v2.md