Exploding IPFS data — enabling single use links, expiring links and more through a simple link shortening service.

Link-shortening services have been around for a long time and are built into many of the services we use every day. At Textile, we’ve been wondering what benefits would come from combining a short-link service with IPFS content addresses. As a primer, here’s how short-links work in services like Twitter or Bitly:

When you share a link such as the URL to this blog post, a link-shortening service will turn the link into a shorter, alphanumeric code (e.g., zUsHrfTRgz) that you can share with others. Next, when a viewer requests that code from the service from their browser, the viewer will be forwarded back to the original URL. There are two common benefits to link-shortening services, more tidy URLs, and occasionally memorable short-codes to stand-in for long, unmemorable URLs.

Combing IPFS hashes with a shortening service like those described above could be interesting, as it may provide the ability to create memorable codes for the long hashes typically available on IPFS (e.g., QmVXhdE6GeMa... could become boom123). However, as we share below, we can do a few more useful things than shorten a URL. Here’s the TLDR; of what an IPFS link-shortener* could provide:

1. Make it easier to share encrypted content on IPFS.
2. Make it easier to share sensitive content addresses.
3. Make it possible to revoke access to content on IPFS (e.g., one-time use links).

If you want to skip the rest of the post and start playing with our experimental link-shortener now, head on over to https://boom.fyi/ or jump onto https://slack.textile.io and message @pinbot.

* We’ll continue to refer to it as link-shortening, but by now, you should see that shortening isn’t the primary benefit.

Sharing encrypted content on IPFS

At Textile, we encrypt content on IPFS using one-time-use encryption keys. Our encryption means that by default, only the owner ever has to know the hash (content address) of the original data. This provides a solution for: “I want to pin my data and move it around while leveraging the DHT, but I don't want anyone else to know what it is”. But what happens when you want to share that content with another person or machine?

There are two methods commonly used to share encrypted content. Both involve giving the recipient both the hash and the symmetric key.

1. Sharing content address and key. In the first, the content owner shares the hash and the key directly with the recipient, who can then fetch the data over IPFS and decrypt its content. The payload for that share might look like this:

2. Sharing decrypting gateway URL. In the second method, a content owner can create a link to a decrypting gateway that will fetch and decrypt the content on the fly. Here, the recipient doesn't need to know what to do with the key since the decrypting gateway will decrypt the content on-the-fly for the end-user. As in the previous example, a gateway link might look like this:

https://us-west-dev.textile.cafe/ipfs/QmVXhdE6GeMa28PPSwooz9GvaAs6s2y5tw78hMQgX6mSho?key=24k6zC3UTwPEXJicW4QZhLtKsVFUQEh6yMARy4d2rnTTZUnERLdDqBYw8qPGA

The problem is that the recipient has both the key and the hash to the data. The end-user can let other people know what data is stored at the encrypted hash, the end-user could begin pinning the encrypted hash, or the end-user could share the hash and key with other users who might do either of those things. Even if these things never happen, the risk of exposure may cause real concerns for projects dealing with sensitive or private data for end-users.

An IPFS link-shortening service

Now, using an IPFS link-shortener, we can allow users to share links from IPFS that expose neither the hash nor the key! Here, instead of sending a hash and key to any other viewer (or service), you can create a short-link to share instead. Here's how it works (figure above):

Just like the link shorteners described at the beginning, the content owner can provide an IPFS link and get back a code for fetching that content. Unlike traditional shortening services, this IPFS-based service can also take an encryption key. Finally, our new shortening service wont forward end viewers to the original hash, instead it will decrypt the content and provide it back to the viewer directly.

Using the decrypting gateways we mentioned previously, a user might typically share encrypted content using a link like the following:

https://us-west-dev.textile.cafe/ipfs/QmVXhdE6GeMa28PPSwooz9GvaAs6s2y5tw78hMQgX6mSho?key=24k6zC3UTwPEXJicW4QZhLtKsVFUQEh6yMARy4d2rnTTZUnERLdDqBYw8qPGA

Instead, that user will first send the hash (QmVXhdE6GeMa28PPSwooz...) and key (24k6zC3UTwPEXJicW4QZhL...) to our shortening service and get back a short link for that content (e.g., 0yokD49oHnYtaO6i). Now, the content owner can share a direct link to the content as follows:

https://boom.fyi/q/jLDG1rcLrv75zqPJ

Now, when a viewer visits the IPFS short-link they aren’t forwarded to the original content but instead are served the content directly! So our short-link becomes a proxy that ensures an end-user can never access the raw hash or shared gateway link mentioned previously.

Revoking access to IPFS content

Now that we have a simple IPFS link-shortener, it’s clear there is a friendly and simple way to allow content owners to revoke access to their content on IPFS (remember, the short link doesn't forward the user to content, but acts as a proxy). Now, the content owner can instruct the service to forget the mapping to the original content and key at any time.

While it's true that the viewer of the content may store a decrypted copy, they can never associate it back with your peer or other peers pinning the encrypted data. It's a simple solution but requires a little bit of trust or the ability to run a link host. Using a system like this, you could encrypt and pin every book in the Library of Alexandria. You could then ask others to help you host that data without any of those others having to know which book is behind which hash. Using a simple service like this, you can then loan those books out for people to read at will, while keeping your book hosts secure.

We've put together a demo of the concept. Try it at https://boom.fyi/. Boom runs on a Textile Cafe using some new tools we are rolling out over the coming weeks. While we run this service for you to use, soon, we'll make it possible for you to set up and run your own services like this in about 5 minutes. The demo showcases a simple HTTP API for shortening IPFS content, but in our upcoming release, we'll also show you how these services work over libp2p (peer-to-peer)!

Demo: https://boom.fyi/

Reach us on Slack or Twitter if you have any feedback or want to collaborate on new IPFS services.