This is a proposal for custom_json standards that Hive dApps can adopt when designing their ops. Let's talk about it!
If memory serves, @blocktrades may have suggested the development of standardized custom_json usage.
I have linked to a work-in-progress doc right at the bottom, containing the draft proposal for the standard.
A standard will make it easier to develop auxillary software for all apps and protocols (such as plugs for Hive Plug & Play), while increasing integration opportunities.
A way to track changes
Apps evolve over time and changes made to the structure of their custom_json ops need to be tracked. I propose including versioning data within the ops. This will make it easier for parsers (like Hive Plug & Play) to use different code for different versions, much like hardforking. So that the code doesn't break on resyncs. The owners of the op will have control over versioning, as new changes are introduced.
This would mean using a standard main container for ops. Either a JSON object (dictionary) or an array/list. I propose the use of an array (second example below).
Examples:
{
"header": {"ver": 1, "app": "splinterlands/0.7.81"},
"op_name": "sm_submit_team",
"data": {}
}
... or
[
{"ver": 1, "app": "splinterlands/0.7.81"},
"op_internal_name",
{} or []
]
Using an array (second example), we'd have the first item as the header, always. With the third being an internal op identifier and the third being the actual data that the app/protocol will use.
Consistent use of IDs
I propose using the id field of the custom_json ops to apply to application-wide or protocol-wide usage. This will make things more organized, with less fragmentation of code to parse the ops.
For example, Splinterlands currently uses a number of IDs for its protocols. These include sm_submit_team, sm_find_match, sm_combine_cards, etc.
Communities use the community ID for all actions.
So a developer could use the app or protocol name as an ID.
Feel free to leave feedback!
READ THE DOC: https://gitlab.com/imwatsi/hive-plug-play/-/blob/master/docs/op_standard.md
The transition to this new standard will be flexible and optional, in that individual apps can migrate to the new format as and when they are ready, or not. I will implement legacy support to convert the old format ops to the new, when stored in the Plug & Play database.