Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC3189: Per-room/per-space profiles #3189
base: old_master
Are you sure you want to change the base?
MSC3189: Per-room/per-space profiles #3189
Changes from 1 commit
4fd6f1a
7d01509
2479921
d1aa8d3
a77d7ae
96c8c03
fb6c4a2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
…though I'm personally not sure how much value there is in solving it