Create API description

Let's create an API description for the interaction with frontend.

This API will have the following functionality:

addProfile()

Creates a new profile - basically a pair of ECDSA keys. This profile is saved encrypted in local storage on the domain (keys.swap.io) and can further be referenced to sign txs.

This method pops an iframe on your website with dialog to create a new profile.

This method will also be used to restore a previously backed-up profile. When addProfile is invoked, a dialog with Restore Profile / New Profile prompts will be shown....

After the addProfile method is executed the frontend will be responsible to lookup all addresses associalted with the profile if there are any known addresses, or prompt user to manually restore addresses.

createAddresses()

Creates one or more blockchain addresses.

This routine should take parameters to create one or more addresses for user based on network, address path, and template used to create an address... Different templates may be used to create addresses for the same address. For example bitcoin address is derived differently by different bitcoin clients.

Our profile is basically a mnemonic phrase, however, using the same phrase you can't get the same addresses in electrum wallet and bitcoind. Therefore we need to define commonly used templates.

The swap.io-networks needs to cointain static network definitions used for deriving addresses for different networks, whereas this repo will cointain the library to actually use the definitions to create the addresses.

I think its logical for the frontend to be responsible for keeping the list of derived addresses, with all the parameters needed for the createAddresses() for each of the addresses derived. The frontend is also responsible for backing them up on server if needed...

Having the derivation parameters for each of the addresses will often be important to restore the funds, hence the address restore paths/params need to be backed up in a centralized and may be decentralized way - as step one it will be kept on the server part of the backend... We will need to think of a way to store the settings in a way that they are disconnected from the actual profile, so that only owner of the profile can know what address derivation parameters are associated with her profile... But storage of the address definitions is not in the scope of this ticket, rather this needs to be kept in mind while designing the API.

signTransaction()

Signs a transaction for an address. In our design, i believe the keys.swap.io doesn't have to be address-aware, meaning.. it doesn't need to have every address derived for a profile stored along the master keypairs. Hence the sign method can take the same derivation parameters that createAddress takes, so it derives a keyPair for each address a transaction is signed with on the fly ...

Another approach is to store the derived addresses with the derivation parameters, on the side of keys.swap.io ... This has an advantage that the sign(), signMessage routine is easy to use - you only pass an address to identify the needed address... however this way we will either need to make keys.swap.io be responsible for backing up the address definitions or to keep the definitions both on frontend and on keys.swap.io

signMessage()

This signs a message - a common function in many blockchains, often used for address owner proves. This shall take similar arguments like in sign() method.

The newrork definitions will be used to sign the messages, many blockchains prefix the signed message with a string prior to signing a message. the prefixes will need to be defined for every network...

verifySignature()

this will verify the crypto signature of a previously signed message.

publicKey()

Returns public key for a specific address.

privateKey()

Pops up a dialog on your website with private key for specific address.

backupProfile()

Pops up a dialog to backup a profile.

The task

The task of this ticket is to describe the API in every detail, with examples from diffrerent blockchains... In particular ethereum, bitcoin (bitcoind), bitcoin (elecrtrum - compatible wallets) ....

Test cases

Test cases for future implementation need to be collected for at least these networks:

bitcoin
bitcoin-testnet
litecoin (as btc-like)
litecoin-testnet
ethereum
etherem-ropsten
handshake (hns)
stellar (xlm)
polkadot (dot)
tron (trx)
solana (sol)

We will need to see how each testcase will look like in API calls...

https://fortmatic.com/ research

похоже https://fortmatic.com/ так же делает кастодиальное хранилище, т.е. отдает ключи со своего домена, возможно стоит перенять их опыт в подключении web3

swaponline / swap.io-keys Goto Github PK

swap.io-keys's People

Contributors

Stargazers

Watchers

Forkers

swap.io-keys's Issues