The search endpoint, https://core.blockstack.org/v1/search?query=, is very useful to Blockstack dApps that connect users with one another for social experiences and work sharing.
One thing that could really help with onboarding new Blockstack and dApp users at conferences and other venues with many new users would be if we could index new IDs faster in the search endpoint. Otherwise users may have to wait a significant amount of time before they can experience the social aspect of these dApps. (The name endpoint and fully qualified id searching is also possible as a workaround but it takes away from the experience).
I talked with @jude about this a little bit, and I think if you run your own core node, you can check for new name registrations and add those names to a file of your own that can be queried in conjunction with the names endpoint. Maybe there’s an easier way, though?
@alexc.id Was wondering if you could help me understand the specific value-adds you see by hitting the search endpoint directly, instead of querying usernames from the /v1/names endpoint? Is it the autocomplete feature specifically, or are there other things you’re searching on?
Asking because one approach to solving this (if simply falling back to /v1/names isn’t good enough) could be to have the resolver expose its set of queued names and profiles. Then, it might be possible to colocate a second search indexer like the one running on /v1/search to specifically process the registrar’s pending names and profiles. The “main” search indexer could be configured to redirect clients to registrar-based search indexers. CC @aaron
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: