MSC3189: Per-room/per-space profiles #3189
Conversation
robintown
changed the title
Signed-off-by: Robin Townsend <[email protected]>
robintown
force-pushed
the
room-space-profiles
branch
from
b2f959e to
4fd6f1a
Compare
turt2live
added
client-server
|
First MSC, eager to see how this goes! :) |
Signed-off-by: Robin Townsend <[email protected]>
Signed-off-by: Robin Townsend <[email protected]>
Signed-off-by: Robin Townsend <[email protected]>
Signed-off-by: Robin Townsend <[email protected]>
Signed-off-by: Robin Townsend <[email protected]>
| rooms are joined, added to spaces, etc. If desired, servers could be changed to | ||
| automate some of this behavior in the future, though arguably this should be | ||
| left to clients, since they have more context for e.g. which parent space the | ||
| user was viewing a room from when they joined it. |
There was a problem hiding this comment.
Leaving it to clients makes sense when joining initially, but when updating my name/avatar it is left to the sever. My understanding is that this is to save the client from needing to send hundreds or thousands of m.room.member events. It seems that since the display name and avatar that you use in a room transcends clients it probably makes sense to have server support here to ensure that consistent policies can be applied.
To be honest the multi-space room issue makes me uneasy. I would expect that setting my avatar in two spaces would have the same result irrespective of which order I performed the updates. I think that anything else is an unfortunate behaviour and we should try really hard to avoid it.
There was a problem hiding this comment.
Thanks for the feedback, now that I've thought it over I think I do actually want to handle these concerns in a more explicit manner.
I still believe that having one actual profile per room as part of m.room.member state is the way to go, given this "just works" for clients that don't care about scoped profiles, and because users could be very confused if it looks like different people are talking depending on which parent space they view a room from.
However servers could certainly do more to acknowledge conflicts when they exist, by keeping explicit track of what overrides exist and what their scopes are, as you suggest. This would also very likely be necessary for proper application of inheritance policies, which I'll try to integrate into this proposal as it does seem pretty important for UX.
Will mark this as a draft until I can make the proper revisions.
There was a problem hiding this comment.
Thanks. I agree that putting the profile in the room makes sense. I don't think it is the only option but I think it is quite viable.
I think the key is fixing the "update" procedure. I can imagine some simple solutions such as the user has a list of profiles and where they apply. The order of the list can indicate priority and resolve conflicts. This order can potentially be generated explicitly but there is the option to adjust it when necessary. Fancy clients could warn you when setting a per-space avatar will update a room using a non-default avatar and ask you to resolve. This is a quick sketch but I think there are a number of options.
There was a problem hiding this comment.
The update procedure should now be more in line with what you're asking for, and I've added server support for inheriting on joins. This piece of feedback still stands:
I would expect that setting my avatar in two spaces would have the same result irrespective of which order I performed the updates.
…though I'm personally not sure how much value there is in solving it
| `boolean` is added to the `PUT /_matrix/client/r0/profile/{userId}/avatar_url` | ||
| and `PUT /_matrix/client/r0/profile/{userId}/displayname` endpoints. | ||
|
|
||
| If `force` is `true`, the profile change is propagated to all of the user's |
There was a problem hiding this comment.
Thinking about this further, I realised that we may be doubling down on what's effectively a major design flaw in Matrix today: that setting a profile scales O(N) with the number of rooms you are in. For instance, I just saw someone take 3 minutes to change their displayname because they were in a few hundred rooms :( - see also https://github.com/matrix-org/matrix-doc/issues/3194 and matrix-org/synapse#1297
I wonder if we should fix this first (and then make it support per-room/space semantics at the same time) rather than further entrenching the current misdesign. This could also be interesting in terms of simplifying lazy loading, as currently the main reason to LL membership events at all is so the timeline has the profile details to render their messages correctly.
One slightly crazy solution could be to switch to portable identities (a la MSC #2787 or MSC #1228), where each user has a different user ID in every room. Then, each per-room user ID could legitimately publish on their extensible profile (MSC #1769) a pointer to their displayname/avatar, and we never have to set these per room at all.
A simpler idea (which doesn't improve LL, and is more aligned with this specific MSC) would be to have the membership events reference a profile room for the profile data rather than a literal displayname/avatar. You could point it to whatever persona's profile room you like, and then by changing the profile there, it'd propagate everywhere. You could avoid impersonation by having the personae profile room say which mxid the personae is intended for. For instance, my m.room.member event could have an m.profile: !ara4npr0fil3:matrix.org, and that room could have a state event of m.displayname: ara4n. This then gives us per-space profiles fairly easily, as it's just up to the client to select the right personae when participating in a space. However, it depends entirely on MSC #1769 and peeking (#2753 and #2444) working efficiently and nicely so that clients can calculate the right profile. Also, the act of switching persona (as opposed to renaming a persona) would still be O(N) with number of rooms affected.
I don't particularly want to block this MSC on #1769 (let alone #2787), but wanted to raise this concern for completeness. If #1769 ends up ready sooner than later, I think be better to skip forward to proper personae extensible profiles rather than bodging the O(N) behaviour further.
There was a problem hiding this comment.
I think doing this based on profile rooms/identities with #1769 would be very nice. As someone who's very affected by the problem you mentioned earlier (~1300 rooms, changing avatars/display names is tremendously painful). Entrenching the current misdesign (as you put it) would be something I wouldn't be very comfortable with.
A sidenote on that though: Currently we have a specific avatar and display name for each message: When we link a profile room instead, we do loose that information, because it's not in the state for that specific information anymore, right? I don't think that's a bad thing, just something we need to consider.
Last but not least: would such a change require a room version bump? The format of the m.room.member event changing doesn't really sound like a good idea to me without a room version bump, if only for the reason that we don't mix-and-match the two different variant inside one room.
There was a problem hiding this comment.
Historical profile values could be achieved by specifying timestamp ranges in the extensible profile room - ie "this persona was called Bob from 2003-2006 and then B0b from 2006-2007".
Not sure this would technically need a new room version, as it doesn't change federation and it could still be backwards compatible - but you'd need a way to tell clients that the new profiles are in use.
For this to work nicely in practice we'd need to right ensure v3 sync can lazyload the profile data without the client having to explicitly peek into all the relevant profile rooms.
(also, portable accounts are completely orthogonal to this problem, in retrospect)
There was a problem hiding this comment.
While reading this a thought came to mind, you could sort of half way house this, by allowing profile info in rooms to reference another room. The obvious use of this is the profiles as rooms idea discussed here, but alternatively you could instead reference the space room and just inherit your profile info in the m.room.member event in there?
There was a problem hiding this comment.
@Cadair That was the thought I was playing with initially for how to improve this MSC. Though I quite liked it and was rewriting this MSC around that idea, it would preserve the O(n)-ness which I agree is a major flaw. Given that this is probably the right time to fix it being O(n), but #1769 is not quite ready, I'm not exactly sure where to go from here, as this pretty much comes down to priorities… The prospect of having native support for a #1769 solution in v3 /sync is encouraging though.
On the other hand, migrating from a system of manual propagation to a persona-room-based solution at a later date could be simple, I think? As long as both have a concept of profile scope and inheritance (which both would as I currently envision them) and the CS endpoints would look the same, I believe this would make persona rooms a natural upgrade path for when we do want to add extensible profile data and O(1) updates. @ara4n Thoughts on this course of action?
|
One thing I'm curious about is addressing how to set your profile data before joining a room. Based on the client behaviour I've seen so far, you can only change it after you've joined a room, and I believe this proposal doesn't alter that. If I understand how it interacts with Spaces correctly, it would mostly "automate" altering the A consequence of that is that my global nickname and avatar leak into every room I join and can be observed before it gets altered. This limits the usefulness of per room/space profile data a lot when it comes to separating identities, especially as it relates to the avatar image. |
I've actually decided that I need to rework this MSC to also automate the inheritance of profile data on joins and other actions (hence the draft label), so this should no longer be an issue.
Presumably your global profile is something that is known and intended to be public, since anyone can look it up if they know your MXID. Though when I rework this MSC, I will definitely make sure to carefully consider privacy issues that could stem from inheriting per-space profiles without any action from the user. |
IIUC this is a client issue. The client is the one that sends your profile. It is just that currently all clients send your global "profile" by default. However I'm not sure how it works for invites. |
This completely reworks MSC3189. Signed-off-by: Robin Townsend <[email protected]>
robintown
changed the title
|
I just pushed a reworked version which hopefully resolves most concerns about room/space profiles not being first-class, so I'd be very grateful to get feedback on this again. The new solution still scales O(n) with the number of rooms a profile change affects, though it is laid out in a way that should hopefully allow "upgrading" to O(1) updates with persona rooms in the future if desired, thereby separating concerns. |
| GET /_matrix/client/r0/profile/@me:example.org?scope=!space1:example.org | ||
|
|
||
| { | ||
| "inherits_from": "global", |
There was a problem hiding this comment.
Instead of a magic string "global" should we just use null to specify the global profile? This also has nice symmetry with omitting the scope URL param.
There was a problem hiding this comment.
Possibly, though I personally like having a self-explanatory keyword, and would like to avoid situations where undefined and null have not-so-subtle differences in meaning.
| |to `inherits_from` C|All children of A that inherited from B recursively changed to inherit from C|All children of A that inherited from A recursively changed to inherit from C| | ||
| |to profile root|All children of A that inherited from B recursively changed to inherit from A|No change in inheritance| | ||
|
|
||
| ### <a id="inheritance-restrictions"/>Inheritance restrictions |
There was a problem hiding this comment.
This is unfortunate. Why can't I create any random room to be my "alter ego" and configure arbitrary rooms to inherit from it?
There was a problem hiding this comment.
The intent of tying profile data to the space hierarchy is to avoid confusing users by introducing yet another perspective to organize one's rooms and spaces from. Also, I feel it would be weird to allow sibling rooms on otherwise equal footing to be able to inherit from each other - thus I believe that putting profile data in spaces is the most practical and user friendly option, given that users will generally already have rooms grouped together in a space when they want them to share profiles.
There was a problem hiding this comment.
But I feel that this is leaving common use cases on the table. What if I have two profiles I use often and just want to pick one for each room? It seems weird that I can't do this if they don't align with spaces I am in.
I feel it would be weird to allow sibling rooms on otherwise equal footing to be able to inherit from each other
I don't think there is anything preventing cycles in spaces so while it may be "weird" it isn't actually avoiding any complexity in the algorithm. I don't think this is enough of a reason to deny it.
| above inheritance conditions are upheld. For these reasons, servers implementing | ||
| per-room/per-space profiles must apply the following rules: | ||
|
|
||
| - When the user joins a space/room, perform a breadth-first search for an ancestor space that is a profile root, by following `m.space.child` links backwards through spaces the user has joined. Break any ties by selecting the first in a lexicographic ordering of room IDs, and then set the joined space/room to inherit from this profile root, or the global profile if none is found. This profile data should go immediately into the initial `join` state, rather than being updated after the join is complete. |
There was a problem hiding this comment.
If I understand the algorithm correctly it may prefer my global profile over a custom profile because the parent that was lexicographically first didn't have a custom profile set. Does it make more sense to say "The custom profile of the nearest parent with a custom profile (ties broken lexicographically). Falling back to the global profile if no parent has a custom profile set). I don't think that "nearest parent" is a perfect choice but it seems reasonable. The important part is that I think we should always prefer a custom profile in any parent over the global.
Furthermore while the auto-guess algorithm makes sense to have it should really be user choice. For example Element has a screen with some room info and a "Join" button. It would make sense to also have an indicator of what profile will be used and the option to select a different one. However one complication is that the client may not know which spaces a room is in until they join.
There was a problem hiding this comment.
Does it make more sense to say "The custom profile of the nearest parent with a custom profile (ties broken lexicographically).
Yes, this is essentially what I mean. The global profile is intended to be a last resort, only chosen if the server has traversed the room's entire ancestor graph and found no profile roots. (might see if I can reword this better)
Furthermore while the auto-guess algorithm makes sense to have it should really be user choice.
I also think it would be great UX-wise to allow clients to choose profiles before joining. Clients should have enough information to be able to tell which spaces a room could inherit from just by looking at the m.space.child links they can already see before joining (which for the purposes of this MSC, are what matter, not m.space.parent links). Augmenting the join APIs to support this is something that could easily be done in a follow-up MSC, so I'm going to call this out of scope for now.
| per-room/per-space profiles must apply the following rules: | ||
|
|
||
| - When the user joins a space/room, perform a breadth-first search for an ancestor space that is a profile root, by following `m.space.child` links backwards through spaces the user has joined. Break any ties by selecting the first in a lexicographic ordering of room IDs, and then set the joined space/room to inherit from this profile root, or the global profile if none is found. This profile data should go immediately into the initial `join` state, rather than being updated after the join is complete. | ||
| - When the user leaves a space A, if A was a profile root, reset every space/room that inherited from A to inherit from `global`. Otherwise if A inherited from a space B, reset every child of A that inherited from B to inherit from `global`. |
There was a problem hiding this comment.
This seems surprising! Maybe the custom profile should be "popped out" to its own room and references redirected.
Furthermore this makes me wonder if a space is the right place to store a profile. What if I want to use the same custom profile in two spaces? Maybe I work for CompanyA and we partner with CompanyB so I want to use my same "Work" custom profile for both.
I see the need to link the profiles to spaces, it is the more reasonable way to pick a default profile for new rooms, but I wonder if the profile data should actually live elsewhere. For example my profile is a room and it references which spaces it applies to. When changing that profile I change children of the referenced spaces. Then leaving a space can be updating the referenced spaces to remove the space itself and add the children (if desired).
There was a problem hiding this comment.
Furthermore this makes me wonder if a space is the right place to store a profile. What if I want to use the same custom profile in two spaces? Maybe I work for CompanyA and we partner with CompanyB so I want to use my same "Work" custom profile for both.
My assumption is that if a user wants to use the same profile across multiple spaces, they can either create a parent space ("Work") encompassing them both, or just maintain the two profiles independently. Neither option seems especially burdensome, especially in the case of two spaces.
There was a problem hiding this comment.
Maybe the custom profile should be "popped out" to its own room and references redirected.
Hm, I'd feel weird about having a behavior where leaving a room causes you to spontaneously join a new one.
There was a problem hiding this comment.
Hm, I'd feel weird about having a behavior where leaving a room causes you to spontaneously join a new one.
I don't see why this is weird. I had a profile before. Now I still have a profile. Note that if as mentioned above these rooms aren't necessarily spaces they don't need to show up in my space list so it isn't weird to a user.
| - When the user joins a space/room, perform a breadth-first search for an ancestor space that is a profile root, by following `m.space.child` links backwards through spaces the user has joined. Break any ties by selecting the first in a lexicographic ordering of room IDs, and then set the joined space/room to inherit from this profile root, or the global profile if none is found. This profile data should go immediately into the initial `join` state, rather than being updated after the join is complete. | ||
| - When the user leaves a space A, if A was a profile root, reset every space/room that inherited from A to inherit from `global`. Otherwise if A inherited from a space B, reset every child of A that inherited from B to inherit from `global`. | ||
| - When the user adds a space/room A to a space B, if A inherited from `global` and B is a profile root, set A to inherit from B. Otherwise if A inherited from `global` and B inherits from a space C, set A to inherit from C. | ||
| - When a space/room A is removed from a space B (whether by the user or someone else), if A inherited from a space C, check whether A is still allowed to inherit from C by [the above rules](#inheritance-restrictions). If this is no longer the case, then reset A to inherit from `global`. |
There was a problem hiding this comment.
This feels wrong to me. I would expect that the profile is sticky. I like the idea of using space membership to easily apply it to existing and future rooms but it seems that one applied it should stay until I explicitly change it.
| An alternative would be to store all per-room/per-space profile data in a single | ||
| global [extensible profile](https://github.com/matrix-org/matrix-doc/pull/1769), | ||
| essentially keeping a public mapping of room IDs → profile data. However, this | ||
| alternative would leak data about users' profiles in private rooms, which is a | ||
| significant privacy concern, and it is unclear how conflicting profiles would | ||
| affect the "one source of truth" given by `m.room.member` state. |
There was a problem hiding this comment.
Maybe both of these could work together. I think that using spaces to apply profiles makes a lot of sense, and I think that this MSC is in the right direction, just a couple of minor tweaks. However I also think that storing the profiles in their own room makes a lot of sense, this allows sharing a profile between spaces and makes the behaviour simpler if you leave or are kicked from a space. So maybe they could work together to make an awesome solution.
- Use this algorithm for easy application of a profile to existing rooms and for picking a default profile for new rooms.
- Update 1769 to use separate rooms per-profile.
- Update this to reference the individual profile rooms.
|
|
||
| ## Security considerations | ||
|
|
||
| None that I am aware of. |
There was a problem hiding this comment.
- User may think that setting a profile for a space hides their global profile from people who only know them from that space.
- DMs "started from a space" will use the global profile.
Neither of these are new, but I think worth noting as they are unsolved and relevant.
turt2live
added
the
needs-implementation
|
I would like to ask what is the current status of per-space profiles, and have a couple of scenarios where this would be really helpful.
Edited a bit as I legally took Aminda as my second first name in December 2021 |
|
Hi @Mikaela, those are all use cases that the general idea of per-room and per-space profiles was meant to solve, however this MSC is unfortunately blocked behind other spec work at the moment. After some discussions in the Matrix Spec room, I came to the conclusion that it would be best after all to wait until extensible profiles and sync v3 become more concrete, so that this MSC can take advantage of them. For that reason, I think I'll actually mark this MSC as a draft for the moment, because while the profile semantics proposed here will largely remain the same, the internals of this MSC will probably look quite different by the time those proposals become a reality. Sorry for the wait! |
|
I have a question, sorry if this is weird/addressed somehow: |
|
that would be great. just had a couple of issues/delays, because some entities know me in one space under another nick, and then blocked my dm because they didn't know me by my 'standard' account name. |
|
Has there been any development here or in the blockers, or is the best bet with pronouns #3755 ? |
|
This is unfortunately still blocked behind extensible profiles, peeking over federation, and changes to sync, so I don't think this is going to develop anytime soon. |
|
Would it be possible to avoid the blockers on federation peeking/sync by instead proposing a change to the |
|
Hi, looks like a year later since the last update on this... how is this coming along? Has it been folded into another MSC, perhaps? Thanks, in advance! |
|
One related question: within a space I've set up, I can change the nick in each room, but at the space-level I seem to keep the nick-name I had when setting up the space. How do I change that? Seems related to the MSC here |
Rendered
Closes matrix-org/matrix-spec#103.