a music marketplace DApp with a Ethereum/IPFS based decentralized serverless architecture handling the backend.
Alternatives To Resound
Project NameStarsDownloadsRepos Using ThisPackages Using ThisMost Recent CommitTotal ReleasesLatest ReleaseOpen IssuesLicenseLanguage
Aws Network Helper23
6 years agoPython
Project for submission to the 2016 AWS Serverless Chatbot Competition
Serverless Plugin Vpc Eni Cleanup20
8 months ago4November 30, 20213mitJavaScript
Cleanup of VPC network interfaces on stage removal
4 years agolgpl-3.0Go
A Scalable FAAS Network based on DAG.
5 years agoJavaScript
a music marketplace DApp with a Ethereum/IPFS based decentralized serverless architecture handling the backend.
5 years ago1lgpl-3.0Java
A secure and serverless chat application that uses the TOR network (Deep Web) to send the messages
Simple P2p Social Network6
2 years ago2JavaScript
A Simple P2P Social Network that runs exclusively in the browser to create 'pop-up' social networks on the fly
Mnist Ai Up6
5 years agoHTML
Learning deep learning :sunglasses: and neuroevolution :space_invader: :star:
Cvp Serverless Openfaas4
5 years agoHTML
Dispersed Network3
4 years ago1JavaScript
Dispersed Network is a proof of concept distributed serverless network
Bro Chat2
10 years agoGo
Lightweight serverless chatsystem for local networks. Keep the bro's connected ;)
Alternatives To Resound
Select To Compare

Alternative Project Comparisons


Resound is a decentralized music marketplace for independent artists and labels.

The goal here was to develop a front end using React/Redux, and develop an 'always on' decentralized, serverless backend. In doing so, people could choose to use the website without this frontend due to the nature of such a backend. This ultimately enables unlimited access despite any efforts to remove it.

This code needs to be refactored!

To Run It

For this version, I currently run it on Truffle's Ganache. However, it points to whatever you have locally listening on port 8545 (edited through truffle.js), so you could easily use a Geth node or similar. Additionally, MetaMask must point to the same network as the port in truffle.js.

You also need to be running a local node of IPFS on the same system, and ensure that the HTTP API is available.

yarn to install dependencies.

Run truffle migrate (add --network [network name or id] if you have multiple networks configured and want to pick one). This will compile the contracts into the ABI. It'll also deploy the contract to the given network.

Now, you should be able to run yarn start and start working with the app.


resound Flow Chart

In developing this decentralized serverless architecture for my backend, I leveraged two services:

  • The Ethereum Virtual Machine (EVM) as a database for primitive data types and transaction logic.
    • I was limited to using the EVM solely for transaction logic here due to cost of gas when writing to the blockchain. Storing large files in here was not an option, since the goal is for this website to be accessible; large files on here would be cost prohibitive for the average artist. Instead, I prioritized the information that was warranted the security of being stored on the blockchain.
  • IPFS (InterPlanetary File System) as a location for blob storage.
    • Since there needed to be a place to store the primary contents of the site - the audio files
    • One caveat here is that while the IPFS is designed to be decentralized, that is contingent on other people 'pinning' your data on their server. As such, it's not inherently decentralized. Currently, this web app is designed to be running on a server that is expected to have an IPFS daemon running in the background in order to connect it to the network. While it is yet to be implemented, a solution around this would likely be requiring artists to pin data to their own servers / computers, and the server 're-pinning' it locally for a fee to speed up transmission to the artist's fans. Alternatively, in lieu of a fee, artists could re-pin a certain amount of other artists data. This would force more artists to join the network, and as such, hosting the data, speeding up the network overall. This is the ideal solution, but also the tougher option to convince the masses of. It also unfairly leaves out artists who don't necessarily have access to internet in this way, so that would have to be worked out.

Concerns and Issues

  • In its current iteration, the files hashes are exposed to the public. This clearly isn't secure for artists avoiding piracy. A solution is to encrypt the location of those hashes
  • In terms of scalability, I can't expect to host all files on my own IPFS local node. Not only is this not truly decentralized, but it will bottleneck the network and not be able to keep speeds up to speed (pun very much intended.)
  • I also don't provide nearly enough security on the user verification front. I just pull from MetaMask's injected web3 instance. In the future, I should implement something like Consensys' uPort to verify the user.
  • Intellectual property. How do we protect artists? What if something is released somewhere else first, where someone takes it and tries to sell it here?
  • I handle Wei / Ether conversion pretty messily. I only stored up to a complexity of 0.0000 decimal places, but it would have been far easier to just force the user to work in Wei. However, I thought this might be confusing to the average user. May explore this again later with a live conversion below.
  • Lots of refactoring and optimization. There's a lot of async work in here that needs to be corralled a bit as far as triggering rerenders etc.
Popular Serverless Projects
Popular Network Projects
Popular Cloud Computing Categories
Related Searches

Get A Weekly Email With Trending Projects For These Categories
No Spam. Unsubscribe easily at any time.