joystream v0-5-1 released

JOYSTREAM Mise à Jour

We are very pleased to release the next major version of JoyStream, version 0.5.1. This release is a very significant improvement in the usability, stability and feature set of the application. Moreover, we have invested a great deal in laying the foundations for being able to much more rapidly improve the application going forward. Here is a rundown of what is new in this release, in no particular order of significance, w.r.t. the prior 0.4.4 release.
New user interface

The prior release was really a proof-of-concept interface, not fit for purpose as client for daily use. Many users were confused about what they could do, how to do it, and what was going on.

User interface in JoyStream 0.4.4

Quick action toolbar

We have grouped all critical actions on a single click toolbar for each torrent, with descriptive icons which also explain purpose and status.
Toolbar displayed for each torrent being downloaded.

Starting a paid torrent download was particularly complex before, where we required you to deal with prices, and there was no indication about whether anyone was available at the other end. Now we only offer you the option when someone is at the other end, and we make the price choices for you. If you can’t do a download, we will tell you why.

As a point of comparison, most clients do not organize what actions are most relevant in any way, so you are confronted with a gigantic flat list of confusing options, we hope to avoid this by putting the most important actions in this toolbar.

Action toolbar for uTorrent (1.8.7)
Onboarding

Getting started with a client requires that you have a torrent file of interest, and in our particular case, that there are other JoyStream peers on the same swarm, at least if you want to try the payment features. To solve this, we created an onboarding experience where all new users are encouraged to try out a few movie torrents. This makes it super easy to get started with a paid download.
The first screen you see when you run JoyStream for the first time is this suggestion.
A seeding guide

Another challenge people faced was how to get setup with seeding for payment. This is now a single click action.
How to get started seeding for payment.

Moreover, we also created a guide when you want to start seeding a torrent which you already downloaded prior, outside JoyStream. You start by initiating the seeding on the uploading screen.
You can’t miss how you are supposed to start uploading a new torrent file.

After selecting the torrent file of interest, you will be asked to provide the folder where the complete download already resides.
Tell JoyStream where to find your prior download.

JoyStream will then look for for a complete and valid download, and if one is not found, it will automatically start downloading the torrent data for you.
Keeping on top of your torrents

When you introduce payments in BitTorrent, things get complicated. There is a lot of information the user may want to keep track of. This is bad news, because BitTorrent is already pretty damn complicated. Take a look at this 16 column view of a single torrent as seen in a popular client.

16 colums shown in uTorrent (1.8.7)

When you add payments, thing get totally out of hand. So we chose to factor out a separate screen for each major mode a torrent can be in, downloading, uploading and finished. This way, we can limit how much information a given screen has to convey, as any given state renders many information fields irrelevant.
Streaming torrents

You can now enjoy one click streaming playback, and seeking, of torrents which include video media. To our knowledge, this is a feature which currently is only available in one or two other free clients.

The really cool part of this is that this streaming is integrated with our payment feature, so if you seek around in some media, then your client will start requesting and paying for pieces which corresponds to what you want to see right now.
Streaming playback of Sintel from the Blender Foundation
Fast peer discovery

A tremendous problem we have faced up to now is that there are extremly few active JoyStream peers on any given swarm, hence, even if two JoyStream peers were part of the same BitTorrent swarm, they would be unlikely to know about each other. This is a big problem, since JoyStream peers are currently the only peers aware of our payment protocol. To solve this problem we made sure all JoyStream peers also participate in a second layer of the normal BitTorrent DHT.

This means that JoyStream peers will now reliably be able to find each other near instantly, regardless of how many other normal peers are part of the swarm for a given torrent.
Simpler payment channels
Old style channels

The traditional payment channels suggested by Spillman et. al required that payor and payee collaborate on creating a refund transaction which is time locked. This transaction is meant as a last resort for the payor, in case the payee for some reason never attempts to settle the channel. This would otherwise leave the funds locked forever, and would therefore also constitute a denial of service attack.
Newer CheckSequenceVerify (CSV) channels

The scheme above was complicated, in particular when trying to pay mulitple parties out of the same contract. It meant you always had to setup multiple refund transactions, which required potentially asking everyone to resign their refund if a single party did not cooperate during setup. This got very complicated. Moreover, this approach is also open to a malleability attack, where someone could malleate the contract transaction in transit, making the refund transactions invalid

Enter OP_CHECKSEQUENCEVERIFY
BIP 112 describing OP_CHECKSEQUENCEVERIFY

For any given content hash H, JoyStream peers will also coordinate around the hash H* = sha1(H + ‘joystream’).

This opcode allowed us to entirely drop the refund transaction setup, since it allows each output to explicitly control when it is spendable in the future. It was a huge boon to the simplicity of our channel construction and management.
Persistent application state

A basic feature we previously had not found time to implement is that your client will reload with the same torrents that were previously loaded, very simple, but required.
New application architecture

We have previously explained how our old client was organized. Our entire codebase was in C++, everything from the wallet, to the peer protocol, to the application logic and user interface. This created three serious challenges

Limited availablility of reusable third party code
Extremly difficult cross platform dependency and build management
Limited and expensive supply of experienced developers
Less mature and supported toolkit for user interface design

As a result, we decided to throw away eveything in the core application, including our home grown SPV wallet, and write the application logic in Node, in combination with the Electron application framework, while keeping all of our protocol, payment channel and extension code in C++. We will get back to this in a future post.
What is next?
Weekly releases

If there is one lesson we have learned so far, its that longer release cycles are much harder to manage. Its very hard to prioritse among the myriad of potential directions of improvement without user input, and the scope and depth of an improvement is hard to limit. This is why we are making a radical shift, and switching to a 7–10 day release cycle for our minor version updates.
Focus over the coming weeks

Problems we are tackling over the coming weeks are

Prepare for mainnet: Some finalisation is required, like completing a functional wallet screen. We will get back to this in a future post.
Faster paid exchange: Ironically, paid exchange is now much slower than it should be, in particular for torrents with small piece sizes. We will add pipelining to our payment protocol as a solution to this problem.
Support more video formats: The video playback component in our user interface only supports a few video encoding formats in genuine streaming mode, which means that users will sometimes have to wait for torrents to complete download before playing the content in an external video player.
General Bug Fixes: We expect a lot of great feedback and suggestions from you over the coming weeks to help us identify and prioritize issues in the software to work on.