feat: Add a Wallet interface

[dariusc93]

In the beginning, one part of warp was to deal with cryptocurrency (though was not limited to it). The base at the time was solana, and although solana was used initially for identity and friending (apart from other smart contract aspects), one part that was discussed a bit but never implemented was a interface to handle wallet side such as transacting, etc. Currently we use ipfs as the main component for identity, files and chat in warp, however we still lack such a interface (and thus any implementation) for dealing with crypto wallets.

The interface should provide functions for (but not limited too):

• Listing addresses and transactions
• Listing tokens from smart contracts
• Transacting (sending/receiving crypto between users)
• Signing and validating messages (although this can be done with the private/public key directly, cryptocurrencies are known to have derivation path, which can generate its own set of keys that can be used for signing/verifying messages (including transactions) so this could be done on the interface itself based on the provided key).

While it would be preferred to have each wallet implementation to be separate (to reduce complexity and provide options for those who wish to switch between different implementations in the future), a single implementation can include multiple wallet implementations. The interface may also introduce associated types to reflect for specific address types (if the interface doesnt come with a generic item to represent different address formats and allow the implementation to parse accordingly), different cryptocurrencies (if multiple is implemented in a single implementation), etc.

Note:

• This interface should be detach from the other components, but internally, the implementation can interact with other components as needed (eg sending addresses between friends would require interacting with MultiPass and RayGun, etc.)
• warp core library has a helper function to generate a ed25519 keypair based on the mnemonic phrase (the implementation is based on ed25519-dalek-bip32). If other implementations are used, this helper function should probably be changed to represent the correct keypair.
  • warp-ipfs also depends on ed25519 so if the main keypair is going to be used, this should be kept in mind if attempting to derive from the keypair used there.
  • We can also store the seed generated in tesseract and allow implementations to derive a keypair from that accordingly.
  • Could possibly benefit from Replace DID key with inhouse key. #324
• Information here TBD

[ashneverdawn]

I think it's worth considering implementing this as an uplink extension.

The backend of a wallet is really its blockchain. And there isn't really a universal way to interact with all the different types of blockchains - they all have different features or different ways of implementing them that directly affect how the the end-user would interact with it.
That said, we probably still want to be able to use the same recovery phrase for all of them, so we'd need at least some interaction with Warp still.

I think it would make sense for third parties to want to create their own wallet extensions. And ours could serve as a model for anyone wishing to do so.

[dariusc93]

Do keep in mind the extensions on uplink is different than what is here on warp as the extensions there are more of a plugin that add interaction to the UI.

With that said, might be more appropriate to have it on warp, although I do agree there isnt a universal or simple way of interacting with different blockchains, but having a interface that would use common functions that implementations can use would be a start for its usage as the implementations would handle the bulk load of dealing with it. Of course if @InfamousVague wish to have this solely on uplink side, then that could be done there instead.

[ashneverdawn]

Also, one big benefit of having it on the warp side is it might make it easier to unify info from multiple blockchains together. For example with wrapped or bridged assets across multiple chains. Creating implementations for every type of blockchain would be endless work though, so we'd probably end up creating implementations for just the most popular ones.

If the uplink extensions are only intended to add interaction to the UI, then perhaps it's best to stick to this pattern. Although I suppose we can't stop a 3rd party from adding whatever functionality they want through an uplink extension, be it a wallet or anything else.