aeternity / aexs Goto Github PK
View Code? Open in Web Editor NEWAeternity expansions repository — application layer standards
Aeternity expansions repository — application layer standards
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.
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:
Connection request sent by wallet containing an identifier that it wants to assign to the aepp/sdk.
Object
id
- The unique identifier, must conform to the UUID v4 standardsObject
id
- The unique identifier as in requestname
- Tha name of aeppI think it is less typo-prone and should make reading easier.
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.
"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?
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?
Calling aepp.subscribe.address({ type: 'unsubscribe', value: 'current' })
, in other words to call subscribe method for unsubscription looks illogical.
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?
Can we just omit parameters in that case? Also, that is ¬
stands for?
AENS names are more readable than aeternity addresses.
see #37
For instance, Example Account Format introduces the name
field that is not mentioned anywhere else.
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.
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-831.md
Adding of prefixes will allow future extendability of the proposed URI scheme.
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.
@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?
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)
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".
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.
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.
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
?
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?
Wallet returns its current address and other account addresses it may help the SDK in getting signature for.
AEX-2 method names | AEX-5 method names |
---|---|
wallet.request.connect | wallet.channel.initiate |
wallet.disconnect.aepp | wallet.channel.close |
aepp.request.sign | wallet.sign.tx |
wallet.broadcast.tx | wallet.request.broadcast |
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.
Can't it be handled on transport layer?
Can we use URI in that case? If not then why?
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?
As I understand, all AEXs related to aeternity, so it is not necessary to mention it additionally.
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.
aepp.get.address
method?aepp.request.sign
method? I see several options: hex string, an array of bytes, tx_..
string, the current explanation is too ambiguousaepp.request.sign
method?aepp.request.sign
and other methods should return id
received in arguments?wallet.get.network
method?wallet.update.address
if it can't switch between them? We either should drop it or add a method for account switching.wallet.update.address
be simplified by extracting of getting a list of connected accounts into a separate method?wallet.update.address
method should explain parameters explicitly, not only by providing an examplewallet.broadcast.tx
and wallet.verify.tx
methods are necessary?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.
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?
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:
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler#Permitted_schemes
This proposal is inspired by SEP-0007
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?
Can callback URL contain ?
, &
chars? If yes, then how they should be encoded? I think we should mention it in AEX.
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.
Or what is the purpose of locked
flag in aepp.request.sign
params? (related issue: #55)
Because of possible confusion with android deep links/ios universal links
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.
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:
In both cases, special chars like %
, {
, and }
should be encoded to %25
, %7B
, and %7D
correspondingly and then be decoded by a wallet.
Related PR and discussion: #18
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).
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.