@AndreasGassmann @shekhar-shubhendu it appears to me that the two proposal are overlapping in one or more area, for example messages being supported.
Can you confirm that this is not the case?

Original issue: It is intentioned to work with two peers transports or transports with multiple actors?

If the first one, then why do we need identification?
If the second one, then can APP-2 introduce itself as APP-1 by intercepting of id that wallet has send to APP-1 in wallet.request.connect method call?

Would be great to add requirements/expectations about transport to AEX-2.

From what I found, Bitcoin, Ethereum, Stellar are using a single name for URI schemas, why do we need two names (ae and aeternity)? From my point of view, it makes development more complicated, each wallet should support both of them.

What if some aeternity: call failed, should aepp in that case try ae: scheme? What if the environment (like registerProtocolHandler) is asking confirmation for adding schema handler and the user agreed for the first one but declined the second? The single scheme will help to avoid such confusing situations.

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1710.md

Is it necessary to have a name of calling instance as a prefix for method name? I think it won't become more complicated if we drop them. Ex: aepp.request.sign => request.sign.

Also, does it have sense to rename methods that are already defined in sdk like address and sign?

https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler#Permitted_schemes
This proposal is inspired by SEP-0007

Can we just omit parameters in that case? Also, that is ¬ stands for?

JSON RPC supports return values of methods. Right now aepp.get.address is notification (without return value). And when this notification emitted by aepp, as I guess, the wallet should call wallet.update.address notification in advice. Straightforward usage of JSON RPC would be calling of aepp.get.address method and getting an address in reply, without introducing of wallet.update.address method and error method that is needed to return an error to aepp.

Can callback URL contain ?, & chars? If yes, then how they should be encoded? I think we should mention it in AEX.

For instance, Example Account Format introduces the name field that is not mentioned anywhere else.

I propose to use txHash to be consistent at least with aeternity node api:

    "/transactions/{hash}" : {
      "get" : {
        "tags" : [ "external", "transaction" ],
        "description" : "Get a transaction by hash",
        "operationId" : "GetTransactionByHash",
        "produces" : [ "application/json" ],
        "parameters" : [ {
          "name" : "hash",
          "in" : "path",
          "description" : "The hash of the transaction",
          "required" : true,
          "type" : "string"
        } ],
        "responses" : {
          ...
        }
      }
    },

https://sdk-testnet.aepps.com/api

Also would be great to explain what is it (similar issue: #65).

For example:

• wallet.request.connect: connection request sent by wallet containing an identifier that it wants to assign to the aepp/sdk. The generated identifier must be unique and must conform to the UUID v4 standards.

  json-rpc 2.0 structure:

  Request:
  {
    "jsonrpc": "2.0",
    "method": "wallet.request.connect",
    "params": {
       "id": "<unique_identifier_uuidv4>"
    },
    "version": 1
  }
  
  Response:
  {
    "jsonrpc": "2.0",
    "result": {
       "id": "<unique_identifier_uuidv4_as_request>",
       "name": "<aepp_name>"
    },
    "id": 1,
    "version": 1
  }

replace with something like this:

wallet.request.connect

Connection request sent by wallet containing an identifier that it wants to assign to the aepp/sdk.

Parameters

Object

• id - The unique identifier, must conform to the UUID v4 standards

Returns

Object

• id - The unique identifier as in request
• name - Tha name of aepp

I think it is less typo-prone and should make reading easier.

JSON-RPC 2.0 defined two types of requests: actual method call and notification. Notification is used when the client is not interested in the return value. As far as the current version of AEX-2 doesn't explain return value for aepp.get.address method I was thinking that it is notification and any errors should be returned in a call of another method (because the server can't reply for notification with error). From #44 I understood that it is not true. To fix this confusion I think we should either define return value for all methods nor mark such methods as not notifications.

Its current value ed25519 is ambiguous, for example, it can be just a private key, or a key that is for the derivation of child account that will use the same curve for signing. Is it correct to use AEX-3 for arbitrary data or it should be somehow related to user accounts?

see #37

Can't it be handled on transport layer?

Is it JS SDK? I think 2, 5 AEXs should explain communication between instances (aepp <-> wallet, and wallet <-> wallet) without mentioning of the existing project that is supposed to implement this, otherwise, it gets more confusing. I think these AEXes should be explained in a way that makes possible to implement them without relying on existing SDK package.

I propose to implement two methods: one for getting a current account, and the other one for getting all accounts.

JSON-RPC specification doesn't say anything about version field in the root of response/requests objects. If it is needed to store protocol version it should use params, result, or method name to be compatible with JSON RPC.

I have seen the usage of version field in AEX-2 and AEX-5.

Looks like that currently it implemented implicitly by using of JSON-RPC in an unusual way: aepp sends aepp.get.address notification, wallet should send wallet.update.address notification in reply (#46). We can make it more explicitly and clear by:

• apply proposal from #46
• add methods for subscribing/unsibscribing to account changes on aepp side
• add a notification for pushing a new account value on wallet side, that should be called only of aepp subscribed

In what cases each of them should be used? If we are talking about applications based on aeternity is this terms meaning same or not? Do we have any preferences or guidelines here?

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-831.md
Adding of prefixes will allow future extendability of the proposed URI scheme.

In the 2nd step, "Check if the address exists or not" this will check address existence in the user's accounts or that address exists in blockchain?

As I understand schema:address means an intention to send some tokens in Bitcoin and Ethereum, not just account opening, I think we shouldn't break that semantic in this proposal. It can be used in cases like if some charity is collecting donations without exact amounts of tokens to send. Also, the wallet shouldn't check account existance, because that charity can generate a new address each time to track user conversion.

In the 4th step, maybe account not found shouldn't be in quotes because we are not expecting the exact message but some message that explains this?

In AEX-2 wallet and aepp exchanges with names as strings by calling of wallet.request.connect method. I think just name it is not enough. In Base app we are fetching Web App Manifest of aepp that we are taking to, we can do it without additional standards, just fetching manifest by aepp url.

I propose to make peers metadata a separate standard or use Web App Manifest objects instead of just app names.

Calling aepp.subscribe.address({ type: 'unsubscribe', value: 'current' }), in other words to call subscribe method for unsubscription looks illogical.

Example in BIP-0021. One more example: EIP-681 is more flexible than BIP-0021 and this AEX, it defines scientific notation and an ability to send amounts of tokens on top of ethereum.

In what cases each of them should be used? If we are talking about applications based on aeternity is this terms meaning same or not? Do we have any preferences or guidelines here?

In Base app we are using account mostly.

Because of possible confusion with android deep links/ios universal links

As I see technically it can, because aepp.request.sign returns a signed transaction (not a signature of the transaction). We need this feature for the Base app to allow the user to change transaction fee before signing. Also, it should be useful to change nonce in some cases. Would be good to explicitly mention the possibility to change a transaction on signing in AEX-2 if it is intentioned behavior.

AENS names are more readable than aeternity addresses.

As I understand, all AEXs related to aeternity, so it is not necessary to mention it additionally.

It makes more difficult to use third party RPC server/clients that by default won't add request to predefined errors like "Method not found".

As I see error messages of JSON-RPC specification uses capital letters only in the first word and words that mean entities defined there (like Request), maybe we should do the same instead of making all words starting with a capital letter?

error: used to communicate any error occurred. Embedded data field in each error object MUST contain the request that triggered it.

JSON RPC supports error objects as part of the response object, so I think it is not necessary to introduce an additional error method and force to pass all error through it ("used to communicate any error occurred"). In which cases error method is needed?

In some cases (like usage of vue-router) it is easier to accept parameters in a path instead of a query. We can use URL templates to allow the vendor to set a way how parameters should be inlined into a callback URL. For example, this request:

aeternity:ak_.../125.12/myaeshop?callback=https://myaeshop.com/verify/{txId}/

can redirect the user to

https://myaeshop.com/verify/th_.../

This approach supports the initial proposal as well:

aeternity:ak_.../125.12/myaeshop?callback=https://myaeshop.com/verify?txId={txId}
=> https://myaeshop.com/verify?txId=th_...

Also, this approach can help to get rid of the return param in "Sign and Broadcast" method by passing it in the template.

I'm not sure how placeholders can be encoded into URL, I have to approaches:

• %paramName, used in registerProtocolHandler
• {paramName} taken from URL Templates

In both cases, special chars like %, {, and } should be encoded to %25, %7B, and %7D correspondingly and then be decoded by a wallet.

Some transports like postMessage interface provide own identification mechanisms. That in the case of postMessage interface (origin field) even more secure that proposed solution, because of the origin field provided by a browser so can't be faked. This makes reasonable to make identifiers proposed by AEX-2 optional.

As I see, currently wallet cat requests updation of its network details by wallet.get.network, then aepp should call aepp.update.network, passing only networkId. In which case may be needed to update network from aepp? More reasonable is to be able to get the current network id from the wallet, to be able to show, for example, special UI if the use on a test network.

Also, I'm not a fan of this idea because, I see that wallet is supposed to extract common functionality from aepps including network switcher, as well as managing of several account and so on.

Bytheway, that should happen if received networkId is unknown for a wallet?

Get network flow has the same issues as getting of address #46.

As proposed in https://hackmd.io/@0GocXL2UTk-75Bt3XDppsA/BJObJntjQ?type=view#3-Wallet-app-opens-the-deep-link-to-the-source-app

It makes easier for aepp to understand what happened if the request didn't succeed.

Wallet methods

• what is return value of aepp.get.address method? extracted to #46
• in what format tx should be passed to aepp.request.sign method? I see several options: hex string, an array of bytes, tx_.. string, the current explanation is too ambiguous extracted to #65
• in what format tx returned from aepp.request.sign method? extracted to #65
• for what reason aepp.request.sign and other methods should return id received in arguments?

Aepp methods

• what is return value of wallet.get.network method? extracted to #50
• how aepp can use a list of connected account returned from wallet.update.address if it can't switch between them? We either should drop it or add a method for account switching. extracted to #47
• can wallet.update.address be simplified by extracting of getting a list of connected accounts into a separate method? extracted to #48
• wallet.update.address method should explain parameters explicitly, not only by providing an example extracted to #45
• for what reason in which cases wallet.broadcast.tx and wallet.verify.tx methods are necessary? extracted to #63

Common issues

• add errors that can be thrown by method to explanation of every method remove errors explanations from wallet.broadcast.tx, wallet.verify.tx for consistency with other methods extracted to #66
• how aepp.update.network and wallet.get.network methods are supposed to work? extracted to #50

AEX-5 mostly duplicates the functionality of AEX-2 I think we should unify them into AEX-2. So, if we want to connect two wallets, the "master" wallet should communicate with "slave" wallet as with aepp. (this proposal also mentioned in #42)

Related PR and discussion: #18

Or what is the purpose of locked flag in aepp.request.sign params? (related issue: #55)

"Invalid Transaction" and "Invalid Address" exceptions is a special case of "Invalid params", do we need to handle them separately?

That should aepp sent in response if addresses are correct but they sent in an array instead of object?

Can we use URI in that case? If not then why?

As I see, communication should start with sending of a random id by the wallet to aepp, and later aepp is identified by this id. What if the user has used some aepp before and give it some permissions, and when he opens it back does AEX-2 can identify this aepp as previously used? Or wallet and aepp developers should build one more identification mechanism on top of AEX-2?

Wallet returns its current address and other account addresses it may help the SDK in getting signature for.

• For what reason wallet should return other accounts? How it can help in getting signatures?

https://github.com/aeternity/AEXs/blob/9e7a9360d8fb942ff32a4492deb2e289b51e3aff/AEXS/aex-5.md#proposed-process-with-inter-wallet-communication

• What is the difference between direct and indirect links?

• Why don't make names of these methods same? (excluding difference in wallet/aepp)

• AEX-5 mostly duplicates the functionality of AEX-2 I think we should unify them into AEX-2. So, if we want to connect two wallets, the master wallet should communicate with slave wallet as with aepp.