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:](https://www.theguardian.com/technology/2015/apr/03/how-much-musicians-make-spotify-itunes-youtube) (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](https://www.rollingstone.com/music/music-features/should-spotify-change-the-way-it-pays-artists-763986/) model should be more fair (economics/business, less CS) * [The distributor could censor tracks](https://www.springfieldnewssun.com/entertainment/spotify-removes-kelly-music-from-playlists-under-new-hateful-content-policy/9NIgUD8qJBd2tAYmVhn5hK/) * [Platform lock-in](https://www.google.com/search?q=Google+Rules%3A+The+History+and+Future+of+Copyright+Under+the+Influence+of+Google) **Existing and upcoming solutions** Blockchain-based solutions exist for music streaming services. At least two start-ups attempted. * [OPUS Audio](https://opus.audio/) "Helps artist generate the revenue they deserve". It uses [IPFS](https://ipfs.io/) 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](https://musicoin.org/) 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](http://myceliaformusic.org/) 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](https://coinmarketcap.com/currencies/musicoin/) 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 Tribler/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)](https://www.forbes.com/sites/rogeraitken/2017/08/17/how-the-blockchain-is-disrupting-the-art-economy-as-we-know-it/#53c12c9f74fe) * 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](https://sloanreview.mit.edu/article/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]

The central research question within this thesis is can we automate the music industry as a robot economy? We envision an autonomous ecosystem with an integrated financial system, audio streaming platform, all middleman removed, and implemented with a zero-server architecture. Autonomy in the sense that it is owned by both nobody and everybody (self-governance). We successfully designed a novel zero-marginal cost industry, various prototypes, a fully operational ecosystem, and deployment to real Internet users. We introduce a novel Artist Income Division Algorithm (AIDA) which regulates all monetary flows within our fully robotic music industry. Our AIDA component determines income fairness and winner-takes-all dynamics. All money goes to artists within our robot economy, already gives 80% more income to artists.

AIDA is implemented based on validated artists playlists and monthly automated payouts with Bitcoin wallets.

ToDo:

• write 2-page next version Problem Description: https://scholar.google.com/scholar?q=%22robot+economy%22
• other half of your time, code writing: keyword search (1-click play from frontpage ?)

Please do a weekly push of your code to Superapp!

[Tim-W]

I had a more in-depth code review of RemoteQueryCommunity and wrote around quarter of the functions so far. I feel that it will be difficult to have a full and bug-free implementation of this in Kotlin by next week. It is not a trivial engineering process and will require some integration testing and application testing. I'm a bit doubting if this is the best way to spend my time :thinking:

As an alternative idea I could try to run a headless, bare-minimum instance of Tribler on Android (this might be a bit crazy), and then do API calls to itself locally such as /search and /metadata. I can expect this will be costly in terms of APK size and threading on Android. The upside is that I can rely on the existing Python code and run into less bugs. Does this idea make any sense for browsing/searching channels? @ichorid

Another more simple idea is to interact with Trustchain more directly, by scraping, and store all content under a certain identifier (which is what I'm doing right now). Then content can be searched/filtered locally. This requires some more CC content, as we discussed before @synctext

one of our scientific developers to build a Creative Commons content library + seedbox

So tldr; I'm investigating and building code for the RemoteQueryCommunity but am also looking for other solutions

[ichorid]

@Tim-W , you don't really have to implement the complete functionality of the RemoteQuery Community. It is enough to only do two fixed types of queries: one for keyword search, another for subscribed channels list. Of course, this is only gonna be easy if there is already an implementation of ipv8 for Android. We can discuss the problems in-depth in Slack or in the office this Tuesday in person.

[Tim-W]

That's right, I'll try to filter out unnecessary functions.

Interesting: this article draws a relationship between blockchain and robot economy, in one (short) section:

Arduengo, Miguel, and Luis Sentis. "Robot Economy: Ready or Not, Here It Comes." arXiv preprint arXiv:1812.01755 (2018).

[Tim-W]

I filled a large part of the functionality of RemoteQueryCommunity, see the latest commits at https://github.com/Tim-W/kotlin-ipv8 . For now I decided to build a simple scraping mechanism on the side, which crawls content on the TrustChain from peers. Then the user can view content directly after connecting to some (perhaps bootstrap?) peers. And local search/filtering is easy to implement this way. The reason I'm building this (which should be only few days to build and test) is so we have something running that displays songs directly when opening the app; namely the one-click play from homepage which we discussed before.

For this work check my latest commit: https://github.com/Tim-W/trustchain-superapp/commit/36e9249c39ea808ddf33bd51c3c122f49f458c80

[Tim-W]

Progress: now able to do keyword search (simple search: it checks if the keyword is contained in either the title, artist or date). Also, the content is crawled from TrustChain, periodically in the background for now (for testing and simple prototype). So the app should display some content more quickly now on first launch, if it finds peers that have blocks with tag publish_release stored.

Commit: https://github.com/Tim-W/trustchain-superapp/commit/e4ca500b27a4f8043cd42609b0ad72f50063f96d

app-debug-13-07-2020-trustchain-superapp.zip

[Tim-W]

In MusicCommunity, which is a community that inherits from TrustChainCommunity, I built a mechanic with "initial addresses". This is kind of like a list of bootstrap nodes (which can be expanded in the future), which are used to load some initial content from, on first launch. This should give new users a list of Playlists directly when they first run the app, as they connect with the initial address and crawl their MusicCommunityTrustChain.

app-15-07-2020.zip Latest report, see problem description

[synctext]

Focus only on economic motive and mention "market failure". Can you find financial breakdown of total music industry revenue, income portions, Apple/Google cut, and other stats for problem description? Money from Music: Survey Evidence on Musicians’ Revenue and Lessons About Copyright Incentives Music income statistics Old stats http://loas.creativepassport.net/breakdowns/uk-physical/

EDIT: Rising tides? Data capture, platform accumulation, and new monopolies in the digital music economy

Billy Bragg and other indie musicians blast YouTube rates https://www.rootsmusic.ca/2019/03/14/a-brief-history-of-why-artists-are-no-longer-making-a-living-making-music/ MP3s are killing home taping: The rise of Internet distribution and its challenge to the major label music monopoly Music Production in Times of Monopoly: The Example of Sweden "Which technology can correct the market failure and restore a reliable income stream to artists?" Related work: music passport screenshot by Imogen Heap?

Progress check: started part-time 17Feb, full-time 20April. Now in Corona time its 15 July. Status: Convergence on general thesis storyline, Problem Description had few iterations, getting final. Schedule: currently in week 13 of 45 ECTS thesis job. Safely on Track.

Determine final thesis focus in coming sprints; Artist Income Division Algorithm (AIDA) ? the music listening histories dataset For final thesis chapter: experiment on artist payout dataset, "good torrenting" and solid "Trustworthy Trustchain", subscription scalability figure, etc.

First draft of final thesis ToDo:

• [ ] Autonomous DAO-level music streaming
• [ ] Bitcoin wallet
• [ ] Artist Income Division Algorithm (AIDA) ?
• [ ] Graphs & Experiments
• [ ] Done.

[Tim-W]

Draft version 3 of problem description: https://github.com/Tim-W/msc-thesis/blob/master/report.pdf

• Introduction of problem needs a rewrite, will do it when it is near completion.
• Removed some sections about privacy/GDPR/user data, resiliency and security.
• Improved focus on economic and power aspects of "case study" Spotify.

Based the red line of the problem around 4 pillars: gatekeeping, intermediaries taking large cut, monopsomy, recommendations and curatorial power. Found some articles about Spotify-curated playlists, which was an eye-opener for me. 99 out of top 100 popular playlists on Spotify are Spotify-curated and have large influence. Draws attention away from labels and towards Spotify-signed records in the future (just like Netflix is doing). Also part about human influence on top of 'black box recommendation machine learning' is interesting for my prototype: No artist knows why it is visible or invisible on some playlist, no one knows how to get promoted on playlists, no one knows how recommendations work (can be combined with distributed collaborative filtering story, as future work)

[devos50]

Just did a quick read-through of the problem description. A few comments:

• Your research question ("How can we design and implement a music streaming service that distributes the power from one authority to its users?") can be more precise. From what I understand, you are not building a platform around the redistribution power process, but a platform where this empowerment is already built-in. Your research question should reflect this. Furthermore, I think your topic resolve around the concept of disintermediation, the process of taking out the middlemen or reducing the extent to which it can exercise its power on the platform (judging from the thesis title). I also suggest evaluating your prototype for more credibility. Proposed research question: "How can we design, implement and evaluate a disintermediated music streaming service?", or maybe: "what are the key challenges when building a disintermediated music streaming service"?
• For a better storyline flow, I suggest moving your research question to the end of the problem description, after you introduced the four pillars. These four problems then come together in your research question. I like how these pillars are divided.
• Make sure to give proper citations for the claims you make in the introduction sentences in Section 2.
• It seems you are using subsubsections instead of subsections.

[Tim-W]

Thanks for the feedback @devos50 !

Make sure to give proper citations for the claims you make in the introduction sentences in Section 2.

This is an introduction that uses statements, which I afterwards backup using the sources in the paragraphs below it. Does that make sense? Good ideas for the research question, which indeed needs some thought and revision.

For the future experiments, demos and tests I would like to have a set-up with multiple (20+?) Android Virtual Devices and/or multiple physical Android devices. Do you, by any chance have an idea who could help me set up an environment with virtual Android devices in the cloud @synctext ?
Update 05/08 Today installed android studio and launch an Android Virtual Device on my DigitalOcean droplet, just to see if it works.. But I found out running an AVD on a remote server will require at least 4gb of RAM, and preferably more if we want multiple AVDs. That will be a quite costly experiment, so I guess experiments on cloud servers will be without Android. But rather, by scripting all interactions with TrustChain and jlibtorrent.

Superapp update I created various UI and UX improvements for the superapp MusicDAO. Such as: a button in action bar that shows up/down and other connectivity stats, showing loading info, improvements to layout. More detail can be seen in description of this PR: https://github.com/Tribler/trustchain-superapp/pull/46

[Tim-W]

@synctext Some questions about the next steps of this thesis: I was working on cryptocurrency integration for payment to artists. BTC wallet is already integrated in the superapp, as a light wallet. However I'm thinking about integrating something with a DAG (like NANO) for scalability and fast tx confirmation time for a demo. Does that make sense?

The issue I see with integrating this with our MusicDAO, is that these cryptos are still dependent on external servers (namely high throughput nodes), which makes it not truly autonomous, "phone-to-phone serverless". I don't think there exists a solution for this currently, so it should just be mentioned in future work?

How should the musicDAO decide which crypto node to use? I could run my own node and connect the superapp to it, but this moves towards a more centralized architecture. On the other hand I could connect the superapp to an external node, but then we rely on node uptime from an external party. The phone could try to run a full node by itself, but the memory, space and network requirements are too high for any Android phone.

So TLDR: 1. is it a good idea to work on crypto payments now? If so, how do we preserve the decentralized, autonomous nature of the MusicDAO?

[synctext]

please focus on Bitcoin, Trustchain and music (industry) DAO (in dApp form).

Bitcoin has existing fast confirm ability using server optionally. Would advise to first perfect the music (search) part of your app before switching to replacing operational Bitcoin libs. Other DAGs such as Nano introduce critical required servers, so 'fake tech' :-)

[Tim-W]

Integrated bitcoinJ library:

• In-app wallet screen to view your status, public key, funds
• Synchronizing the chain
• From now on, whenever a person submits a new album/EP/single, his/her wallet public key is added to the trustchain block, so that other users can send money. Therefore only newly made releases after this 'protocol upgrade' will have a tip/donate button
• Sending $1 tips to the artist directly from a playlist
• Direct conversion of USD/BTC as a helper for the user (obviously using an external API so this might be removed for "fully distributed" cleanness)

No real device-to-device bitcoin transactions tested yet, as BTC transaction fees are high, up for discussion tomorrow :P

Pull request: https://github.com/Tribler/trustchain-superapp/pull/47 APK can be downloaded at: https://github.com/Tribler/trustchain-superapp/actions/runs/222351824

[synctext]

Comments on thesis draft:

• impressive "work summer" progress
• "How can we design and implement a music streaming service that distributes the power from one authority to its users?", congrats! that is a good research focus.
• Ignore high transaction fees, out of scope of this master thesis effort. That is the difficulty of another master thesis :smile:
• can you use the "robot economy" term? Is it or can it in the future be fully autonomous and fully automated?
• integrated in real APK app (11).zip
  • trustchain
  • bitcoinJ
  • libtorrent
  • ExoPlayer
• consumer focus GUI: search and music discovery is central to experience plus added direct donations
• ToDo: what are nice graphs for thesis?
• key result field trial or?: artist income algorithm. supports robo argument
• possible final thesis objective, then get diploma
  • address problem of performance analysis, measuring results, and a proper evaluation
  • deploy in Google Play store and Tweakers post
  • each user gets 10 "Euro" in worthless testnet Bitcoins
  • experienced users are able to donate these testnetcoins to playlists inside Superapp
  • Trustchain crawler obtains these results
  • show fascinating stats and find embarrassing bugs
• future Kotlin sprint: @ichorid support remote keyword search IPv8 community (leech only mode)

[Tim-W]

Progress toward Remote Keyword Search I implemented a simple, fully distributed algorithm which uses neighbour nodes to find content. Basically, it works as follows: Scenario: a user wants to find content with keyword "Creative Commons"

1. User checks its own local database (downloaded trustchain blocks) to filter out content by this keyword
2. If there are less than X results, ask neighbours (max N) to obtain it, by sending a "KeywordSearchMessage":

   query: "Creative Commons"
   ttl: 3
   origin: <my public key>

3. When a peer receives a KeywordSearchMessage: check local database for results. If there are results: send results as trustchain blocks directly to original peer and terminate.
4. If ttl > 0: Reduce ttl by 1, and forward message to own neighbours (max N). Otherwise terminate.

This is a simple (but effective?) algorithm for doing remote keyword search. I think it is a somewhat similar algorithm as used in remote_query_community.py, but simplified (no SQL). I implemented the code in Kotlin here: https://github.com/Tim-W/trustchain-superapp/commit/18ea0d1ae6833d00ffe23fa091d94a8165dd41b6

It requires testing & device-to-device experimentation. Is this a step in the right direction for search?

[synctext]

Good stuff! Please simplify and always ask 20 peers around you. Science: https://www.semanticscholar.org/paper/Improving-P2P-keyword-search-by-combining-.torrent-Zeilemaker/a020b8007cf2687997090655729e07b44a19066a/figure/11

[synctext]

ttl: 3 Actually, there is no need for Gnutella explosion of query traffic. Keep a local database and caching. 1 hop only!

[Tim-W]

Progress update - apk download below Searching.gif - also I changed the searching parameters to use the "20 peers, 1 hop" strategy.

Donation.gif - Please note that the donation is not yet a confirmed transaction after sending. On my remote server I have a simple miner script that mines 1 block every 10 seconds (so confirmation time is currently 1000 sec), to test transactions on my own testnet. I'll try to also make this lightweight server a seedbox to help with some content seeding.

trustchain-superapp-07-09-2020-apk.zip

[synctext]

Great progress!

• First ToDo: write chapter "design and implementation".
  • select 4 key screenshots
  • explain them
  • link into coherent story
  • finally, think of a clean design (architecture; old industry, your app) that you intuitively implemented already :rofl:
• Field trail realistic
  • goal: show irrefutable results of you unique autonomous system
  • Experiment: We show that money flows without any middleman
  • A total of X Tweakers users found free money and used our Tip-Jar feature
  • Your Bitcoin fork is your dataset for transactions; critical thesis data!
• Question of user-generated content
  • [X] Trustchain record with magnets link and Bitcoin wallet (e.g. Artist passport)
  • [ ] offer free money to users in forked Bitcoin network
  • [X] support keyword search
  • [ ] support popularity community
  • [ ] support channels
  • Frontpage without donate (sorted last, filter music, import ability provided)
  • Frontpage with donate (discovered Trustchain content)

[Tim-W]

Currently I am mostly working on implementation.tex (see recent updates to https://github.com/Tim-W/msc-thesis, report: https://github.com/Tim-W/msc-thesis/blob/master/report.pdf) Also I am aware that I am mixing some design in implementation, I will make a better division of the two once I have more content :)

[synctext]

Reading latest version (direct raw thesis .PDF)

Discussed "DAO", what is proposed in this thesis on the Organisation side? Brainstorm: all users contribute income for artists and get to vote, artists create content and get to vote also. Each Bitcoin either donated by a fan or received by an artist obtains proportional voting rights inside the DAO (or capped for abuse/central control purposes; voting threshold). ToDo left for thesis wrap-up (?December?):

1. thesis report (solid progress, more high-level scientific writing; less engineering)
   • design: design choices!; architecture picture, superapp screenshot (or put this in Problem Description, state-of-the-art chapter) and design of (donation) screen
   • implementation: much more high level; libraries, code coverage table, and end-to-end quality assurance model (.PNG of crash report)
   • We identified the following open problems; we uncovered these as the key issue for achieving a magical uptake of one million users?
   • what do you seed and how much?
   • the perceived lack of control on spam uploading, authentication of content injection, impersonation of famous artists
2. popularity community
3. GigaChannels
4. (optional) artist income algorithm

This sprint: Another writing cycle

[Tim-W]

report.pdf Changes to the report

• Started work on an architecture diagram for the design section. WIP:

  

• Rename related work->state of the art

• Add Tribler, TrustChain-Superapp to state of the art

• Add design choices (short explanation) to design for the use of TrustChain, TrustChain-Superapp, Release blocks model, Bitcoin.

• Make Implementation more readable by starting with showing the interface

• Add a shortlist of features to implementation

• Table of libraries usage of implementation

• Simplified many parts of implementation and make it more high-level

• Add QA section in implementation

Changes to the code

• Implemented more unit tests
• Upgraded dependencies
• Updated the PR with all recent changes, trying to fix issues with CI

https://www.volkskrant.nl/mensen/bij-spotify-kon-dieuwertje-heuvelings-artiesten-maken-of-breken-ze-schreef-er-een-roman-over~b274536aa/#&gid=1&pid=1

[synctext]

Reviewed current thesis draft, making solid progress. All content is there, just present it at a higher abstraction level:

• Content discovery, versus "artist identification"
• Tamper-proof storage, versus "trustchain interaction"
• Zero-Infrastructure communication, versus "phone-to-phone serverless communication"
• Artist and user are the two key architectural elements; your work connects them
• Chapter 4: from a model of freedom, versus data model
• Section 4.1 Zero-Server architecture, versus "4.1 Phone-to-phone connectivity"
• Section 4.2 End-to-end ecosystem; from artists to fan ears; zero-intermediaries
• Section 4.3 Grounding of an alternative industry; not perfect but future proof and permissionless infrastructure which can be improved upon by anyone
• Section 4.4 free of arbitrary rules and sovereignty
• "6. Release Experiment", coin minting, voting, direct payment flows, income distribution, etc.
  • beyond search latency, scalability, catalog size
  • prove with a large phone-to-phone that you made a viable infrastructure with permissionless innovation
  • how to prove you created an autonomous new industry?
  • how to prove the viability of your architecture?
  • how to show the extendability and long-enduring nature of your work
  • :fire: generality Prior work created a social network, we now created a Spotify alternative; Superapp could replace Big Tech :heavy_check_mark:
• Planning, Beta
  • October thesis finished, minus experiment section
  • November: popularity community, search, polish
  • December: final chapter

Scientific article of music industry architecture

[Tim-W]

This week, mainly focused on making visualizations/models of current vs. desired situation in distributed vs. centralized music streaming services. Also added pseudocode for the remote keyword search function. See problem description & design. I tried to make the design chapter a bit more abstract/high-level (mainly the first sentences and titles of sections).

Now that I filled the report with more models, I need to introduce more explanations in text, that is the next focus.

See report.pdf

3 Short questions:

• @synctext I use "We" everywhere, but did not add you yet as an author/contributor. How should I mark your name in the thesis?
• Is pseudocode for algorithms more logical in implementation? In the pseudocde I left implementation details so that's why I left it in design for now.
• Same Q. as above, for data models (see figs. 4.4 and 4.3: Release blocks and KeywordSearchMessage)

[synctext]

• There is a standard TUDelft template for thesis work, thesis committee members are listed there.
• pseudocode looks look there
• datamodels; Chapter implementation has too much details. If the reader wants to know: read the code.
• Could be more scientific. Look at this stuff! Thesis still can use more abstraction. (now more blogger terms in Figure 2.1) These figures could be more detailed. More abstract and business level: show a money table or 2%-ish revenue cuts that go to the creator.

related work. Obviously this is false, as your MusicDAO work pre-dates LikeCoin: "As the world's first data registry specifically recording the internet's digital creative content, it stores ISCN metadata for every item published or shared within Liker Land or associated with the LikeCoin button.",

[synctext]

More flavor for the "problem Description" at a high abstraction: business-level:

Wixen raised the case in December 2017, claiming that the music-tech giant was hosting tens of thousands of songs
managed by Wixen on its streaming service without holding the proper copyright to them. It also said Spotify offered
“outrageous annual salaries to its executives” while skimping on artist payments.

Spotify Settles Its $1.6 Billion Publishing Lawsuit

The court papers accuse the streaming service of lacking the infrastructure needed to make sure songs are
licensed and musicians are paid.

Spotify sued over 'billions of Eminem streams' by BBC Bad IT in music biz, by Daan: https://www.copyrightdelta.com/media/CopyrightDelta-Presentation-CordaCon2020.mp4

[Tim-W]

Thank you! will look into it. There are a lot of different problems in the music industry right now, so I could go on forever in the problem description section.. So I will need to filter out until we have the most important!

https://github.com/Tim-W/msc-thesis/blob/master/report.pdf Work from last days:

• Added intro
• Added to problem description: revenue cut table, subsection 2.5.2, re-created figure 2.1 to make it more clear. Started on "Slow and inaccurate royalty payments" section
• Rewritten most of state of the art and extended it to 4 pages
• Design: Tried to reduce complexities. Added "End-to-end music delivery model" (with figure 4.2). Added % to figures 4.5/4.6. Added "Open protocol and artist freedom". Added BitTorrent design choice. Added Identification of Participants and trust system with sybil-resilience.
• Implementation: Removed implementation/engineering details. Tried to make everything more readable/abstract (Identity/authenticity, priority handling). More explanations for the interfaces.

[synctext]

Lastest .PDF download link: https://github.com/Tim-W/msc-thesis/raw/master/report.pdf

Fresh idea that I also had: Big Tech platforms (Youtube, Netflix Apply music, Spotify) are already the first wave of the robot economy ref. Feel free to include this within your thesis storyline.

• Higher level introduction: We are seeing broader centralisation and concentration of power within economies (Nobel Prize winning author).
• Plus general theme that software is eating the world; Music Biz is run by big platforms. What Happens to Society When Robots Replace Workers?
• Chapter 2: more on unfairness and monopoly details. Perhaps even some history. Open with table about the "combined market share of 81%". Possibly put Table 2.1 on the first pages. Then slowly build up the story of the villain.
• "This facilitates rent-based monetization of user data", too detailed for first page of Problem Description.
• Table 2.1. Dramatic bottom row in bold: this thesis challenge 0% label, 0% platform, 100% artist: plus this "Streams per month to earn min. wage". (180000 - 180000 x 40% cut == 108000.0; Lower the bar to live of music)
• privacy argument better fully omitted to keep it readable and reduce complexity
• "2.5.1. Black box" integrate these small sections of only 6 sentences into Section 2.5.
• Chapter 3: start with scientific literature, not with some money losing projects.
  • Predatory pricing: the literature starting point from 1977
  • the Big Five of Amazon, Apple, Facebook, Google, and Microsoft

    One of the principal themes of this uprising is that present-day antitrust policy, forged in the rusty era of
    steel, oil, and cars, is now obsolete. We are in the age of information, which ipso facto calls for new rules.
    A second animating theme is that the antitrust thinking of the Chicago School, which came to prominence
    in the last quarter of the last century, must be completely overthrown.

  • Monometapoly or the Economics of the Music Industry

    This article calls this traditional wisdom into question and demonstrates that the majors are not only monopolies
    but also monoposonies: they are monometapolies. It is shown that the negative effects of a monometapoly are
    worse than those of a simple monopoly and that the loss of welfare indirectly caused by IPRs is likely to be much
    higher than is usually expected.

• Keep Chapter 3 simple: economic literature on centralisation of power; Section 3.2 Alternative music industry initiatives (organisational!); Subsection "3.3 Decentralised technology alternatives" (Good Kind of Tech) with IPFS, DAO, Superapp matters.
• Always leave out engineering details to keep it sciency. "IPFS uses an efficient graph implementation (a Merkle DAG) for addressing content and nodes", remove the Bittorrent, IPFS tutorials. More abstract then their tech. Started with a large team, lots of money, published a world-domination roadmap, now missed milestones and delayed testnets.
• Chapter 4: make the goal more explicit with an inline bounding box around the text
• "4.1. Serverless architecture" please use term 'zero-server architecture'.
• Section 4.x: the idea of a network of mobile phones which cant be stopped by governments, companies or lawyers. Use 2 pages for that and quote MattSkala2020.
• Open Chapter 4 with the idea of "zero-cost autonomous music industry which is middleman-free" and talk about that for 2 pages. Our utopia would be a Linux, Wikipedia,. Firefox like global movement. This sustainable movement for a few decades will chip away market share from the traditional players and grow in strength. Similar to the Linux domination within the OS industry; it took 25 years. Open innovation, open source, and permissionless ecosystem.
• Chapter 5: ", the app is set in a dark-styled color scheme.", remove such details. We created a fully operational alternative for the music industry. In the next chapter we will show how we deployed our implementation to real users and the learning for the future of the music industry. We successfully created a music industry alternative within our zero-server architecture. Our zero-cost platform discussed within this chapter ensure maximum revenue for artists. (discuss generalities for 2 pages)
• Chapter 5: technology re-usage: we re-used industry standard software component. For our content distribution solution we selected Bittorrent, as IPFS is not yet mature. We opted to include a wallet inside our end-2-end solution. Our payment solution is Bitcoin, because Paypal, Ethereum or traditional banking systems are not as easy to integrate in a permissionless manner. etc etc Music Player solution...
• Chapter 5: how does a zero-server app works? Every reader needs to understand...
• Experiment chapter: you can already do a first draft page of storyline! (example, daily users of Tribler picture)
• Evaluation chapter 7: merge with implementation, saves time.
• (repeating) "6. Release Experiment", coin minting, voting, direct payment flows, income distribution, etc.
  • beyond search latency, scalability, catalog size
  • prove with a large phone-to-phone that you made a viable infrastructure with permissionless innovation
  • how to prove you created an autonomous new industry?
  • how to prove the viability of your architecture?
  • how to show the extendability and long-enduring nature of your work
  • :fire: generality Prior work created a social network, we now created a Spotify alternative; Superapp could replace Big Tech :heavy_check_mark:

[synctext]

The first robot economy

Apologies for giving conflicting advice yet again. April 6 comment about the "first robot economy" also has great potential as superior scientific storyline. Because you did not implement any AI, I incorrectly assumed it wasn't a valid storyline.

Please consider adding more of AI storyline in for the final thesis writing sprint. No need to have any AI within the implementation: you worked on the cardinal first step towards an AI DAO; deployed in the wild with zero-server architecture for a zero-cost music industry. Compared to music labels and platform overhead (e.g. 90% of cost) you can sustain 800% to 1000% increase in artists living of their work.

Brainstorm, Chapter 3: Problem Description (leave the chapter as is, insert this up front and see how it goes) The central problem addressed within this thesis is exploring new architectures for the first "AI DAO" applied to a specific industry. A DAO is an autonomous organization with a decentralized governance, budgeting system and without traditional employees or managers. An "AI DAO" is the envisioned idea of a leaderless organisation with a decision making process controlled by AI. Our goal is to create the first AI DAO framework and deploy this in the wild to further evolve. We will focus on a viable framework itself within this thesis and leave the increase in intelligence and learning to future work. Theoretically it is possible to use an AI DAO to fully automated an entire industry.

For many decades AI scientists have failed to materialise in the wild the more basic concept of an "intelligent Agent". This is an "Autonomous entity that acts, directing its activity towards achieving goals, upon an environment using observation through sensors and consequent actuators. Intelligent agents may also learn or use knowledge to achieve their goals."

Much is still unknown within the young AI DAO field. We do not yet understand on how to achieve them or give them intelligence. Especially governance issues are still insurmountable, who owns them and who ultimately controls them? What even makes something autonomous in the first place?

This thesis acts as a first concrete step to increasing our understanding of AI DAO. By trying to engineer an AI DAO we will irrefutably identify the gap between theoretical speculations and running code. This empirical approach leads us to the selection problem of which business to automate with our AI DAO framework.

We now present an analysis of the music industry because we believe for four reasons this is the most fertile starting point for our AI DAO framework called "TimDAO". First, the music industry has an overhead percentage of 90%. Only 10% of the revenue stream goes to the producers of the core product: music artists. This means TimDAO could be fiercely competitive. Second, this industry is inherently digital. Digital music recording and digital music playback ensure that the entire industry, in theory, could be replaced by TimDAO. Third, due to anti-competitive practices such as price fixing this industry has lost the moral high ground. Fourth, the music industry value chain is mature and numerous components have already been digitised using open source libraries. We can re-use many building block to implement the TimDAO framework and realistically release it in the wild. {expand the above into 2 pages with existing fantasy blog posts and thoughtful ideas on AI DAO as inspiration}

[Tim-W]

Thanks for the good resources.

Experiment ideas I started writing some drafts for graphs and experiments. Please check it here in chapter 6. My main idea is:

1. give the app to 20+ devices, everyone installs and receives $10 fake dollars.
2. run the experiment for 7+ days
3. Every day, I increase the music catalog: start with ~50 songs, then add 50 every day.
4. We measure the latency of buffering music, searching music, sending money.
5. We measure the amount of money artist get.

Using these numbers, we can measure how large the catalog size can be in comparison to the network size. So, we can calculate the expected catalog size we have when we extend the network size to 1 million. Also, using the same calculations we can find out the expected income for artists per month, (and possibly even show that they get better paid then now!)

BTW, I feel like it would be the best to start with fixing code and preparing experiments sooner rather than earlier. So I can write my thesis report while the experiments are running.

Updated State of the Art (edit: 10 nov) Started on 2 new sections from the beginning: "DAO theory and technologies" and "AI DAO"

Updated problem description (edit: 3 nov) I added a little history and tried to build the 'story of the villain' (Big Tech) more slowly and more logically. Removed some details.

Updated design (edit: 10 nov) Added an explanation for a phone-to-phone censor-resilient network, and what kind of censorship-attacks there are, and how we defend against them (see section "Phone-to-phone censorship-free network"). Added short section "phone-to-phone connectivity:. Added short section "Zero-cost autonomous music industry".

Updated Implementation (edit: 11 nov) Added a new introduction to implementation, and moved the current introduction to a separate section "Android app". I tried to explain zero-server app infrastructure in general terms

---

*Brainstorm, Chapter 3: Problem Description (leave the chapter as is, insert this up front and see how it goes)* Keep Chapter 3 simple: economic literature on centralisation of power; Section 3.2 Alternative music industry initiatives (organisational!); Subsection "3.3 Decentralised technology alternatives" (Good Kind of Tech) with IPFS, DAO, Superapp matters.

Currently, Chapter 3 has title "State of the Art", but with the above comments it seems that it should include a Problem Description as well? economic literature on centralisation of power seems more logical to be in Problem Description (Chapter 2) to me. Then with Chapter 3 listing all current decentralized organizational structures (non-tech), then DAO applications/protocols outside of music industry (tech) and then DAO applications/protocols inside the music industry (tech). Does that make more sense?

Other stuff that is on my mind and I am unsure of: the title (edit: 4 nov) The robot economy also implies interaction with robots, but we rather show a peer-to-peer network than an artist/listener-to-robot network (except for robot miners)

Therefore for the title I would suggest "The first steps to a Robot Economy: ..." or "The first steps to a fair and automated music streaming industry" or "The first steps towards fair and transparent digital value chains: an implementation of the first robot economy"

I don't know if the current thesis date is still viable, if I want to fix these issues and incorporate a design for a DAO AI. But I'll try to add it

[Tim-W]

@synctext Could you check my email? For me the thesis date and formalities are very unclear now Recent news: here is the 30% Google cut again: https://blockchain.news/news/ethereums-vitalik-buterin-creating-app-store-after-google-demands-30-cut

[synctext]

Latest .PDF download of thesis, remarks:

• Putting AI DAO as central storyline is going well
• Thesis is maturing and progressing nicely (3 weeks left writing?)
• "Towards the Robot Economy: an AI DAO music industry replacement" title :upside_down_face:
• 4.2.1. Rename 'Autonomy and resilience' was "Censorship-resiliency"
• 5.1. Zero-server infrastructure for AI DAO (moved forward)
• 5.2. AI DAO music industry (rewording of app features)
• 5.x Decentralised content discovery (was "Playlist overview interface")
• 5.y Decentralised financial infrastructure (was :"Wallet interface")
• keep your experiment as simple as possible!
  • crawler of usage in time as key measurement
  • your own miner node, collect all data + Android Play Store app deployment
  • make this the only data to discuss: "6.5. Money transfer measurements"
  • avoid spyware needed for buffering time measurements
  • no changes during experiment of letting the catalog grow
  • avoid making a money server
  • simply create 1000 wallets, integrate in the app, randomly give 1 wallet to 1 user, and share between users if 1000+ join your trail
• 7 December launch of MusicDAO Experiment during our Delft workshop? Nu.nl level exposure..

Implementation section; repeat your related work, compare, and close the circle:

Features	Operational	Scalability	No cut for Platform	Fancy DAO, something, something
Spotify	:heavy_check_mark:	:heavy_check_mark:	:red_circle:	:red_circle:
OpenMusic	:heavy_check_mark:	:red_circle:	:red_circle:	:red_circle:
Other work1	:heavy_check_mark:	:red_circle:	:red_circle:	:red_circle:
Other work2	:heavy_check_mark:	:red_circle:	:red_circle:	:red_circle:
This Thesis	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:

[Tim-W]

1. Created bitcoin faucet: every user that obtains a fresh wallet key, sends this key to my faucet server, and receives 10 fake dollars.
2. Created an IPv8 message type for sending swarm health messages. Basically implemented most stuff of popularity_community.py (from Tribler) in Kotlin.
3. Devices now keep track of swarm health of 5 popular torrents and 5 random torrents internally.
4. Devices once every X seconds send a swarm health message to a random peer -> mostly done, need testing with few devices
5. Album overview is sorted based on swarm health.
6. Fix some bugs: Music keeps playing while browsing, syncing wallet blockchains, downloading/buffering progress bars

GIF of end-to-end popularitycommunity/swarm health messages

10 fake BTC on startup

TODO for Android currently:

1. Crawling of music metadata on TrustChain over local network is very slow? I need to investigate and fix what the issue is.
2. Fix various bugs with the recent functions.
3. Test functions on ~5 devices (only done 2 devices so far)

Plans: work on the app until first week of December, see how far it is progressed for the conference. (news post?) Then perform release experiment, give the app in hands of users and measure what happens on the network. APK on Nov 26: app-debug.zip

[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: https://github.com/Tribler/trustchain-superapp/pull/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://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 https://github.com/Tribler/trustchain-superapp/pull/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: https://github.com/Tribler/tribler/issues/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 :)

https://user-images.githubusercontent.com/4957928/107580497-edc26900-6bf6-11eb-8c82-2f83d6cdf704.mp4

Summary of updates to Thesis Report