Enormous Team Airnode UI Progress Report (Oct 2021 - Jan 2022)

[enormous]

During the last 3 months the team was busy preparing an independent Airnodes UI on-chain history explorer and manager - one more user interface which would be the alternative to future Chain API.

Just like our on-chain DAO tracker was revealing all events of the DAO, this tool was supposed to show the general picture about all known Airnodes activity, reveling some visuals for DAO participants not willing to become etherscan researching experts.

Airnode UI

The primary goal of that tool is have a track of all Airnodes activity, which is being recorded on EVM-compatible chains in so called Request-Response Protocol (RRP) contracts. By watching every event in such smart contract the tool is keeps building the history of every interaction with its Airnodes.

The link to the demo version is finally released and available for beta testing:

API3 Airnodes

A few screenshots to grab your attention:

The stack of technologies that was used for the tool consists of Rust as the server side language, ReactJS for rich client interface and RocksDB for the storage.

• Only active known RRP contracts are presented on the demo website.
• There is no Ethereum main net usage of airnodes yet.

Looking at activity of the core team on Github, we are excited to see the 1.0 protocol is coming soon. At this moment our UI supports only established protocols versions: 0.3, 0.2 and prealpha.

RRP Explorer

API3 Airnode RRP Explorer

Since the initial announcement RRP explorer tool was improved and includes much more parameters, allowing Airnode integrators to research their RRP contracts with more filtering arguments

But the main feedback we received from it was that using its CLI version remains much more convenient. airnode-rrp-log can be installed using cargo:

Whats next

At this point we would like to collect the feedback about existing tools, improve their security and robustness before management operations will be safe enough to be recommended.

We will be waiting for Chain API and the possibilities to make that tool better by integrating with it.

And we are eager to see 1.0 version of protocol and its usage to adjust our libraries and tools with it (historically we are around 1 month behind the core team releases)

Any kind of found issues, questions, proposals or any other type of feedback is welcome in the Github of the project or on this forum.

We would like to thank everyone who supported this initiative and made this milestone possible.

[ryan]

Hi @enormous,

I am wondering if I can use the explorer to find contracts that are using the new QRNG service that was just launched.

What is QRNG? | Documentation

I tried using the demo version and put in the RRP contract address for Mainnet but I’m getting back 0 events.

I know there has been some activity bc Burak tested it and I see txns on etherscan.

Am I not using it properly?

[enormous]

@ryan Probably you are doing everything correctly. I just see some new events on the main net that were not earlier when the tool was originally published - this is the reason why you see no results with that type of query.

I will make releases for the tool to support the latest formats of events in the nearest days.

[ryan]

@enormous

But the main feedback we received from it was that using its CLI version remains much more convenient. airnode-rrp-log can be installed using cargo :

Whats next

At this point we would like to collect the feedback about existing tools, improve their security and robustness before management operations will be safe enough to be recommended.

We will be waiting for Chain API and the possibilities to make that tool better by integrating with it.

Are you still planning to build out the web GUI for this? Or are you saying you won’t build the web GUI because the CLI is enough?

[enormous]

CLI is absolutely not enough. I am rather saying it is more convenient - you can share requests, save them (to make sure every parameter is correct), and use results for automated scripts.

So, for example, instead of screenshots as above, the following could be used to check QRNG transactions on the main net. This is exactly how we do it (and probably is the recommeded way for developer)

airnode-rrp-log \
  --address-contract 0xa0AD79D995DdeeB18a14eAef56A549A04e3Aa1Bd   \
  --rpc-endpoint `chainstate --endpoints -t mainnet,infura | head -n` \
  --min-block 14622752   \
  --max-block 14698580   \
  --rpc-batch-size 25000 \
  --format json | jq .

and as for GUIs - there are 2 of them

1. API3 Airnode RRP Explorer - the one that you were using is up to date.
2. Airnodes UI Management - this one was in a demo mode, out of sync now and it will have an update within a week or two.

[enormous]

A little feedback about your experience
ankr.com RPC API node seems to behave weird though. And I can’t just recommend it.

Obviously this is not a full node and it has some severe limitations.

• when not using batches, it gives no errors. just empty result.
• they do not allow batch size to exceed 3000.

Its quite challenging to get results from it.
So my advice is to use Infura or Alchemy at this point. They work 100%.

[ryan]

Got it. Yes, the RRP explorer GUI is working for me now and I can see requests on it. Thanks!

I think the user experience would be improved if we offered a select list or search for live AirnodeRRP contracts. Currently it requires me to manually enter an RPC URL and a contract address which seems like unnecessary friction. I see why you would want to have the flexibility for users to enter them manually for special cases but most of the time I think users would just want to search the well known chains and wouldn’t care which RPC is used. What do you think about enhancing it like that?

My other suggestion is with how the results are displayed. Wouldn’t it be better render the transactions in HTML instead if printing raw JSON objects? That would seem more normal to me. Then have a download option if someone wants to download the whole search result as JSON or CSV.

Make sure to work with @can on the styling so that it looks on-brand in terms of font face & size, spacing, etc… It would also make sense to move these so they’re hosted on their own domains like api3tracker.io, api3explorer.io, or similar. I can provide the domains and hosting.

Great job with these tools! They’ll be super helpful for devs and non-devs alike.

[enormous]

I think the user experience would be improved if we offered a select list or search for live AirnodeRRP contracts

This is what second tool was supposed to be for. Airnodes UI Management

But the main issue is that most RPC API endpoints are private and shouldn’t be exposed.
It is hard to get stable and good working fully functional RPC API, and the main recommendation ironically was to host your own node and request localhost:8545 That totally doesn’t work with that many chains as we have now…

Make sure to work with @can on the styling so that it looks on-brand in terms of font face & size, spacing, etc…

Have this in my list. He periodically reminds me via Github Issues about corporate styling.

It would also make sense to move these so they’re hosted on their own domains like api3tracker.io, api3explorer.io, or similar. I can provide the domains and hosting.

It would be probably nice to have a private conversation about it (ping me in Discord). I am open to that and it we could setup up additional servers as mirrors of the tools that you would have control of.

[ryan]

@enormous

This is what second tool was supposed to be for. Airnodes UI Management

I see. Could there be a way to pick an Airnode in the UI Management app and link from there to the RRP Explorer with the RPC URL and the contract address already filled in? That way if I want to explore RRP on a mainnet I can get there from the main management app and not have to enter in the details manually?

@enormous

But the main issue is that most RPC API endpoints are private and shouldn’t be exposed.
It is hard to get stable and good working fully functional RPC API, and the main recommendation ironically was to host your own node and request localhost:8545 That totally doesn’t work with that many chains as we have now…

I don’t quite understand. The Airnodes UI Management app doesn’t make me manually enter an RPC URL. Neither does the DAO itself. Why is it different for RRP explorer? It seems like asking people, even developers, to run their own node just to explore RRP is asking a lot and isn’t necessary. Maybe I’m misunderstanding something?

[enormous]

Could there be a way to pick an Airnode in the UI Management app and link from there to the RRP Explorer with the RPC URL and the contract address already filled in

I don’t think it is necessary. AirnodeUI should show all the same information directly - and there is no sense in linking.

Please refresh AirnodeUI to see the mainnet contract at the top.

I just forced it to be there, but again, please wait for the release, as there are a few obvious issues that need to be resolved to say it is up to date and works correctly.

The Airnodes UI Management app doesn’t make me manually enter an RPC URL
Why is it different for RRP explorer?

The key thing is, again, these RPC node access have to be private. If it is not private - its just a question of time that it will not work

And this has an implication, so these tools are different, balancing between user friendliness and security

RRP Explorer

• it doesn’t share the information with any server it is hosted as it is a static client side application.
• this tool is simple, secure, it allows to connect anything and great for debugging purposes or exploring new nodes/contracts.
• you do need to be a little tech savvy to use it.

Airnode UI

• it is probably what you are mainly interested in, as it was supposed to follow click-and-see principle and should be not for nerds (as much as possible).
• as a trade off, it is more complicated inside, it has a database, it tries to keep in sync data from multiple contracts of multiple networks in the background.
• this means it keeps every RPC API that you’ve enter and starts using it intensively.
• so, adding new RPC API is disabled on the demo website (but its there in the app).
• you suppose to run this app locally to explore airnodes that you own, contracts that you are interested in, in the networks that you have access to. But your local environment is the only safe place to allow storage of RPC API endpoints.
• having all known RRP contracts / networks on the demo website is a part of a plan.
• as a more complicated tool, this one is immature, there is a plenty of room to make it better, and any feedback it always welcome as separate Github issues.

It seems like asking people, even developers, to run their own node just to explore RRP is asking a lot and isn’t necessary.

oh… this is so frequent claim to all actually decentralized projects… This does ends up that almost no developer does that and relies on a few providers. (With reliable provider it is not that the nodes that doesn’t work, its their keys that become overused or outdated)

But jokes aside, this is exactly why the proposal was originally created - to bring some simple interface just to see what is going on. However the trade off between privacy and usability is the main thing that probably needs to be explained down the road.

[ryan]

OK I think I understand now.

RRP Explorer is a debugging tool for developers. It’s just a static, stateless web app that is equivalent to running the command line tool. I see your point then, I might prefer the command line tool myself instead of the GUI.

Airnode UI is a management tool for Airnode administrators. It’s intended to be run locally by the admin to manage their own Airnodes. It’s not a publicly hosted tool for everyone to use from a web browser.

I (mistakenly?) thought these tools were meant to be like blockchain explorers such as Etherscan where it’s hosted publicly and anyone can go to see Airnode activity and usage statistics with a browser. I suspect some others might have misunderstood like I did.

[enormous]

RRP Explorer is a debugging tool for developers. It’s just a static, stateless web app that is equivalent to running the command line tool. I see your point then, I might prefer the command line tool myself instead of the GUI.

100% correct. “Explorer” is part of the name that probably misleads…

Airnode UI is a management tool for Airnode administrators. It’s intended to be run locally by the admin to manage their own Airnodes.

100% correct. This is its primary mission

It’s not a publicly hosted tool for everyone to use from a web browser.
I (mistakenly?) thought these tools were meant to be like blockchain explorers such as Etherscan where it’s hosted publicly and anyone can go to see Airnode activity and usage statistics with a browser. I suspect some others might have misunderstood like I did.

Except that we do have demo of AirnodeUI.
Publicly hosted for everyone .
That does some work for us like “blockchain explorer” and does show Airnode activity and usage.
But there are limitations for being both “etherscan” and management tool in a demo version.

Direct link to the mainnet usage BTW:

API3 Airnodes