Streaming Data Payment Protocol (SDPP) on IOTA

What is it? And what does it mean for IOTA?

Published in

vessels

5 min readMay 23, 2018

As the IOTA team keeps working on the core platform, we are starting to see 2nd and 3rd layer applications emerge. In keeping with the much used analogy, these projects are the SSL or HTTP to the TCP/IP of distributed ledger technology.

I was recently enthralled by the paper for Streaming Data Payment Protocol (SDPP) on top of IOTA’s Tangle. In this post, I’m going to summarize it, attempt to break it down in terms that you and I can understand, and give my take on what it means for IOTA and the community as a whole. This is the first of my blog posts were I try to do this — so please let me know if you like it, and please suggest other papers or articles for me to summarize!

One Sentence Summary:

SDPP allows buyers to purchase data streams from sellers.

Longer Summary:

SDPP is a protocol which defines a relationship between data producers and data consumers. Data producers sell data streams to consumers, which are paid for with micro-transactions. All transactions are recorded in an immutable distributed ledger for dispute resolution and auditing.

Oh. You mean the Data Marketplace

Nope. SDPP actually aims to be platform agnostic, the authors just used IOTA in their first POC (more on this later). While there’s no public api for the data marketplace at this stage, I’m guessing that interoperability isn’t going to be the first priority of the IOTA Foundation. Open protocols such as SDPP are great as they foster multiple platforms working together — which to me is much needed in the fragmented world of IoT.

Why?

Existing IoT applications rely on some pretty heavy-handed vertical integration. Most often, the company using the data collected is also the company deploying and managing fleets of devices. The authors argue some pretty compelling use cases for the need of IoT data streams that are more scalable, interoperable, and temporary.

This could also help prevent the duplication of effort when it comes to data collection that could be monopolized. For example, there’s no real point having 2 sets of plumbing in your home — why should there be 2 sensors recording air quality on the same rooftop? SDPP could make this a possibility.

In fact, SDPP and similar approaches turn a company’s capital expenses into operational expenses. Sound familiar anyone? Maybe like cloud computing? If this approach takes hold, who knows what possibilities it will unleash? Will there be an IoT service akin to Amazon attaching sensors to all things that move? Or maybe it will democratize data collection, so that highly specialized companies can exist for the sole purpose of collecting specific types of data. Maybe we will even see a role for data aggregators that pull together multiple streams, perform some data cleaning and enrichment for you, and pass on a single stream to an end user. Who knows!

How does it work

The protocol can be broken down into 3 parts:

Data Transport (implemented in TCP)
Payment Channel (micro-payments in IOTA)
Records Medium (recorded on IOTA tangle)

The data transport is pretty straight forward, it can be summarized as JSON encoded messages sent over TCP. Nothing new here. As an aside, one could actually implement the entire thing in IOTA, using MAM for the data transport layer.

The payment channel and records medium are the interesting part however. As I said above, SDPP is platform agnostic. Someone wishing to implement this themselves doesn’t even need to use crypto to make the payments, but since IOTA is fee-less, it does make good sense. The records medium is used to store orders made by the buyer and invoices generated by the seller in an immutable fashion.

Steps:

The Buyer establishes a connection with the Seller
The Seller presents a ‘MENU’ to the buyer, and
The Seller then starts sending data to the Buyer, with the Seller sending back an acknowledgement for every message.
After k messages, the Seller sends an invoice to the Buyer, and the Buyer pays the invoice. When the invoice is sent, a record is made in a public ledger.
When the buyer wishes to disconnect, the Buyer sends the final payment.

Benefits

One of the things I really like about this protocol is that it has good separation of concerns. This makes it inherently more flexible, and hopefully builds a solid base for further work on micro-payments for IoT data streams. It also means that the protocol is platform agnostic — meaning it can be made to work with just about any DLT platform. As it evolves, hopefully it will be picked up by other companies interesting in creating and consuming data streams.

Drawbacks

One of the notable drawbacks is the reliance on a client/server model. This is something mentioned by the authors — as a publisher/subscriber model is growing in popularity in the IoT space. A pubsub model would allow for more complicated architectures, for example: a single subscriber could pay for multiple data streams from different publishers at once.

Conclusion

Well that’s about it. I hope I’ve interested you in this protocol, and made it somewhat easier to understand. Please let me know in the comments below if this is or isn’t the case 😐😐😐.

Here’s hoping we see more 2nd and 3rd layer applications being built on top of the Tangle!