API for changing displayname in a specific room (SPEC-230)

[matrixbot]

Submitted by @​matthew:matrix.org
Not high priority, but we theoretically support per-room display names and profile data - could be useful for manual disambiguating and other fun. Alien and others occasionally ask for it

(Imported from https://matrix.org/jira/browse/SPEC-230)

[matrixbot]

Links exported from Jira:

vector-web matrix-org/matrix-spec-proposals#2458

[jcgruenhage]

Possibly not that rare use case:
Someone uses Matrix to communicate with people they know in real life. They'd probably want their normal name shown then. This same person also is in some Matrix channels about a game they play, for that they'd want to use their in-game name, so that others can recognize them.

[leonerd]

There already is an API for doing this. You simply update your own m.room.member state event in the room. I've been successfully using this in some bridges/gateways, to allow them to set per-room displaynames.

[leonerd]

https://github.com/matrix-org/matrix-appservice-tg/blob/master/lib/Portal.js#L145-L153

[richvdh]

sounds like this is just a documentation job then

[richvdh]

(though we might need server-side support to ensure you can still change your "default" displayname without breaking per-room displaynames?)

[akien-mga]

So this seems to be implemented in the API already, but it's not exposed to end users in clients such as Riot, is it?

[jooert]

If someone is interested in updating their displayname in certain rooms manually, I wrote a small Python script to do this.

[KitsuneRal]

For the record: libQMatrixClient 0.2 supports room-specific user names and avatars.

[turt2live]

Duplicate of matrix-org/matrix-spec-proposals#516 although this side has more information.

[HarHarLinks]

Room-local display names and avatars are technically possible and "supported" in current Element and some other clients. However there are many shortcomings preventing this feature from being really nice and useful which are in my opinion absolutely necessary. I came across this thread from the issue/proposal I filed at element-hq/element-meta#370, where you can find a more in depth discussion.

Here follows a collection of my rough ideas that are at least correlated to this issue. It may make sense to split this up eventually.

• allow adding on a display name (for oneself) when joining a room, i.e. included in the join request, as not to leak a display name between e.g. your work and gaming rooms. That display name can be set by the client and possibly be exposed as an input field in client's join room dialogs.
• support setting some default names, especially with the advent of spaces. For example, default to my full name inside my work-space. There should be a toggle whether this default is filled in and used automatically, or just pre-filled when joining a new room. The same applies for your "global" default display name
• decouple changing your "global" display name from propagating these changes to all rooms, overriding potentially set per-room display names. That could use this feature.
• probably more privacy issues to be considered. Display names should not be able to "leak" to users who don't share the context (room, space, ...?) in which you use it.

[instantchow]

• probably more privacy issues to be considered. Display names should not be able to "leak" to users who don't share the context (room, space, ...?) in which you use it.

IMHO, I don't agree that Display names need to be "leak free". The existing feature of /myroomnick does nothing to obfuscate your profile name. Extending this could allow for easy Per-Space Display Naming or other Display Name features.

Much rather have a feature to change my Display Name given what Space I'm in, automatically, than wait for a totally un-leaky method to get fleshed out.

If the user requires a higher level of profile separation, the client software should handle this through profile/account switching. PR #3189 seems to be a solution for more complete privacy.

[heyakyra]

Preventing identity leaks across communities is important to strive for, allowing people to use one account across various purposes (personal, professional, etc) but if there's a way to do this in a leaky way first without complicating a proper implementation down the line then that seems ok

[KitsuneRal]

To be very clear, it is not possible to completely separate identities with profile data alone, as long as your MXID is common. Having community/group-specific profile data is a matter of convenience, not privacy. If you actually need to separate identities, use different accounts (and yes it is down to your client application(s) to manage more than one account).