Giters

fioprotocol / fips

FIO Improvements Proposals

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

API autodiscovery and reliability

cc32d9 opened this issue · comments

commented

Wallets need an automated way to find the FIO API endpoints. Requirements:

  • Only FIO block producers and authorized API providers should be included

  • The API endpoint information should be verifiable (for example, the content should be signed by each API provider)

  • The discovery method should be resilient and decentralized.

  • A monitoring system should indicate which endpoints are currently offline, so that the wallets don't try connecting to them.

My old project can be used as a starting point to develop the required solution: https://github.com/cc32d9/eos.apidirectory

commented

The autodicovery service should also include the FIO Testnet, so that wallet developers have a complete testing infrastructure

commented

here are my reliability check scripts for Nagios and HAproxy:

https://github.com/cc32d9/eos-nagios-plugins

https://github.com/cc32d9/eosio-haproxy

commented

The monitor needs to check that API return proper Chain ID. Also ideally, the monitor should send periodic transactions to verify that API endpoints are fully functional.

The check_eos_watchdoggiee script can be used for that. It sends a transaction to watchdoggiee smart contract and checks that another API endpoint returns an expected result.

commented

We have https://wax.stats.eosusa.news we could port over for FIO testing. Probes are light python scripts that any bps could run and independently provide results thst are then presented via the web interface, curated json of endpoints by region/service, and could publish on chain as well.

Probe script: https://github.com/eosusa/rpcmonitor-probe

commented

I'd love to see more discussion on this, especially considering the input on the user experience if an endpoint goes down. @pawmmm is this something we should put some time into? Hard coding APIs with each wallet release... just seems like a problem waiting to happen unless the wallet/sdk has a way to mark an endpoint as unresponsive or something.

commented

Weve already started building the system to find, test, and historically track all the chain nodes from all around the world, so instead of reinventing the wheel, maybe we port over a copy for fio and add the ability to extract list of endpoints? Then u hardcode in the multiple sources of the json feed to the wallet so it dynamically uses best nodes. Being a wallet, seems perfect for providing endpoints specific for that region. Would that be something we could use the wps system for to offset the dev costs?

commented

@eosusa we were just discussing this on our standup today. I'd like to see this get thought through as an initiative that also includes the needs of the wallets. I also want to keep FIP 14 in mind as the needs may change as we change the approach to security of the API node bootstrapping and data validation process. Again, the wallets should be involved so we can design something that works for everyone.

One idea I had was to create a pool of funds or bounty as the initiative progresses into an opportunity and finally into a worker proposal and the payouts on the proposal would just be for the work done, but the group submitting the proposal could work together (for example @cc32d9 has some thoughts as well) and distribute the pay as they see fit. My goal is to get more groups working together to accomplish shared goals without having to add the administrative burden of figuring out who should get paid what according to their specific level of contribution. I'm hoping that can be done within the team accomplishing the goal. Makes sense?

See the link Pawel shared above regarding the terms "initiative", "opportunity", and "worker proposal". Depending on any on-chain smart contracts needed, it may migrate into a FIP as well.