Open synctext opened 11 years ago
igraph is a library (also for python) that can allow us to generate large graphs. http://igraph.sourceforge.net/screenshots.html
Updated prototype:
Closing ths one, bartercast isn't going to be integrated into Tribler any time soon. Hence, there is no direct need for a gui.
Our 2018 work is now deployed and a new "barter" graph is created from the Trustchain crawl
Older crawl, from original Bartercast by Rahim; the June 20 until September 9, 2009 crawl.
Real-time render of TrustChain interaction graph: http://explorer.tribler.org/visualization
Examples:
OK, I'll focus on it.
Initial stuff I've started with exploring Alexander's code, and decided to code from scratch because:
Current state of the code
Issues
Next sprint (upon discussion with Johan)
The GUI looks very nice!
It might be worth having a discussion about the second point you mentioned. If one wants to take into account the nodes that have downloaded from the seed node as well as the nodes that have uploaded to it then a good way of doing this is by considering bidirectional edges, instead of our current unidirectional ones. This would enable us to evaluate peers, not just based on their up-to download ratio, but also on absolute values.
Also, we should think about somehow combining the BFS with the actual random walks to reduce complexity. Otherwise random walks might not be really necessary any more (as was discussed this week).
I totally agree with Alexander that we need a different implementation of edge weights (or directions). I discussed it also with Johan, giving the following extreme case as an example: Consider two nodes which download and upload a huge amount of data from/to each other. At the end, the weight of the edge between them will not reflect the amount of traffic. Moreover, if they upload/download the same amount of data from each other, the weight of the edge will become zero.
I think we will come up with it a clever strategy over time.
The current state of the code:
I implemented a Transaction Discovery module. At this stage it either generates fake data or listens to the tribler crawler to feed Random Walk module.
Current state of random walk module:
Before each batch of random walk, the node takes as an input a list of 3-tuples (from_node, to_node, edge_weight) and updates its own transaction graph (rooted at itself).
These new transactions update the existing graph proportionally, so that if no transaction is done on an existing edge, it is subject to be removed as the time goes by.
Edge weights show the amount of one-way traffic between nodes and are significant for the determination of the next step of a walk.
Having updated the graph w.r.t. new transactions, the node then performs random walks, and the procedure repeats.
Random walks determine the other nodes' importance observed by 'the node'.
A node which was discovered through 'transaction discovery' but not visited frequently during random walks are subject to be removed from the graph in order to control the size of the graph.
The code is now modular (Transaction Discovery, Local Vision, Random Walk, Graph Positioning)
In addition to the random walks, the update of local vision of the node w.r.t. the discovered transactions is also animated now.
Next sprint
I have already started focusing more on research than on coding.
Research for finding/offering a function to calculate trust values of nodes (may be the title of a new issue)
Some interesting studies that will help us:
We agreed with Bulat that we will use 16GB of tribler transaction history to make tests for our algorithms. He will prepare the interface which will feed my code with real data. We decided to spare a small portion of the data for determining the initial "the most trustable peers" list.
Easy bootstrap and visualisation idea to take "mathematics-of-trust into production usage. Show the user and include a first version of our trust formula. Possible goal for end of March: genesis trust swarm.
Detected a problem with both Alexander's and my implementation of random walks. Presented here.
New Attacker model: majority is malicious, however majority of evil nodes are overseas.
Brainstorm, combine latency-restricted communication #2541 with the 25MByte boostrap concept (oldest mention):
Decided at last Dev Meeting: we will first launch an "animation-only" version of the genesis trust swarm in Tribler.
PR #4488
visualization of trust buildup for virtual identities. Key issues: rendering, smoothing and node placement as nodes get added and pruned.
Depends: #20
initial prototype:![web-of-trust-in-Tribler-GUI](https://f.cloud.github.com/assets/325224/232079/405969b4-8723-11e2-9812-29685446631d.png)