MSC4133: Extending User Profile API with Key:Value Pairs

[tcpipuk]

Rendered

Signed-off-by: Tom Foster tom@tcpip.uk

---

Known Implementations:

• Clients:
  • Complete: Add timezone to user profile element-hq/matrix-react-sdk#20
  • Complete: Add timezones and pronouns tulir/gomuks#574
• Servers:
  • Complete: Implement MSC4133 to support custom profile fields. element-hq/synapse#17488
  • Complete: Implement MSC4133 and MSC4175, some bug fixes and features, drop target CPU for aarch64 to Cortex-A53, bump to Rust 1.81.0, RocksDB v9.6.1, and Nix build fixes girlbossceo/conduwuit#571
• SDKs:
  • Complete: MSC4133 - Extended profiles matrix-js-sdk#4391
  • Complete: Implement arbitrary fields for RespUserProfile mautrix/go#337

---

FCP tickyboxes

MSC checklist

[turt2live]

@tcpipuk when you get a chance, please sign off on your changes to allow the MSC to eventually be eligible for acceptance.

[turt2live]

Looks great, thanks!

[andrewzhurov]

Seems we discuss here a key-value CRDT, as keys would need to be updated over time. Personally, I'm all in favor.
With no regard be those events a part of a (messaging) Room or be in its own Profile Room (#1769) (which would be neat),
we need a mechanism to get the latest key-value pairs.

Matrix Event Graph is isomorphic to Merkle-CRDT that powers OrbitDB (key-value DB is one of the supported CRDT).
Taking an inspiration from how key-value CRDT works may be of help to spec it for those Servers wishing to opt-in.

[anoadragon453]

@mscbot concern "the MSC does not provide an example for clients of when they should hide abusive custom profile fields within the context of a room"

[anoadragon453]

@mscbot resolve "the MSC does not provide an example for clients of when they should hide abusive custom profile fields within the context of a room"

as the suggestion in #4133 (comment) was accepted.

(This is mostly symbolic - I don't think the bot actually picked up the concern during FCP.)

[turt2live]

The SCT would like to take recent comments into consideration as part of the FCP call for this MSC, and is pausing FCP for the moment while that consideration happens.

Our process is that a concern raised during FCP prevents the FCP from finishing, but our bot doesn't understand that and may say that the FCP is finished over the weekend. If this happens, it's untrue and we'll manually correct the state to be in FCP when we're back at a terminal.

@mscbot concern Feedback during FCP needs consideration.

[richvdh]

The final comment period, with a disposition to merge, as per the review above, is now complete.

No it isn't

[turt2live]

I'm not sure how the bot will respond to this, but the SCT is resolving the outstanding concern on addressing the recent feedback. Under normal process, this would cause FCP to finish immediately, however it feels valuable for this MSC to have an opportunity for final thoughts to be raised.

FCP will resume until 15:00 UTC on Friday, January 31st, 2025.

@mscbot resolve Feedback during FCP needs consideration.

[turt2live]

The final comment period, with a disposition to merge, as per the review above, is now complete.

No it isn't

Now it is