Closed ichorid closed 8 months ago
Nice plan!
I see much overlap with my initial write-up on the ecosystem to incentivise good behaviour, specifically, running exit/relay nodes (we formerly called it the “token economy”).
I think the items for 7.6 are reasonable and mostly consist of the stuff that we have discussed already.
traffic accounting mechanism (Trustchain ➡️ Bami)
Could you elaborate how traffic accounting would fit in the channels ecosystem?
Serving community is incentivized by assigning a "social score" to participants. The better your score, the better service you get. If your score is zero, you become "bottom feeder" who can only use surplus resources not claimed by people with higher score.
As it is currently implemented in Tribler, this score is only based on how much bandwidth you contribute/consume from the network. Would this be sufficient to incentivise users to share channels? In your described system, it seems to also depend on how much information you share with others. This would make the trust score a multi-dimensional metric.
Anyone can send tokens to any address in the Tribler network, thus creating a donation-based system where authors can directly receive payments from their fanbase.
Warning ahead: Integrating crypto payments in Tribler is not trivial, given that we need a Python library to do so, and that we need to bundle all required dependencies in our final executables. A group of students recently completed the software engineering course with the ambitious goal to create a “universal wallet” that can support any cryptocurrency (spoiler alert: this turned out to be impossible). They improved the Python-based Bitcoin wallet but their code is not ready for integration. We could consider integration a L2 cryptocurrency that allows for small, incremental payments to others.
add separate "Now trending" view to the GUI
A similar view used to be on the home page, but the selected torrents were random :D
parts of tunnels data processing to an endpoint written in a lower-level language (like Rust or Go).
While this might improve performance, I doubt this is a good idea as target somewhere in the coming year, given that we then have an additional library to maintain (even in another language), and that we need to radically redesign our build processes.
traffic accounting mechanism (Trustchain arrow_right Bami)
Could you elaborate how traffic accounting would fit in the channels ecosystem?
The line you mentioned has nothing to do with Channels (at least for now). However, we planned to experiment with moving Channels to Bami backend at some point. Also, Bami is going to replace TrustChain as accounting mechanism.
Warning ahead
I did not meant that we should implement external crypto payments. Instead, we should start by implementing a one-click mechanism to send Tribler tokens.
This would make the trust score a multi-dimensional metric.
The score is going to be a unidimensional metrics calculated as a function of many variables (including bandwidth token balance, Channels seeding score, etc). This is @grimadas 's idea about everyone implementing their own interpretation of common knowledge.
Sounds great.
We could consider integration a L2 cryptocurrency that allows for small, incremental payments to others.
For the crypto stuff, are we talking about waiting for something like polkadot, or L2 as in off-chain to avoid network fees.
Alternatively, something else in the space of decentralised private information is this — https://xx.network — may be worth reaching out.
By the second half of 2021 we should plan to hire outsourcers to completely redesign the GUI to modern standards. The finished GUI will become a major compelling point to release Tribler 8.0. This should be a very good moment to "whitewash" our reputation and start a media campaign.
Is the plan for this a native app, or a revised html UX?
@balupton , thanks for your interest in Tribler project!
Is the plan for this a native app, or a revised html UX?
We have not decided on exact technology to use for UX/UI yet. This question is open for discussion.
Alternatively, something else in the space ...
I've never heard of this project. Their whitepaper lacks any technical details. Maybe you could tell us something about it?
@ichorid your plan looks great.
I am a relatively new user of Tribler and also a relatively new team member. That means I'm still not deeply familiar with current code and scientific issues.
My POV (point of view) is the POV of a new user. I think, the application might respond to my base requests:
If I can't find or I can't download content, then I'm not interesting in other fancy stuff.
If we want to get more users, we should solve their problems. Not ours. We have to always ask ourselves: "What's the worstest user's pain now?"
There is widely used metrics like R1 (day 1 retention) and R30 (day 30 retention). We can use them, for example.
But the thoughts above is right only if the main focus is users.
@drew2a , the thing is, anything and everything we can offer to our users is much better done by some existing multi-billion :heavy_dollar_sign::heavy_dollar_sign::heavy_dollar_sign: app. Our competition spends more money per single button of their GUIs then we spend on our developer's salaries in a year... But we're not trying to build something that is better or different from our competition. We don't need to. We just need to do the same stuff they already did in regards to UX, but on a completely decentralized basis instead.
Unsurprisingly, that turns out to be an extremely hard problem. What happens here too often is, people trying to take a shortcut by "temporarily" delivering a "semi-centralized" solution. Which - as usual - sticks around permanently for the lack of alternatives (or because of a student who developed it leaving just after finishing their thesis). Eventually, the whole app becomes a gross mock-up made of compromises and undelivered promises. And it is not good enough to compete with existing centralized solutions but is not truly decentralized either.
The plan above is focused on tackling exactly that problem: delivering the UX finesse of the state-of-the-art centralized systems while using an uncompromisingly decentralized back-end.
If I can't find or I can't download content, then I'm not interesting in other fancy stuff.
We did cut down Tribler to just that. There is (almost) no "fancy stuff" now, so we can focus on important things, like the user-serving stuff you mentioned :wink:
Also, regarding the retention metrics, these are only useful if you can do A/B tests. Anyone who will come up with a solution of how to implement A/B tests in our current situation (pre-packed, pre-compiled offline app focused on user anonymity) will become a Tribler Employee of the Year for sure! :tada:
The focus for 7.8 should be remote keyword search, semantic Channels overlay and "torrent market" with different prices per MB for different torrents. Another focus is i18. Also, donation system should work by that moment.
Social score mining via "rare torrents support"
Collective authoring GUI
This roadmap contains a lot of features i've wanted for the past 15 years. Sadly its not very realistic to have differentiated prices on a content market. Please focus all our energy on making the current channels scale, implement simple things like a "progress bar" and lets get the PopularityCommunity
deployed and operational.
Good to have a clear table with assigned tasks. A key thing I would like to do with the new and bigger team is iterate faster. Thus monthly releases and a methodology that code is much more stable during development. The development team always works as a single team on a single topic and always is focused on a single sprint task. For the future I would like minimal fragmentation of attention or the development team. Temporary freeze on all new features until we have addressed PopularityCommunity and Channel issues.
Component | Tasks | People |
---|---|---|
Anonimity | Improve stability, fast startup, and security in general Uniform message size |
@egbertbouman |
Accounting - Bami | First experimental release of Trustchain with audits: Bami | @grimadas |
tragedy of the commons | end-to-end token ecosystem to prevent tragedy | @devos50 |
Overlay network | IPv8 version 3.0 redesign | @qstokkink |
Channels | Design documentation Improved design and minimal changes First Minimal Viable Product |
@ichorid |
Channels GUI | Feature freeze repair subscribe button tweaks to improve usability |
@ichorid |
Torrents popularity | Improve torrent popularity community Use as training project iterate monthly until we have MVP |
@kozlovskybr>@drew2a<br@xoriole |
Dashboard | Show key performance indicators of we are doing show Tribler resource usage, (anon) download speed, etc. show basic Tribler network health indicators "Trending torrents" view in the Dashboard Exit nodes, bootstrap nodes, infrastructure health stats |
@drew2abr>@xoriole<br@kozlovsky |
Infrastructure | Solve Pytest migration consequences Make tests run in parallel ~Use real Core for GUI tests~ Stabilize flaky tests Integrate nice view for failed tests |
@devos50br>@ichorid<br@egbertbouman @drew2a |
The development team always works as a single team on a single topic and always is focused on a single sprint task.
Like the whole team, or a sub-team? The plan above assigns individual people to individual tasks instead...
(Continued from #5348)
Tribler Mission
Our mission is to build a completely decentralized, anonymized, impossible-to-shutdown information market. The market will provide anyone willing to participate in it an opportunity to serve the community in the following ways:
Incentivizing social good
Serving community is incentivized by assigning a "social score" to participants. The better your score, the better service you get. If your score is zero, you become "bottom feeder" who can only use surplus resources not claimed by people with higher score. Effectively, this creates "information abundance economy" where spare resources are given to the community for free, as a kind of "information welfare".
Social score system
According to @grimadas 's idea, we should implement the model of "common knowledge, subjective interpretation" of social score. This means that everyone will ask and share common information about social behavior of peers they are interested in, but will use this info subjectively to build their personalized "trust ranking". The ranking will effectiely map multi-dimensional social interacition data to unidimensional "trust function".
Author payments
The system will provide fairness to artists. Anyone can send tokens to any address in the Tribler network, thus creating a donation-based system where authors can directly receive payments from their fanbase.
Minimum Viable Product
The minimum architecture to get the network going includes the following components:
libtorrent
, :+1: ):v: Roadmap to victory :v:
Old plans circa august 2020
### 7.6 (Shipped December 2020) | Component | Tasks | People | |---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------| | Channels | Asynchronous queueFast previews via Bloom filters neighborhood
Improve channel processing w/o changing format
OR
implement `ATTACH`-based channel format | @kozlovsky
@ichorid | | Torrents popularity | Improve torrent popularity gathering,
add separate "Now trending" view to the GUI | @kozlovsky
@drew2a
@xoriole | | Channels GUI | Change channels GUI to be more intuitive, resembling popular services | @ichorid
@drew2a
@devos50 | | GUI | Add tree-based torrent contents view
Solve "create torrent" screen problems
Solve minor GUI defects | @xoriole
@ichorid
@devos50
@drew2a | | Infrastructure | Solve Pytest migration consequences
Make tests run in parallel
Use real Core for GUI tests
Stabilize flaky tests
Integrate nice view for failed tests | @devos50
@ichorid
@egbertbouman
@drew2a | | Dashboard | "Trending torrents" view in the Dashboard
Exit nodes, bootstrap nodes, infrastructure health stats | @drew2a
@xoriole
@kozlovsky | The main goal for 7.6 is to produce an imperfect, but usable application, by addressing the most pressing issues, while also opening up a road to future experiments. ### 7.7 (Shipped April 7.7) | Component | Tasks | People | |--------------|--------------------------------------------------------------------------------|-------------------------------------| | Channels | Collective authoring
Individual files support (e.g. music albums) | @ichorid
@grimadas
@kozlovsky | | Channels GUI | Collective authoring GUI
Individual files support GUI
Generative avatars | @drew2a
@ichorid
@xoriole | | Tunnels | Zero-copy endpoint in low-level language | @egbertbouman
@kozlovsky | | GUI-Core | GUI running independently of Core
Tribler as Windows Service | @xoriole | | Content | Content bootstrapping | @drew2a | | Economy | Social score mining via "rare torrents support" | @grimadas
@xoriole | | Infrastructure | Add voluntary anonymized monitoring to the app | @xoriole
@drew2a | The goal for 7.7 is twofold: enable the Collective Authoring system for Channels and radically improve Tunnels performance by moving the hot :hotsprings: parts of tunnels data processing to an endpoint written in a lower-level language (like Rust or Go). It is also possible to split these two goals into two smaller releases. ### 7.8 The focus for 7.8 should be remote keyword search, semantic Channels overlay and "torrent market" with different prices per MB for different torrents. Another focus is i18. Also, donation system should work by that moment. ### 8.0? By the second half of 2021 we should plan to hire outsourcers to completely redesign the GUI to modern standards. The finished GUI will become a major compelling point to release **Tribler 8.0**. This should be a very good moment to "whitewash" our reputation and start a media campaign.
Update June 2021
(August)
(October)
(December)
Generative avatars
Music albums pages
Updates with EVA (Channels 2.5)
health and Popularity page
@drew2a
@drew2a
(converting from @grimadas 's simulator code)