This is the second post in a series that highlights projects developing solutions that challenge the current norms of user dependency on the cloud. Given the ever present challenges related to privacy, database breaches and platform lock-in, it's crucial to begin returning data autonomy back to users.

For this issue, we're diving into Steven Vandevelde's Diffuse: a music player that connects to your cloud/distributed music storage. First we'll look at how the project works, followed by a few questions FISSION asking about Steven's background.

Repo: https://github.com/icidasset/diffuse

Try it out yourself: https://diffuse.sh


How does Diffuse work

The basic idea is that users should be able to access music files they own from anywhere, even local content.  This ranges from cloud servers like Dropbox or Google Drive to distributed storage solutions like IPFS. Steven has been iterating on Diffuse, written in Elm, for over 6 years now. The Diffuse About page also has some good information.

There are three main pieces to the product: the user data storage, the file storage medium, and the frontend which sits between them both.

To start a user would navigate to diffuse.sh, no need to install anything. In the current V1, users can authenticate themselves through Blockstack, Remote Storage or use the product anonymously via the browser.  

here's what the user sees first

Using a proper authentication method allows users to save things like music metadata, user favourites, and settings, whereas an "anonymous" login may result in data loss if the browser is cleared. Once they have been authenticated, users are able to add new content or access previously added content.

The user facing front-end is hosted on Netlify. Further down the decentralisation spectrum, it's certainly possible to self-host the frontend by downloading the html and mimicking Netlify (check this IPFS + ENS site hosting tutorial).

Here's an example of what would happen under the hood for a file hosted on Google Drive. Once a user authenticates on Diffuse and requests to add a file, they will be logged into their Google account and asked to allow permissions to the Diffuse app. Once granted, the app will request that Drive construct a filetree, which is a list containing the path to every audio file. It works in chunks of 1000 files requested from each url and then gets the music tags/metadata from each file via the JSmediatags library. The parsed metadata from those files is then cached in a user's storage provider: in V1 this is limited to either Blockstack or RemoteStorage. That way, when a user logs in and any metadata from previously loaded music is already there.

Once music on the storage medium has been identified and the metadata cached, the app users can enjoy whatever music files they have saved. Content searching is facilitated by the Lunr library.

A V2 is already in the works to make the entire product more user friendly. This next version will have data encryption, and even more storage options, including Textile for user data, or Blockstack's Gaia for file access. Fission is looking forward to when the V2 is live hopefully later this summer. We'll plan to do a blog post then detailing any of the updates.


Finally, here's a set of questions we asked Steven.

What’s your background as a developer?

Started with web dev as a hobby when I was 15 (I’m 29 now). First gig was for a web agency, mainly doing small artsy websites and a cms using ruby. Four years later I started working for another agency, but mainly doing app development. I've been doing all kinds of dev things in my spare time, but my main side project for the last 8 years has been Diffuse and its predecessors.

Where do you go to read tech news / developer news?

Twitter, email newsletters, slack/discord channels

What first inspired Diffuse?

Someone asked me to build a UI for https://github.com/trevorturk/kzak, and at the same time I was collecting music. Seemed like an interesting idea and fun to work on. Also, I used Spotify for a while, but they kept silently removing some of my favourite music, after that I never turned back.

How has user testing gone?

Could be better. People like the design, made a few feature requests, but never really expressed what could be better. That said, Blockstack recently put Diffuse on https://www.trymyui.com/ which has given me good feedback.

Where have you gotten the bulk of your users?

IPFS forum, https://electronjs.org/apps/diffuse and chinese/japanese blogs about IPFS. I think… I don’t have any analytics except on Github, so I don’t really know.

What was the most useful feedback you’ve received?

“I don’t know how to use this”

What is the benefit of using Blockstack? Drawbacks?

Easy decentralized authentication. Drawback, way too much javascript, bad performance.

If you were to redesign or reset your structure what would you have done differently?

I’m currently working on V2, which is built from scratch. So this’ll be easy to answer 😄 I like the design very much so that stayed the same, just more fine tuned, more attention to detail. Structure has improved as well, better performance, moved more things on the web-worker side, easier to extend (build on).

What challenges did you experience integrating IPFS?

I don’t really remember the music-storage integration, was over a year ago. But I think it went pretty smoothly, except for a CORS issue which was later resolved in go-ipfs. I recently did IPFS “authentication”, or in other words user-data storage, which is the unpublished work-in-progress V2. That was more challenging, I had to find a good way to encrypt the user’s data.


Thanks Steven for spending time to help get this ready for others to learn from. We'll be posting other IPFS projects on this blog as well >> be sure to check back soon.


Cover image from David Jorre