Blockchain Engineering 2023 - Upvote Token II

[synctext]

Upvoting token. Each user can give away an infinite amount of ❤️ tokens. Content creators are rewarded with ❤️ tokens, boosting their visibility. Content gathering lots of ❤️ will get more attention and go viral. Content creators can see in real-time who is giving them a ❤️ token. The ❤️ token economy design and implementation is your responsibility. Part of your demonstration will be a wipe-based UX implementation which favours viral content. Fraud and manipulation of your token economy such as the Sybil attack can be ignored. Bonus background reading: The like economy: Social buttons and the data-intensive web.

[WJehee]

Status update (27-02-2023)

All 6 members are added to organization, all members can compile the project and have read the background. Added a like button to the main screen.

Questions

1. Should others be notified of the like? As in, should others (i.e. the network) eventually know who likes what and thus an aggregate can be constructed? Or do we trust a node to report its own likes with a given video?
2. I am not sure what role Sybil attack plays here? If I understand correctly our task is merely to send a generic token when something is liked to the network. Who sends the like token doesn't matter much. Only issue I can think of is users creating accounts to like their own videos but that's a problem in any such system (buying likes/follows). And if we use other metrics to choose top content, simply buying likes is not enough, thus the reward is diminished.
3. What constitutes for our project an MVP (minimum viable product). I understand the two major parts are the like sending and registering and content choice. BUT this hinges on the fact that there already is a functional content upload system and users attached to them. And that such an ecosystem exists and that it is large enough so that the content recommendation can be actually useful and noticeable. So how to get around this without also implementing content publishing and accounts and all that (because I feel this goes out of the scope of our project)? And idea I would have is to simply populate the network with some 10/15 accounts each with some 10/15 videos and then use that as a demonstration. The problem is this is a very small network and a person would have at most 10/15 likes, hard to show virality. Also this is too little to show any sensible recommendation system (especially one based on something more than just number of likes as it requires some time to "learn"). So hence the question: what is MVP for this project (and inquire well what the requirements are)
4. Should visibility be based on the amount of likes the video has gathered or the amount of likes the creator has, or both?

Answers

1. See below: dashboard page for creators
2. Can be ignored
3. No concrete MVP, maximize features
4. See below: think like TikTok product owner

[synctext]

• Week3 and 1 member has done actual "test coding"
• Sprint goal: like button press, create upvote inside Trustchain transaction, send to channel owner.
• post working .APK file on this issue???
• Feel free to decide things, always discuss the big issues in our weekly meetings and document design decisions here. Think like the decentral TikTok Product Owner and user.
• Good idea: like dashboard page for creators. Watch those :heart: come in without a manual screen refresh.
• take the code/take inspiration from MusicDAO
• MVP: Make a skeleton content system. For instance, take the standard Android video camera capture and link it to the Libtorrent torrent swarm creation. (record audio, create torrent, seed in Libttorrent already works somewhere in the Superapp :-)
• Note that DeTOKS has stability issues..hint..hint..
• @ivanstodorov indeed, recommendation is key to going viral and token economy. Our old 2005 efforts: https://grouplens.org/beyond2005/full/pouwelse.pdf
  • explicit feedback that user likes this: :heart:
  • implicit feedback: this user watches it 7 times on average every morning during breakfast.
  • Keep it simple
  • 1 trustchain record with the upvote token. also integrate the Bittorrent magnet link in there. Atomic. Therefore you have a trivial simple content discovery loop and popularity discovery mechanism. Even peer discovery, as this can be given in bulk: transfer 10 upvotes + matching 10 magnet links.
  • collect 10k records of upvoting + content. now you can start recommending the next swipes
  • Advanced: You can match profiles of people with similar :heart: liking behavior. Recommend not what is globally popular, but with similar "taste buddies".

[ivanstodorov]

Ivan's branch: https://github.com/NikolayBlagoev/trustchain-superapp/tree/profile-page

Ignjat and Wouter's branch: https://github.com/NikolayBlagoev/trustchain-superapp/tree/4-relay-messages-received Nikolay's commit to master: https://github.com/NikolayBlagoev/trustchain-superapp/commit/d2e0ba2b1134e921d9e31d69e19870cfa27f0919

[synctext]

• two team members dropped out of the original 6 :disappointed:
• Learning how things are done in Kotlin.
• Strategy: duplicate existing user experience of short video apps (Youtube Short, TikTok, and Facebook short videos)
  • Homepage: frictionless page where everything happens with minimal swipe user feedback
  • Profile: ToBeDetermined
• Selected one "volunteer" for user interface and integration
• Branching and working together: all team member in same branch
• discussed MvP: voting ecosystem
• balance between exploration and exploitation (e.g. serendipity)
• Focus, focus, focus: recommend ordered by: download progress and :heart: upvotes (e.g. popularity)
• test magnet link Creative Commons Tears of Steel, Sintel, etc.
• Encode :heart: upvote into a Trustchain block in progress.
  • Community to share signed votes, if you also add the magnet link you combine content discovery and content recommendation.
  • Thus you simply gather a few thousand upvotes, rank, extract the top-N for immediate torrent downloading.
  • Bonus sprint: magnet link, {filename}, Swipe_Away_Time (1 second, watched 5.2 times), public key, signature, trustchain hashing.
• warning: connectivity of emulators, certain 4G providers is bad. firewalls and connectable UDP sockets: NAT puncturing of IPv8 is not 100%.
• Please get ready to create a Pull Request on 20 March, similar to ongoing efforts

[WJehee]

Meeting (14-03-2023)

Progress

• Embedded like into trustchain block
• Profile page with dummy data
• Got started on content uploading, but having some issues

Goals

• Request chain crawl when joining the network after inactivity (issue)
• Like functionality even without any peers (issue)
• Gather more videos and likes so we can start giving recommendations
• Integrate profile page with actual data
• Create pull request for March 20th

[synctext]

• Issue report with progress per Dev. Bonus: somewhat working .APK on issue
• Great content checkin by Chelsea with Archive.org hacking https://github.com/Tribler/trustchain-superapp/commit/bd8f42daf66ff7b5e1075b031b4e36c167375ff4
• Other team PR made it in master https://github.com/Tribler/trustchain-superapp/pull/136
• @NikolayBlagoev: discovered that Jlibtorrent content injection and seeding in MusicDAO is broken. It used to work. Please try to fix this :wrench: {maximum 2 weeks}
• Sprint Target: Pull Request of a minimal viable GUI by Friday. Ask @OrestisKan and @InvictusRMC for a code review.
• Advise to use dummy node concept. Not a bunch of emulators which eat all memory and CPU. Basically you use a single IPv8 community in cmdline mode. Then you can spawn a lot of nodes from Kotlin easily with low overhead.
• Bonus reading on Tiktok recommender https://haneulkim.medium.com/paper-review-monolith-tiktoks-real-time-recommender-system-72b90bece653
• end-to-end cycle of an upvote token
  • new content gets recorded and seeded
  • first recommended to somebody, plays it 3 times in full, hits the :heart:, and creates an upvote token
  • content gets first views (testing script using dummy nodes)
  • everybody runs a crawler to collect ClickLogs
  • aggregation of ClickLog reveals hot content
  • for each item: how many :heart: it has gathered
  • for each item: how many users viewed it / aggregate viewing seconds = average viewing seconds
  • coin toss, either
    • select top :heart: count item
    • recommend the top-N item with highest average viewing seconds {and not played yet}
• Single IPv8 message format. Token data format is merging: coin concept, content discovery, and content recommendation
  • item ID: magnet link
  • _time_till_swipeaway in seconds, replaying {ignore for now, another team is working on these metrics}
  • :heart: true/false, user has provided explicit like feedback
  • public_key of :heart: upvoter
  • signature
  • Can we avoid a sequence number, signature, or ID by just using item to uniquely identify a ClickLog line for the crawler.?

[WJehee]

Made the pull request! We still need to fix the merge conflicts however, hopefully we can get that done within the next few days.

[WJehee]

Meeting (23-03-2023)

Progress

• Created the pull request into the main repo, but some questions:
  • How should we deal with merge conflicts for the UI? multiple groups are working on the same tasks as us and thus there are conflicting things
• Integrated profile page with the backend
• Content uploading
• Added timestamp to Like so we can sort based on most recently uploaded

Goals

• Fix merge conflicts
• Request chain crawl when joining the network after inactivity (issue)
• Like functionality even without any peers (issue)
• Generate content and likes + work on recommending content
• Hot content page: show list of videos with amount of likes, etc. (for debugging)

Screenshot from the app

[synctext]

• Made PR, but no review request. So idle for a week.
• .APK for testing on issue next meeting (drive link?)
• caching clearance on app startup, need for fix
• how realistic is the "MvP" delivery?
  • hopeful about closing the loops of record,upload, seed, like, recommend, and go viral.
• for debugging purposes a screen with overview of amount of discovered video and top-10 list of most :heart: upvoted videos?

[WJehee]

Meeting (31-03-2023)

Link to most up to date working APK

Progress

• Fixed merge conflicts and fixed all the requested changes by reviewer, hasn't be reviewed again since however
• Recommender system theoretically works but still requires manual testing
• General bug fixes + live updating of profile page almost done
• Setup a private tracker that automatically seeds content

Goals / Todo

• Test recommender
• Hot content page (issue)
• Quality of life updates
• Refactoring/cleanup of code
• Document that unliking is not possible

[synctext]

• Solid progress !! :1st_place_medal:
• [ ] learnings: taking ownership of the entire process :bulb:
• {repeating} Great content checkin by Chelsea with Archive.org hacking https://github.com/Tribler/trustchain-superapp/commit/bd8f42daf66ff7b5e1075b031b4e36c167375ff4
• [x] big milestone: running .APK on your issue {asked for a few weeks}
• [ ] ask external storage on-demand when recording
• [ ] Rebase and polish your PR. get a V1 prototype PR accepted.
• [ ] Required: add 1-section of documentation in readme.md format as with all Superapp PR projects by students:
  • https://github.com/Tribler/trustchain-superapp#peerchat
  • https://github.com/Tribler/trustchain-superapp#digital-euro
  • https://github.com/Tribler/trustchain-superapp#ai-trading-bot
  • https://github.com/Tribler/trustchain-superapp#luxury-socialism
  • https://github.com/Tribler/trustchain-superapp#freedom-of-computing-app
• no :heart: un-liking. You can't revoke a :heart: token once it is minted
• "WOW moment" for the final demo in week 10
  • multiple phones, show peers or live network stat updates (liveness feeling)
  • Also: IPv8 networking basics. What phones are your seeing? (last digits of remote public key)
  • record video, publish, others receive it, likes, :heart: token, counter increases
  • Multiple fresh videos, multiple :heart: tokens
  • Seeing {some} recommender internal statistics {number of likes, how many users viewed it / aggregate viewing seconds = average viewing seconds}
  • working recommender, best liked video first
• [ ] Add animated .GIF to your readme.md documentation

[WJehee]

Meeting (07-04-2023)

Latest APK

Progress

• External storage permission on-demand works (since last week)
• PR is ready to merge, not merged still
• UI improvements: more live updating, red upload button, etc.
• Readme WIP + Animated GIF

Goals

• Peer / connections tab
• Hot content / recommender details page
  • Unique peers gossiped with
  • Like profile page, but sorted on number of likes
• Improve documentation in README
  • example: https://github.com/Tribler/trustchain-superapp/blob/master/currencyii/README.md

[synctext]

• 24 MByte .GIF demo :roll_eyes:
• Solid demo, very happy with this team progress
• everything: content discovery, content recommendation, and :heart: is now implemented through a single IPv8 message
• [ ] document and explain all the fields of this message in your detailed (second level) documentation (in your PR)

[WJehee]

Meeting (20-04-2023)

• APK
• Documentation in main readme
• 2nd level documentation

[synctext]

• user journey: it crashed on first start :rofl:
  • 2nd try works
  • can upload video :+1:
  • no refresh, but shows on profile page
• https://github.com/NikolayBlagoev/trustchain-superapp/blob/dev/detoks/README.md#like-token
  • add please "forget what you know about blockchain, bitcoin, or tokens. This is different and based on older Aug 2007 ledger primitives.
  • "tokens in our system are simply self-signed data blobs. Everybody mints their own tokens in our tokenomics model."
  • using a central server tracker is considered cheating in peer-to-peer: https://github.com/NikolayBlagoev/trustchain-superapp/blob/dev/detoks/README.md#tracker :face_with_head_bandage:

[NikolayBlagoev]

The tracker was not used for the demo. It is provided as an altruistic "dummy node" which can seed content when the original creator is not online. It is used as a more stable alternative to the IPv8 python package which was quite buggy and often refused to work. This implementation on the other hand was stable and would never fail us when we would need to test content uploading/downloading.

Currently we rely on public trackers to discover content (the bittorrent public trackers) and not on a private tracker (the phones seed the content themselves). There is no way as far as I am aware to have working magnet links reliably without trackers (and they havve become the defacto standard in the modern torrenting world).

The issue we aimed to counteract is the following (a short incentive analysis): 1) when a user creates their own video, they have interest to seed it (as they want others to discover it). 2) When another user downloads that video, they are obligated to also upload (by the bittorrent protocol, as otherwise their download speed would also halt). Thus when downloading another person also has incentive to seed. 3) When the video is downloaded the other person no longer has an incentive to seed. Even in the current bittorrent protocol, seeding after the file is fully downloaded is considered purely altruistic behaviour. 4) The original user can then disconnect from the network (application closed, changed networks, etc. - all of which were issues not fully resolved by either IPv8 or libtorrent). Thus their video can no longer be downloaded by anyone, which will lead to loss of potential views/likes. If the network were large enough, there could often be many active users currently sharing content between each other, thus, probabilistically, that content would not be lost. 5) However, as we are in a stage with only 3 users, we provide altruistic nodes which can help the network in the early stages and thus not lose engagement.

In the future, the application could make use of tokens to pay others to seed your video while you are offline (and thus counteract the need for altruistic nodes). However, this was considered out of the scope for this project and hence a more simple solution is offered