-
Notifications
You must be signed in to change notification settings - Fork 14
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
Hide room use by verifying #286
Comments
Hmm, interesting feedback... The in-room verification was imagined as a good way to keep a log of your verification activity with someone without needing to invent yet another view of actions and history that is somehow separate from rooms. In some of these cases, the room itself seems like the least of your worries though: to do verification as intended, you should be comparing things OOB, such as emoji in person (more likely on a video call or similar), so the current system somewhat assumes and expects that you would be verifying people already know personally. It's not really expected for you to verify random people "just because"... (I do not doubt it happens, I am just trying to add context of what was imagined when designing it.) This is would be a significant change to the verification system, so I think we'd need to process a lot more feedback before we're ready to change something here. In any case, I'll pass this along to the team. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I don't think a significant change is needed - just make the room throw-away, skip the need for explicitly accepting the invitation, and make it all happen behind the scenes. And for my personal use case - yes, as a counsellor I do supervise people verifying each other that I would never want to be in a room together without proper supervision. In fact, it is because of the sensitive nature of the discussion in the room I made, and invited them to, that the verification is necessary. |
Maybe it is good to separate out some issues. I propose two actions:
|
I wholeheartedly agree with the others mentioned, and have often grumbled about this UX flow with others for many of the same reasons. Specifically, even in a tech-friendly and privacy-focused group, opening what is to all appearances a new private message window causes massive confusion. The idea that "I don't want to accept this invite" or "I don't want to switch my current view" because you are waiting for the verification to complete is spot on. It is also exacerbated by the fact that if you DO switch windows, often the "awaiting verification" panel will disappear until you actively select the user pending verification again. This can lead to confusion about whether the process failed, or if it worked, and removes the obvious next step interaction ("yes, they match" in the case of emoji verification) from the view. If opening a new room is necessary, I would strongly suggest some visual indicator to show that this is not a direct/private message, it is a verification process -- and as Biep mentioned above, ensure the members have no write power in the verification room. This would also prevent screencapping the emoji verification within the room itself, which I have seen frequently as a quick and dirty (and insecure) way to get the verification out of the way. |
Currently, when verifying someone, one gets an invitation to a room. This is unwanted, for many reasons:
Using a room under the hood is fine - that comes with the idea that everything is a room. But please don't leak that to the user by default.
The text was updated successfully, but these errors were encountered: