I like the idea of the User Discovery feature, but for applications that support Facebook and Google+ login, it doesn't work that great because it doesn't seem like you can match on the "_socialIdentity.facebook.name" field (in fact not even the "id" is working now it seems). I understand that this likely requires returning more data from the "_lookup" endpoint than before, but it would make it more useful. My basic use case is to hook it up to something like typeahead.js to get the user id to use in a KinveyRef or ACL.



A simple solution could be to take the "first_name" and "last_name" fields from the "_lookup" query and also search in the respective _socialIdentity fields to try and find a match since both Facebook and Google+ (possibly others) have these fields available.



Another solution to this might be the following. When a "social user" (Facebook, Google+, etc.) logs in for the first time, Kinvey already fetches some basic user data such as name, gender, locale, etc. Why not use this data to also populate the "first_name" and "last_name" fields in the Kinvey user object if they are currently empty? App developers currently have to write code to check the full name of a user by checking several fields in the user object on how the account was created, but it would be nice if I could reliably just read user.first_name and user.last_name.

Hi Jason, we will add social identity names (as well as IDs for the rest of the supported identity providers) to lookup as part of the next release.



As for populating the user's details with information from the social identity: while we are not currently planning to do so automatically, you could implement such logic yourself using business logic, by creating a post-save hook on the users collection and writing the merging logic you mentioned.

As of today, you can perform a lookup by social identity names and ids for all supported providers.

Hi Gal, thanks for this. I just gave this a try and had problems using it from the API Console due to the required quotes around the attribute name I think. I tried it using the Backbone SDK though and it worked fine however I have some follow up questions:



1) It seems like I have to know how a user logged in before I can search for him/her because I need to specify the exact attribute name (eg: "_socialIdentity.facebook.name"). This gets further complicated by the fact that it treats multiple attributes as a conjunction (AND) instead of a disjunction (OR) so searching for a user across multiple social networks would require multiple requests?



2) Also, it seems like there is no substring or wildcard matching so I need to type out the full name exactly as it appears on the social network to get a match?



Basically, what I would like is to search for my friend 'Dave' and get his user ID. I know he uses my app, but I don't know how he signed up (username, facebook, google, etc..). Additionally I don't know how to spell his last name, but I know it starts with a 'W' :) Is there anyway to support this use case or should I maybe look at implementing my own RPC endpoint to do what I want (perfectly acceptable)?

Jason, you're absolutely right in noting that the user discovery feature is very restrictive by design. Allowing wildcard or ambiguous search on a feature that allows finding users when the user collection has been explicitly set to "private" has a potential for unwanted leaks, and we chose to err on the side of extra security.



I would recommend implementing a custom BL endpoint, as you suggested, which would allow you to get the functionality that's right for your use case.



As for using strings to define nested properties on the API Console, you've encountered a known bug that has a fix lined up for the next release.