Fairness and freedom for artists: Towards a Robot Economy for the Music (Streaming) Industry

[Tim-W]

(Placeholder issue for msc thesis)

Problem statement

(Musicians/artists/creators) receive low compensation for publishing their content.

• Typical cut of revenue: (distributor: Spotify/iTunes/Google Play/...)
  Signed records: 25% distributor 55% label 20% artist
  Unsigned records: 40% distributor 60% artist
• Smaller artists get low revenue, due to the "pro rata" model applied by e.g. Spotify. A user-centric model should be more fair (economics/business, less CS)
• The distributor could censor tracks
• Platform lock-in

Existing and upcoming solutions
Blockchain-based solutions exist for music streaming services. At least two start-ups attempted.

• OPUS Audio "Helps artist generate the revenue they deserve".
  It uses IPFS for distributed file storage, but actually uses a back-up off-chain database for performance purposes. Strategy for IPFS nodes: OPUS deploys its own nodes around the globe for low latency.
  OPUS uses Ethereum smart contracts. Using smart contracts, "[consumers] can rest assured almost 100% of the payments are delivered to the artists transparently, immutably and without intermediaries taking large chunks of revenue”.
• Musicoin project
  encourages independent artists to register and publish their work on its own blockchain-based platform. Very interesting: consumers have a free service without ads, while artists get paid (in $MUSIC)
  Uses earn-per-play smart contracts based on preset fees each time a song gets played (for >s seconds). Consumers can also tip artists (micropayments).
  Uses mining in the form of bitcoin.
• Mycelia project is not a streaming service on its own but does provide "creative passport" technology: a digital container with authorization of work, acknowledgements, payment mechanisms and metadata.

Shortcomings of these solutions

• Musicoin pay-per-play system depends entirely on investors and the price of its non-stable currency. If its currency becomes worthless then the artists also receive low revenue.
• OPUS deploys nodes itself and consumer pay a (small) fee for this infrastructure (different from Tribler/torrents)

The dream: a good decentralized streaming system

• A (torrent) streaming technology as fast as spotify, based on a p2p file sharing system (tribler? IPFS?). Challenge: seeders for content with small popularity. To think about: are bandwidth tokens enough incentive?
• Proof of authorship on the blockchain Proof of Authorship on GigaChannel with TrustChain tribler#4144
• (Near) 100% of fees from consumers go directly to the artists they listen to.
• Payouts with stablecoin (USDT/EURS)
• Tipping system/micropayments
• Effective sharing and recommendation systems

Completed reading list

• How the blockchain is disrupting the art economy as we know it (2017)
• de Vos, M., & Pouwelse, J. (2018). A Blockchain-based Micro-Economy of Bandwidth Tokens. CompSys 2018.
• Blockchain is changing how media and entertainment companies compete
• Zhang, B. (2018). Credit Mining: An Incentive and Boosting System in a Peer-to-Peer File-sharing Network.

[synctext]

Brainstorm on direction:

• pre-fetching algorithm/engine for uninterrupted audio streaming
• organic growth of music taste and neighbour discovery
• crowdsourcing of music playlists (magnet links, fight spam, build trust)
• Eurotoken foundation for artist donations
• flawless streaming of magnets (latency and stutter)

Work from now 15 years ago Wi-Fi Walkman: A wireless handhold that shares and recommend music on peer-to-peer networks

Upcoming sprint: document related_work.tex in thesis wording?

[Tim-W]

Looked up more decentralized music streaming services:

1. Audius (85% profit to artists, uses ads, other profit to developers of music app)
2. BitSong (unreleased) (no stablecoin)
3. Musicoin (No stablecoin)
4. Resonate (Profit distribution is a "co-op": Musicians 30% Listeners 25% Workers 15% Rainy day fund 20% Owners of “supporter shares” 10%)
5. eMusic (Seems to be most mature, 60 tracks for $20/month. No stablecoin. They sell their eMC token for 0.35$ each, but could up this price whenever they want, pays artists/content distributors in eMC)

IMO services only using non-stablecoins can be disregarded. They build a platform and launch their own token/coin which hopes to gain value (hard to say for future).

Conclusion: None of these applications pay near-100% of profits to artists in "real" money (eur/usd)

[Tim-W]

(Work in progress) related_work.tex

[Tim-W]

Updated the tex with a summary of current decentralized audio streaming services, and decentralized content delivery networks.

Also, possible future directions:

• "content discovery and metadata sharing using gossiping protocols (torrents and/or blockchain)"
• "incentivizing seeders (bandwidth token?)"
• "paying seeders and artists through fast smart contract system"

• Encrypted audio files, key unlocked via smart contract ?

[synctext]

Feedback on progress:

• are you providing an alternative to Big Tech and the centralisation of our economy?
• what is a better problem description for your thesis?
• Can this be (in principle) generalised beyond audio?
• "pre-fetching algorithm/engine for uninterrupted audio streaming"
  • radio non-interactive model
  • invest MBytes into an audio asset
  • Only when downloaded 100% we score user satisfaction
  • Downloads of 99% or less resulted in waste of user resources
  • Having no download to play for a user results in significant user anger
  • assign a factor to usage of caching space and speculative bandwidth usage
  • flavors: greedy, frugal, or unlimited resource usage for true uninterrupted audio streaming
• Optionally filter potential magnet links with existing collaborative filtering algorithms
• completely other direction is "follow the money"
  • artist fairness, frictionless Bitcoin donations, "Tipping system/micropayments"
  • build upon the DAO
  • pay Bitcoins for pull request which extend The DAO (e.g. enslave developers)
  • crowdsourcing, text files of magnet links mashups, music discovery, bluetooth local discovery
  • proof-of-authorship, artist passport
  • 17 student: Blockchain Engineering projects - class of 2020 tribler#4863 (comment)
  • content discovery ongoing work

[Tim-W]

Reading:

• Kreitz, G., & Niemela, F. (2010, August). Spotify--large scale, low latency, P2P music-on-demand streaming. In 2010 IEEE Tenth International Conference on Peer-to-Peer Computing (P2P) (pp. 1-10). IEEE.
• Y. Huang, T. Z. Fu, D.-M. Chiu, J. C. Lui, and C. Huang, “Challenges,
  design and analysis of a large-scale P2P-VoD system,” SIGCOMM
  Comput. Commun. Rev., vol. 38, no. 4, pp. 375–388, 2008.
• Zhang, B., Kreitz, G., Isaksson, M., Ubillos, J., Urdaneta, G., Pouwelse, J. A., & Epema, D. (2013, April). Understanding user behavior in spotify. In 2013 Proceedings IEEE INFOCOM (pp. 220-224). IEEE.

[Tim-W]

From my perspective, depending on time constraints/progress I could try system 1 or system 2 (using a DAO):
System 1: fairness for artists, any files
Challenges:

1. Latency/speed of (donation) payments, synced with torrent downloads
2. Proof of ownership/artist passports
3. Permissioned access to publish content
4. Sharing and discovery of content, metadata storage
5. Incentivizing seeders (bandwidth tokens? seeders receive stablecoins?)

System 2: fairness for artists, music streaming
Additional challenges:

1. Low latency/stutter/seeking audio files
2. Prediction of next played audio file, pre-fetching algorithm
3. Music discovery/recommendations
4. Pay-per-stream instead of pay-per-file?

[Tim-W]

Change in relation to my most recent comment:
The system:
A music streaming and/or file sharing DAO where users can donate to artists. (near) 100% of those donations are received (near) instantly by the artist. Artists can prove which content is theirs so that the correct artist receives the donation.

[synctext]

cool!
btw Both Bitcoin and Libtorrent have now been integrated in DelftDAO. That saves you lots of engineering.

[synctext]

@Tim-W online for sprint update?

[Tim-W]

Sorry, I have not been able to make much progress in the recent weeks.. (see my email) I will give an update before the coming Tuesday

[Tim-W]

@synctext Sprint update:
Trying to define a better problem statement:
Problem statement updated, split up into 4 subproblems:

• As a user of any good paid audio streaming service, large share of my money goes to the platform instead of my favourite artists.
• Torrenting the music while giving donations in parallel to artists is a solution. However this is a bad user experience as there exists no seamless streaming and exploring system for audio torrents.
• I need to look up how to donate for each of my fav artist which is cumbersome.
• I need to be sure that when I make a donation, it actually goes to the right artist/label/rec holder.

any good paid audio streaming service refers to any of the spotify/google play/itunes that provide seamless experience and a large amount of content.
A possible (dreamy) solution:

• A seamless music streaming experience without a middleman taking (nearly any of) my money. I want to donate directly to my fav. artists. As a listener I want these functionalities combined in a single app.

Progress
Read most of Mitchell Olsthoorn's FBase thesis
Read The DAO whitepaper
Trustchain superapp: Inspected docs, code, ran the app.
Kotlin-ipv8: Inspected docs, code.
Plans
Coming days: fork superapp, create a DAO, upload&share audio/music metadata with peers on an IPv8 app.
Coming week: Find more papers about fast music (torrent) streaming. Then: describe the "dreamy" solution in a more technical system, describe what the "MusicDAO" should be able to do, and predict feasibility for thesis.

[Tim-W]

Forked IPv8 superapp, wrote some code, added my own very simple app to it.

• Created custom ipv8 community
• Iterative peer discovery
• "Discover music content": iterative scanning
• Very simple "discovery" messages on overlay with authenticated communication

* Followed [TrustChainTutorial](https://github.com/Tribler/kotlin-ipv8/blob/master/doc/TrustChainTutorial.md) to get hands on with trustchain interactions. Content on trustchain: "Artist" publishes a track with a track id, name, magnet link. Others can validate whether the content is a duplicate (simple identity theft resilience)

[Tim-W]

@synctext Can you link me to the project for bitcoin/libtorrent integration in DelftDAO?

[synctext]

Great stuff! Feel free to re-use the pro-artist storyline I wrote April 2019:

Many people have tried to create a micro-economy for Internet privacy using coins, credits, and
karma for onion routing. Various incentive mechanism have been proposed to prevent the tragedy
of the commons, such as, GoldStar, PAR, BRAIDS, LIRA, TEARS, and TorCoin
[ARS08,DWB10,GRF14,JHK10,JJS13,JMS14,RMS04]. However, the problem remains unsolved.
Our prior work: In prior work we created “Self-replicating autonomous AI agents”. Our
self-replication toolkit called “​ CloudOMate​ ” is now mainstream open source software 2 . CloudOMate
offers a permissionless open compute API which provides an automated way to buy VPS instances
and VPN services from multiple providers. Our work differs from buying cloud hardware by credit
card. Our agents are truly autonomous and humans are unable to access their money. This
architecture offers unique security properties, theft of credit card numbers or passwords are no
longer possible. Based on this toolkit we created a live ecosystem. Our self-replicating agents can
own electronic money (Bitcoin, Ethereum), buy server space in the cloud without any human
assistance, offer compute services on a decentral market, have a primitive learning ability, and
can convert income into replicating themselves [RSP19].

Method and approach:We will study the right conditions for a decentralised digital economy
focused on music to flourish and realise it. Our alternative for the music industry is dubbed the
“Maximum Love Music” (MLM) community. Previously, we’ve grown a Youtube-like community
with ​ currently 35.000 daily active users​ , called Tribler. This MLM community will focus on
trust, marketplaces, and feature real money. MLM is academically pure and disruptive; it only
exists in code (e.g., “DAO” [UDA17]); all middleman functionality is conducted by open source
software for free. All money directly goes to the artists. Musicians can release music, sell concert
tickets, and receive payments without ​ any of this money going to record labels, producers,
bankers, credit card companies, or tech companies.
MicroEcon is deliberately provocative. The irony is that companies, like Spotify, use secret AI
algorithms extensively. We aim to disrupt the “Tech Elite” by offering a transparent non-profit AI
alternative, based on CloudOmate. The tension and emotion we consciously trigger lies in our
conflicted desire to create superhuman contraptions in capacity, but subhuman in status.
Creative element: We will create a live micro-economy with a self-sustaining society of
agents. All decisions about self-replication, money, tokens, and long-term survival will be taken
by autonomous intelligence. By applying end-to-end reinforcement learning we will use a single
goal which will drive the behaviour of agents: survival.
Our provocative approach is designed to stimulate volunteer contributions and mirror successful
projects like Linux, Ethereum, and Wikipedia.

We did CloudOMate. A full 19 master students are actively working on Delft-DAO towards a single codebase. Including Libtorrent integration and Bitcoin MultiSig scripting.

[synctext]

Suggested thesis sprint goals:

• Build upon existing Delft-DAO
• use Bitcoin wallet (Testnet)
• Libtorrent seeding of Creative Commons music
• Trustchain records to publish music Magnet links and link it to Bitcoin donation wallet
• play and donate button for music
• Proof-of-Principle for MusicDAO
• Do pull request of MusicDAO to SuperApp of @MattSkala of basic prototype in coming weeks
• iteratively improve for thesis
• build-up expertise and devise a clean architecture of what you already prototyped

Scientific issues:

• artist passport (this is My music and My wallet)
• music discovery and recommendation
• seamless, friction-free experience which has zero-maintenance and requires no central servers
• disruptive business model for artists (self-funded, self-publishing, self-managed)
• architecture for direct donations
• security: spoofing prevention, pollution of recommender, etc

[synctext]

The first Robot economy

Maximum ambition claim, you replace an entire industry by software. For the specific case of music you remove all middleman from the value chain. All economic activity into a single architecture. This means creating creating an operational end-to-end prototype. Emphasis can be in various directions:

• Private streaming; Tor-like privacy on smartphones; approaches that fully scales; build upon Universal communication using imperfect hardware tribler#4827
• Flawless streaming; speculative downloads, swarm health monitoring, fetch in parallel and only play if downloaded fully correctly
• User focus; improve user interface; search existing player code
• Business model; donations, artist revenue; talk to actual artists for a field trial and publicity
• AI; connect to CloudOMate
• Recommendation engine; operational playlist exchange without servers; spam flighting and pollution prevention; Trustchain for building web-of-trust
• Delft-DAO; creating a sustainable robot economy; get paid a bounty for extension of your app; create an autonomous micro-economy for this superapp; Bitcoin for new features.

[Tim-W]

Coming 4-ish weeks:

• Create a thesis.tex
• Prototyping simple app that can do:
  • Store magnet links + metadata on trustchain for tracks
  • Discover tracks
  • Play tracks using libtorrent
• Problem description (+introduction)

[synctext]

content: Jamendo + these 29,818 Creative commons tracks

[Tim-W]

Progress of code: https://github.com/Tim-W/trustchain-superapp/commits/master

0. DHT peers are continuously searched in background
1. The user can select an audio file from his Android
2. Audio file is converted to trackerless torrent, magnet link generated
3. Proposal block generated to trustchain including 1 song: {track ID, author, magnet link}
4. Block is self-signed
5. Other peers can fetch signed blocks (in video it is the same person), grab magnet link, start torrent metadata fetch
6. Use libtorrent to discover DHT peers, start buffering torrent pieces
7. When torrent pieces > X are loaded, exit "buffering" state. Play button then clickable
8. Keep downloading the torrent file. Seed after completion

Uses https://github.com/frostwire/frostwire-jlibtorrent and https://github.com/TorrentStream/TorrentStream-Android . TODO: seeking, track selection

Caveats:

1. Cannot demonstrate uploading and streaming from 2 peers as only 1 peer is not enough for torrent streaming. Will be very slow obv. In the video, the magnet link used for downloading is a static one with ~50 seeders.
2. Video is sped-up, "establishing peer time" is ~10s for magnet link described above

[synctext]

nice!
please rebase superapp with latest upstream additions + use a fixed creative commons content linked for demo purposes.

[Tim-W]

👍 Good point about the creative commons content, also I already rebased the superapp with latest upstream additions.

Thesis document updates will be from now on here:
https://github.com/Tim-W/master-thesis
I extended the related work and abstract here (document.pdf) mainly as a guideline for myself

Also, still thinking about the title. Perhaps "A music app/system fully owned and run by its users" or something more in the DAO direction (sustainable/future-proof app?).

Edit 30/04: Started working on introduction. see thesis git

[synctext]

Direct link to binary .PDF of master thesis
a music industry without any industry

Thesis draft comments:

• Solid progress with your prototyping: Libtorrent, streaming, Trustchain-based music discovery
• "A music app fully owned and run by its users", focus on a collective. Alternatives welcome with more bite.
• "This thesis investigates the feasibility and usability of an audio streaming service without a central distributor."; too modest and hesitant language. You will design a system and present a proof-of-principle where all money goes to artists. full stop
• shift in business model: online payments and integrated tickets purchase for live performances
• Read prior thesis work as preparation:
  • Trustworthy code execution
  • Sybil-proof accounting with Trustchain
  • Trading and markets
  • Consensus that scales
• Please do an upstream PR coming days. Before 11st May have a stable Creative Commons music playback (http:https://bt.etree.org/index.php?sort=seeders).
• Upcoming sprint goal?
  • integrate with MultiSig Bitcoin wallet
  • Artists can create a signed playlist with wallet and magnet links
  • any user can discovery this music and reward artist directly
  • most rewarded artists get top of frontpage (e.g. Like and Followers culture)

[Tim-W]

Short update on recent work: Worked on the app to make it more stable for a very simple proof of concept and to prepare it for a PR to the superapp repo. Also I'll try to share an APK soon once downloading/playing runs more smoothly.

• Use creative commons magnet links
• Each block is now a Release (album/playlist/EP/...) with 1 or multiple audio files. Once the magnet link metadata is fetched, the audio tracks are shown in a scrollable list. Each track can be selected independently to download & play.
• Created simple seeking & buffering behaviour: once you seek the song, it prioritizes the according torrent pieces to those minutes
• Created a view where you can see the torrent pieces. Each torrent piece turns blue when it is downloaded. (for debuggin & buffering testing)

[synctext]

Impressive progress again..! Please do a first PR today or tomorrow at the latest for the Superapp

[synctext]

robot economy for music

comments on thesis progress:

• repeating thesis direction: a music industry without any industry
• repeating: the first robot economy
• "2. Problem Description" focus: The robots are coming. Big Tech is dominating our online world. We attempt to create the first real alternative for Big Tech. We focus on the music industry due to the low level of innovation, monopoly formation, significant friction in this industry, copyright orthodoxy, market failure to control prices, and its overall readiness for digital displacement.
• a music collective is less scientific then a first robot micro-economy with real users, real money, democratic rule and full self-governance. e.g. DAO-based
• platform lockin: Youtube is too large, you have to be there as an artist and play by their monopoly rules
• luxury communism feedback: sounds nice dream, but can it also deliver within a non-trivial setting. Can this underpin the music industry of the future?
• too much activism, too little science: "breaking the tyranny of central control"..
• pragmatic artist naming claim: first claim wins, TOFU, note vulnerability for name squatting

Exploring scientific directions:

• "3. System architecture and design" We explore using swarm intelligence as the new organisational for alternatives to central Big Tech. Our design uses acadamic pure forms of self-organisations without any central point for coordination, control or governance. Specifically, music is discovered by gossip between neighbors. The emergent effect is that within seconds keyword searches return relevant results and zero-server AI content recommendations are keep users engaged.
• Business model focus: we show a real functional micro-economy with 100% going to artists.
• App focus: self-publishing and artist passport.

Upcoming sprints:

• wrap up streaming, buffering and seek. Create a stable basis for next sprints, ideally no need to re-visit the Magnet-Level and Libtorrent.
• first re-write of Chapter 2. and start with "3. System architecture and design" chapter
• Open question, re-usage of TUDelft broad knowledge of music recommendation
  • single artist playlist
  • crowdsourced recommendation playlist

[Tim-W]

Short update on this week's progress:
Focussed on stability and debugging progress per file.

• Removed the torrentstream-android dependency layer for now and only use JLibtorrent, as torrentstream-android was buggy
• Fix several issues with seeking, pausing/playing and switching tracks
• Handle file priorities: Once a file is selected to play, it gets a high priority to download
• Created a progress bar per-file
• Created animated GIF, see below

[synctext]

Please include subscription concept in thesis, if you agree with this: https://stratechery.com/2020/dithering-and-the-open-web/
open + pay-for. Playlist donations in Bitcoin in prototype?
We need to replace Big Tech storyline

[synctext]

MPs to investigate whether artists are paid fairly for streaming music
Musicians Can and Should Organize to Improve Their Pay and Working Conditions
More nice details and inspirational graph:

• Thesis getting ready nicely
• Section 2.4 and 2.5, 2.8 etc are too short. Merge or expand.
• Ground truth for your experiment. Validate and correlate statistics:
  • Google Play store download stats
  • requests for 10 MusicDAO Dollars (as background request)
  • Donation activity of users to artists

[ichorid]

Tried to install the abovementioned app-debug.zip on my phone, the phone says "syntactic error while opening the packet". What am I doing wrong?

p.s. Feel free to delete this message if this is off-topic.

[Tim-W]

@ichorid Please try using this artifact https://github.com/Tribler/trustchain-superapp/suites/1636262534/artifacts/30239452 let me know if there are issues. Unpack the zip on your phone -> open the APK.

Just merged all latest functionalities (swarm health gossiping, faster content spreading) and bug fixes here: #48

[Tim-W]

Added cover art & new layout (nothing fancy, if the album is pre-downloaded it fetches the cover art from the phone cache, no fetching from other devices directly). "Royalty free background music" here are 2 different records on TrustChain, it's not a duplication bug from the app itself

Cover art & new layout

I'm currently in the progress of obtaining 100+ creative common albums and making torrents and wallets for the demo. Then they can be put on seed box.

Edit 12 dec: Sandip helped me set-up a server for seeding of torrents. I am now seeding all of this free Creative Commons music from frostwire: https://www.frostwire.com/featured-downloads (free downloads for personal use), (112 albums, around 30-50 Mbs per album).
I'm now writing a script to put all this data into magnet links, extract metadata, create wallet identities and publish on TrustChain

Edit 14 december: now torrenting 2.5 GB of FrostWire and Jamendo creative commons music on the seedbox on TU Delft

Torrenting 60+ albums

Now the next step is to publish on TrustChain & generate wallets for each artist

Also installed the app on a friend of mine and working well after some last minute bug fixes. (network of my phone, virtual phone on PC and his phone)

[synctext]

MusicDAO is getting there. Please upload a new version to Play.Google for wider testing and bug feedback. Crawling trustchain will give you a scroll list of 2.5GByte of magnet links. Gossip of these magnet link by seedbox? Good thesis material and music discovery protocol design (20 unique demons, 20 UDP ports (same IPv4) running at seedbox). One album shared by all 20 peers, goes to the top of the page, should have incoming donations enabled...

In a broader 10-year vision, DAO is only a first milestone. Solid step towards a "Democratic Economy" in which people vote, contribute to the greater good and give reward to those who "do good".

.APK downloading link fails to work on Android

app (12).zip
Content: http:https://bt.etree.org/index.php?sort=seeders

[Tim-W]

app-14dec.zip
@synctext Update: MusicDAO version from 14 dec is now available on Google Play: https://play.google.com/store/apps/details?id=nl.tudelft.trustchain
From now on I'll deliver updates through the Open Testing on Google Play

[devos50]

It seems that Spotify is supporting direct artist donations without taking a cut:

[synctext]

Play store version works! Donated 1BTC to a good free album.
btw direct donation with Spotify still have PayPal as an intermediary taking a cut.

[Tim-W]

MusicDAO release 0.2 "Christmas release"
Google Play store: https://play.google.com/store/apps/details?id=nl.tudelft.trustchain&gl=NL
The app is ready for its release experiment. I will send a message over Slack to other 'colleagues' to download, install and run the MusicDAO.

I currently have 2 "seedbox" nodes running to get the music data started. There are a little over 100 albums published on TrustChain with torrents, with 3.9GB of music. I have 20 virtual IPv8 nodes running which are publishing this data, spread over 2 servers (10 nodes each).
I also renamed "Ipv8 apps" to "TrustChain Superapp" for more consistent naming.

Latest new features and changes #50 :

• Various stability improvements and fixes
• Drag to refresh overview
• Streaming implementation improvements
• Fixed inconsistent naming of track files

GIF: Browsing and streaming music

GIF: Sending money to artists

Main challenges currently:

• IPv8 nodes eating up memory of the bootstrap nodes
• Possible bugs

[synctext]

• Status of master thesis
  • Now bug fixing, 100% of the code is complete
  • Thesis writing, 75% done.
• For debugging: add number of IPv8 nodes or something to understand album discovery one level deeper (ideal: Commulative unique IPv8 nodes seen)
• DHT announce from 1 IPv4 within IPv8 for 100 swarms
  • probably detected as a DDoS attack by the other participants in DHT
  • This is a confirmed known issue: DHT node spam from exit nodes tribler#3065
  • Our Ipv4 is banned then
  • results in extremely slow content discovery speed
  • Performance analysis: without DDoS fix, with central tracker, and with DDoS fix by using multiple IPv4 addresses
• Quality assurance content
  • Figure 5.9: Firebase Crashlytics crash reporter; this figure shows the crashes over time
  • Document the bugfixes
• "7. Evaluation", Performance analysis and field experiment
  • 1 node measure the content discovery speed of your 100 swarms. With tracker and without, and hopefully a DDoS fix (Time of 24h versus amount of albums discovered)
  • Graphs of MusicBTC donations

[Tim-W]

Finally, after getting some rid of some pesky bugs in the seedboxes, I'm creating the first graphs measuring performance. Lot of work in evaluation/measurement still to do

Also I am now able to 'control' a network of 6 real world Android devices, for doing experiments. (and for making demo videos for the thesis defence?)

[synctext]

That graph is good thesis stuff!

[Tim-W]

Last 2 weeks:

• Started with measurements/evaluation: now I have 4 graphs and a tiny bit of text: evaluation-v1.pdf
• Fixed various bugs, new releases on google play store
• Finally fixed seedboxes well, downloading an album should be 10-20 seconds now
• Ran experiments with ~5 android devices locally (see pdf)
• Gave the MusicDAO to 10 people so far, to let them play around with it and send money to artists. I can inspect this money flow by inspecting the blockchain
• MusicDAO has run on 10-15 devices in total

Still to do:

• graph/list of all bitcoin donations to artists over time and some nice visualization showing which artists received money
• other graphs/evaluation material: search latency, streaming buffer preparation time in comparison to network size
• Larger test group? More devices and people

[synctext]

• Good chapter 7 matter.
• ToDo: writing sprint
• minor quality of life improvement: click triggers download of swarm, also auto-play please when 50% downloaded or 100% downloaded.
• Chapter 7: In an ideal world we could measure how happy music artists are before and after using our ecosystem plus their earnings.
• money more interesting than streaming stuff
• Goal of this first experiment is to determine the responsiveness of our infrastructure in ideal circumstances. We scripted our downloading and streaming activities to determine the lower bound for the end-to-end latency. This experiment uses hardware, thus Android will be less. etc.
• "we inspected the blocks in our Bitcoin regtest environment in order to show all transactions", re-formulate into more scientific focus. like: We obtained a dataset for our experiments by combining information from various sources .. combining the Google Play transactions with Bitcoin monitoring, etc.
• Trail promo movie of 60 seconds or less
  • opening screen, TUDelft logo, master thesis, your name
  • google play "search for 'trustchain' "
  • show walkthrough all your app features "1) discovery music", "2) play music" "3) pay artists 4) share music freely (magnet link demo, multiple devices)"
  • final credits show Github URL

[Tim-W]

New graphs, that show the transaction success of our bitcoin blockchain environment.

(Cumulative) artist income vs. bitcoin block count

(Cumulative) transactions vs. bitcoin block count

Question: I'm wondering, what is a valuable visualization of artist donations for my thesis report? Currently we have these graphs with total transactions, throughput, block count etc. but we do not show any individual artists and what they receive. @synctext

Expected releases vs. simulations - versus network size

Last couple of days: did a few more experiments and created more graphs for latency, throughput of certain activities in MusicDAO. Mostly working on evaluation.tex now.
(5+ pages as of 04/02/20201)

Update 05/02/2021 made some improvements to implementation and evaluation
Update 06/02/2021 added keywords and empty sections for things I still want to (at least) write. There is a long section I can write as Future work. Where should this be placed? Evaluation or Conclusion, or as chapter inbetween?
Update 10/02-2021 Updated title. Added several things to intro end evaluation, fig. 4.5, sections 1.4, 4.10, table 1.1. Updated conclusion with section titles.
Update 11/02-2021 Add short sec. on transaction fees in Evaluation.

Thesis version can be found here (40 pages), direct link: https://github.com/Tim-W/msc-thesis/raw/master/report.pdf

[Tim-W]

Update 10/02/2021 created MusicDAO demo video
Currently 1:27 minutes, could remove some stuff. It is not very professional, but it does show all its functionalities in quite a short time. Also, I'm working on a better render with higher FPS. Advice welcome, I am not a video editor :)

musicdao-demo-video-v4.mp4

Summary of updates to Thesis Report

[synctext]

• Learnings: running 6 Android emulators on local laptop as ideal development environment. (plus 3 real phones and unit tests)
• Promo video on Youtube.com
• 9 crashes reported inside Kotlin-IPv8 messaging since 5Feb; 7 other crashes
  • create issue(s) with details please (fixing is something else, essential to know pending quality issues)
  • 2 inside Trustchain payload generator
• Video is great intro to your thesis work and publicity for user-trail + measurements of live network.
  • users may be confused where music comes from and what the copyright status is.
  • suggested text to add "Streaming any Bittorrent audio swarm", "Grow the Creative Commons"
• Thesis review, 48 page version.
  • No new content needed anymore!
  • Make everything cleaner please (removed Storyline deviations, polished text, consistency, Figure perfection)
  • 4.2. Phone-to-phone censorship-free network. Deviates from storyline. Replace or remove. other angle; Zero-server architecture is selected because it created a zero-cost public infrastructure to facilitate a Create Commons infrastructure of digitally shared cultural heritage artefacts.
  • Sections are too short within entire thesis. Merge 2.4 into 2.3 and also: "2.5. Slow and inaccurate royalty payments"
  • Remove fragementation: 3.3.1. Audius. More readable without these headers
  • More scientific angle "3.4. Financial transparency in the music industry". Citations for this 'The exact overhead and spending in the industry seems to be hidden. Where all the money goes is unclear, but it does not goes to the musicians.'
  • "The overall design of the system can be seen in fig. 4.1.", please move this after the great text box; make it flow beautifully.
  • "4.7. Establishing trust and reducing sybil attacks", 4.7 trustworthy public infrastructure with attack-resilience
  • Table 5.2: Code coverage overviewTable 5.2: Code coverage overview: please add "Total Lines of Code" for all your work.
  • Figure 6.4: Average time spent per download stage; cleaner: make it a graph going to 120 seconds.
  • 5.11. Quality assurance: "In order to preserve quality of code we make use of continuous integration", claim credit for all the nice work you did. like 'Quality assurance is particular important aspect of this thesis work. With high quality code we facilitate potential re-usage of our ideas and implementation within industries outside the music business. We used industry best-practices such as continous integration'... 'Finally we used 20 unique Android smartphones for hands-on bug mitigation, User Experience uniformity, and performance analysis. Table X lists the various... During the implementation phase we ensured that MusicDAO operates smoothly on all these different Android versions, screens, and processors.'

[Tim-W]

I got a second bootstrap server succesfully running thanks to Sandip.

• Reduced the music gossip time for a few devices; 5 Androids are now sending music blocks every 0.5 seconds (on day&night).
• An actual end-to-end video of peer-to-peer libtorrent and bitcoin payment! The phone on the left is the only uploader and published the "John Doe" album. The tablet consumes it and sends bitcoins to the phone. See here: https://drive.google.com/file/d/1XKU91P0lShjQHtztdCMpFC6U4sAy-cfx/view?usp=sharing Will record a better version of this for the final defense presentation.

[synctext]

Nice!, please push speed (initial music discovery) and robustness (bootstraping) improvements to Android store.
today if you can.

[Tim-W]

Updates week 1 of writing

• Started on a more coherent Introduction and main storyline (theory around robot economy still needs some work):

Problem of centralization/platformization on the Internet > What is a robot economy (theory) -> What is a robot economy in software? -> What does it achieve (key characteristics) -> Problem of centralization in music industry -> Our first steps towards robot economy: MusicDAO

• Added conclusion + generalization of our framework
• Started on Future work (will be very long, so should this be a separate chapter?)
• Reduced focus on censorship-resilience
• Evaluation: P2P bootstrap problem section
• Evaluation: Battery usage section
• Evaluation: Scalability
• Evaluation: improved graph Content discovery and fixed maths
• Implementation: improved quality assurance section
• Design: add content popularity gossiping algorithm
• Design: add centralized vs. phone-to-phone netwokr diagrams
• Overall: Improve layout of images
• Overall: Improve layout of sections, reduce fragmentation of sub(sub)sections
• Problem description: added financial transparency section
• Problem description: added figure of music revenue over time in different sectors

In other news: Effect of TorrentFreak publication first day

Updates week 2 of writing

• Rewritten introduction and reformatted problem description
• Added sketch: Robot economy in software, visualized:
  
• Added overview of main contributions of our thesis in introduction
• Problem description: add table market share of music labels
• Proofread of chapters 1,2,3 and small changes
• State of the Art: improved AI DAO section + add figure
• Problem description: add more graphs showing reduction in Artist Income over time + add more latest numbers
• State of the Art: improved "Decentralized Music Distribution Technologies" sec + figures
• Cleanup of Design section + added AIDA algorithm
• Evaluation: improved Scalability sec
• Overall: made all sections roughly the same length (if they were too long, added subsections)
• Implementation: add Content Popularity gossip algorithm
• Implementation: improve keyword search algorithm sec + add screenshots
• Implementation: make introduction more clear

MSc_Thesis_25-02-2021.pdf

[synctext]

52 pages 👍 quick remarks, that robot economy architecture picture is great! Please make this the centerpiece of your solution and final thesis presentation. This is the future of the firm! Spend a few hours to make it stand-out if possible:

• remove the distributed data store
• "Collective Money" as separate box 🗳️
• give it an aesthetically pleasing star-shape with DAO at center with 4 connecting items (users,creators,robo infra,money)
• polished icons for everything, like open source:
• Icon for AI, single icon for user, icon for creative type/artist 🎨 , green icon for money 💵 (or use the €10 banknote which is red 💶)

[Tim-W]

More updates week 2 of writing

• Overall: made all sections roughly the same length (if they were too long, added subsections)
• Improved robot economy image, improved its storyline in connection to 3.2 "AI+DAO" and Design intro
• Implementation: add Content Popularity gossip algorithm
• Implementation: improve keyword search algorithm sec + add screenshots
• Implementation: make introduction more clear
• Evaluation: analyzed total money flow of donations to artists, improved graphs
• Evaluation: analyzed the influx of users from TorrentFreak impacting the transactions as registered by bitcoin node
• Add comparison to related work:
  

Received first feedback from Georgy Tim-W/msc-thesis#1 - he is working on more feedback
MSc-Thesis-26-02-2021.pdf

[synctext]

• 🟢 Green light, thesis is sufficiently ready to schedule a master thesis defense.
• Main issue with this thesis, still everything is described from engineering perspective. Science perspective secondary (e.g. "meaning there are 13,734 Android devices supported" in main chapter intro text).
• "Democratic user engagement" suggest not negative cross, but 'out of scope'. (evolution and AI are both: "ongoing research" with a Github issue citation)
• citation style, (Rayna & Striukova, 2009), switch to "[9]" if not too much work.
• consistency in: figure style (sketch,color,icon), language used, Figure centrering (versus table left aligned).
• "How can we design and implement a music streaming service that distributes the power from one authority
  to its users?" or 'How can we design and implement a music streaming service that prevents natural monopolies and transfers all power to Internet users?' ref
• Section 3.5 could use a forward pointer. "The Superapp is the software framework used within this thesis".
• 3.7 "Another is the FileCoin" missing text.
• Section 4.13 exists! Merge these small subsection and reduce it to Section 4.6 maximum. (e.g. Peer-to-peer music discovery and sharing)
• "table 5.1 Overview of our work compared to related work" make your two positive check more distinctive ( bold and/or green).
• "5.2.2. Gossip-based algorithm for content popularity", section too small
• 100% crash-free! 😎 🆒 😎 "Figure 5.12: Firebase Crashlytics crash reporter; this figure shows the crashes over time"
• rename please "6.2. public release experiment"
• More clearly: Bitcoin DAO fork 1 hour block creation interval (not only inside brackets in a figure caption)
• wow, "Figure 6.8: Search latency of performing keyword search"
• "99.9996%" please add more bits of accuracy
• 6.5. 'infrastructure cost analysis' , too engineering details: "Bitcoin node and transaction fees"

[Tim-W]

Updates to report and evaluation/experimentation

• Tab 1.1: mention related work instead of "out of scope"
• Incorporate feedback from Georgy
• In general: improve layout so that most sections are around half a page, reduce fragmentation of short (sub)sections
• Improve tab 5.1, also overall more "positivity" in tables
• Overhaul of chap 4 layout: 13 sections -> 7 sections
• Rewrite 4.2
• Improved robot eco diagram, Re-made fig. 1.2 with consistent style. Added consistent style for all the diagrams I made.
• Replace package diagram -> component diagram (5.1). Improved architecture diagram in Design.
• Changed research question throughout
• Chapter 7: Improved conclusion throughout
• Chapter 1: Improved introduction throughout
• Added preface
• Added abstract

Improved test coverage, add LOC to table. Most non-ui code is covered with Unit tests

Updates to Evaluation (re-done some experiments, updated some analysis

• More accurate tx fees
• Block creation interval more clearly
• Overall explain the experiments and results more detailed, rewrites
• Renaming: (un)supervised -> (un)controlled experiments, public release experiment
• Improve 6.5

Re-done n=10 content discovery experiment as the previous run suffered from network congestion

Re-done search latency experiment, now timed without UI rendering time

Improved analysis: BTC Faucet Responsiveness experiment throughout a full month (d=28)

Please note, app activations are here also recorded **outside of google play**, so also local test devices are incorporated in the data (the data is from Crashlytics _first_open_ event).

The lines should overlap. Reasons for no overlapping can be:

• Red above blue: activations
  which only use other mini-apps inside trustchain superapp (opened the app, but never opened MusicDAO)
• Server outages or Firebase Analytics precision faults

Improved analysis of artist income vs. Google Play installs:

Clarified experiment: phone-to-phone vs. central server+phones topology

Abstract (draft)

During the last decades of explosive growth in economic value on the Internet, we observe the trend of platformization: a shift of economic activity from happening on a wide range of companies to a few major platforms run by Big Tech corporations. This trend is highly susceptible to the rise of monopolies and oligarchs, as seen in the music industry today. In this industry, the top 5 streaming services and top 3 labels form oligarchs. Artist income is diminishing because these powerful intermediaries take large revenue cuts. Streaming services also have curatorial power: they decide the inner workings of their black box recommendation systems. As an alternative for centralized Internet platforms, this thesis presents a theoretical framework for building a robot economy in software: autonomous software in which robots perform monetary transactions on their own. It allows for building infrastructure for the common good: software systems that (1) handle financial transactions in a fair way, as (2) decided by democratic engagement, (3) run transparently and autonomously, (4) are open to any participant (permissionless), (5) are decentralized and leaderless, (6) support a self-evolving codebase, and finally (7) can make intelligent decisions on their own using AI. We show a proof-of-concept of this framework, by implementing features 1,3,4 and 5. We present a fully operational decentralized music streaming, publishing and discovery mobile app (called MusicDAO) with peer-to-peer donations to artists. It is built on a fully distributed, self-scaling network of Android phones. The app was released to the public, and was installed on 50+ devices. During this public trial, the decentral financial infrastructure was successful: most music streaming platforms take a 20-40% cut of music revenue; MusicDAO takes <0.001%. Discovery and metadata search is operational with low latency. Peer-to-peer music streaming is operational, but its latency is not yet competitive. Our framework and proof-of-concept are fruitful steps towards research into infrastructure for the common good: software systems that are governed by its users instead of by profit-driven corporations.

New version of MSc thesis:

Update march 12: proofread everything, many small updates throughout entire thesis to make it a better flow/storyline.
Update march 13: Improved robot eco diagram, Re-made fig. 1.2 with consistent style. Added consistent style for all the diagrams I made. Replaced package diagram with a more simplified component diagram (5.1). Improved architecture diagram in Design. Improved conclusion. Added abstract and preface. Improved introduction. Improved conclusion.
Update march 14: Improved explanation of our robot economy framework in 1.2

https://github.com/Tim-W/msc-thesis/blob/master/report.pdf