Improve Integration Experience - Project plan

Rework navigation and user flow

• Currently, the site takes a “list information” approach and is not geared to a specific user (e.g., wallets, exchanges, etc.)

@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:

done

Building an API node and upgrade process (for wallets and exchanges)

• Create a document on the different paths to building an API node

done

Integration guide

• Fixes to new integration guide from Pawel

done

Indexing transactions

• Add more detail on indexing transactions

done

Submit transactions: Packing and Signing

• Add more detail on packing and signing transactions

done

BP Voting and Proxying

• Updating voting page to clean up and add intro on how to research BP activity

PR:

done

general BP info

• Links to different BP resources

PR:

done

FIO Versioning

• Port Versioning document from confluence

Dev hub page:

done

Pub/Priv Keys

• Info on deriving and validating FIO Pub/Priv Keys

Devhub page:

done

BP Fee setting

• BP Fee setting - update with links to tools

PR:

done

UX best practices

• Document best practices for UX (@Emily Mader )

History API

• Add 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 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:

Integration Checklist

• Complete integration checklist page.

• Include list of which integrations are done for which partners

Certification

• Complete certification pages. Include map all currencies and review on

Free FIO Addresses on private domains

• We need to better describe the options for registering “free” FIO Addresses on domains that will be kept private.

EOSIO content

• Use content similar to eosio

Devhub Readme

• Create readme similar to eosio

Ecommerce Integrators page

• Home page link for ecommerce integrators - work with Pawel

FIO Dev Guide

• Contributing to FIO dev page

Example:
(not sure if that’s the post I was thinking of, but there are others that talk about this)

Multicasting

• Create document on accessing FIO nodes (multicasting)

Address/Domain renewal

• Add page on address/domain renewal

API Error Codes

• Clean up error codes (and make generic) some 403s look incorrect.

• Add 202 response to all actions (make this generic). See old site

OBT and Request auth checks

• Writeup on authority checks with FIO Requests

FIO Contract development

• FIO Contract development - Description of how to create actions and getters in contracts

Mapping options

• Document different mapping options

Compatibility matrix

• Matrix for different releases

Known issues

• Document the known issues and helpful hints with SDKs, APIs, and chain.

FIO Glossary

• Add a glossary of FIO terms

Devnet setup

• Add a section on devnet setup

API - addaddress

• Add explanation of chain level mappings

FIO API

Leverage existing EOSIO libraries and code

• FIO chain code has diverged from EOSIO core code making it difficult to “plug and play” with existing EOSIO tools

Support for unique FIO endpoints

• Support for transaction-based API endpoints creates release overhead and could cause confusion

Complexity of chain code releases

• The need to update the chain code for every new getter adds release overhead.

Simplify Fees

• Change how max_fee works to include a buffer on the current fee set by the BPs

SDKs and third-party libraries

Simplify SDK and reduce upgrade complexity

• We would like to reduce the number of upgrades required by integrators

  • Integrators should be able to access all Mainnet features, including getters and contract actions, without having to upgrade.

  • SDK updates should only be required for bug fixes and when breaking changes in the API are introduced.

Reduce complexity of SDK

• A proliferation of getters and api endpoints increases the size and complexity of the SDK

Serialization and encryption

Standardize and simplify serialization and encryption libraries

• The encryption used in FIO Requests and OBT Record actions is non-standard

• There are issues with the fiojs library including encryption libraries, difficulty of integrating with other EOSIO tools, and maintaining a copy of eosjs

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.