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.

    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.

      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.

        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.

          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, ^^^^

          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

            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.

              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.