Improve Integration Experience - Project plan
- Eric Butz
Links
Initiative: https://fioprotocol.atlassian.net/browse/WP-153
Project Wiki: Improve FIO Integration Experience
Devhub and Integration Documentation
Item | Summary | Links | Status |
|---|---|---|---|
Rework navigation and user flow |
| @David Gold suggested we migrate to target specific integrators: Wallet Integration, Exchange Integration, etc. We would pull out common tasks into shared pages, but would gear the integration language to be specific to the different use cases. Suggested outline: https://docs.google.com/document/d/1fu0KJr_pYg75WJN7zgtvx459vKUzPh2iFWfGhAsTpFM/edit?ts=60888ed6 | done |
Building an API node and upgrade process (for wallets and exchanges) |
| Update Ubuntu build instructions · Issue #95 · fioprotocol/fio-devhub Exchange node upgrade process · Issue #7 · fioprotocol/fio-devhub | done |
Integration guide |
| done | |
Indexing transactions |
| Add more detail on indexing transactions · Issue #50 · fioprotocol/fio-devhub | done |
Submit transactions: Packing and Signing |
| Add more detail on packing and signing transactions · Issue #138 · fioprotocol/fio-devhub | done |
BP Voting and Proxying |
| Improve voting/proxy information · Issue #20 · fioprotocol/fio-devhub PR: Update voting, proxy, and bp research by ericbutz · Pull Request #177 · fioprotocol/fio-devhub | done |
general BP info |
| General BP info · Issue #27 · fioprotocol/fio-devhub PR: Update voting, proxy, and bp research by ericbutz · Pull Request #177 · fioprotocol/fio-devhub | done |
FIO Versioning |
| Port Versioning document from confluence · Issue #22 · fioprotocol/fio-devhub | done |
Pub/Priv Keys |
| https://github.com/fioprotocol/fio-devhub/issues/11 | done |
BP Fee setting |
| https://github.com/fioprotocol/fio-devhub/issues/108 PR: Update voting, proxy, and bp research by ericbutz · Pull Request #177 · fioprotocol/fio-devhub | done |
UX best practices |
|
| |
History API |
|
| |
Purchase of domains and addresses | Simple explanation of how to purchase a domain or address if you are a new integrator. How to transfer if it is owned by the foundation. Also the pros and cons of holding the keys for a domain versus having the foundation hold the keys. |
| |
Free FIO Address workflow | How to integrate free fio address giveaways into your site |
|
|
| In https://developers.fioprotocol.io/docs/how-to/transactions be more explicit that an action consists of account, name, authorization and serialized action data. May want to add an action type to the API. There is an example there under Transaction Schema, but needs more detail |
|
|
Integration overview | @ericbutz @pawmmm I think I’ve seen this question before regarding TPID and max_fee so let’s think through how we can explain these concepts up front. Same for the need to pack and encrypt certain body payloads. I know it’s there buried in the details but mentioning there terms and explaining them up front in a getting started section may be useful. |
|
|
Complete SDK main page | Need to populate with all SDKs: https://developers.fioprotocol.io/docs/sdk/ |
|
|
Integration Checklist |
|
| |
Certification |
|
| |
|
|
|
|
Free FIO Addresses on private domains |
|
|
|
EOSIO content |
| https://developers.eos.io/welcome/latest/introduction-to-eosio/index https://developers.eos.io/manuals/eosjs/latest/how-to-guides/index |
|
Devhub Readme |
| https://github.com/eosdac/eosdacio-website/blob/master/docs/02-create-page.md |
|
Ecommerce Integrators page |
|
|
|
FIO Dev Guide |
| Example: https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md |
|
Multicasting |
|
| |
Address/Domain renewal |
|
| |
API Error Codes |
|
| |
OBT and Request auth checks |
|
| |
FIO Contract development |
|
| |
Mapping options |
|
| |
Compatibility matrix |
|
| |
Known issues |
|
| |
FIO Glossary |
|
| |
Devnet setup |
|
| |
API - addaddress |
|
|
|
APIs and SDKs
Item | Summary | Links | Status |
|---|---|---|---|
FIO API |
|
|
|
Leverage existing EOSIO libraries and code |
|
| |
Support for unique FIO endpoints |
| https://fioprotocol.atlassian.net/wiki/spaces/DAO/pages/10617063 |
|
Complexity of chain code releases |
|
| |
Simplify Fees |
|
| |
SDKs and third-party libraries |
|
|
|
Simplify SDK and reduce upgrade complexity |
| https://fioprotocol.atlassian.net/wiki/spaces/DAO/pages/35455578 |
|
Reduce complexity of SDK |
| https://fioprotocol.atlassian.net/wiki/spaces/DAO/pages/35455578 |
|
Serialization and encryption |
| https://fioprotocol.atlassian.net/wiki/spaces/DAO/pages/96469009 |
|
Standardize and simplify serialization and encryption libraries |
| Luke: I’ve had good success so far using AnchorLink, though it is front-end specific and currently requires Anchor. That said, under the hood, is EOSIO Core which seems to be a useful improvement over eos.js or fio.js and it supports FIO well (such as allowing you to pass in a legacy prefix such as FIO when getting public keys). I think this is a really important problem to overcome. It should be easy for any developer to quickly work with OBT data, send, receive, cancel, and approve FIO Requests without having to import tons of extra code or libraries or sdks, especially if most everything of what they want can be done via things like EOSIO Core from Greymass. If existing tools for interacting with EOSIO chains will work well with FIO, we should embrace them and provide very minimal code needed to do FIO specific things. We also need to figure out how “authenticator” wallets like Anchor, Metamask, and Ledger (hardware) wallets can work with OBT data. What’s the path of least resistance for them to get up and running quickly? What’s the minimal code footprint we’ll be asking them to introduce? How will this work with secure enclaves coming in the future with crypto-enabled hardware devices like phones. |
|