Invite by mxId - Don't add unrecognised mxId in the ‘suggestions’ section

[giomfo]

Steps to reproduce

Scenario 1:

• Start a new DM by filling a non-existent MatrixId

Scenario 2:

• Open an existing group chat
• Invite a new member by filling a non-existent MatrixId

Outcome

What did you expect?

if we do not recognise the MXID (= the getProfile failed (for example: M_NOT_FOUND error, or 502 code)) we should not show it in the ‘suggestions’ section

What happened instead?

The unrecognised mxId is added in suggestions:

Operating system

No response

Browser information

No response

URL for webapp

No response

Application version

Element version: 1.11.31
Olm version: 3.2.14

Homeserver

No response

Will you send logs?

No

[t3chguy]

if we do not recognise the MXID (= the getProfile failed (for example: M_NOT_FOUND error, or 502 code)) we should not show it in the ‘suggestions’ section

Synapse has settings which make it hide profiles unless you share a room, e.g. #23403 so doing that would prevent users starting DMs even if they had shared MXIDs out-of-band. Doubt this is what we want and is inherently only privacy by obscurity.

[giomfo]

@t3chguy in that case, the "Invite" button is still available to start DM or invite the unrecognised Id
(cc @daniellekirkwood )

[daniellekirkwood]

I don't follow the technical constraint here --

If the MXID is invalid/unknown, we should hide the "suggestions" section.

[daniellekirkwood]

Sorry, somehow managed to click too many buttons at once on the keyboard... Found some new shortcuts though 🤦

If you share a room with the user, it makes sense that that profile shows up in "suggestions". If you don't share a room or can't recognise the user it doesn't make sense that there's a "suggestion"...

Happy to loop in design here as they may have other ideas, or a way to rename the section from "Suggestion" to something more meaningful (as suggestion is not accurate).

Removing "Suggestions" doesn't stop the user from clicking invite?

[t3chguy]

I don't follow the technical constraint here --

If the MXID is invalid/unknown, we should hide the "suggestions" section.

The MXID isn't invalid, it's unknown because servers won't tell us definitively whether an MXID exists for privacy reasons.

[daniellekirkwood]

but when you do know the MXID, it renders with a display name instead?

[t3chguy]

@daniellekirkwood Yes, if the server wishes to give you a profile then we will render it

[daniellekirkwood]

can we have: if there's a profile then show 'SUGGESTIONS' else show something else ✨ ?

[t3chguy]

Sure

[daniellekirkwood]

Have reached out to @nadonomy for a design consult. I think we either hide suggestions if there's no profile or we rename it to something more appropriate.

Alfie also had a bit of feedback on this topic so I will pass along there also :)

[untildo]

I agree that hiding Suggestions that failed to retrieve a profile would be sensible. It doesnt make sense to suggest an unknown MXID, an invalid MXID, or a user with a irretrievable profile.

If the MXID is unknown to your homeserver then you should just manually type it out fully then click invite, as you would with email. If the MXID is known, a partial match is known, or a profile could be retrieved, then it would make sense to provide a suggestion.

If I search for the user @a:b, Element Web will suggest it above all other suggestions. While it is technically possible for @a:b to be a valid MXID, we all know it isnt and the current UI just creates ambiguity.

[t3chguy]

If the MXID is unknown to your homeserver

That isn't the issue here, your own server can hide all other users from you for privacy. You wouldn't want matrix.org to enumerate all users on the server to you as this is abusable.

we all know it isnt

Why isn't it? Private DNS is a thing, Element has no way of knowing whether your server is on a private subnet or not, 1 char localparts are a thing too

[untildo]

That isn't the issue here, your own server can hide all other users from you for privacy. You wouldn't want matrix.org to enumerate all users on the server to you as this is abusable.

Yes sorry, poor wording on my part there but I think you get my point? The current behaviour of only displaying known (to you not your homeserver) is fine.

Why isn't it? Private DNS is a thing, Element has no way of knowing whether your server is on a private subnet or not, 1 char localparts are a thing too

Ok, poor wording again. We dont ALL know its invalid but I certainly do because I do not have a private DNS resolving the b domain. The point is that Element has no way of knowing so should not make suggestions about things it does not know.

[nadonomy]

@daniellekirkwood I stepped through this and I'm coming to the conclusion that the original suggestion from @giomfo is the best one - we should just omit a result if we don't know it, and the entire section if there's no content to display within it.

I looked at if we should rename suggestions to something else, but I think we'd end up re-tweaking this when we zoom into contact discovery and FTUE.

[daniellekirkwood]

OK, that feels like the plan ahead then ☝️

@giomfo is this confirmed part of the retainer time?

[giomfo]

is this confirmed part of the retainer time?

Yes I will ask @weeman1337 to work on it

[richvdh]

Transferring some context from the pull request:

This reverts a change originally made to fix #12440. @turt2live gave some more context around the reasons for that change in this comment. In summary:

• There are many good reasons why a /profile request may fail for a genuine user. A successful /profile request is a good indication that a user exists, but an unsuccessful one doesn't tell us a whole lot.
• The fact that you can still click "Invite" when the user doesn't appear in the list is hard to discover.

I realise this thread has been around this loop before, but I just wanted to double-check that we still think this is a correct change to make in light of the fact that we've deliberately made the opposite decision in the past.

I don't have strong feelings either way, but I just want to be sure that the decisions are being made with all the information.

@nadonomy, @daniellekirkwood could you confirm, please?

[daniellekirkwood]

I think our options are still the 2 highlighted above... Rename the section, or remove it. I'm happy with either one of these but I understand how some folks can see how the "invite" button might not be discoverable.

Suggestion:
I created this posthog graph that we can use to monitor any drop in create room and revert this change if needed
https://posthog.hss.element.io/insights/GS7jX5qe

[daniellekirkwood]

Having read @turt2live 's feedback on the PR I'd like to re-iterate that the issue is mainly that Element "suggests" MXIDs that are invalid. Changing the title of the section when there's no profile found would help to clear up the confusion.

I do not agree that that "Invite" button is hard to find but as we're not looking at updating this screen for a little while, renaming the section would be a suitable solution for me atm.

👀 @nadonomy

[weeman1337]

Some users have a closed network. They have profiles enabled and do not federate with the world. For them it would be good not to display invalid MXIDs. I can also understand that this may not work great in the context of (unknown) federation.

→ What about considering this as a config option? The option should not be visible to the user. It can just be in the JSON shipped with the client. This would meet the demands of users in a known, closed network.

[t3chguy]

It can just be in the JSON shipped with the client.

That'd require building & signing & notarising your own desktop apps. IMO this should be done at the spec level with a proper way to query whether an MXID exists which has a tri-state response. Yes|No|Unknown - where open federation servers return Yes|Unknown only depending on public presence, closed federations can switch to Yes|No if they deem it to be what they desire.

[daniellekirkwood]

Confirmed with @nadonomy that we're comfortable removing the "Suggested" section (as planned) for all and keeping an eye on the PH graph to ensure users are still able to 'see the invite button'.

I believe there's a PR already going @weeman1337 ? Maybe @nadonomy and I just need to add our reviews there so we can move forwards here?

[richvdh]

No need; thanks for confirming!