Music player with IPFS backend

ipfs-cluster
go-ipfs
#1

Hey folks, I’m building a music player with IPFS support.

App: http://ongakuryoho.com/
Code: https://github.com/icidasset/ongaku-ryoho

I am waiting for the approval of this PR on go-ipfs though:

Would be awesome if someone could look at this PR, it’s super small
but necessary for my app to work.

Let me know what you think, thanks :v:

7 Likes
#2

The screenshot looks cool, but I didn’t get past the part where it seemingly requires something called blockstack to be installed – and it apparently doesn’t have a release for windows.

Is there a way to try it without a blockstack account (or having to build it from source, if that’s even an option on windows)?

1 Like
#3

@icidasset Is blockstack really needed?

#4

@leerspace @koalalorenzo Yeah, Blockstack is still in alpha. Would be cool to have some alternative to Blockstack, but I haven’t found any (yet). Blockstack is used for the authentication and storage of the processed metadata, your favourites and other settings (so it will be persisted across your devices).

Maybe I could add an anonymous mode where all those settings are stored in localStorage or something similar? Thoughts? I’m open to suggestions.

PS. You don’t have to build it from source, it’s online at http://ongakuryoho.com

#5

Anonymous mode is an interesting idea. As for metadata & settings etc., these could also be stored on the IPFS, right? IPNS, to be precise; you just need an IPNS publishing key shared between all of the user’s devices, then every device can update them to whatever the latest setting etc. is.

A public mode could also be nice, e.g. if you have songs of your own you want to make publicly available; then all you need is a website that gathers the IPNS hashes of people’s public libraries (or they register the IPNS hashes there), with player functionality, social stuff etc., for a kind of distributed SoundCloud. :slight_smile:

And, of course, a system for sharing parts of a library (or even the full one) with friends & family. :wink:

Don’t know how to do the authorization thing. Maybe you can even use IPNS keys as a system to authorize users and assign access to certain content?

2 Likes
#6

@icidasset, actually @JayBrown is right: you can use IPFS to store metadata (…and also encrypt the values) and share the IPNS pub-keys across the devices to technically sync.

The anonymous settings in localStorage would remove the dependency of Blockstack… that would be awesome! :slight_smile:

Keep rocking, this project has a cool start!

1 Like
#7

@JayBrown @koalalorenzo Thanks for the great feedback! I just added an anonymous mode.

I’ll look into this IPNS thing, I don’t know much about IPFS yet.
I’ve also added a small “DSL” to make it easy to add new authentication methods:

So hopefully it’ll be easy for people to contribute and to add IPNS support.


Thanks for the great suggestions!
I will definitely keep these in mind for the future :smile:
A public mode sounds like a really good idea :+1:

2 Likes
#8

This is working great for me (the logging in part), but now I’m trying to figure out how to get the IPFS integration to work. Does it look like I’m missing something?

After adding an IPFS source I’m getting the following error in chrome.

XMLHttpRequest cannot load http://localhost:8080/ipfs/QmeMoVQGwE5tWTxkS3UJkmkZTwBMrUWciagXn9ErgQ5Bsi. Request header field Range is not allowed by Access-Control-Allow-Headers in preflight response.

So far I’ve tried the following steps (I already had go installed).

  1. go get -u -d github.com/github.com/icidasset/go-ipfs
  2. ln -s $GOPATH/src/github.com/ipfs/icidasset/go-ipfs/ $GOPATH/github.com/ipfs/go-ipfs to allow the make command to complete without errors
  3. cd $GOPATH/src/github.com/icidasset/go-ipfs
  4. make install
  5. cd $GOPATH/bin
  6. ./ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["*"]'
  7. ./ipfs daemon
1 Like
#9

@leerspace Thanks for trying this out, much appreciated!
Sorry, I forgot a few steps with the CORS setup (I experimented too much with the config) :sweat_smile:

Here are the updated CORS instructions, this should work:

#10

That did the trick! :+1:

This is probably one of the first apps I’ve personally encountered integrating with IPFS that I could see myself using on a daily basis.

This might be user error on my part, but assuming it’s not do you have any plans to support flac and other audio formats? So far I’ve only been able to get it to work with mp3s, but it’s working great for those.

#11

I agree: since IPFS is cross-platform, such a music player should also support formats like m4a (mp4), mp3, flac, alac, wma etc. … not sure if that’s possible right out of the box, e.g. with alac or wma.

Personally, I would highly appreciate production formats like Broadcast Wave (.wav, .bwf) and AIF. Would be great exporting a cue during production, just add it to the IPFS, and the relevant people with correct access can just stream (and download!) it in the original format. (All header metadata intact, like timecodes, production notes etc.) But that’s just me… always thinking about work, not entertainment. :stuck_out_tongue_winking_eye:

#12

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.

#13

@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 https://github.com/aadsm/jsmediatags 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
#14

@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.

#15

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!

#16

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!

#17

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 slack.com)

1 Like
#18

Thanks for the detailed answers @flyingzumwalt! :smile:

#19

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.

Thanks!

“Gateway”: {
“HTTPHeaders”: {
“Access-Control-Allow-Headers”: [
“X-Requested-With”
],
“Access-Control-Allow-Methods”: [
“GET”
],
“Access-Control-Allow-Origin”: [
“*”
]
},
“PathPrefixes”: ,
“RootRedirect”: “”,
“Writable”: false
},

#20

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 -> https://gist.github.com/icidasset/c1883d594574a958ae4b4a5a91db1070)

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: