The Plan, 6-21 #5587
Comments
|
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.
Could you elaborate how traffic accounting would fit in the channels ecosystem?
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.
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.
A similar view used to be on the home page, but the selected torrents were random :D
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. |
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.
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.
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.
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.
Is the plan for this a native app, or a revised html UX? |
|
@balupton , thanks for your interest in Tribler project!
We have not decided on exact technology to use for UX/UI yet. This question is open for discussion.
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.
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. 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 💲💲💲 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.
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 😉 |
|
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! 🎉 |
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 |
Monthly Release ScheduleGood 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.
|
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, 👍 )✌️ Roadmap to victory ✌️
Old plans circa august 2020
7.6
(Shipped December 2020)
Fast previews via Bloom filters neighborhood
Improve channel processing w/o changing format
OR
implement
ATTACH-based channel format@ichorid
add separate "Now trending" view to the GUI
@drew2a
@xoriole
@drew2a
@devos50
Solve "create torrent" screen problems
Solve minor GUI defects
@ichorid
@devos50
@drew2a
Make tests run in parallel
Use real Core for GUI tests
Stabilize flaky tests
Integrate nice view for failed tests
@ichorid
@egbertbouman
@drew2a
Exit nodes, bootstrap nodes, infrastructure health stats
@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)
Individual files support (e.g. music albums)
@grimadas
@kozlovsky
Individual files support GUI
Generative avatars
@ichorid
@xoriole
@kozlovsky
Tribler as Windows Service
@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 ♨️ 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)
The text was updated successfully, but these errors were encountered: