Was doing a demo with Travelstack recently and noticed that a new ID could not be located when searching. I remember discussing this with @aaron a while back and thought we had a working solution.@alvesjtiago is using https://core.blockstack.org/v1/search
Aaron clarified…
yeah – the search endpoint won’t pick up a name until it’s been confirmed on the blockchain
which means that it won’t show up in that until at least an hour after registration
other apps do one of two things
(1) try to do an exact name lookup using https://core.blockstack.org/v1/names/<foo> which will work for pending subdomains
(2) lookup via the subdomain registrar’s recent registrations list
(this endpoint: https://registrar.blockstack.org/list/0)
I’m assuming this isn’t explained in docs. Would probably be ideal to somehow combine these so that a single endpoint returns all users irrespective of the ID state.
Was chatting with @hank about this and he had some related ideas. cc @yukan@jude
Yeah hitting two different endpoints to accommodate for this opens up all kinds of bug opportunities. I’ve had a ton of bugs around this and I know others have as well. A single, useful endpoint would be huge.
The search endpoint could be a bit more aggressive in picking up pending subdomains, but the endpoint itself will never be completely up to date with respect to user profiles, because those need to be indexed (that’s kind of the nature of user profiles being stored wherever the user chooses)-- so, as it currently works, there’d always be a lag between a registration and the username appearing in that search result.
However, a “name-search” endpoint wouldn’t have this issue. It would just be returning results based on the name, and could handle searching for pending subdomains on the server itself.
Well my thought here was to use the explorer API to handle this kind of thing. The explorer API could keep a database of all pending and registered usernames, and then searching on that would be easy. However, this would require a big refactor of the explorer, as it doesn’t work that way right now. I’m not 100% sure that this would be the right place for that kind of API.