MSC4133: Extending User Profile API with Key:Value Pairs

[tcpipuk]

Rendered

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

[cvwright]

Why put the new stuff under extended? Why not make the entire profile a key:value store?

This way just makes things more complicated. Once the new fields become established, no one will remember which fields were the historical ones and which ones are the "new" extended ones, and it will be a source of confusion.

[tcpipuk]

My main concern was that this is user-entered data, so it'd be safer to keep the keys in a special object separate to the core profile information.

We also have a special API for "extended" fields because there's already separate ones for avatar and display name - making the fields look like established ones won't change those API endpoints immediately.

My hope was that this would get data structures added so as fields enter clients and become more common/standardised, future MSCs can then pick profile info that should be "promoted" to having state events, per-room data, etc.

[tcpipuk]

(I can certainly clarify these bits, but the reason the /extended API route returns an object containing the "extended" key is that it adds the ability for this to be improved in the future as the community desires)

[cvwright]

errr... Actually according to @clokep's comment above, it looks like the profile is already supposed to be a generic k:v store?

[tcpipuk]

There's no endpoint to update it though - it seems to be suggesting fields that the homeserver admin's authentication system would publish into the user profile.

This MSC is creating the ability for users to add their own custom metadata to their profiles.

[tulir]

I think a new key makes sense with the assumption that it doesn't modify the m.room.member event. There could be a future MSC to allow custom top-level fields that do go into member events. If this MSC used top-level fields for non-member-event stuff, it would cause conflicts.

[cvwright]

There's no endpoint to update it though

Maybe this is an opportunity to make that change?

Personally I would love to see a /_matrix/client/v3/profile/{userId}/{key} replace the existing /displayname and /avatar_url endpoints.

[clokep]

Personally I would love to see a /_matrix/client/v3/profile/{userId}/{key} replace the existing /displayname and /avatar_url endpoints.

This was also my initial thought. 👍

The extended field seems unnecessary. Servers can know that they only copy displayname and avatar_url into m.room.member events. Guidance can be that clients and servers should ignore unknown keys (with the caveat that servers should pass them through to clients).

[tcpipuk]

Yeah, my main concern was about abuse, or complicating clients/timelines. People updating avatars and names is a big deal, but updating your work cellphone or your next vacation day is probably not so much.

I do think it would make sense for an MSC to follow that expands the array of per-room fields that can be copied to member events, but the intention of this account-wide set of freetext fields is to be as un-intrusive as possible for users until they actively visit a profile to see what is there.

[Half-Shot]

I can see the merit in the extended field / API paths, but I think it's probably creating more overhead than necessary. I see the profile logic here and the membership updating logic as separate issues and I don't think the object structure here necessarily has to line up with the membership event.

As @clokep says, the spec already specifies that only two fields should be copied to the event, so servers shouldn't be blindly copying all the fields.

My feeling is rather it's enough to have the profile endpoints on an unstable path during the MSC process and see if the theoretical problems with abuse or complication actually manifests? I've written some thoughts on abuse in https://github.com/matrix-org/matrix-spec-proposals/pull/4133/files#r1576137660 which I think might also be more relevant here.

[turt2live]

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

[tcpipuk]

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

Sorry, did I do it right?

[turt2live]

Looks great, thanks!

[tcpipuk]

Thanks to feedback from Travis in #matrix-spec:matrix.org, I've clarified my intention that this MSC is freetext for both keys and values - I'd love for the community to be inspired and have certain fields "promoted" to full per-room member events, but this is intended to keep timelines clean while allowing users to communicate small pieces of information about themselves in their profile that may be interesting to other users.

[Half-Shot]

For those of us with extremely long memories of this feature request, a semi-alternative is discussed in #1769.

I'm not actually sure the two things here are incompatible, since MSC1769 is more about the storage mechanism (rooms) rather than the API surface.

Anyway, I think it's worth mentioning where the thinking went before.

[tcpipuk]

Indeed, it was talking about profile rooms that led me to propose this.

Profile rooms are considered dependent on a number of other MSCs, including fast joins and peeking, and that's taken years so far.

The objective of this MSC is to offer a far more basic level of service (that would be very simple to implement in servers and clients) to allow people to start designing UI, bots, and other features, that could fairly easily be migrated to use profile rooms later should that proposal finally make it into stable.

I also suspect a number of servers will ultimately disable/restrict profile rooms, but may allow this feature to pass (even just with a whitelist of keys/values) so offering both options could be a way to offer a "Extendable Profiles Lite" even once profile rooms are live.

I'm certainly happy to explain some of this background - I wasn't sure if adding the extra detail would be distracting!

[Half-Shot]

Yep, I agree. This MSC should happen first at any rate. I'd probably put in a mention to say that these approaches are compatible, should anyone be wondering why we're going for one rather than the other.

[Half-Shot]

We may want to put a "sensible" limit on the size and number of keys on a profile, to avoid potential issues.

EDIT: I suppose that may be difficult since nested objects are a thing. Maybe also a depth limit..

[tcpipuk]

Very good point. Perhaps a maximum total number of keys of any depth, but also a maximum depth for sanity?

[Half-Shot]

Thinking about this, maybe we just do what we do for events and cap this to 64KiB overall https://spec.matrix.org/v1.10/client-server-api/#size-limits. Whether or not we still want a depth limit, I'm not sure.