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:
  • WIP: 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

---

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.

[turt2live]

FCP checklist:

• Are appropriate implementation(s)
  specified in the MSC’s PR description?
• Are all MSCs that this MSC depends on already accepted?
• For each new endpoint that is introduced:
  • Have authentication requirements been specified?
  • Have rate-limiting requirements been specified?
  • Have guest access requirements been specified?
  • Are error responses specified?
    • Does each error case have a specified errcode (e.g. M_FORBIDDEN) and HTTP status code?
      • If a new errcode is introduced, is it clear that it is new?
• Will the MSC require a new room version, and if so, has that been made clear?
  • Is the reason for a new room version clearly stated? For example,
    modifying the set of redacted fields changes how event IDs are calculated,
    thus requiring a new room version.
• Are backwards-compatibility concerns appropriately addressed?
• Are the endpoint conventions honoured?
  • Do HTTP endpoints use_underscores_like_this?
  • Will the endpoint return unbounded data? If so, has pagination been considered?
  • If the endpoint utilises pagination, is it consistent with
    the appendices?
• An introduction exists and clearly outlines the problem being solved.
  Ideally, the first paragraph should be understandable by a non-technical audience.
• All outstanding threads are resolved
  • All feedback is incorporated into the proposal text itself, either as a fix or noted as an alternative
• While the exact sections do not need to be present,
  the details implied by the proposal template are covered. Namely:
  • Introduction
  • Proposal text
  • Potential issues
  • Alternatives
  • Dependencies
• Stable identifiers are used throughout the proposal, except for the unstable prefix section
  • Unstable prefixes consider the awkward accepted-but-not-merged state
  • Chosen unstable prefixes do not pollute any global namespace (use “org.matrix.mscXXXX”, not “org.matrix”).
• Changes have applicable Sign Off from all authors/editors/contributors
• There is a dedicated "Security Considerations" section which detail
  any possible attacks/vulnerabilities this proposal may introduce, even if this is "None.".
  See RFC3552 for things to think about,
  but in particular pay attention to the OWASP Top Ten.

[turt2live]

overall the MSC looks good - thanks for taking the time to update it! A few low-medium concerns for your consideration.

[turt2live]

@mscbot concern [High] Checklist is incomplete
@mscbot concern [Medium] Clarity on how servers can deny a value being set, regardless of capability

[tcpipuk]

This is an attempt to answer the authentication/rate-limiting/guest access requirements in the FCP checklist: f686090

Please post a review if any further clarification is required, thanks!

[turt2live]

@mscbot resolve [Medium] Clarity on how servers can deny a value being set, regardless of capability
@mscbot resolve [High] Checklist is incomplete

[richvdh]

A couple of minor comments, but overall, this looks great. I particularly like that you're keeping the initial proposal small and encouraging future extensions via future proposals.

I know a lot of time and effort has gone into putting this proposal together, and it shows. Thank you.

[richvdh]

Homeservers SHOULD NOT enforce namespaces

I feel like homeservers SHOULD enforce at least some of the requirements of the CNIG (key length, character set, starts with [a-z])?

I notice that an error is defined for M_KEY_TOO_LARGE which implies that there is some expectation here.

[tcpipuk]

Ah yes, the wording of this should be clearer... homeservers should not be checking whether the key uses a known namespace, but they must still enforce the grammar. I'll try to make this a bit more explicit.

[tcpipuk]

I've had a go at this - what do you think? 9b2918e

[tcpipuk]

Oh, I screwed up the line wrapping, so this should fix that: e00d2e9

[anoadragon453]

Very clear and easy to read proposal. Well done!

Only two minor comments below - the rest looks good to me!

[anoadragon453]

Could you add a case for M_MISSING_PARAM for if the client tries to set the profile field "foobar", yet neglects to include a "foobar" field in the PUT request body JSON?

I noticed this case was handled in the Synapse implementation, but clients will not be expecting it.

[clokep]

I copied that from the avatar URL profile endpoint, so probably is a spec bug that it was never documented?

[tcpipuk]

I'm happy to take this opportunity to document it now? 🙂

[clokep]

Sounds good! Was mostly implying it housing be controversial!

[anoadragon453]

When it comes time to write the spec PR, the author will be trying to match up error codes to each individual endpoint.

Is it expected that all status code/error code combinations here can be used for all Client-Server and Server-Server endpoints introduced in this MSC? If so, could you explicitly say so at the beginning of this section?

[tcpipuk]

My assumption was that the Server-Server endpoints would have identical errors to the current ones, as federation access is still read-only in this MSC.

I'm happy to try to make the Client-Server endpoints a bit clearer on which errors apply to each of them though!

I might not have time to work on this over the weekend as my schedule is pretty full, but I'll try to get time ASAP 🙂