Bytes — Alpha Version Debrief

Further to the teaser we published in our telegram group, here is a full debrief of our progress developing Bytes, with a small demo, a compilation of lessons learnt and a prediction of what is to come next.

Intro: What is Bytes?

Bytes offers a platform for last mile, distributed, Internet access trading. Last mile means we are not substituting ourselves to regular ISPs, and distributed means the trade is not intermediated. The absence of intermediation for the processing and the structuring of the transaction is made possible by the Blockchain.

Having a platform for last mile, distributed, Internet access trading enables to:

  1. Do away with roaming by enabling locals to sell their excess Internet access to travellers (we will make sure this is compliant) — when was the last time you used up your 100GB monthly limit?
  2. Enable machines (or “Things” in the IoT parlance) to transact with one another. Indeed, connecting billions of machines to the Internet is nearly impossible for today’s centralised offerings. A distributed, programmable payment stack is needed.

Demo and Product Walkthrough

UX — Simplicity and Abstraction

The philosophy guiding our UX design is SIMPLICITY and ABSTRACTION.

Demonstration — cell phones selling Internet access to one another.

The main screen is super simple and consists of only two buttons. Upon touching connect, the “buy mode”is activated and the app looks for sellers in the vicinity, all by itself. Analoguously, tapping sell will allow nearby buyers to connect with you.

In the background, the buyer pays the seller with cryptos (IOTA). Remark this is entirely abstracted away.

Architecture — True P2P

The stack is completely P2P. By this we mean that the interaction between the two devices is not mediated by a third pary (not even us). To this extent, we are more similar to BitTorrent than to Uber for instance.

This fully distributed stack is enabled by the Tangle/Blockchain, which processes and structures transactions autonomously.

A distributed architecture has advantages: it is censorship resistant, and operationally leaner. The downside is that no one is here to make sure that:

  1. the buyer does not run away before having paid
  2. the seller does not stop giving Internet access after having been paid. To address these scenarii, we enforce real time payment (i.e., the buyer pays for each Mega Byte of Internet).

This demand that:

  • the app keeps track of how much Internet bandwidth is being used on each side of the transaction (since you can't trust the counterparty)
  • the many small transactions resulting from real time payment do not generate too much fees

We implemented both an Ethereum and an IOTA transaction stack. The good thing with IOTA is that there are no transaction fees. As such, Bytes can be used even for very short interactions / infinitessimal amounts (as we expect to often be the case in the field of IoT).

Mobile App and IoT App: What is Next?

We iterate quickly. Expect a Beta version to come soon. Moving ahead, we will divide two streams of work more clearly: on the one hand a gorgeous mobile app incorporating a crypto wallet, on the other hand a requirements-driven IoT Stack.

In its next iteration, the mobile version of the app will approach a commercialisation ready state. It will be gorgeous.

It will enable users to deposit/withdraw funds (right now, the app is preloaded) and monitor his/her consumption over time. It will look gorgeous, as we are onboarding a professional designer in the team… stay tuned! 
 
At this stage of development, there is little difference between our IoT and end-user stacks. We are now compiling specific requirements for the next iteration though. Besides usability — we will provide users with a remote control dashboard — portability on small IoT devices will be one of the main priorities.

IOTA dev tips:

We are experimentation biased: with new technologies like the Blockchain, practical experimentation rocks. Here are some lessons we learnt on the way:

1. iota-java & iota.js

The IOTA javascript library is great. The Java library has almost the same inbuilt functions. Minor heads up, “optional” parameters in Javascript are to be replaced by empty (equivalent to the argument type) in Java.

2. Reattaching & promoting

When a transaction is pending for a long time, it is unlikely I to be accepted because the tip selection algorithm favors newer transactions. Users that are in a hurry to see their transaction confirmed are thus likely to rebroadcast it.

Rebroadcasting can be done by "promoting" or "reattaching". In practice "promoting", which involves the creation of a zero value transaction, is more effective.

Not all transactions can be promoted however. In javascript, you can check this using iotaJs.isPromotable(tail), while in Java your need to catch a potential NotPromotableException. Here is a basic Java example of an IOTA transaction.

3. Attaching adresses to the Tangle

Remark that while it is easy to generate new addresses (getNewAddress), the libraries/API do not automatically attach these to Tangle for you. You can attach it by sending a 0 value transaction.

You can always successfully send IOTAs to non-attached addresses but it is recommended to attach an address before using it. The purpose of attaching and address to the Tangle: prevent the re-use of the address’s private key.


We believe that when presented with a proper use case and a seamless UX, people will love the Blockchain. We move fast, stay tuned!

…Join the Community to Be in the Know!

Website | Telegram | Twitter | Facebook | LinkedIn