msc placeholder: class of 2026 thesis around DAO CDN service with voting

[synctext]

Graduation period: Nov 2025 - 30 June 2026 (Hard stop, because vacation)

By X-Mas have a concrete 1-page written Problem Description. Still exploring optional and talent/assignment fit. Product-development focus and likes programming. No DAS6 experience.

Month	Deliverable
December	First thesis chapter written in draft: Problem Description
Jan	First idea of the experimental section of your thesis
March	first running code for your thesis problem, write introduction section
April	First performance graphs for thesis, first draft of Experimental Results section
May	Multiple graphs, running code is better code
June	FINISH

To keep the 2026 project viable: try to prevent Sybil attack with donations ==> Non-free identity. Ignore mostly for this year. Simple known user lists. First release in March for small-scale silent testing. April or May we have a deployment and press cycle.

Possible directions:

• threshold voting with known public key members
  • Bitcoin donations, make 1 donation, get 2-2k invites ($5..$5k)
  • Donation or invite code gives you the right to vote 🤔
    • three level of users? Donors,invites, and permissionless join?
    • keep simple: donors, non-donor vote.
  • What to focus on for threshold voting (keep it simple!): code change or content changes or both
  • Everybody free to propose something, so spam problem
  • Prior operational prototype of SmartphoneDemocracy with actual voting
  • Prevent Sybil attack: costly identity (see Gitcoin experiences)
• system architecture and algorithms (content.txt and members.txt system boundries)
• Field trail, promotion, uptake, measurement, performance analysis, and publication

🆕 now the architecture for 6 students

ToDo:

• read prior thesis work, https://arxiv.org/a/pouwelse_j_1.html Especially SmartphoneDemocracy
• Threshold voting literature search all ready for you to read from prior student
• Get your first Python overlay running connect to our live Tribler discovery community, https://tribler.readthedocs.io/en/latest/autoapi/tribler/core/components/index.html
• Future sprint: dummy GUI design to throw away.

[Stanverl2]

Papers

The focus of last week has been on reading a lot of documentation and literature to familiarise myself with threshold voting and the systems I will be using. Below is a list of papers that I have read (in order that I read them):

1. Web3: A Decentralized Societal Infrastructure for Identity, Trust, Money, and Data by Joost Bambacht and Johan Pouwelse.
2. SmartphoneDemocracy: Privacy-Preserving E-Voting on Decentralized Infrastructure using Novel European Identity by Michał Jóźwik and Johan Pouwelse
3. Who Watches the Watchmen? A Review of Subjective Approaches for Sybil-resistance in Proof of Personhood Protocol by Divya Siddarth, Sergey Ivliev, Santiago Siri, Paula Berman

yt-dlp

Besides reading the papers I took some time to look at the yt-dlp repo. This project "is a feature-rich command-line audio/video downloader with support for thousands of sites". The project is starred 136k times, showing its popularity.

I had not used it before, so it took some time getting everything set-up. For the sites where it actually works it is great, but I must say the "thousands of sites" is a bit misleading for multiple reasons:

1. Many are duplicate aliases (same backend, multiple domains), many are sub-extractors (region versions, language versions), and many map to the same platform with dozens of country variants (e.g., 60+ news sites using the same player).
2. Then I immediately bumped into problems where Digital Rights Management (DRM) using Google's Widevine prevented me from downloading anything from the NPO (NPO Start, Zapp, Het Klokhuis, Jeugdjournaal, Nieuwsuur). There is no workaround around this, this is a serious limitation as we can expect only more and more places to start making use of this.

If you ask ChatGPT for an estimate of how many sites there actually are you get the following answer:

1. Raw number of extractors: ~1800
2. Functional, truly separate websites yt-dlp can download from: ~250–300
3. Sites that work out-of-the-box without login or cookies: ~120–150
4. Sites that work 100% reliably and are regularly maintained: ~60–80

Then lastly what I found interesting is that there are some websites that are solely broadcasting live streams. When you go and look online why yt-dlp is used for live streaming websites you quickly find out that is mainly focused on adult websites. There are people out there that have servers set-up to record these live streams from these adult websites.

IPv8

Read the preliminaries, basics, and part of the references of the PyPI IPv8 documentation. I followed the tutorial Basics: Creating your first overlay and looked over the code fragments in the other sections.

Progress

Unfortunately I got caught ill last week and had to stay in bed for almost a week, not in a shape to focus on any papers. For that reason I wasn't able to make the expected progress. In the coming weeks I'll be making some extra hours wherever I can to make up for the missed time.

[synctext]

First step of Problem Description.
We created the tooling for an experimental democracy. Significant amount of Reddit users downloaded our tool for democratic decision making and started participating. Our starting point was a prototype with proven scalability to one-million active voters. In the past decades numerous social experiments have been conducted, yet, digital democracy has not thrived. We identify the key friction points. First is usability. Second, trust in infrastructure. Third, lacks a purpose. We fixed all that👷 The dream of digital utopia is near/s 🤣

• start with static list of 1 million URLs to Creative Commons content
• prior Kotlin voting code
  • ElectionScreen.kt
• Create a first voting framework to throw away😨
  • create IPv8 Python 3 clients, process to randomly create items to vote on
  • react randomly to incoming votes
  • Backup plan replay a voting dataset
• Everybody can propose new content
  • incoming proposals for voting
  • everybody can see and react to new proposed content. Either approve, reject, or propose to ban user🤔.
• feeling of liveness within the GUI. Live vote discovery, live peer discovery.
• Jan first field trail? See how we can get activity and "voter turnout".
• Goal for May/June is to have new users joining graphs and experimental results graphs of voting.
• Roadmap
  • 1 person 1 vote system
  • create identity with a Bitcoin transaction (minor cost burden)
  • vote on: content, bug bounties, feature bounties (textual specification), awarding of bounties to code proposal (security risk, does code follow spec or hidden backdoor), and improvement to the core intelligence (measured by ARC AGI scoring in future).
  • attack resilience, see our old IETF Internet Standard work
• WILD card: municipalities such as Rotterdam have an experimental digital identity wallet. QTSP wallet? Use real passport-grade identity for democratic processes with legal standing 🎉🎉🥳🎉🎉

[Stanverl2]

https://github.com/Stanverl2/democracy

[Stanverl2]

Progress

The goal for the next meeting was to have a minimal version of threshold voting implemented. After having played around a bit with IPV8, I first created a small GUI, so it was easier to get feedback from the application (e.g. you can press buttons and can trace errors). This GUI has been finished and works.

The GUI contains 3 frames:

1. A frame for creating elections.
2. A frame that contains list of known elections.
3. A frame with more details about the elections and a button to vote on it.

For the time being data is stored in locally saved JSON files. This is not a permanent solution, but did allow for a quicker start of development. Voting has been limited to one vote per user.

The next step was to use IPV8 to allow for broadcasting elections and votes. The skeleton for this has been set-up, but I ran into some problems that I am solving, but each time I solve one the next one appears. Right now the sending of elections seems to work, but on the receiving side only empty packets are received.

The GUI is not the prettiest, but that also wasn't the goal:

Thesis problem description

The current state of the art in this domain is represented by SmartphoneDemocracy, which enables large-scale digital participation using smartphones while relying on cryptographic techniques for authentication and vote integrity. Unfortunately, this system still depend on a single "leader" smartphone for identity verification and management. This central point of control introduces trust assumptions, creates a potential single point of failure, and limits the system’s resilience against censorship, compromise, or misuse.

This thesis explores the next step beyond this architecture by removing the need for any central element. It investigations identity creation to be regulated through economic cost mechanisms, thereby discouraging large-scale identity fabrication without relying on a trusted central server. As a proof of principle, Bitcoin is used.

With our fully decentralised architecture ...

Key challenges:

• Bitcoin wallet creation and one-time funding.
• Using a single Bitcoin transaction to register your identity.
• Spending this Bitcoin on fully automated robotic seedboxes.
• Early testing and social experiment in March
• Experiment with 1 million votes.

Related work

• GitVote
• SmartphoneDemocracy

[synctext]

solid! Sprint focus: First finish IPv8 overlay logic with voting and vote gossip. Then Python local Bitcoin wallet integration and initial identity linkage ideas.

Related work: git on bittorrent, last updated 11 years ago🤔