What is criteria used to determine what functionality should be accessed via blockstack-core API calls and what functionality should be built into blockstack.js (or blockstack-browser)? For example, it appears as though blockstack.js no longer makes a call to the blockstack core API for the following:
- Looking up users
- Pending transactions
- Name pricing
I found the following statement in a couple places in the core documentation:
Blockstack Core’s API module provides a set of API calls for interacting with the node’s configuration. However, most of this section is DEPRECATED in favor of moving configuration state to the Blockstack Browser. Client-side state is managed by blockstack.js.
Moving configuration state into blockstack-browser (where it can be accessed via UI, but not API) seems contrary to “API-first” design principals. What options are there for blockstack clients that do not have the ability to display a browser UI?
Also, moving Client-side state into Blockstack.js introduces the necessity of more code duplication should there be interest in other language bindings. As proof… the following proposal in the 2018-03-29 engineering meeting notes:
What advantage is there in browser no longer being dependent on Core?