Stealthy (and a number of dApps I’ve seen–Graphite & Misthos I believe) offer the ability to search for other Blockstack user’s to connect with for various in-dApp functionality.
This search is typically hitting the /v1/search endpoint after a minimum number of characters, presenting the user with a number of possible Blockstack user’s for each new character entered. You can think of this as a narrowing down of the search space with the goal being to converge on the specific Blockstack ID of the desired person.
Ultimately this is not entirely necessary if you have the desired person’s precise Blockstack ID, however that is often not the case and sometimes the Blockstack ID is very different from the person’s name as you may know it, for instance:
correcto.id ---> 'Tiago dos Santos Carlos'.
The ultimate goal is to make it as easy as possible for people to connect with one another to build networks and drive social interactions across dApps. Right now the /v1/search endpoint is the most useful tool for that purpose. We want to help people have great decentralized experiences and a lot of work has been done to make it easy for new users to get a Blockstack ID. However before they can really be up and running, connecting and experiencing the social possibilities of dApps, they have to get into the /v1/search endpoint for their friends and new acquaintances to find them. This can take a lot of time.
At a conference or show where many people might get exposed to Blockstack for the first time, we want people to be able to see this functionality work right away. For example two people both without Blockstack IDs who want to try one of these Apps for the first time together. This shows that decentralized offerings are every bit as powerful as their centralized counterparts.
The suggestion you have about a second search indexer, like that on /v1/search to specifically access the registrar’s pending names and profiles sounds like a good idea. If that existed today, the state of things would be such that you would want to query all three endpoints (depending on the data the user provides). The reason you need to query all three comes from corner cases–for instance the /v1/search endpoint doesn’t work on .id TLDs but works fine on .id.blockstack. For example #1 below returns a result, but #2 does not–yet both are valid Blockstack IDs in existence today:
You probably would want to query both search endpoints because of the possible overlap in names that would occur and then merge the results.
Edit: Once our dApp has the precise user ID, we always go to the /v1/names endpoint for data, when needed.