A Smart Contract for the Music Business : First diggings

What a great week! I somehow knew that the tools were great, but further digging around showed that the reality was beyond expectations.

Not only have I discovered fantastic frameworks and tools for ethereum blockchain development such as OpenZeppelin, Truffle, Drizzle, Remix, I also had the chance to talk to wonderful people at Augur and Emanate.

Profiling the contracts

Basically, the project will involve two contracts in order to distinguish the two main activities related to music production that are writing on the one hand and performing on the other.

Therefore, the project implies creating a writing contract which will serve as a timestamped proof of creation and hold reliable information about the author(s) as well as their respective shares.

Once the work is registered by the writing contract, its address will serve as a reference for a performing contract, which will hold information about any person artistically, technically, financially or otherwise interested in the master recording.

Some technical considerations and perspectives

The main challenges for any smart contact seem to be security and cost-effectiveness.

As I’m a true beginner in blockchain development, my view is that I can leave security aside for the moment as possible flaws that I may introduce in the code may be corrected by proper audit later on without having to redo everything. Besides, the frameworks I mentioned have reached such a great level that most of very basic mistakes can be easily avoided.

That’s why I think I must rather focus on cost-effectiveness as that has far greater influence on fundamental choices from the start.

By cost-effectiveness, one must understand that reading information stored on a blockchain is most of the time free, but writing to it necessarily implies a fee, which corresponds to the reward for the persons who actually provide the infrastructure to insert the information (activity generally known under the term “mining”).

There is also a question of portability of the code. Basically, I’m working for the Ethereum blockchain, but the possibility of either linking or porting the contracts should be done at least for two other projects, EOS as it’s the one chosen by Emanate which seems a promising project, and Uniris which might well be a “blockchain 2.0”, but that will have to wait for accessible tools to be made public. In the meantime, Hashgraph is also a project that need to be closely followed.

Regarding the token of choice for primary development, my opinion is that Brave’s BAT might offer interesting perspectives as it is integrated into the web browser, but as it’s an ERC20 (Ethereum) token, that decision may be postponed. If you’re not using Brave yet, switch to it now :-)

Now, let’s get some hands dirty

During the past week, I also noticed that Creative Commons are about to launch a new and easier to use licence chooser and that gave me an idea.

Even though Creative Commons licences are not well suited for music, as their primary object targets texts and self-made pictures while music needs to distinguish between writing and performing, I think porting CC to a smart contract can be a nice and useful running test nonetheless.

The global picture for a small Dapp is :

• Get the work you wish to release under CC to some sort of permanent storage (one can run one’s own IPFS node for instance, here again Brave Browser has its own IPFS Companion that can be enabled in the preferences, it’s off by default)
• Select your CC licence
• Fill in the URI/IPFS Hash
• Fill in your personal info (your ETH address can do)
• Deploy the contract

From then on, another small app can be programmed to retrieve data and licence information from the contract.

RFC

As always, comments and suggestions are welcomed.

I hope I’ll return with some code :-)

Write Medium in Markdown? Try Markdium!