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)?
@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.
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.
And, of course, a system for sharing parts of a library (or even the full one) with friends & family.
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?
@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!
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
A public mode sounds like a really good idea
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).
go get -u -d github.com/github.com/icidasset/go-ipfs
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
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.
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.
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! 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
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
How secure is IPNS? Can I use it to store sensitive data? For example, in my case it would be Amazon S3 secret keys.
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?
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?
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.
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)
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.
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