Hi everyone, this past CPS cycle I submitted a grant “Tracker Address Pages and API Doc Updates” where I ran into some difficulty with the submission process and without going into detail, ended up submitting the wrong draft which beyond the formatting issues lacked a few details I wanted to clarify.
On the address page updates to support staking / voting:
We’re going to make a call about whether a dedicated governance tool is needed later after we include all the functionality in the address page. This could be anything from a new tab in the address page to a dedicated tool in the tools section or no additional pages at all with just broad improvements to the address page like we outlined. Regardless, this proposal will see through that all the governance related functionalities are consolidated into user-friendly interface within the tracker that is on-brand and looks good.
On the better ABI and event logs outputs:
This section was relatively complete but just to add, making this upgrade is going to make consuming event log data much simpler compared to what we have now. One should not have to look up the ABI when looking at the event log list to see what the field name is in the indexed and non-indexed event log outputs. Every developer in the ecosystem can speak to the pains with having to deal with this. These with changes will also appear in the /transaction/ Events tab such as this one along with supporting some kind of filter for “method” in the address view Events tab. Lastly we’ll integrate a toggle for methods marked as payable per this issue which is really just about enrich
On the API docs updates:
This section has the most budget and it should be noted it is also the area where we expect to have no margin / lose money. This is primarily due to 2 reasons, first simply being that it will require a lot of work relative to the amount of value added to the ecosystem but also this process of rendering custom API documentation is core to our business so putting in extra effort for us makes sense.
The value added in these deliverables stand on their own but in the long run, it sets us up to use this same process for rendering JSON RPC API docs for all contracts in the ecosystem. Doing so would require building some equivalent specification to OpenAPI, the specification we use for REST APIs, for JSON RPC, the protocol all contracts expose their methods through, and is being developed on under the banner OpenRPC. This is a complex topic but without going into too much detail, a future grant will be coming to encapsulate ICON specific functionalities / ABIs into a spec that can be translated into these other specifications OpenRPC / OpenAPI and thus bringing with them the tooling these ecosystems enjoy like API documentation / client code generators which in the context of ICON would be useful both on and off-chain. It would be a significant project that will be proposed at a later date but suffice to say all this work we are doing now in these deliverables will be very useful in that planned future work.
Hopefully this information gave the proposal more context. Please feel free to leave any comments / feedback / suggestions here or reach out to me directly on telegram.