MSC4133: Extending User Profile API with Key:Value Pairs #4133
Conversation
tcpipuk
changed the title
turt2live
added
proposal
This comment was marked as resolved.
This comment was marked as resolved.
|
Looks great, thanks! |
|
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. |
|
Seems we discuss here a key-value CRDT, as keys would need to be updated over time. Personally, I'm all in favor. Matrix Event Graph is isomorphic to Merkle-CRDT that powers OrbitDB (key-value DB is one of the supported CRDT). |
Co-authored-by: Tulir Asokan <tulir@maunium.net>
| The existing fields, `avatar_url` and `displayname`, will continue to trigger state events in each | ||
| room. These fields are replicated per-room via member events. Custom fields, however, will **not** | ||
| trigger state events in rooms. They will exist solely at the global level and are intended for | ||
| storing metadata about the user that does not need to be replicated in each room. |
There was a problem hiding this comment.
I would love to see the same semantics here as in MSC4069, where a client can inhibit updating the profile info in rooms.
There was a problem hiding this comment.
(In addition, this would also allow users to override these profile values per room, say one's exploring their identity and wants to try different pronouns etc. etc. in a room with trusted friends, besides other use cases)
There was a problem hiding this comment.
There was a problem hiding this comment.
(it's worth noting this MSC doesn't add any new fields that are published per-room in member events, this MSC exists solely to add fields to the user's public profile at an account-wide level)
| ```json | ||
| { | ||
| "displayname": "Alice Wonderland" | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Wouldn't it make sense for the key to be value instead of the field's name?
This would avoid potential future expansion clashing with existing keys (eg. a privacy field, rooms, etc. etc.)
There was a problem hiding this comment.
I'd far rather we maximise compatibility with current clients than a breaking change that requires all clients to change to update basic fields like name/picture.
The only way we could do that at the moment would be to add workarounds/exceptions for displayname and avatar_url which seems like a backward step when this MSC aims to offer a clean way to expand the current set of profile fields.
There's no reason this couldn't change in a future/extra MSC, which could investigate how extra metadata would be treated, but it could also just as easily add metadata keys (like "privacy" or "rooms" keys) while communicating the actual value under the name of the key.
I can imagine that being quite a contentious debate that could hold the MSC up for a while, when this one's main purpose is to get some basic profile field functionality out quickly while we wait for more advanced profile functionality (like "profile rooms") to be ironed out.
Rendered
Signed-off-by: Tom Foster tom@tcpip.uk