Music player with IPFS backend

I’m not sure if I’m somehow still running the development version of IPFS (I’m pretty confident I’m running the 0.4.10 release right now), but the site seems to be working for the most part even without using @icidasset’s PR. I’m able to add new IPFS sources and play songs from those sources.

I am seeing a couple of errors from elm-loader.js, but I’m not seeing an apparent functional impact.

@leerspace Awesome! :tada: If you do start using the app on a daily basis (which would be amazing, thanks so much) and you encounter any bugs or find that some things are missing, feel free to create an issue on the Github repo.

That said, there’s only support for m4a/mp4 and mp3 right now. It’s using under the hood, so maybe, if I ever get to it, I could look into writing additional parsers. But that’s totally not my area of expertise (like at all). But yes, .flac and .wav support would be nice. I’ll look around on Github for some alternative libraries though.

Always thinking about work, same problem here @JayBrown :grin:

1 Like

@leerspace Oh really :thinking: That’s odd, I’ll look into it, thanks! What are the other errors you’re seeing?

EDIT: Just tested it, and it kind of works without using my fork. But I’m getting these kind of errors for some files:

Object {type: "parseData", info: "Offset 1025 hasn't been loaded yet."}

Which is because it doesn’t actually return the Content-Range header, which I fixed in my PR.

Those are the ones. For some reason I’m not getting them right now (with vanilla go-ipfs 0.4.10), but I’m not complaining :slight_smile:.

Will do!

Hey @JayBrown

I was looking at integrating this IPNS thing and was wondering about a few things.
Could you answer some of these questions for me?
Totally fine if not :relaxed:

  1. How secure is IPNS? Can I use it to store sensitive data? For example, in my case it would be Amazon S3 secret keys.
  2. What is this publishing key exactly? Is it like a password, in the sense that I keep this key to myself and don’t share it with others?
  3. What would be the easiest way for people to start using IPFS/IPNS with my app? Do people set up their own server (eg. brew install ipfs && ipfs daemon) or is there an easier way?

Thanks for your time!

Neither IPNS nor IPFS encrypts your content for you. block-level encryption is planned but right now it’s up to you to encrypt the content you put on IPFS.

IPNS does uses private key cryptography to prove who published an update, but it does not encrypt the content itself.

Search around on discourse to find discussions about this topic. Example: Ipfs dynamic content like cms

Read up on public-key cryptography.
You could start with the wikipedia entry and then explore the idea space. That’s where you will find the answers you seek.

Write your app as an offline-first distributed app and bundle IPFS with it. You can still run a web-based version of the app, but the downloadable desktop version will be the main thing people use (Like Slack – where you mainly use the desktop client but can also interact with the same information at

1 Like

Thanks for the detailed answers @flyingzumwalt! :smile:

My attempt to add a music source failed. Or rather, the source was added, but no music came through. The console shows me an error: “Request header field Range is not allowed by Access-Control-Allow-Headers in preflight response.”

I’m running go-ipfs 0.4.11-dev (up to date from Git) with your patch to allow content ranges. I applied the patch, did a ‘make install’ and then restarted the daemon. Do I need to do something further to make it work? I’ve pasted below the ‘Gateway’ part of my config file in case I need to make a change there.


“Gateway”: {
“HTTPHeaders”: {
“Access-Control-Allow-Headers”: [
“Access-Control-Allow-Methods”: [
“Access-Control-Allow-Origin”: [
“PathPrefixes”: ,
“RootRedirect”: “”,
“Writable”: false

Thanks for testing this @JamesVasile!

Your config doesn’t look right, “Access-Control-Allow-Headers” should also specificy “Range” and “Content-Range” as per the instructions (ie. the link on the ‘add new source’ page ->

Let me know if that works for you.

PS. That ‘add new source’ page will be improved in the future, it’s a bit of a mess atm :sweat_smile:

That works. Not sure how I missed the instructions the last time around. Thanks for pointing it out so kindly.

As a simple music player, your site is nice, clean, and easy, even if it isn’t packed full of features. It’s good work. Can I ask where you go from here? What’s the intended use?

You now have a bunch of ID3 and filename data correlated to hashes. Will you make that usable to others? If so, how?

Good luck!

No problem and thanks for the feedback! :relaxed:

I’m not 100% sure where I’ll go from here, but I do know that:

  • I’ll add the ability to upload files as well
  • It should be really easy for people to copy their IPFS hashes, share it with people and then play the music with the app
  • Proper integration with the Blockstack platform (currently in development)
  • Add more features like playlists and a album-art view

As far as the data goes (the id3 and filenames which you mentioned), I don’t have access to that at all. The application is completely client-side and the data collected is completely in the user’s control.

Thanks again!

1 Like

@flyingzumwalt already answered it well, but one addendum, because you asked for the publishing key. That’s the key a user would generate in his client software to publish metadata, playlists etc. (maybe even songs for download) on ipns. The go-ipfs equivalent is ipfs key gen --type=rsa --size=2048 mykey. The key “mykey” will then be saved to your ~/.ipfs directory, and you can then publish using that key, instead of using your PeerID. You can create as many keys as you like, e.g. if you want to share metadata/playlists etc. with different friends, you can create one publishing key & one ipns publication per friend sharing linkup. Then you just need to share that publishing key with the people you’ve linked up, and for that key-sharing operation, the key needs to be transferred encrypted, and for that a public-private key cryptography would be the best way. (Simple S/MIME with openssl would probably suffice.) You also need to account for the situation when one user leaves or is kicked out of a sharing group: then your app needs to remove that key again, i.e. it has to be stored locally in encrypted form as well, but this time the encryption is only known to your app, not to the user, i.e. the user won’t be able to just snatch the key from the Application Support folder before leaving the group. :wink:

PS: what you put into the ipns directory should be encrypted too. And that would complicate things, if multiple users share that directory, if users are added, if others leave etc.

1 Like

Thanks for the awesome explanation @JayBrown! I really appreciate it!
It’ll be quite a challenge to implement this, but I’ll see what I can do :sweat_smile:
It certainly has a lot of potential :open_mouth:

Ok, here’s my first attempt at writing down something that would work for my application. It’s definitely not as refined as what you described, but I’m slowly getting there :stuck_out_tongue_winking_eye:


PS. I know that it isn’t very secure (yet), but I’m trying to wrap my head around the basic idea :sweat_smile:


I’m still very excited for this! I’ve been wanting something similar.

A) Is there a way for my server to add files to my library? Use case: having my mqtt-controlled cloud-dwelling bestie receive a song web address, rip it via youtube-dl or similar, push it to ipfs/AWS, and put it in my library. Only required input is sharing the link on the relevant mqtt topic.

b) could a server modify my queue on my phone or laptop? I.e. have a recommender system of my own on my server be able to dynamically live-recommend songs into my queue

C) could this run on a phone? I.e possibly by

  • using pre-populated local storage in a folder, and other software (synching) actually batch updating the folder when on WiFi & plugged in
  • pulling from AWS, caching locally
    • using IPFS on the phone (not yet afaik)

D) the songs are stored not-encrypted, correct? It’s only the personal info that is encrypted like AWS keys and blockstack stuff?

1 Like

Thanks @haniawni!

A - Part 1 :: I’m not sure what you mean by ‘server’, this application is client-side only (html + javascript). There is no backend/server. It connects to remote sources in the browser itself, finds all the music files on it, gets the metadata from those files and then stores that metadata somewhere (ie. localStorage, Blockstack storage or something else). I’m also working on IPNS support, but IPNS in go-ipfs is hella slow at the moment…

A - Part 2 :: I’m not sure if I understand your use case entirely, I have no idea what ‘mqtt’ is. But I can say that file uploading is planned for the future. Then you’ll be able to upload files from inside the app directly to your storage. Does that answer your question?

B :: That’s not possible no. Maybe someday?

C :: Only using the “anonymous” mode at the moment. Blockstack is still working on iOS support. So at the moment you can login using the anonymous mode, and then add a remote ipfs hash or AWS S3 bucket/directory.

D :: Like I described in my answer for A, the songs are not copied/stored, the app only extracts the metadata and stores that. Your files stay where they are.

Thanks for all the questions! Let me know if I missed something or if something wasn’t clear.

PS. There’s also the about page, which you can find here But I now realize that I probably should explain it a bit better.


This is an awesome project a little bit ago I was working on something similar with videos it only incorporates the local storage solution you have with the anonymous login.

I wonder if it wouldn’t be worth while to incorporate video into your project too.

Video Player Sample App

Thanks! I don’t plan on adding support for videos, but feel free to fork the project and customise it however you see fit:

By the way, if anyone is still interested, the app is now called Diffuse and can be found at:

The github repo has native versions you can download, see releases page.
Any feature requests can be made on the issues page.



i found your approach very intresting :+1:


1 Like