Feature Proposal: Adding URL Parameters for Function Calls

[VinceBCD]

Context

My company, 3videnZ, develops a solution for generating digital credentials based on blockchain technology named BCdiploma. For several years, we have been using MyCrypto to access smart contract data with one click from digital certificates, making on-chain information more accessible for beginners and non crypto friendly users. We are looking to migrate to a more modern and maintained tool, and we have discovered abi.ninja, which seems like the right candidate for this.

Identified Problem

Abi.ninja already allows specifying a target blockchain, a contract, and one or more target methods in a URL. However, to be complete and enable one-click information reading, it should allow passing arguments to the functions to be called and, if applicable, execute them immediately.

Practical Example

Here is an example with MyCrypto when calling the "issuers" method on with 237 as the value on a gnosis smartcontract:
https://app.mycrypto.com/interact-with-contracts?network=Ethereum&address=0x90bb0b538253d279642439d5f54f336414ec06f7&function=issuers&input=0:237

We could imagine a similar system for abi.ninja. For example:
https://abi.ninja/0xAE811D62a3A3D53Dddc4e106335af35a3a0cE4dF/100?methods=issuers&input=0:237

Note that the parameter values would be passed by index rather than by name to handle both functions with named parameters and public mappings in Solidity.

Proposed Solution

1. Add the ability to pass arguments to functions in the URL
2. Arguments would be specified by index for maximum compatibility
3. Allow immediate execution of functions with the provided arguments.

Call for Contribution

If this proposal is of interest, I can ask my team to contribute to its development. However, I would like to be sure before we start that this feature, once it passes QA, can be integrated into the online version of abi.ninja. It is important for us that this on-chain reading is done through a third-party tool and not our own solution to increase user trust.

Please let us know if this feature interests you and if it could be integrated.

KUTGW guys

[portdeveloper]

https://abi-ninja-v2-git-feat-inputs-in-url-buidlguidldao.vercel.app/0x6B175474E89094C44Da98b954EedeAC495271d0F/1?methods=allowance&allowance_input_0=ownerAddress&allowance_input_1=123

-> gets values from url and puts them into the relevant inputs
-> does not update the url when the inputs change, the url has to be prepared manually, otherwise the UX might get confusing(imo)

url: https://abi-ninja-v2-git-feat-inputs-in-url-buidlguidldao.vercel.app/

select methods then append the values you want:
e.g.
&allowance_input_0=ownerAddress&allowance_input_1=123

will put "ownerAddress" into allowance input #1 and "123" to allowance input #2

[VinceBCD]

For it to be really smooth and without any manipulation for the end user, the reading should be done automatically without the user needing to click on "read". Is that possible? By the way, it could be automatic or done through the addition of an extra parameter to the URL.

[portdeveloper]

Honestly I am not sure about whether that could be a little bit too specific or could be exploited in the future.

[VinceBCD]

Your questioning is legitimate, but let me provide some additional information on this request.

1. Regarding the overly specific aspect, it could be mitigated by adding a parameter per called method, e.g., &allowance_autoread=true.
2. Concerning the risk of exploit (if I understand correctly, a potential security risk): in my opinion, this risk is negligible as long as we are talking about operations on "Read" type methods. Of course, this functionality should not be available on "Write" methods, which would be too dangerous.

Finally, this autoread is, following your development, the only discrepancy that remains with the Mycrypto functionalities we have been using until now. We are really eager to switch to abi ninja, but it will be difficult if the end user has to make an additional click (even if it is very simple, our users are not necessarily tech-friendly, not necessarily English-speaking, etc.).

Looking forward to discussing this further!