Skip to content
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

Choose display name when joining room #370

Open
HarHarLinks opened this issue Jan 21, 2021 · 6 comments
Open

Choose display name when joining room #370

HarHarLinks opened this issue Jan 21, 2021 · 6 comments

Comments

@HarHarLinks
Copy link

HarHarLinks commented Jan 21, 2021

Display names in Matrix are a bit iffy in general. Remarkably updating them has been slow since the dawn of time (matrix-org/synapse#1297), it is possible to set your name on a per-room basis (via /myroomnick in element), there is a global nickname that serves as a default but changing that also requires the homeserver to override per-room names per the spec (11.2.6).

Matrix (with Element as the front line client) is shaping up to be an ecosystem that allows a user to communicate in multiple contexts (even more so with spaces slowly getting there). That implies a user might want to use several "identities" for their account, e.g. something related to their github account for public dev-rooms, private name in personal/friend rooms, gamertag in gaming rooms, professional name in work related rooms. This leads to trouble when you have your global display name set to something other than your mxid minus your server's domain or nothing at all, since you would be leaking your name from one context to another. Further, even if you keep your global display name "clean", you need to remember and set your per-room display name manually upon joining.

Describe the solution you'd like
My suggestion: ask the user for the nickname to use in the room joining dialog. This can be a simple input field that defaults to nothing or the global display name when left empty. This input field could also be pre-filled with said default and additionally offer a drop down menu with all other display names the user is currently using in any room, while still being editable to create a new one.
There would also be a toggle in the client's main menu (preferences tab? alternatively maybe privacy tab, but it would be buried there), that can revert this behavior to the current one (default).

Further, when spaces arrive and assuming you would group the different kinds of rooms under spaces, it would make sense being able to preset and manage a display name for the rooms in that space. Note: since spaces can "overlap", this needs to be optional in a way to accommodate the needed structure. That would also override the proposed toggle for the appropriate contexts.

This suggestion would still work well, or possibly even better in the case that the requirement of home servers to propagate global display name to all rooms is abolished (it should only be a default to either new rooms or existing rooms using the global default at that point in time). This could be further expanded with the management possibilities of my spaces-proposal, but exceeds this issue.

Last but not least, this same issue/proposal applies also for the other Element clients (feature parity!), but I can not access the meta bug tracker.

Describe alternatives you've considered
See above.

Additional context

@t3chguy
Copy link
Member

t3chguy commented Jan 21, 2021

This issue is more one for the spec, you cannot specify your displayname/avatar at join time. You could update it as soon as you join but that is not what a lot of users want.

since you would be leaking your name from one context to another

It wouldn't solve this goal, as you'd join with your global then your per-room one would be added after the fact.

I suggest adding this request to #499 and a matrix-doc issue - maybe https://github.com/matrix-org/matrix-doc/issues/545

Given that Element Web's per-room displayname is not fully supported, as per matrix-org/matrix-spec#597 I think having this assume that it is isn't great.

@HarHarLinks
Copy link
Author

issue is more one for the spec

In part certainly, yes. i was contemplating to go there as well, but I thought the core of this issue (display name input field in join dialogue) was a client one.

you cannot specify your displayname/avatar at join time

I seem to have misunderstood "a m.room.member event (with a join membership) is sent to every room the user is a member of" then.

you'd join with your global then your per-room one would be added after the fact.

Correct me if I'm wrong here, but i think the issue is solved if your global one were empty, equal to your mxid, or something otherwise neutral that you chose with this issue in mind.

I will take a look at the other issues you linked and add my suggestions there.

@t3chguy
Copy link
Member

t3chguy commented Jan 21, 2021

I seem to have misunderstood "a m.room.member event (with a join membership) is sent to every room the user is a member of" then.

Yup, but the only way for a client to send one of those (respecting federation) is to use the Join API which doesn't take a displayname paremeter. https://matrix.org/docs/spec/client_server/r0.6.1#post-matrix-client-r0-rooms-roomid-join

Correct me if I'm wrong here, but i think the issue is solved if your global one were empty, equal to your mxid, or something otherwise neutral that you chose with this issue in mind.

Right but then also when someone pulls up your profile outside the context of a room, or also for yourself in the top left corner of Element you will have no displayname, as that feeds those.

@HarHarLinks
Copy link
Author

Hold on, so the client sends such an event, which gets propagated over federation and then leaves it to the federated servers to figure out the display name? No wonder this is slow.

outside the context of a room

That would be so, but I don't see how that could be remedied satisfying the privacy concerns I described. Not even e2ee verification trust would work since that likely still involves multiple communities. The only option left short of multi account I see is for the client (or server?) to try and find the canonical PM or other rooms with both parties and fill from there (or a list of all?). In the end you are your mxid and may not need a pretty name in the top left corner if you're concerned about these leaks, while others who can't see one of your display names know you only by your mxid anyway.

@t3chguy
Copy link
Member

t3chguy commented Jan 21, 2021

Hold on, so the client sends such an event, which gets propagated over federation and then leaves it to the federated servers to figure out the display name? No wonder this is slow.

No, the client calls the /join API. The server creates an m.room.member event with membership=join and your avatar and display name from your global setting and appends that to the room DAG, including dealing with federation.

The client cannot specify the name/avatar at join time.

Given the current mechanics of global name/avatar overriding the name/avatar in all rooms this idea feels too brittle without proper spec support.

I suggest appending this to matrix-org/matrix-spec#597 for the Element side and extending the matrix-doc issue with a request to be able to specify it at room join time, then servers could actually be smart and not nuke your per-room profile every time you update your global one.

@aaronraimist
Copy link

Related: #366

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants