wallet connection research & PoC

[marc0olo]

Requirements (Result workshop at CryptoCastle, 13.09.2022)

• End-to-End Encryption (if centrally relayed)
  • How to do initial key exchange?
• Read Requests
  • Address
  • e.g. for Deeplink/Hardware where request frequency is limited (wallet/user has to provide consent to app to make it work properly)
  • Request multiple at once
• Node Connection Wallet Side
  • NO EXCEPTION, PRIVACY!!! → prevent malicious network, dapp or node operators from collecting private data (account address, node url)
  • default → no node data leaked to application without prior consent
• Protocol needs to be defined
  • error-handling
  • payloads/messages/requests in each direction
  • suggestion wallet actions
    • change node
    • change network
• Any platform to any wallet connection
• One Line of Code (Aepp Side)

TODOs

• [ ] Initial Research
  • [ ] Look at existing wallets and connection types (how do they fit into our requirements?)
  • [ ] Research for blockchain-agnostic solutions
• [ ] Design-Document for the connection (technical communication, protocol specification)
• [ ] Build a PoC (with one line of code)
• [ ] Come up with a new AEX proposal for wallet-connection

Historical Discussion / Content

this was discussed many times and raised by @nikita-fuchs a lot of times. not sure what implications we have here and if AEX-2 (which is "withdrawn") is the right approach here.

this definitely needs some discussion. here an old forum thread about this:

• https://forum.aeternity.com/t/easier-superhero-wallet-integration-in-js/9269/2

we also have some other open issues regarding wallet-connection, signing and AEX-2:

• https://github.com/aeternity/aepp-sdk-js/issues/907
• https://github.com/aeternity/aepp-sdk-js/issues/1068
• https://github.com/aeternity/aepp-sdk-js/issues/1255
• https://github.com/aeternity/aepp-sdk-js/issues/1103
• https://github.com/aeternity/aepp-sdk-js/issues/1088

[sunbx]

Compared with ETH, AEX2 can indeed be optimized, and ETH is more convenient to use

[subhod-i]

Thread-comment: https://forum.aeternity.com/t/easier-superhero-wallet-integration-in-js/9269/18?u=subhod-i

Action items

• Implement requestNode feature
• Remove dependency of Node details in RpcAepp stamp. Route requests through wallet(Provide an example).
• AEX-** : Add support to smartphone deeplink communcation. Introduce a new standard in the SDK to enable deeplink communication. Provide an interface to support different wallet communication types. Right now the interface will have Browser wallet, DeepLink wallet, and Hardware wallet types.

[marc0olo]

@kenodressel @thepiwo shall we use this issue for the further wallet-connection investigation?

[thepiwo]

sure, why not

[davidyuk]

I'm planning to do a minor improvement here: onSign callback in AeSdkWallet should be removed and signTransaction method of Account used instead.

The reason is that in case we using Ledger HW the signing confirmation actually happens on the device side (while calling signTransaction). In current architecture, we have either ask user to confirm signing twice (in onSign and on Ledger side) or automatically allow the request in onSign depending on the account type and then the rejection won't be handled properly.

In preparation for this, I've implemented Ledger support on sdk side: https://github.com/aeternity/aepp-sdk-js/pull/1685