Optional per-HS user/people directory.

[ara4n]

We still have major UX problems when inviting users. If I tell someone out-of-band to register on Riot, and they sign up, i have no way of finding them short of guessing which email they used.

One way to help on this would be to give users the option of publishing themselves in a HS user directory, similar to the room directory, to make them easier to find. It would also make the search results more intuitive when searching for users (rather than just showing users with whom you have rooms in common).

Pros:

• Makes user search results more intuitive and useful, and increases your chances of finding a user, even though it's not guaranteed to work.

Cons:

• Doesn't work with federation (but even searching local users would be better than nothing, and would also help solve Users directory / Being able to list local users #2906)
• Ideally needs extensible profile info (e.g. geo location) to help disambiguate users, but can work anyway.
• Risks encouraging invite spam (although the cat is already out of the bag there, given if you're a member of a public room, which most people are, you are at risk of invite spam. And if you're not in any public rooms, you're probably also the sort of person who would opt out of this user directory)
• "Skype does this and i don't like it" <-- not a valid con

My hunch is that the cons don't outweigh the pro here.

this is very closely related to #2906, which is asking for a per-group user directory.

[erikjohnston]

"Skype does this and i don't like it" <-- not a valid con

I think its more that at least when I last tried to find someone on skype it proved impossible and I ended up asking for the other persons email anyway. That coupled with:

And if you're not in any public rooms, you're probably also the sort of person who would opt out of this user directory)

makes me wonder if this will actually help that much for the use cases where this seems to arise often (e.g. people who are using it more as a hangouts/whatsapp/facebook alternative, where they're using private rooms, rather than as an IRC alternative).

That said, I'm not against a HS user directory list.

[ara4n]

Agreed that the Skype-style approach doesn't always work. However, i'm trying to increase our chances of successfully inviting users from 10% to 30% or something rather than to 100%.

It also makes it the user's problem if they can't be discovered. If Bob signs into Riot, sees the "do you want other users on Matrix to be able to find you?" prompt, clicks "no", and doesn't join any public rooms... then he really shouldn't be surprised that people have problems trying to invite him to convos.

[ara4n]

Dave suggests we could (ab)use the ID Servers as a user directory - which fixes the federation concerns - but we'd need to somehow also sync/query profile info when searching too.

[ara4n]

bumping the priority on this; watching people try to use riot this weekend at StudentHack without the a people directory was a trainwreck.

[maxidorius]

I would like to share some feedback I get from my own users and from mxisd users.
This approach is more an improved search approach rather than a public directory that can just be listed.

Long-term view

First, I believe using the ID servers (IS) is the appropriate way to go here, since what we want to do is establish a mapping between a 3PID and a Matrix ID. In this case, the 3PID could be anything, and it would mostly be up to the user to tell what it is.

The IS could return a list of supported 3PIDs with their ID and a friendly default label, and a generic 3PID would be supported within the spec, maybe generic or unknown, which would tell the IS that the type is unknown, and would be up to the IS to decide how to handle it, if configured to do.
Riot could integrate this with a simple dropdown menu on the left of the search field, listing all supported 3PID by the IS, and possibly an extra entry for "Client" or "Cached" or something like that to keep the current search mechanism intact.

Second, it would be important to support a multi-answer lookup, just like the bulk_lookup API, but maybe with a more detailed answer, inspired from the specific lookup but with a list instead.
This could allow the search to be integrated in the current contact search built into Riot, simply adding server-side results to the list.
To be safe on the privacy side, I think the query should go from the client to the HS and then to the IS, so the IS has a way to only answer to trusted HS for this kind of privacy-sensitive search queries.

Short-term view

Overall, I believe the current spec and implementations are simply too restrictive in term of user lookup.
If IS could simply support a generic kind of 3PID that would be triggered when trying to invite someone using an arbitrary string, the IS could perform any kind of logic it wants to try to find a certain match.
If those results are limited to self-hosted solutions with a self-hosted IS, the privacy leak risks of multi results when entering a username or the full name of the person seems small enough to be acceptable.
At the minimum, a specific error that could be used to inform the user that more than one match was found (and no result found) would help.

My two very raw cents.

[jfrederickson]

I would also recommend that whatever solution you come up with should be flexible enough to support multiple such directory servers in the future - a hypothetical group server (e.g. for a company) could provide a user directory specific to that group.

[knfiey]

When searching for somebody I think the following format would be much easier to use. @[search-field]:input-field-prefilled-with-the-server-the-typer-is-using

That way they would most often only have to type in their friends name they were given. and hit search and something useable would come up. Maybe even resolve the nickname for them to confirm, preferably showing both. If no search result comes up, suggest to the user the person they are looking for may be on a different server.

Also there should be a banner under the "messages" section with your own address in it. If I need to give my own address to somebody why is it buried in the settings under advanced? What good is it doing there?

But yes... to reiterate, there is too much back end showing. The users should never see @ or : while using the app, there is no reason to do it. We have the technology to make a nice connection GUI with username, nickname, and server name text fields. This app feels like it was made by somebody who is comfortable with linux and thinks everybody should be. Love noobs... please love noobs.

edit: as for other searching for other contact details linked to account -
"We live in a world of twitter and facebook messenger. My friends don't email me or phone me anyway... I don't know the email address of any of my friends I talk to online everyday let alone their phone numbers. Sheesh what decade are we living in here."

[ara4n]

Okay - this is proceeding as of yesterday. We basically see four ways of fixing the user directory problem:

1. "Mastodon-style semantics" - where each HS maintains a list of all publicly visible users it's ever seen, and as more people use the HS the more visibility it gets about the state of the wider world, and the more complete the directory is. Obviously, you'll always see the local users on your own HS.

2. "HSes gossip about the user directory" - like 1, but with the ability of HSes to gossip together to synchronise a global datastructure of the public users they know about. This obviously has reputation problems to some extent; a rogue HS could inject a bunch of bogus users (although this is obviously possible with option 1 too, if a rogue party floods a public room with bogus users)

3. "Logically centralised directory via IS" - @maxidor's proposal from above, that we store a centralisedish user directory in the ISes alongside the current 3PID->MXID mappings. This has a certain elegance, but we'd need to solve the problem of storing and syncing profile data with the IS, and i'm not keen on making the IS even more logically centralised.

4. "Decentralised user directory" - some kind of generic decentralised datastructure with the necessary reputation systems in place to stop people filling it up with crap. Option 2 is a flavour of this.

Right now we're going for option 1 as the lowest hanging fruit to see how well it works in practice, but not ruling out any of the other solutions. @erikjohnston has the conn...

[maxidorius]

@ara4n I think there is really two distinct needs in this thread, which end up being the same UI/UX feature:

• User can search public profiles, which other users have choosen to create/publish. This is, in essence, exactly what people are doing when mapping 3PID in the Identity Servers, except Riot has a hardcoded set of 3PID, which doesn't allow you flexiblity in term of searching. A full name could be a 3PID.
• User can search known users of its HS/IS, regardless if those people published something. It's really the same as what we have in Riot right now

I think the how is less important than the where: having a single end-point would help a great deal.
Being in the HS is the natural outcome, as the HS is aware of the IS configured by the client, but not vice-versa.
Also, a single end-point would help greatly for custom implementation where we could try different scenarios.

Finally, I believe in consistency. Matrix is a federated network, where decentralized entities exist, but federation is the initial lookup mechanism, like room aliases.
Why would we shy away from it right now for identities?

[ara4n]

yup, a single endpoint would help a lot - hence us putting it in the HS for now.
Consistency for user directories (short of centralising them) is not that easy though, due to the potential for spam. If I search for all users on Matrix called 'Matthew' (i.e. whose displayname is currently Matthew, or whose mxid contains Matthew), if we do query a single global address space there's huge scope for abuse as people populate it with crap.

[erikjohnston]

Landed on synapse develop: matrix-org/synapse#2252

[ara4n]

The main issue here (a user directory API) is now solved (thanks @erikjohnston!!). I think we should have a separate issue to discuss how to delegate the API through to other directory mechanisms (e.g. LDAP, or a hypothetical global Matrix user directory, or carddav or whatever).