MSC4201: Profiles as Rooms v2 #4201
Conversation
tulir
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Server
- Client
| 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. |
There was a problem hiding this comment.
This fails to answer "Why?" -- it being a desire isn't enough. Why is this helpful?
| 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. |
There was a problem hiding this comment.
Please link to the spec for merged features.
| 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 query. |
There was a problem hiding this comment.
I assume this is something like filter is the state keys of events in the profile room? This isn't clear though. The response is the stripped m.profile state events?
There was a problem hiding this comment.
Yup you filter based on the state keys you care about and the response is stripped m.profile events responsive to the query.
| 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. |
There was a problem hiding this comment.
I don't really see how this helps T&S concerns TBH. Why is it easier to redact events in a room than to update a profile?
There was a problem hiding this comment.
I, as a user on homeserver A, cannot update the profile of a user on homeserver B.
| 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 |
There was a problem hiding this comment.
Having all historical data via state events sounds like a big privacy violation that would be surprising to users?
| 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. |
There was a problem hiding this comment.
What happens if other events are sent in this room? I'm confused at who is expected to be joined to this room.
There was a problem hiding this comment.
Its not clarified properly but the parties expected to be present in ones profile room is traditionally only the user them self and optionally bots that can update their profile if that isnt handled via scoped access tokens.
There was a problem hiding this comment.
Its not clarified properly but the parties expected to be present in ones profile room is traditionally only the user them self and optionally bots that can update their profile if that isnt handled via scoped access tokens.
Without reading this comment, it's not clear that the room should be joined only by the user and bots. Maybe that should be explicitly specified in the MSC?
| These rooms contain `m.profile` state events to store profile data as the state key determines | ||
| the profile field this data is for. |
There was a problem hiding this comment.
An example of this event would be useful!
|
|
||
| `visibility` of `restricted` restricts who can look up a profile to users who are | ||
| 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. |
There was a problem hiding this comment.
I was confused that this is referring to the sender of the m.room.member as opposed to in the m.profile.privacy event.
There was a problem hiding this comment.
Yes this is a bit confusing i can agree.
The intent is essentially that only the profile owner can create valid pointers for non public profiles.
Rendered
Signed-off-by: Catalan Lover catalanlover@protonmail.com
Disclosures: As it has been requested in #matrix-spec:matrix.org the following disclosures in line with matrix-org/matrix-spec/issues/1700 are made. Im writing this MSC as a foss contributor independently of my work for The Draupnir Project nor the Community Moderation Effort.