MSC4440: Profile Biography via Global Profiles #4440
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,69 @@ | ||
| # MSC4440: Profile Biography via Global Profiles | ||
|
|
||
| A lot of users, especially those switching to Matrix from other platform (e.g. Discord) are finding Matrix | ||
| lacking for not providing a way to write information about themselves, e.g. their interests, and having | ||
| others be able to view that. Several clients already have their own, client-specific implementations of a | ||
| biography field via extended global profiles, creating a split in the ecosystem. | ||
| To bring back standardization, this proposal defines a standardized biography field on top of [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). | ||
|
|
||
| ## Proposal | ||
|
|
||
| Profiles may have an optional `m.biography` field as object. These fields can be fetched through the [profile API endpoints](https://spec.matrix.org/unstable/client-server-api/#profiles). | ||
| Clients should display the biography of a user in their respective user popup/profile view UI. | ||
|
|
||
| ### Examples | ||
|
|
||
| Plaintext only: | ||
| ```json | ||
| { | ||
| "m.biography": { | ||
| "m.text": [ | ||
| { "body": "hello world!\n\ninterests:\n- programming\n- matrix\n- sleeping\n- petting cats" } | ||
| ] | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| with HTML formatting: | ||
| ```json | ||
| { | ||
| "m.biography": { | ||
| "m.text": [ | ||
| { "body": "hello world!<br/><br/>interests:<br/><ul data-md=\"-\"><li><p>programming</p></li><li><p>matrix</p></li><li><p>sleeping</p></li><li><p>petting cats</p></li></ul><br/><img data-mx-emoticon src=\"mxc://fomx.gay/ICgRWFY6HWvMVVrHRqr7MYMLiTCgWxpl\" alt=\"bwaa\" title=\"bwaa\" height=\"32\" />", "mimetype": "text/html" }, | ||
| { "body": "hello world!\n\ninterests:\n- programming\n- matrix\n- sleeping\n- petting cats" } | ||
| ] | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| The `m.biography` object should hold an ordered `m.text` array as defined by [MSC1767](https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/msc1767/proposals/1767-extensible-events.md) | ||
| / extensible events. | ||
| Clients may wish to add formatting to their biography in forms of an HTML-formatted representation of the | ||
| body in the same format as [formatted messages](https://spec.matrix.org/v1.18/client-server-api/#mroommessage-msgtypes), | ||
| in which case clients should prefer rendering that one instead. | ||
|
|
||
| ## Potential issues | ||
|
|
||
| Unsure? | ||
|
|
||
| ## Alternatives | ||
|
|
||
| Maybe linking a pastebin URL in your username? | ||
| Potentially setting an m.presence status_msg could work too, though that is much more limited. | ||
|
|
||
| ## Security considerations | ||
|
Contributor
There was a problem hiding this comment. I would say that the sizable Trust and Saftey considerations that need to be made should belong here or in a dedicated section. Because malicious actors setting large info is the least of the concerns. I would be concerned with all the various types of harm that will be put into these bios because you need only look at Discord, Steam and various videogames to know people will abuse this. A system like this needs serious design considerations for how to allow moderators to handle it. This is why the MSC that added the Extended global profiles in the first place had to stay away from this as its survival as a proposal was essentially made possible by postponing this question to this MSC. There was a problem hiding this comment.
Isn't that a general moderation concern, you can have about most things in matrix? In the sense of moderation, this doesn't really differ from profile pictures, which can hold bad content like CSAM. As far as I understand matrix, the moderation, is always up to instance owners and room administrators, otherwise you would need to centralize. In that sense, the instance trust system also plays into this general idea of moderation and keeping safe spaces. For example, a homeserver could block all profile pictures and descriptions from untrusted instances.
Contributor
There was a problem hiding this comment. Room administrators have absolutely no possible say under this proposal is an example of a concern because it builds on a proposal that is global profile only scoped not per room configurable. There was a problem hiding this comment. Room Administrators, can always ban/kick people, that have things that aren't wanted in the space, and can report to the homeserver administrators. So no, they don't have a say in this proposal directly, but the general moderation flow still applies, that's what I wanted to point at. It's basicly the same on Discord if you think about it, where Guild Admins can ban people that have stuff they don't want on their Guild, and report illegal stuff to discord. |
||
|
|
||
| - Malicious actors could set an unreasonably long bio, potentially lagging or even crashing clients, if length | ||
| stays unlimited. | ||
| - Additional T&S concerns, e.g. moderation and when clients should (not) render a users biography. | ||
| One possible consideration could be disallowing clients from rendering a biography once a users' membership | ||
| event has been redacted or they've been banned from the current room, while not sharing further rooms with | ||
| the viewer. This approach would be similar to Discord in terms of UX. | ||
|
|
||
| ## Unstable prefix | ||
|
|
||
| Clients implementing this MSC early may use the profile key `gay.fomx.biography`. | ||
|
|
||
| ## Dependencies | ||
|
|
||
| None. | ||
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:
Since there might be moderation concerns (the reason why MSC4133 didn't define freeform input fields):