QRCodes and uri schemas implementation

Torkus

I am developing Galactica for iPhone and I will be reading/showing QRCodes to simplify payments so this is what I'll do:

If the code starts with G and has 56 chars I'll consider it a Stellar address
If the code starts with stellar: I'll consider it a uri scheme in the form:

stellar:payment?address=GA123...&amount=100.00&asset=USD&issuer=GALT...&memo=hello

where asset, issuer and memo are optional.

Galactica for Iphone will allow the merchant to select any option when generating POS QRCodes. If the user's wallet can read uri schemes good for both since it will populate all fields which is specially helpful for purchases that use order ids in the memo field, if not it will default to only the address.

Posting it here to see if we can reach consensus for moving wallets and payments forward.

dzham

Torkus

https://github.com/johansten/stargazer/blob/master/docs/qr-codes.md#payment-request

This is what I'm using for payment requests at the moment.

But that's json, and json kind of sucks, when we get into wanting to do more types of QR codes.
Ideal would be XDR, since it's a structured binary format, and we need to be able to handle that anyways.

MisterTicot

dzham
Torkus

Hm I beg your pardon I just got you where working on the part that write the links while I'm on the part reading it.

Well hard or not I'm up to code this thing. I'm splitting the code between the app ui and the protocol implementation; so later it'll be easier to make a lib that help generate the links. The links format will be:

https://cosmic.link/?payment&amount=100&destination=someone*example.com

I'm trying to implement every operations, but for now I'm lagging on inflation. It doesn't makes any sense to me that one have to sign an operation that trigger inflation while it's supposed to run automatically at network scale. Anyway...

I advice to use

?operation&option=value&....

As a standard rather than

operation?option=value&....

The reason behind it being you only need one page to handle everything. More convenient.

Besides, I'm following the stellar javascript formatting, so I have:

asset=name:issuer

Instead of

asset=name&issuer=address

With a special case scenario for asset=xlm or asset=native

MisterTicot

Well you could have said me you were working on this ?

I started an implementation of this because nobody seemed to grab the job.

Now we're both working on it but like competitors :/

Edit:
Well actually maybe I don't clearly understand the function of your app.

dzham

MisterTicot

It's not like nobody did it before out of laziness, nobody did it because it's bloody complicated.
A payment in itself is trivial, but that's not all you can, or should be able to do.

Torkus

dzham

Json is a valid option too but schemas are simpler, after stellar just put the operation and then the fields:values:

stellar:allowtrust?trustor=GA234&asset=USD&authorize=true
stellar:changetrust?asset=USD&issuer=GA234&limit=999999
stellar:setinflation?address=GA234

That's why I wanted to get the ball rolling, world commerce is knocking on our doors and we must act fast.

dzham

Torkus

The wonderful thing about standards is that there are so many of them to choose from.

Seriously though.. Take some time to really understand the platform, the use cases, etc. before rushing into things. You have enthusiasm, and that's good. But please, ^^^^

Torkus

MisterTicot

This is not an API for a website, this is a standard uri schema just like email:john@example.com so browsers recognize them and act on them perhaps requesting the user to open a wallet even though browsers have restricted their use but the standard still exists.

I'll take the asset:issuer convention, I like that.

MisterTicot

Torkus

I explained this choice in another post, your proposal is custom uri scheme and what I'm doing is universal link.

The reason why I'm doing so:
- universal links doesn't need browser-level implementation: it'll works for everybody as soon as the service is online
- universal link are tied to one app, while custom uri scheme can be handled by any application. While custom URI scheme are more open, they are also more likely to get hijacked by unauthorized application.
- My goal is to offer a "standard" (default?) transaction authenticator along with the uri protocol.

Anyway the relevant part of the link is the

operation&option=value...

And the code works the same whatever the uri begin with.