Skip to content
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
62 changes: 62 additions & 0 deletions proposals/4440-profile-biography.md
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

  • Client (modifying bio)
  • Client (rendering bio)

Since there might be moderation concerns (the reason why MSC4133 didn't define freeform input fields):

  • Review from trust & safety

Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
# 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": {
"body": "hello world!\n\ninterests:\n- programming\n- matrix\n- sleeping\n- petting cats"
}
}
```

with HTML formatting:
```json
{
"m.biography": {
"body": "hello world!\n\ninterests:\n- programming\n- matrix\n- sleeping\n- petting cats",
"format": "org.matrix.custom.html",
"formatted_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\" />"
}
}
```

The `body` field should hold a plaintext representation of the users' biography, similar to room messages.
Clients can optionally set the `formatted_body` field to an HTML-formatted representation of the body in the
same format as [formatted messages](https://spec.matrix.org/v1.17/client-server-api/#mroommessage-msgtypes),
in which case the format field has to be set to `org.matrix.custom.html`.
When rendering a user's biography, the `formatted_body` should be preferred if set, but clients are free to
render the plaintext representation in `body` instead.

## Potential issues

Unsure?

## Alternatives

None, really. Maybe linking a pastebin URL in your username?
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean alternatives exist considering proposals like #4201 exists and its all about an alternative way to get this done.

So clearly i would say that this should be updated to address the list of alternatives and why this proposal should be considered instead of other approaches.

I will say that 4201 needs work to be considered (As in its current state as a MSC is not good enough. It was a rushjob of a MSC tbh and it needs work if it ever wants to be viable for FCP assuming implementations existed.)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i feel like #4201 is more of an alternative to #4133 instead of this proposal specifically; i do get your point though.
when #4201 is in-spec, this proposal could be reimplemented on top of that, though i feel like it's much better to base this proposal on top of existing infrastructure which is in-spec (in this case, #4133, which other MSCs such as #4247 also base themselves on)


## Security considerations
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

@snoweuph snoweuph Mar 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

## Unstable prefix

Clients implementing this MSC early may use the profile key `gay.fomx.biography`.

## Dependencies

This MSC builds on [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133).
Loading