Formats for QR codes, URIs, NFCs, ...
- Edited
well, the QR is pretended to be read by a computer, not by a human. Not much people cares about what the URL contains, if the app you trust is telling what it reads, it is enough.
We can decide a key-value language, and then make a XDR version based on that. Having two ways for two user uses.
QR codes must be as clear as possible, and could benefit from the XDR version as normally it is expected that the user has his wallet active to read the code.
Website applications could use the URL version, so the app is getting opened, ready to deal with the request.
I was thinking about encoding the XDR version inside base64 to add it to a URL, but it may end up taking the same amount of bytes. So no point to do that.
I worked a bit today in my C++ SDK, now i will switch to define a XDR/URL version proposition based possible operations and some others proposed here.
We could just define a final deadline, like 1 of September (or when ever), to present propositions and give opinions, and decide then by a poll between the ones cared about it, so people can use this for the next challenge. Then we all will speak same language!
EDIT: After some tests, i came to the conclusion that the way to go is to have these extra fields key-value to define actions not considered in the stellar SDK (the ones commented in this thread, import wallet, callback, user information not prettended to be saved in the net, etc..) and a key-value to include XDR operations.
Still, the result of this can be too big, like 250 bytes for a single transaction with not much extra data. That means QR version 10 with low ECC.
But!! if we apply the lazy way of reducing entropy/size, deflate+zlib header, we get to ~120 bytes that can fit in a QR version 6 with low ECC.
Why that stress with QR code sizes?, well, that numbers are for 1 tx operation without much extra data, what if you want to do more complicated stuff or include more data.
For the ones wondering why Low ECC in QR. Well, we will have ECC at QR level, then CRC at zlib level and then stellar address checksums. I would even add a header indicating the size of the decompressed zlib to discard on time corrupted data.
ECC in QRs are though fot use case of damaged or dirty QR codes. So we should use high level when printing, and low level when displaying it on a clean screen.
To keep things a bit easier, i dont see the point of having a readable url encoding, as it will get very complicated with non trivial operations. I would keep same format for urls, just encoding the same in base64.
It does sound complicated. How about someone else's proposal to define new URL in stellar.toml of every wallet for user approval? Of course it won't solve every problem, but 95% of use cases may be covered.
Looks like this:
stellar.toml will have new url defined
CONFIRMATION_URL=https://papayame.com/confirmation
On merchant website user enters his federated address, like umbre1*papayame.com.
It resolves to stellar.toml and submits prepared transaction XDR to defined CONFIRMATION_URL. Wallet will parse it and show summary to the user, user can confirm or reject with 1 click.
pros:
- getting user account before the transaction is useful for refund purposes
cons:
- doesn't work if you're offline
- XDR format needs to be extended to include useful operations, such as account import. Such payload doesn't need to be signed and submitted to the network, but still makes sense to keep similar format.
- open federation services which are not wallets won't be able to support that, therefore confuse some users
- requires some spamming protection, since action maybe initiated by anyone
Well, i wrote my proposal about a XDR format.
i uploaded it here
https://github.com/bnogalm/stellar_ideas/blob/master/stellar-request.x
Feel free to suggest changes, make your own version or completely different approach.
i have doubts about putting everything in the same level, or keep 2 groups of information, as is a bit more clear.
I did some tests and zlib is really nice for QRs, as address end up appearing multiple times, XDR uses 4 bytes for enums and 4 bytes alignment leaving lot of zeros around. It makes possible to fit more than the double of data.
Hey guys, I am late to the party but interested in this topic. I'm looking for starting a payment request on Android apps so wanted to know if the stellar protocol has been standarized for Android/Mobile intents?
Something like stellar:{operation}?{arg=val}... would suffice so what's the consensus? What are wallet developers using?
- Edited
Being payment the most used I suggest the following uri format:
Basic payment, assumes native asset:
stellar:payment?address=G1234...&amount=100Common advanced payment, assumes memo type as text, if needed specify memo_type as argument:
stellar:payment?address=G1234...&amount=100&asset=USD&memo=123456Full payment uses all possible values for a payment operation, not shown here but you can imagine it. Right now I am working on a Stellar Marketplace and it is extremely important to allow users to send a request for payment to Stellar wallets so instant purchases can be achieved and the user experience will be the best in any platform ever.
- Edited
I suggest a new idea.
Lets each one implement a different format.
Collect them.
Then create a regexp to recognize all them.
And call it "Stellar TIFF" or TISF
For the ones didn't need to support TIFF:
https://www.dpreview.com/forums/post/41593691
- Edited
I added another QR-code format proposal to the already existing dzham format that adds "Transaction Envelope" that I now have some what documented here: https://github.com/sacarlson/sacarlson.github.io/blob/master/qr-code_extention.md. This document also includes some minimal documentation of the escrow format used in Stellar OpenCart plugin. I also have my_wallet setup as a prototype that generates a "Transaction Envelope" QR-code format in the advanced>sign tx section. I also created a primitive qr-code reader that reads this and other formats of the qr-code and translates them to URL format that my_wallet uses. QR-code reader translator is found at: https://github.com/sacarlson/sacarlson.github.io/tree/master/qr_decode or try it http://sacarlson.github.io/qr_decode/ With this you can view a qr-code envelope and decide if you want to sign it or not. I also added an example in my_wallet to demonstrate the webhook version of transaction envelope. In this prototype webhook demo I use IPFS creation and use that as the webhook. The method is settable in settings. This is meant just as a demo of how it can be done and used not really meant to be used for real users as it has a very poor user interface. The example code can be seen at: https://github.com/sacarlson/sacarlson.github.io/tree/master/my_wallet or you can also run it from github https://sacarlson.github.io/my_wallet/
- Edited
An example of the base64 method of an tx envelope in qr-code as seen generated from my_wallet. This envelope contains a create account transaction on testnet.
- Edited
I know it is not this easy to generate and read, but it is about coding once and be used by millions.
Create account with text memo Hello world! created with my on development wallet nobody want to test ?
[
]
The size is reduced quite a lot. It can be scanned without focusing the camera, just moving the camera over it a bit. I am adding an extra header to identify what is inside the binary, (a transaction, in this case) starting with 2 bytes at zero to don't make a chaos on applications expecting a base64