Watching the flippening on Twitter with Streamr and Oraclize

We’ve met with the Oraclize people a few times, and we love what they do. There are also important synergies in what Streamr and Oraclize can do together. Let me explain, and show an example.

For fun, and to demonstrate Streamr and Oraclize working in tandem, we built a little example that watches the flippening (Ethereum potentially overtaking Bitcoin as the leading blockchain) in real-time. This idea was inspired by flippening.watch, which lists many metrics such as market cap and number of transactions, but none related to social media. So we chose to add some analytics using social media data. Using the streaming Twitter API and Streamr we build a process that listens to raw tweets mentioning either Ethereum or Bitcoin, counts the tweets in various timeframes, and makes the results available from our API. Later in this post, we’ll query this data from a smart contract.

Just to show you what the data currently looks like, here’s a table of real-time Twitter statistics, as received from our streaming API:

Window Ethereum tweets Bitcoin tweets Flippening
1 min
1 hour
24 hours


In the Streamr Engine, there’s two ways to convey data to smart contracts. The first method is event-driven: sending transactions directly from the Canvas via the EthereumCall module (see this or this example). The second option is to query for data from our web API when needed. This is preferable in use cases where a smart contract needs the data upon request instead of being constantly notified about the newest data.

Oraclize can easily facilitate this. They offer a request-response bridge between the blockchain and any web API such as Streamr’s. A smart contract can call a function on the Oraclize smart contract in order to request for data from a source such as an URL. Their off-chain system watches for these calls, and when one occurs, they go ahead and fetch the required data, and send the response back to the requesting smart contract by calling its callback function. Oraclize can even generate a proof if required, cryptographically showing that the data really came from our web API.

The results are being calculated from raw tweets using a canvas that counts the tweets in 1 minute, 1 hour, and 24 hour rolling windows and produces the results to a new stream. The result stream can be listened to by external applications, similarly to how this web page subscribes to it to show the table above. However, events in the stream can also be queried via our HTTP API. The following URL returns the latest event in the stream:

https://eth.streamr.com/api/v1/streams/I1AWyGXDRg28AO33ztPBZg/data/partitions/0/last?wrapper=object&content=json
To enable a smart contract to get the latest data on demand (for betting purposes, for example 😊), you can use Oraclize. Below is an example for Ethereum, written in Solidity. It requests Oraclize to fetch the current statistics from the Streamr API by calling the oraclize_query function. The result is soon thereafter delivered to the __callback function by Oraclize:
pragma solidity ^0.4.0;
import "github.com/oraclize/ethereum-api/oraclizeAPI.sol";

contract StreamrFlippeningDemo is usingOraclize {

    string public latest;

    event newOraclizeQuery(string description, uint256 fee);
    event newFlippeningData(string data);

    function StreamrFlippeningDemo() {
        // update();
    }

    function __callback(bytes32 myid, string result) {
        if (msg.sender != oraclize_cbAddress()) throw;
        latest = result;
        newFlippeningData(latest);
    }

    function update() payable {
        uint256 fee = oraclize_getPrice("URL");
        if (fee > this.balance) {
            newOraclizeQuery("Oraclize query was NOT sent, please add some ETH to cover for the query fee.", fee);
        } else {
            newOraclizeQuery("Oraclize query was sent, standing by for the answer..", fee);
            oraclize_query("URL", "json(https://eth.streamr.com/api/v1/streams/I1AWyGXDRg28AO33ztPBZg/data/partitions/0/last?wrapper=object&content=json).0.content.flippening_24h");
        }
    }
}

Streamr Editor is a low-code environment that allows users to build data-driven processes visually using drag and drop. Below, you can see the Canvas that counts tweets for the various time frames on both source streams, and produces the result into another stream (click here to open in full screen):

Take a look at our white paper draft if you want to dig deeper into our stack. In the draft we explain how streaming data can be tokenized and traded in the peer-to-peer Streamr Network powered by a token called DATAcoin. As all data in the Streamr Network will be signed at the source, smart contracts always receive trusted data from the real world. In this scenario, Oraclize can act as a valuable request-response bridge which natively supports data queries from the Streamr Network.

This simple example is just a taster, but it should immediately help you get started in building data-driven smart contracts. There’s so much more that can be achieved using Streamr and Oraclize either together or separately, depending on the use case. We’ll be hard at work in making the data-driven decentralized vision a reality!

Questions and comments about this post and Streamr in general are appreciated! Join us on Slack, and of course feel free to follow us on Twitter as well.

Ethereum-based peer-to-peer package delivery with PassLfix and Streamr

We very much like working with like-minded folks in the blockchain space. An opportunity for one interesting project arose earlier this year when we met Frederic Vedrunes of PassLfix at EDCON 2017. When we met, Frederic outlined the idea of a decentralized, data-driven app where Ethereum smart contracts are used to create a security layer for peer-to-peer delivery services. There’s also a significant data angle to the project, given that parcel deliveries would be monitored by IoT sensors. We were all ears, given that such ideas link nicely with our own vision of a decentralized data backbone as described in Streamr whitepaper.

To make a long story short, Frederic asked for our help in getting out a package delivery Ðapp prototype. We were happy to oblige, and the video below shows the whole thing in action from pickup all the way to delivery. The video was filmed and produced on a shoestring budget, but it’s probably all the better for it; it will bring a smile on your face.

The idea behind peer-to-peer delivery is simple: Where there’s people who’ll be travelling anyway from A to B, there’s folks who wouldn’t mind some extra income for taking a package along the ride. There’s already companies such as Dolly, Roady and Grabr out there with tens of thousands of users. Much of the activity has been in the U.S., but similar services are emerging in Europe (Nimber and Colis-Voiturage), and even international peer-to-peer delivery is on its way (PiggyBee). People clearly like interacting with people, and that’s one of the great aspects of peer-to-peer delivery networks.

The concept is catching on. But it is not like P2P delivery networks yet pose a huge threat which keeps the CEO of UPS or Fedex awake and sweating through the night. One reason why the big boys still sleep well is that they’ve earned trust. If you go with a P2P startup, you’ll hand over that sought-after Rihanna ticket to a person you’ve never met before, and expect him or her to hand it over to your favourite niece in Philly in time for Saturday’s concert.

In the case of UPS or Fedex, you trust the courier because they are employed by a big, reputable company. In the case of newly set up P2P services, several trust-building ways have been proposed, including reputation systems, designated points of pick-up and delivery, and parcel insurance. But we all know that one of the great advantages of the blockchain is the built-in trust. Can we leverage the chain and Ðapps to come up with a better delivery service?

In our mind the answer is a definite “yes”, and the paradigm becomes one of “trust but verify”. You offload the paperwork to smart contracts, and cryptographically sign all the face-to-face transactions in the blockchain. The rewards are automatic: The courier gets back the safety deposit on delivery, and receives the agreed fee in their wallets as soon as the package is delivered to the recipient. And you can complement all of this by a community, a DAO which handles the inevitable but hopefully rare disputes. All in all, this is a great example of a decentralized app with a significant real-life use case.

Apart from a clever use of smart contracts, this project makes a definite inroad to the IoT world. The sender can add one or more connected devices (sensors) in the package. The sensors (see below how they look like) will monitor conditions such as temperature, humidity, and acceleration while in transit. The idea is that the smart contract — as well as the sender and the recipient— will immediately know if the parameters stray beyond what was agreed, and appropriate compensation can then be meted out by the contract.

To make all this work, the prototype makes use of the Streamr platform as an off-chain processing engine. With the IoT data streaming in from the sensors, there’s simply way too much data for the blockchain and smart contracts to handle. In the prototype, telemetry data (such as temperature, GPS, speed and elevation) from each parcel in transit transmitted via a Bluetooth connection to the courier’s smartphone. On the smartphone, there’s an app that leverages the API of Ethereum Android to interact with the blockchain. The mobile app also sends sensor data to Streamr platform where visualizations (charts, tables, and maps) are automatically created. The visualizations can viewed by the sender, courier, and the recipient. Any contract breaches (e.g., parcel crossing a temperature limit) are automatically detected and reported to the appropriate Ethereum smart contracts.

As we see it, the prototype is an archetypal example of a data-driven Ðapp. There is a decentralized backend implemented as smart contracts which handle the delivery process. The prototype web3 frontend (see below) handles parcel and delivery setup, and the tracking view shows the real-time location of the parcel along with related sensor metrics. As such, we hope that the prototype serves as inspiration to the coders and developers out there working on the next big decentralized thing. May the Force be with you!

Questions and comments about this post and Streamr in general are appreciated! Join us on Slack, and of course feel free to follow us on Twitter as well.

 

Posted by / June 8, 2017