ILP Torrent – Web(Monetization)Torrent for Creators

Title image by Rio Hodges on Unsplash, with Web Monetization stamps added

I didn’t belong to the group of cool kids that circulated the latest movies on burned DVDs because they knew about The Pirate Bay, one of the most prominent platforms to exchange torrent files and magnet links to download content. My parents are not the greatest fans of technology so I was left to find out about this place that most people associate with piracy much later.

But setting file sharing via a torrent protocol equal with piracy does not do it justice. The technology is used by companies such as Facebook and Twitter to internally distribute software updates and allows open-source projects to host files peer-to-peer. Moreover, it is also a very fascinating game theoretic problem.

Why are these companies and open source projects using a torrent protocol to share files? The protocol allows massive savings on bandwidth. Let me explain that using Youtube as an example. Whenever we want to watch a video, we make a request to a Youtube server that hosts that video file. If we are authorized to view it, the server will respond with the file (or file stream) and our browser will display it. Given that Youtube has millions of users, a large number of them are requesting videos at the same time, they really have to scale up their infrastructure to have enough bandwidth available to handle all of that traffic.

What does a torrent protocol do differently? Originally, there is also one server that is the only one that hosts let’s say an image. A user comes along and wants to view it, so its client requests it from that server. As soon as it receives at least a part of the image, it automatically turns into a server, so it acts as client and server at the same time, allowing other users’ clients to request the image from it. This peer-to-peer network turns a one to many relationship into a many to many relationship.

The disadvantage of a torrent protocol, however, is that there is no single point of access control. In the case of Youtube, the server can check whether the client is authorized to view a video file and even make them pay. On the other hand, authentication / authorization and payments are not part of a torrent protocol. Hence, it is widely used to share content illegally. Giving just one example, the movie and TV industry estimate that video piracy accounts for at least $29 billion of revenue losses per year. Other affected industries are games, music, and publishing.

ILP Torrent attempts to solve this issue by adding payments to a torrenting protocol.

Adding licenses and payments to a torrent protocol

In order to share any file via a torrent protocol, a torrent file needs to be created. This file includes information about the file name, file size, and at least one initial connection endpoint, among others.

With the aim of processing any kind of payment prior to sharing a file, some sort of metadata needs to be included specifying the payment details and the corresponding usage rights. This is what I call a license. To keep it simple, that license includes a payment pointer, a price, and a verifier endpoint which is used to verify that the payment actually occurred to the provided payment pointer. For now, it is assumed that the payment of that license fee grants unlimited usage rights to the file.

Processing Payments

The above schema of the peer-to-peer network is missing one component – the torrent tracker, which is what I called an initial connection endpoint before. The tracker is a server that, instead of hosting a file as in the client-server Youtube example, it keeps track of which peer has which file or part of a file available for download and also stores a copy of the torrent file.

Every participant in the network, before becoming a peer, connects to a tracker. It requests a list of peers as well as information about which file parts each individual peer has available for download.

For a first demo, this is exactly where we can enforce payment. Instead of plainly requesting a list of peers, the ILP Torrent client has to prove that it paid for the file by passing STREAM receipt IDs along with the request. The ILP Torrent tracker uses the verifier endpoint stored in the torrent file to verify the receipts and if successful, returns the list of peers. The client is now able to download the file.

The implementation

There are various implementations of torrent protocols out there. The most prominent one is probably BitTorrent, which uses the UDP protocol for communication among peers and requires users to download a client. I wanted this demo to work in the browser and to use Web Monetization for license fee payments, hence I rely on another implementation — WebTorrent — which uses WebRTC for communication.

WebTorrent comes with a bunch of modules, of which I made adjustments or additions to the ones highlighted:

A more in-depth technical introduction of ILP Torrent will follow, where I’ll go into detail on torrent protocols in general and the specifics on what I changed in WebTorrent.

The demo

As explained in the Processing Payments section, the tracker verifies payments using a STREAM receipt verifier. Hence, the demo really consists of two parts – ILP Torrent and a Verifier Service. There will probably also be a post soon on the Verifier Service, so stay posted.

ILP Torrent allows you to download (leech) and upload (seed) a file. In order to upload a file, you need to specify all the license components. Right now these are a (proxy) payment pointer, a verifier endpoint, a price, a currency, and optionally a new file name. If you are not running your own STREAM receipt verifier, you may use the Verifier Service which is linked on the demo page.

Quick Interlude – The Verifier Service

The Verifier Service is hosted on a virtual server managed by Coil. After registering your individual payment pointer, it generates a proxy payment pointer which proxies all incoming SPSP requests to the server where your individual payment pointer is registered, let’s say at Uphold, and asks Uphold to include STREAM receipts in the STREAM packets. These receipts are credited to the Verifier service by your ILP Torrent client (in the browser) and spent by the ILP Torrent tracker before communicating the peer list.

The Verifier Service allows you

- To register a payment pointer:

- To test the generated proxy payment pointer:

- And to delete the proxy payment pointer from the server:

After reading until here, you really deserve to see a demo now. Here you go!

Let’s have a look at the individual steps of ILP Torrent:

The landing page allows you to download (leech) a file by just copy and pasting a magnet URI. A magnet URI is an identifier for a torrent file and in the case of ILP Torrent includes:

- A hash

- The file’s name

- The ILP Torrent tracker endpoint

- The proxy payment pointer

- And the verifier endpoint

Once you submit, the payment pointer is extracted from the magnet URI and the meta tag is added to the page. The extension starts streaming micropayments.

As soon as the funds are sufficient, the ILP Torrent tracker releases a list of peers and the client downloads the file. Web monetization stops. Note that you are potentially also seeding to other clients now.

Now let’s have a look at seeding a new file and let’s assume that you already set up your proxy payment pointer. Fill out the details about your file and select it by browsing your file directory.

On submit, you receive the corresponding magnet URI.

In a private window, you can now try to download that file. Copy the magnet URI and paste it into the private instance of the app. After a short time, you should receive your file. Make sure to not price it too high because otherwise it can take quite some time before the funds are gathered.

Issues with this first demo implementation

1. Trust issues

The biggest elephant in the room for me is that the creator, i.e. the owner of the file that is seeded, has to trust that the ILP Torrent tracker performs the payment verification before sharing the list of peers. One could also make the peers perform this verification, but then the creator has to trust not just one entity but potentially thousands of people. One way of circumventing that could be a revenue split between the creator and the peers, where the peers verify payment to a revenue sharing payment pointer. This would also incentivize them to keep seeding the file after having downloaded it completely.

2. Piracy

To circumvent the ILP Torrent tracker and hence payment all together, one could imagine a secondary platform where seeders publish peer lists they have received from the ILP tracker and that can be added to a tweaked version of a torrent client. In that scenario, moving verification to the peers is also the solution.

3. Currency conversion

STREAM receipts do not include asset details (which currency and asset scale is being used) but include the amount received denominated in the receivers’ wallet’s asset details. The ILP Torrent tracker, when verifying payment, spends against the verifier endpoint, using the asset details provided in the license in the torrent file. The asset scale is assumed to be 9. ILP Torrent tracker itself is not doing any currency conversion because it does not know about the receiver’s asset details. Hence, when seeding a file, creators have to select the currency corresponding to their payment pointer. This could be solved when we introduce the Open Payments protocol, which will make asset details more accessible.

There are probably multiple other issues that I am not thinking of and that should be added to this list so feel free to reach out to me and let me know!

All the resources

- In-depth technical introduction (coming soon)

- For those who can’t wait for the technical blog post, here is the code

- ILP Torrent demo

- Verifier Service

- STREAM receipt verifier