Update hive libraries for rebranding changes that affect API method responses
Below is a list of libraries that need updating. As each library is identified, create a project for it, and add a task there to update it.
- hive-js
- hive-python
- lighthive
- Beem
- dhive
- hive-tx
Any API call that returned a response that included the word steem or sbd has been changed to substitute the words hive or hbd respectively. Please do a global search and replace for any such code in your library or app.
Here is a list of known API changes of this type (just a starting point, please add to this list as you find them):
- The fields reward_steem and reward_sbd have been renamed to reward_hive and reward_hbd in get_ops_in_block API call.
- In comment_options,
percent_steem_dollarswas changed topercent_hbd
Activity
added Review label
mentioned in issue #3 (closed)
Any API call that returned a response that included the word steem or sbd has been changed to substitute the words hive or hbd respectively. Please do a global search and replace for any such code in your library or app.
Here is a list of known API changes of this type (just a starting point, please add to this list as you find them):
- The fields reward_steem and reward_sbd have been renamed to reward_hive and reward_hbd in get_ops_in_block API call.
Edited by Dan Notestein
The best would be to accept both old steem/sbd and new hive/hbd names in API return values, at least until hardfork, so during transition period you can talk to both old and new nodes. Understandably that can be too much work in many cases, so replacing all steem/sbd with hive/hbd is next best approach. Most likely it won't be as easy as mere replace-in-files though.
One particular case to be aware of if you are dealing with historical operations:
witness_set_properties_operation.propsis a flat map that usesstringas key. That strings can contain oldsbd_interest_rate/sbd_exchange_rateas well as newhbd_interest_rate/hbd_exchange_rateand both need to be handled properly. Consensus code considers both forms equaly valid (since we can't do anything about old operations, we have to handle old forms engraved in past blocks, while we keep accepting old form in new blocks too, along with new form, because why not, plus it helps smooth out transition). I don't know about custom JSON operations or if any code needs to decompose and interpret them, but I imagine they might contain similar cases.
Symbol names are corrected? I mean after hf, will nodes accept HIVE/HBD? Because right now nodes only accept STEEM and SBD as a valid symbol name. It would be good to accept both old STEEM/SBD and HIVE/HBD symbols.
Edited by Mahdi YariAfter the hardfork, only HIVE/HBD will be accepted by the node software (and reported in fields that include the names of these symbols).
Andrzej is saying that "apps and libraries" need to support both, when handling responses that contain hive or hbd in the the key names of the json responses, because of the HF transition period.
Actually, I was looking over hived code today, and it looks like it will handle the old names for parameters as well as new ones on API calls. Nonetheless, switching is highly recommended.
But more importantly, the API responses will only return the new field names, so any code that processes those fields must be changed.
Edited by Dan NotesteinTo test your library changes, you can use this experimental node: https://beta.openhive.network
Note this is just a hived node, there's no jussi or hivemind associated with it.
If you want to build your own hived node, use: https://gitlab.syncad.com/hive/hive/-/tags/v1.0.0
mentioned in commit hive-ruby@631d7911
Note that one change needed to libraries is to serialize inputs of HIVE/HBD to the same binary value as STEEM/SBD were previously serialized to. For example, when generating a claim_reward_operation.
Edited by Dan Notestein
