Element-web: Avoid guests from being stuck with numeric IDs

Created on 14 Jan 2017  Â·  10Comments  Â·  Source: vector-im/element-web

It sucks that guests can't escape numeric ids without losing their history. Need to either:

  • support changing id
  • prompt guests for a username before they do anything
  • hide mxid so much they don't care about it being numeric
bug p1 uux

All 10 comments

This is a significant issue for me: I've been advocating and using Riot as a community organising hub for a makerspace, and the numeric IDs are actually breaking things really often.

  1. User comes to riot at my suggestion to join our public chatroom.
  2. User joins chatroom with new account, and we invite user to private chatroom.
  3. User changes username so they have something more personal than @\d\d\d\d\d\d\d\d:matrix.org
  4. User is no longer able to access either room, return to step 2.
  5. Moderator has to kick the old user-names.

@cathalgarvey thanks for the example failure mode. one temporary mitigation would be just to turn off guest access on your homeserver, which then forces users to pick a userid from the outset, and is close to the 2nd proposed solution on the original comment - but loses the "just get using the app" behaviour we have today.

Alternatively we could prompt just for userid on first use, but doing so without specifying a password feels a bit weird and risky, hence wondering if we should so a full signup. "hmm."

The right solution here is of course to let you migrate your user ID.

So I think the solution we're going with now is

prompt guests for a username before they do anything

With the newly-suggested ROU -> PWLU-> Registered User flow (see https://github.com/vector-im/riot-meta/issues/59)

Fixed by ILAG me thinks

I'm still having this issue — see vector-im/riot-meta#210 for desired functionality. Generic numbers for guests is dehumanizing!

Guests are no longer used in riot-web so this is no longer an issue.
riot-web forces you to make a proper account by "Choosing a username"
it only uses guest accounts to peek into rooms before you choose a username.

When mixed with the autojoin option on synapse though, it's still an issue.

image

See also https://github.com/matrix-org/synapse/issues/3491

The issue summary says one of three things needs to be done, option 2 was taken :/

Except that at least with autojoin, guests can speak and participate in channels. To be fair, I'm not advocating that this be re-opened, just that there's an edge case.

Was this page helpful?
0 / 5 - 0 ratings