Add verbage for how per-room profiles work #1302
Conversation
Fixes https://github.com/matrix-org/matrix-doc/issues/545 Signed-off-by: Travis Ralston <travpc@gmail.com>
Signed-off-by: Travis Ralston <travpc@gmail.com>
| room. To accomplish this, the client should modify the ``displayname`` and | ||
| ``avatar_url`` properties of the user's ``m.room.member`` event in the room. | ||
|
|
||
| Homeservers SHOULD NOT overwrite ``m.room.member`` events that were updated in |
|
|
||
| Homeservers SHOULD NOT overwrite ``m.room.member`` events that were updated in | ||
| this way when the client invokes the dedicated profile API. Further, homeservers | ||
| should not return per-room profiles as part of this profile API. |
There was a problem hiding this comment.
So how can a client know that an event is global or per room, and how can a client differentiate between an event set globally or per-room?
There was a problem hiding this comment.
out of scope - this is to primarily document the current behaviour.
| this way when the client invokes the dedicated profile API. Further, homeservers | ||
| should not return per-room profiles as part of this profile API. | ||
|
|
||
| Clients SHOULD use the ``m.room.member`` event for users in a room when showing |
There was a problem hiding this comment.
Was this already true or only specific to per-room profile? A better question might be: is this some new item, or a change to an existing behavior?
There was a problem hiding this comment.
This is already well-communicated as the 'proper' way to get display names in a particular room, and therefore the current expectation.
|
Correct me if I'm wrong but it seems to me this text mixes the desired behaviour ("Homeservers SHOULD NOT overwrite |
| Per-room Profiles | ||
| +++++++++++++++++ | ||
| Users may wish to have a different display name or avatar or both in a specific | ||
| room. To accomplish this, the client should modify the ``displayname`` and |
There was a problem hiding this comment.
How to do it is not documented.
There was a problem hiding this comment.
I kinda feel as though describing which fields to modify on what event of what kind is enough information to figure out that one needs to go to the state APIs. I'm open to suggestions for improved wording though.
There was a problem hiding this comment.
At least the endpoint (method + path) that needs to be called
|
@KitsuneRal the "SHOULD NOT" is to get around this limitation, although I do plan on submitting a PR to synapse pending general approval on this. |
|
ftr, this should not be merged until the debate in #matrix-spec is resolved (whether PRs like this are acceptable, and whether they can bypass the proposal process). |
Fwiw I did try this a while ago and we had some problems: matrix-org/synapse#2039 |
|
I'm going to close this for now then. |
Fixes https://github.com/matrix-org/matrix-doc/issues/545
Note
This assumes the following is desired in the spec:
https://github.com/matrix-org/matrix-doc/issues/545#issuecomment-306156163