Arrow of time
Arrow of time

How about a Digital Price Tag?

Share Tweet Share

How about adding intelligent information to our price tags? BitCoin and DogeCoin (and others) already have payment URLs, but we …

How about adding intelligent information to our price tags? BitCoin and DogeCoin (and others) already have payment URLs, but we can do better than that!

The easiest way to offer something for purchase using cryptocurrency is simply to link and/or describe what you want to the buyers on your web shop. You don't really need middle-men and merchants to do so: it's easy to create your own "BUY" link yourself.

Option #1: payment URL's

Most people know this already, but just in case: If you have a web page you can put up a URL which contains the destination wallet address and the amount to pay, and when someone clicks this URL, it will start their Wallet application which will then carry out the payment.

These URLs look like this:

dogecoin://DKUKYfhKV6bT77rkv9oLViTp5N9F3VtHXY?amount=100 - for Dogecoin, and

bitcoin://1MstKbw3XjeG3zE9biKyZ2XKADouuYfHAa?amount=0.01 - for BitCoin.

By the way, you can distinguish between BitCoin and DogeCoin addresses by looking at the first character. If it's a "1", it's a BitCoin address, if it's a "D", it's a DogeCoin address. Practically all other cryptocurrencies work the same way, this is not specific to these two.

But... that's a little too austere, don't you think? You can only put an address and the amount, not a description, an image, or anything else. What can we do about that?

Option #2: "Digital Price Tag"

Truly we live in the future and we have the technology to build-in much more information in our price tags than simply the seller's address and the amount.

NOTE: I've been reinventing the wheel here :) It looks like this is already worked on by the BitCoin guys and there are specification proposals BIP 70, BIP 71, BIP 72 and BIP 73 which mostly cover what I wanted to write about here, though they seem to be cryptocurrency-only, without being applicable to the classic world.

How about we use JSON? Here's what I propose:

{
       "type": "DI-1",
       "item": {
               "id": "donation1",
               "name": "A hundred Doge",
               "description": "You will donate 100 Dogecoin to @ivoras, and he will use it to go to the Moon!",
               "url": "http://ivoras.net/blog",
               "images": ["http://i.imgur.com/cVskFUN.jpg"],
               "quantity": 1,
               "unit": "piece"
       },
       "price": {
               "DOGE": 100,
               "BTC": 0.00004700
       },
       "seller": {
               "name": "Ivan Voras",
               "url": "http://ivoras.net",
               "DOGE": "DKUKYfhKV6bT77rkv9oLViTp5N9F3VtHXY",
               "BTC": "1MstKbw3XjeG3zE9biKyZ2XKADouuYfHAa"
       },
       "notify": {
               "email": "ivoras@gmail.com",
               "ws": "http://ivoras.net/dpay/ws.php"
       }
}

Neat, isn't it? Here is the list of features this piece of JSON implements:

  • It describes some convenient properties of the item in question: it's seller-specific ID, a name, description, URL where the buyers can get additional information, images which representit, the default quantity a buyer will get and the name of the unit.
  • It allows attaching prices in multiple currencies. In the above example, the unit price is expressed both in DogeCoins and BitCoins. Nothing prevents adding "real-world" currencies such as "USD"
  • It describes the seller and its various addresses
  • It has a special section about who to notify about the processed transaction - either via e-mail or by making an ordinary Web Service POST request.

I'll describe those features in more detail soon.

The above JSON contains the maximum amount of information I could think of to describe an article. This may or may not be enough :) But, the only actually required bits of the structure are:

  • The "type" field, identifying the structure as a digital item (in the format "DI-%d" where %d is the version number)
  • The "item"'s "id", "name" and "unit" fields. Both are arbitrary strings. The "unit" should be something meaningful such as "pieces", "kg", "oz", "lb", etc.
  • At least one field in the "price" section. Here, the key (left-hand-side part of the entry) is the currency, and the value is the number representing the price in that particular currency
  • The "seller" section must contain at least the addresses of the wallets in all the currencies specified in the "price" section.

The minimal JSON structure thus looks like this:

{
       "type": "DI-1",
       "item": {
               "id": "donation1",
               "name": "A hundred Doge",
               "unit": "piece"
       },
       "price": {
               "DOGE": 100,
       },
       "seller": {
               "DOGE": "DKUKYfhKV6bT77rkv9oLViTp5N9F3VtHXY"
       }
}

It's convenient to use the least amount of information as applicable in the JSON structure, "minify" the JSON in every way because large JSON structures generate QR codes with lots of small pixels. Compare this code for the full JSON:

QR code for the full JSON

...with this one for the minimal JSON:

QR code for the minimal JSON

All this is well and good but it's no use without an app which can handle these JSON price tags, right? Right! So my weekend project was to learn some more about writing Android apps and I've made an app which allows you to scan such QR codes and issue a payment! It doesn't do all this on its own; it invokes the standard ZXing QR code scanning app and whatever BitCoin or DogeCoin wallet you have installed to do the correct thing.

You can install the Android app from the Google Play store here!

Try it right now! Just install it and point it to one of the above QR codes. It should just work (barring bugs, of course).

The app is open source and I'd like all coding Shibe's and other interested developers to contribute - both to the idea or the JSON spec, and to the actual app code.

QR code for the minimal JSON

Developers who want to use this JSON spec in their own app can simply include this Java class which parses and validates the JSON, making its data readily available to apps.

The JSON spec

The Digital Price Tag JSON is a dictionary object containing the following first-level keys (or "sections"):

  • type
  • item
  • price
  • seller
  • notify

Of these, all sections except for the "notify" sections are mandatory, though not all possible keys in those sections may be mandatory themselves.

The "type" key

This is a simple scalar string, identifying the structure as being in this particular format. The format of the string is "DI-%d", where "%d" is the version number, currently "1".

Thus the current value of the "type" key is "DI-1".

The "item" section

This section contains a number of keys. The following keys are mandatory:

  • id - an arbitrary item identifier string, machine-readable
  • name - a short, human-readable name of the item in question
  • unit - a human-readable string containing the item's unit name, such as "lb", "kg", "piece", "package", etc.

The following keys are not mandatory:

  • description - a longer description of the item
  • url - contains the URL at which the buyer may learn more about the item
  • images - a list of URL's of images which will be shown to the buyer in the app
  • quantity - the suggested default quantity of the items the buyer should buy (usually "1") - this is a JSON number

This section should contain a "modest" amount of information and leave the rest to the web page pointed to by the "url" key.

The "price" section

This section must contain at least one key-value pair (and possibly more than one), where the "keys" is the currency identifier string (e.g. "DOGE", "BTC", "USD", etc.) and the value is the price of the item expressed in this currency (a JSON number).

The "seller" section

This section must contain one key-value pair for each currency-price pair present in the "price" section. The "keys" are the currency identifier strings (e.g. "DOGE", "BTC", "USD", etc.) and the values are appropriate wallet addresses for the specific currency.

The section may also contain some of the following non-mandatory keys:

  • name - the human-readable name of the seller
  • url - the URL at which the buyer may find out more about the seller

The idea is for this section to describe the specific seller of the item.

The "notify" section

This optional section may contain keys describing methods by which the seller will be notified for every transaction made. It may contain these keys:

  • email - contains the e-mail addresses which will receive a message with a notification of a successful transaction. The e-mail will contain the item's ID and name, the quantity and the cryptocurrency transaction hash. Note that due to the limitations of the Android app, the actual sending of this e-mail is optional and depends on the user's confirmation of the e-mail message.
  • ws - contains the URL at which the app will issue a HTTP POST request containing the following data: "item_id" - the item's ID, "address" - the seller's wallet address, "quantity" - the quantity bought and the "transaction_hash". This HTTP POST request will be made by the Android app without the user's confirmation and is thus more reliable than e-mail.

If this section is not present, no notification of purchase will be made.

In conclusion

I'm not saying this is the best way to do it, but it's a start. Future directions may involve expanding the amount of information stored in the tag, adding a digital signature to the whole tag (the private key in cryptocurrency wallets can be used for this), and definitely improving the usability of the Android app.

Discuss!


comments powered by Disqus