MSC4208: Adding User-Defined Custom Fields to User Global Profiles

[tcpipuk]

Rendered

Signed-off-by: Tom Foster [email protected]

---

Known Implementations:

• Clients:
• Servers:

[tcpipuk]

This needs a little work done to it. I've exported the custom field requirements from MSC4133 and am updating this to reflect that it is a new/separate MSC.

[jimmackenzie]

This section needs beefing up considerably - including both client and server considerations for preventing the creation of obviously harmful custom fields, mechanisms for identifying harmful user generated content in these fields, and client controls for choosing whether to display all, some or none custom fields, with sensible defaults.

I'll aim to swing back with suggestions - happy to have conversations to help articulate the concerns more too!

[tcpipuk]

I totally agree! I've had a go at listing out some talking points (a22b9fc) but would definitely appreciate suggestions on what the Foundation would like to see enshrined in an MSC like this.

New T&S section is here if you want a more readable copy!
https://github.com/tcpipuk/matrix-spec-proposals/blob/custom-fields/proposals/4208-user-defined-profile-fields.md#trust--safety-considerations

[tcpipuk]

My expectations at this point for this MSC:

The core API endpoints are defined in #4133 but it's intentionally tightly focused - it doesn't define individual fields because some of them require a much wider conversation. Sometimes it's easy (like #4175) because the content can be standardised and validated, but we need a dependable way for people to know freetext content can be entered without raising moderation concerns, and this MSC is a thorough roadtest of that.

As part of the discussion on this MSC, I'm expecting to identify dependencies (either existing MSCs like #4202 or new ones) that will block parts of this MSC until they're in place, but by discussing the end-to-end user/admin/T&S experience of freetext fields in this MSC, we can coordinate these problems and ensure the full journey is covered before the functionality is used by the wider community.

I'd recommend other MSCs for specific freetext fields also reference this one, as we can then identify the multitude of uses for string profile fields, ensure they're accounted for in this proposal, and therefore relieve the same burden from other MSCs,