MSC4440: Profile Biography via Global Profiles#4440
MSC4440: Profile Biography via Global Profiles#4440RoootTheFox wants to merge 2 commits intomatrix-org:mainfrom
Conversation
Signed-off-by: rooot <[email protected]>
tulir
added
proposal
There was a problem hiding this comment.
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
proposals/4440-profile-biography.md
Outdated
|
|
||
| ## Alternatives | ||
|
|
||
| None, really. Maybe linking a pastebin URL in your username? |
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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)
|
|
||
| None, really. Maybe linking a pastebin URL in your username? | ||
|
|
||
| ## Security considerations |
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.
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.
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.
- change format to the one specified by Extensible Events (MSC1767) - clarify potential security/T&S/moderation concerns - remove dependency as it is already in the spec - add potential "alternative" in the form of setting a presense status message Signed-off-by: rooot <[email protected]>
### Description This pull request adds support for saving and reading user bios in the MSC4440 format, improving compatibility with the MSC4440 specification for Matrix user profiles. The changes ensure that bios are now stored and retrieved in both the legacy and MSC4440-compliant formats, and introduce new types to support this functionality. #### MSC4440 Bio Compatibility - User bios are now saved in the MSC4440 format (`gay.fomx.biography`) in addition to existing formats, ensuring forward compatibility with the MSC4440 spec. When saving, both HTML and plain text representations are stored. - The user profile normalization logic now reads bios from the MSC4440 field first, falling back to legacy fields if necessary. - The fields handled by the normalization function are updated to include the MSC4440 bio key. #### Type and Import Updates - New types `MSC1767Text` and `MSC4440Bio` are introduced to represent the MSC4440 bio format, and relevant imports are updated throughout the codebase. implements matrix-org/matrix-spec-proposals#4440 #### Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ### Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings ### AI disclosure: - [ ] Partially AI assisted (clarify which code was AI assisted and briefly explain what it does). - [ ] Fully AI generated (explain what all the generated code does in moderate detail). No AI was used in the creation of this PR
6 participants
Rendered
Implementations: