Dapi for N3

[lllwvlvwlll]

I'm a proponent of standardizing the protocol as long as it does not impact the transport layer of any solution. Ultimately, most of this interfacing will be handled by sdks which abstract a lot of this so its primarily a standard for tooling developers.

I would also like to request that we generalize the name of this standard since dApi is already a software implementation which also includes a transport layer.

[melanke]

Hello, I just have a few minor considerations regarding this specification:

I've tested Dapi with NeoLine in the past and also by checking it's documentation, I understood that the Chrome Extension doesn't need a proper "connection" process, the dapp receives the wallet information automatically.

1) This is very different from WalletConnect 2.0: the dapp will need to show a code for the user to input on the wallet, this can be done via QRCode or Deeplinking, so it would be interesting to have such event to allow the dapp to handle such UI interaction.

2) On this specification proposal there is an authenticate method. I am not very sure if it was designed with the connection purpose, to continue the discussion I will assume it was. So, here is my first question: What is the purpose of the AuthenticationChallengePayload.nonce property?

3) The Network enum doesn't allow tests on a private network. And AuthenticationChallengePayload.network only accepts a single network, which is fine on most of the cases, but we tought that it would be interesting for the dapp to accept connecting with multiple networks, so the user on it's wallet can control if it will be used for tests, private network or production. This would be great for development purposes, it would make dapp development way easier, testing on the private network before sending to testnet or mainnet.

4) Again, on the connection process, WalletConnect expects the Dapp's meta-data. This is used to show the dapp's name, icon and other information on the wallet. The metadata has this format:

export type DappMetadata = {
    name: string
    description: string
    url: string
    icons: string[] // honestly, we could allow a single icon, so it don't need to be an array
}

I believe it could be an interesting addition.

5) Both NeonWallet's WalletConnect integration and NeoLine's Dapi integration have the following methods that I consider important and could be added to the specification:

• invokeMultiple. On NW we are accepting an optional parameter on each invocation called abortOnFail: it adds 0x39 on the script, so the whole transaction will be aborted if this invocation returns false, which might be very important for transactional operations.
• signMessage

6) The following methods are less important because they could be called directly from the dapp, without the need of the wallet integration, but they are pretty handy, specially to avoid a Neo javascript SDK dependency on the dapp. On NW we are calling those methods without the need for the user authorization, since they are pretty secure, so the dapp and the wallet has a smooth interaction:

• verifyMessage
• invokeRead
• invokeReadMultiple

7) Being able to easily convert an Address or ScriptHash to hash160 would also be pretty handy. Both NeoLine and NeonWallet handle this differently but we could agree on a single method.

[erikzhang]

On this specification proposal there is an authenticate method.

Many websites require users to log in to provide services. The authenticate method provides an identity authentication scheme for users to log in to websites using blockchain addresses.

verifyMessage

I think it should be provided in SDK.

invokeRead

It has been renamed to call.

Being able to easily convert an Address or ScriptHash to hash160 would also be pretty handy.

I think it should be provided in SDK.

[devhawk]

What is the relationship of this to WalletConnect? Are they complementary or competitive?

[erikzhang]

What is the relationship of this to WalletConnect? Are they complementary or competitive?

Dapi is a protocol for communication between plug-in wallet and dapp via javascript. And WalletConnect allows communication between the two through a centralized server to relay messages.

[EdgeDLT]

I think it should be possible for a dapp to provide a signature to a transaction created using the Dapi. From what I understand it should not increase risk for users, only for dApps that need to be careful they don't provide a signature to a malicious transaction.

My imagined use case is for subsidizing transactions as the first signer, but I imagine there are others situations where apps might want to join in a multisig or approve certain contract calls.

[erikzhang]

I think it should be possible for a dapp to provide a signature to a transaction created using the Dapi.

maketransaction and sign are designed for this situation.