Thesis: Artist Investment Token

[synctext]

Thesis: replace music industry with open source code, including the investment part.

Wealth has accumulated with a select few: the investing class. The rest of the world belongs to the worker class. Digital technology is breaking the monopoly on investing. We prove the viability of our ideas with an Internet-deployment focused on an industry that operates purely digitally and has deep rooted monopolistic culture: the music industry.

Prior work: https://github.com/Tribler/trustchain-superapp/issues/45

We automated the music experience. Previously we build the code to directly link artists with their fans (e.g. open source Spotify app). This thesis is focused on the discovery and growth of new talent. This thesis aims to bootstrap a sustainable music ecosystem without any music industry. Any citizen is able to invest in upcoming artists. Investors support artist and enable them to create new music. Investments ensure that rent gets paid, day jobs can be quit, and professional equipment can be procured. Investments pay back when the artist releases new material and income is generated. The zero-server technology stack of Delft University is used, see MusicDAO. The Android-to-Android networking stack is able to communicate music, money, and trust without relying on any central server.

In technical terms the investor simply send Bitcoins to the artist wallet. New Creative Commons music is released. Fans reward the artist and the investor can be paid back. Enforcement of honesty by the artist is out of scope of this thesis. We assume reputational mechanisms are sufficient and no crypto magic needs to be attempted. The usability of the MusicDAO needs further improvement. Discovery of new music is too slow. Connect to main Tribler network: IPv8 Tag Community. Performance results could be obtained during a 2 week observation period after release on forums such as Tweakers.nl and TorrentFreak.com. Thesis format will be an 8-page IEEE formatted scientific article, with additional Delft blue mandatory covers. See zero-server stack IEEE article example.

First print goal: compile musicDAO, inject music, no dumping of code please. Just build upon existing code, fix what needs fixing. Discover music on a 2nd phone. Make a new .APK

[brian2509]

main.pdf

[synctext]

On Monday 6 Feb everything needs to be ready for the new Blockchain Engineering class. Sandip is away soon for 4 weeks, so things need to start now. Could you please create a draft PR to push your changes to the main Superapp branch? FROST is the next thing that needs to goto main branch (JNI route).

[brian2509]

main.pdf

[synctext]

• Solid progress towards master thesis graduation
• Related work is a bit void of related work (leaderless organisation, first smart contract Nick Szabo 1994, first Etereum realisation, first DAO, first DAO that does an ERC20 token issue, etc)
• Fig. 2. Architectural components of the Music DAO, move as Figure 1 and to page 3. Rename to: generic DAO architecture. Transparent is not a functional component, but a system requirement you used as input.
• Sprint focus: PR of your DAO and polish thesis

[brian2509]

The new .apk which is based on the final PR which should now be finished.

[synctext]

• :rocket: the code now works and can serve as foundation for your master thesis :rocket:
• solid content discovery speed! (no UX refresh (initially upon first minute bootstrap) unfortunately)
• Ideas for final chapter: performance analysis
  • content discovery speed (follow customer journey)
  • discovery of DAOs to join
  • donation to artist number of messages and latency
  • Real-life deployment test + App store screenshot
  • Copyright-free image, free to (re-)use. Workshop of the first true decentralised DAO deployment.
  • Latency breakdown of joining a DAO
  • the grand experiment of this thesis
  • specially prepared with auto-approve phones/emulators running
  • instantly approve any incoming request
  • present all message traffic, crypto cost, the latency and bottlenecks.
  • graduation committee possible help
• btw thesis does not mention your dApp approach versus the mainstream approach of smart contracts. (smart contracts with finite run-time are not Turing complete and they only facilitate a single thread of execution globally. Without Turing-completeness and without parallelism it is therefore not acceptable for our usage.)

[brian2509]

This sprint after some final changes the PR is now finally merged in 🚀 . Some work on the draft has been done in performance sections & diagrams. main.pdf. Furthermore working on benchmarking using multiple phones, currently have some benchmarks working with a single phone.

[synctext]

• 5) Application Layer: Kotlin, JVM and Jetpack Compose this is all too much engineering. Whole list could be dropped. Do you have a more scientific "architecture" picture or implementation view?
• Fig. 6. Performance of our voting mechanism Solid step forward! {if it was non-mocked data}
• [cong2021decentralized], please use standard IEEE citation: [1].
• Run multiple emulators on our machine(s) with 128 cores and 256 GByte memory?
• Current simple methodology: select benchmark inside MusicDAO, view result, copy from screen (ToDo:get from app logs)
• Please get results and text improved that we can pick a graduation date

[added] https://mtg.github.io/mtg-jamendo-dataset/ The dataset contains over 55,000 full audio tracks with 195 tags categories (87 genre tags, 40 instrument tags, and 56 mood/theme tags).

[brian2509]

main.pdf Mainly worked on paper and experiments this sprint.

[synctext]

• How far are you from unbounded scalability to billions of humans?
• Thresh-hold signature inclusion: this transaction adds a new members to the DAO, Hotel California? 3) leave DAO
• we do not rely on advanced turing-complete smart contract capabilities. any smart contract language with a finite wallet size, finite gas, and finite run-time is NOT turing complete.
• We have created an implementation of a DAO centered around music using our proposed architecture. Lack the Tim Wissel thesis vision: automate the entire music industry
• Figure 5, make clearer those are 2 screens.
• ToDo: theshold voting inside a IPv8 community. Run till 100 nodes even
• ???CPU usage, segwit, and transaction size for Bitcoin?

[brian2509]

main.pdf

• Got a test-setup working for multiple of ipv8 nodes in the super-app after multiple attempts of integrating projects
• (Any code in super-app is hard (to impossible) to integrate and run in a JVM app and vice-versa. Consequence -> all benchmarks with multiple ipv8 nodes run on emulator/phone. Not necessarily a problem for me, but perhaps others.)
• Will work on re-designing a simplified protocol in such a way it works w/ events instead of polling peers -> otherwise benchmarks are dependent on polling which is too slow.

[synctext]

• Hopefully we can soon give you your diploma
• work on re-designing a simplified protocol in such a way it works w/ events instead of polling peers is this making the MusicDAO better? Or just for making graphs with superior performance?
• Please check in your private code for DAO profiling
• Also, check out flamegraph for master thesis usage as Figure (task?? Vote on DAO)
• plan: 1 JVM emulator, 1 process, numerous threads for individual IPv8 nodes
  • note: this is ambitious task at final stretch of thesis
  • Programming like its 1999: 1 integration test if the response and signature is valid. Nothing else :roll_eyes:
  • Think of master thesis experimental results which are 'cheaper' in terms of development time
• Discussed Kotlin Android versus x86 native compiled Kotlin.
  • essential for scalability experiment on 16GByte laptops or 512 GByte memory servers
  • Common modularization patterns
  • big code change solution: move all Android specific code of superapp inside 1 architecture module/directory. All future project would then make 2 modules: non-android native and Android code

[brian2509]

This sprint was mostly focused on working on the performance evaluation done in order of the multi-sig implementation stand-alone and the implementation in a peer-to-peer setting using ipv8. To do this several steps had (and still have) to be taken.

• A modified implementation of MuSig which is BIP0340 compatible and verified (tested) is added to the project. [1] [2] [3]
  • The current implementation/port was not compatible (incorrect key tweaking, incorrect key encodings, etc). This means that its signatures will not be accepted by (up-to-date) bitcoin-core nodes. There were very few implementations of the MuSig paper available which are BIP0340. Those which are available are either incomplete, not implemented in Java/Kotlin or not suitable to be used in p2p settings.
  • Found two implementations of BIP0340 compatible Schnorr verify functions in order to test the signatures. One was already in JVM and another was ported from Python, both included in project now.
  • For the performance evaluation I've worked on a separate community for MuSig signing of an arbitrary message between ipv8 nodes. This seems to be working, but implementing p2p protocols is more difficult than I expected (especially without reliable communication).
  • Using this some performance evaluations have been done in two settings: a local setting where only MuSig is evaluated and the p2p setting. The p2p evaluation is still limited due to factors I have not worked out yet (UDP size limit, re-tries), but still does show insight into performance.
  • Need to work on the p2p setting and make sure I can do tests on larger number of nodes.
  • There have been some edits made to the last thesis pdf: new diagrams, general cleanup, changes text from suggestions. main.pdf

[synctext]

• Thesis is getting readable ! :medal_military:
• Fig. 3. The voting mechanism of the Simple DAO \columnwidth violation
• Fig. 4. A visual representation of the Music DAO based on the simple DAO.
  • feels like a weird architecture when 'governance' is at the bottom and Bitcoin is on top. Sideways?
  • architectural picture which mixes three views: functionality, components, implementation
  • Not an architectural concern that certain blocks are already implemented and running smoothly for a decade (Bitcoin) or two (Bittorrent).
  • same comment for Fig. 1. A visual representation of the architecture of the simple DAO.
  • architectural components: publish music, trustworthy pinning of artists public keys, collecting votes, making collective decisions, cybercurrency transactions, trustworthy DAO membership discovery, etc.
• Fig. 8. Performance of our voting mechanism Great result! Just 1.2 second for 1 collective signature with 1000 participants (1ms/key ????). unbelievable :clown_face:
• Using the Rahim EVA TFTP re-try mechanism in IPv8? nope.
• Problem Description. with While such organizations are autonomous to an extent, they will still rely on human individuals to perform certain tasks. Translated: has human task execution, free of other human interference. More of a tutorial and related work, not really focused clearly defining your direction.
• Polish please The need for pure academic decentralisation arises from the fact that any deviation from this leads to the mechanism inheriting the problems associated with centralized traditional organizations.
• Fig. 9. Time to first discovery music
  • first screens refresh (first paint)
  • first IPv8 node discovered
  • first music discovered
  • 10 music pieces
  • 100 music pieces
  • etc
  • {make 2-column}

[brian2509]

Generic_DAO_primitives_for_Full_Academic_Decentralization_and_Scalability.pdf

[synctext]

• [ ] Main point: polished thesis text
• [ ] Title
  • "First Deployed DAO with true full decentralisation and leaderless governance"
  • "First Deployed DAO with full decentralisation and voting"
  • "First DAO with extreme decentralisation"
• [ ] Figure 1, architecture. more traditional protocol stack architecture: https://docs.wemix.com/v/en/design/architecture
• [ ] "III. RELATED WORK" bit short
• [ ] Table 1: "COMPARISON OF SIZE REQUIRED ON BLOCKCHAINS FOR DIFFERENT VOTING SCHEMES" please make pretty, add year, and add citation{s} per line.
• [ ] "A. Architectual Primitives" more 'extreme decentralisation requirements'?
• [ ] Governance is selected to be the contested concept of democracy (one person == one vote)
• [ ] Section6, more high level. We have created MusicDAO to re-shape the music industry. We meticulously designed MusicDAO to replace any existing intermediary with open source code. Various roles such as talent scouting remain, but no longer require any human labour. A music curator is no longer required if real-time viral music statistics exist. Current cloud-based architecture restrict such vital business information. {more business and science stuff}
• [ ] Move all engineering to implementation and deployment?
• [ ] Figure 4 also requires polish. "A visual representation of the Music DAO based on our architecture."
• [ ] bad marketing, "Fig. 8. Performance of implemented voting mechanism" Figure 8, cryptographic cost of democratic voting using signature aggregation
• [ ] this works now nicely, THRESHOLD is FUTURE work
• [ ] cut and pixelated flame graph
• [ ] "Performance of implemented voting mechanism in the Peer to Peer setting" :arrow_right: performance analysis of multiple signatures with real networking
• [ ] "node amounts 2.5"
• [ ] "Fig. 10. Time to first discovery music" more a pretty probability distribution function of 1st music discovery time ? PDF of IPv8 neighbor discovery, app startup PDF, etc.

[brian2509]

Did most of above todos and todos by my supervisor and rewrote parts of thesis, in particular related work, architecture, performance evaluation and voting protocol. Polished a lot of text and redid most diagrams/tables (higher quality, pdf, more data/information). Biggest task to do is finish implementation section.

main.pdf

Above list:

- _Main point: polished thesis text_ - [x]  Title - "First Deployed DAO with true full decentralisation and leaderless governance" - "First Deployed DAO with full decentralisation and voting" - "First DAO with extreme decentralisation" - [x]  Figure 1, architecture. more traditional protocol stack architecture: [https://docs.wemix.com/v/en/design/architecture](https://docs.wemix.com/v/en/design/architecture) - [ ] > Different Solution - [x]  "III. RELATED WORK" bit short - [x]  Table 1: "COMPARISON OF SIZE REQUIRED ON BLOCKCHAINS FOR DIFFERENT VOTING SCHEMES" please make pretty, add year, and add citation{s} per line. - [x]  "A. Architectual Primitives" more 'extreme decentralisation requirements'? - [ ] > Named architectual requirements - [x]  Governance is selected to be the contested concept of democracy (`one person == one vote`) - [x] Section6, more high level. We have created `MusicDAO` to re-shape the music industry. We meticulously designed MusicDAO to replace any existing intermediary with open source code. Various roles such as talent scouting remain, but no longer require any human labour. A music curator is no longer required if real-time viral music statistics exist. Current cloud-based architecture restrict such vital business information. {more business and science stuff} - [ ]  Move all engineering to `implementation and deployment`? - [ ] WIP section - [x]  Figure 4 also requires polish. "A visual representation of the Music DAO based on our architecture." - [ ] Replaced - [x]  bad marketing, "Fig. 8. Performance of implemented voting mechanism" Figure 8, cryptographic cost of democratic voting using signature aggregation - [ ] Renamed to peer to peer implementation - [ ]  this works now nicely, THRESHOLD is FUTURE work - [x]  cut and pixelated flame graph - [x]  "Performance of implemented voting mechanism in the Peer to Peer setting" ➡️ performance analysis of multiple signatures with real networking - [x]  "node amounts 2.5" - [ ]  "Fig. 10. Time to first discovery music" more a pretty probability distribution function of 1st music discovery time ? PDF of IPv8 neighbor discovery, app startup PDF, etc.

[synctext]

• Congrats with Green Light moment today :clap:
• [ ] Thesis Chapters ready for graduation
  • [X] missing name of your work MusicDAO
  • [X] Introduction
  • [X] Problem Description
  • "The myth of digital democracy" please add like: 'the open problems with governance is summerised by the booktitle "The myth of digital democracy"'
  • While there is no consensus on how to define a DAO,... why define as an afterthought? Use as opening lines?
  • 150 million USD from why new paragraph?
  • [X] "MusicDAO: most simple architecture"?
  • "flexible and strong building block" perhaps more future-proof, generic, and principled
  • "local-first storage", citation needed!
  • [ ] "V. MULTI-SIGNATURE dao VOTING PROTOCOL", insert DAO there. it's tailor-made I assume.
  • "We now introduce a novel protocol which combines multisignature and blockchain technology in order to make governance possible". bad opening. What are you solving here? like: In this section we address the DAO!! governance problem by using democratic voting processes.
  • 2nd line already: "We visualize our protocol in Figure 2. " no context. no intro. no why. no what. no who. no how.
  • Any relation to IV.E. Governance Processes
  • No style consistency at all! White-on-black boxes, black-on-yellow boxes, Dave versus DAO Member 3, three arrow types, etc.
  • B. Managing Shared Assets use equal terms in section 4 and 5. But now it's not simply voting: it is a whole DAO detailed design
  • Figure 2 very detailed and lots of engineering for this chapter. MusicDAO implementation content? Removed Figure 3, just related work right?
  • Fig. 5. A visual representation of the Music DAO based on our architecture. only now we see how everything fits together.
  • [ ] VI. MUSIC DAO: A TRULY DECENTRALISED DAO
  • [ ] One figure with (a) several (b) screen of your implementation 100% pagewidth (discovery, album-play, dao-discovery, DAO-vote) Never a 0 BTC artist in your ecosystem :cat:
  • [ ] VII. PERFORMANCE ANALYSIS
  • [ ] Fig. 8. Flame graph of the cryptographic operations in the voting mechanism for 10.000 keys. ugly low res
  • [ ] 1) Flamegraph of Local MuSig: sub-subsection "2)" is missing
  • [ ] Fig. 11. Time to first discovery music too simplistic (first screen refresh, first incoming UDP packet, first new music album)
  • [ ] B. Usability Experiment more scientific: end-to-end performance evaluation?

[brian2509]

Completed contents of above comment, can be found in details below. Had a number of meetings with supervisor and some help from PhDer to improve paper text and structure over this sprint. Finished all the text. Improved most figures and display of figures in the paper for style consistency / polish. Very last item on the list (end-to-end-performance of music loading) needs two more bar plots which I am working on.

MSC_THESIS_First_Deployed_DAO_with_True_Full_Decentralisation.pdf

- [ ]   Thesis Chapters ready for graduation - [x]  missing name of your work `MusicDAO` - [x]  Introduction - [x]  Problem Description - "[The myth of digital democracy](https://www.degruyter.com/document/doi/10.1515/9781400837496/html?lang=de)" please add like: 'the open problems with governance is summerised by the booktitle "The myth of digital democracy"' - `While there is no consensus on how to define a DAO,` ... why define as an afterthought? Use as opening lines? - `150 million USD from` why new paragraph? - [x]  "MusicDAO: most simple architecture"? - "flexible and strong building block" perhaps more future-proof, generic, and principled - "local-first storage", citation needed! - [x]  - [x] “V. MULTI-SIGNATURE DAO VOTING PROTOCOL”, insert DAO there. it’s tailor-made I assume. - [x] “We now introduce a novel protocol which combines multisignature and blockchain technology in order to make governance possible”. bad opening. What are you solving here? like: In this section we address the DAO governance problem by using democratic voting processes. - [x] 2nd line already: "We visualize our protocol in Figure 2. " no context. no intro. no why. no what. no who. no how. - [x] Any relation to `IV.E. Governance Processes` - [x] No style consistency at all! White-on-black boxes, black-on-yellow boxes, Dave versus `DAO Member 3`, three arrow types, etc. - [x] `B. Managing Shared Assets` use equal terms in section 4 and 5. But now it’s not simply voting: it is a whole DAO detailed design - [x] `Figure 2` very detailed and lots of engineering for this chapter. MusicDAO implementation content? Removed Figure 3, just related work right? - Made simpler. - [x] `Fig. 5. A visual representation of the Music DAO based on our architecture.` only now we see how everything fits together. - [x] `VI. MUSIC DAO: A TRULY DECENTRALISED DAO` - [x] One figure with (a) several (b) screen of your implementation 100% pagewidth (discovery, album-play, dao-discovery, DAO-vote) Never a 0 BTC artist in your ecosystem 🐱 - [x]  `VII. PERFORMANCE ANALYSIS` - [x] Fig. 8. Flame graph of the cryptographic operations in the voting mechanism for 10.000 keys. ugly low res - [x] Increased resolution / better text rendering - [x]  `1) Flamegraph of Local MuSig:` sub-subsection “2)” is missing - [ ]  `Fig. 11. Time to first discovery music` too simplistic (first screen refresh, first incoming UDP packet, first new music album) - [x]  `B. Usability Experiment` more scientific: end-to-end performance evaluation?

[synctext]

Solid polish! :clap:

• In addition, implementing and deploying a DAO is a difficult in practice due to the many engineering challenges.
• Currently every technology claiming to be a DAO has central points of control and critically rely on central servers. Real decentralized DAOs only exist in theory., Fully agree. Citations needed! {for instance, reference to 10 DAOs, no further details needed}
• There is no consensus on how to define a DAO. We define it as a mechanism for economic activity by an unbounded group... Please move to opening line of Related Work or start of Problem Description. not really something to hide there
• [ ] Consistency: Figure 1: "Distributed Ledger Technology (DLT)", Figure 2: "Blockchain"
• [ ] "Sequence diagram of our voting protocol for a transaction proposal", Sequence diagram of our online democratic governance?
• [ ] "We do however argue that in the most ideal case a one-human-one-vote model is ideal for organizations concerning themselves with the common good.", stronger. We deviate from this mainstream model by deploying the one-human-one-vote model of democratic governance.
• [ ] "The design we describe adheres to our architectural requirements which we deem necessary for decentralization.", stronger. Recall that all prior DAOs lack full decentralisation. Our design doctrine dictates true full decentralisation.
• [ ] our architecture.Our approach
• [ ] Our design builds upon established multi-signature schemes, stronger and clearer. Our design builds upon established multi-signature schemes and carefully avoid the need for costly smart contracts. Explain dAPP?
• [ ] Both of these processes can require multiple full rounds of communication in which every participant sends a message to each other. Remove all tutorial stuff please, replace with citations. Remove 50% of text in "5.A. Governance".
• [ ] Figure 3 "Transaction which adds a member to the shared assets of the DAO", consistency. re-use colour schema of Figure 1.
• [ ] Fig. 5: Screenshots of the Music DAO greatly improved! :heart_decoration:
• [ ] To implement our governance protocol, we have developed a Kotlin implementation of the MuSig [17] scheme. vague text. FROST out of scope, significant engineering effort. Offers ability for missing votes. Limitation of our operational MusicDAO is the requirement for 100% voting participation. A single missing vote blocks any proposal.

[InvictusRMC]

thesis_notes.pdf

Some minor comments. Good luck with wrapping up!