There were a few technical issues during Lecture 2 (December 16) and so @erick and I decided to meet again to record it as a screencast. For Lecture 3, I will have someone taking care of the live stream and I will try to be more prepared. I’m very sorry that the event of Lecture 2 didn’t went well.
We separated Lecture 2 into 6 videos and I just released 3 of them to give you an idea of what to expect.
The audio is a bit better than the one for Lecture 1 because we were recording in a soundproof room. As for the video, ideally it should be in full screen 1080p. But when @erick created the Keynote presentation for Lecture 2, he used standard size (4:3) instead of widescreen (16:9). In the future, he will use widescreen size so that we can get full screen 1080p.
For Lecture 3 (I will announce it soon, it will be in mid-January), we might do a video in front of an audience combined with slides (like Lecture 1) + a screencast (like Lecture 2). After that, @erick is going in Europe until the end of April, so during that time we will do screencasts only.
Unreleased videos:
How are Routing Tables built?
How does a node join the SAFE Network?
How does the SAFE Network compare to BitTorrent’s Mainline DHT?
If you contribute to the campaign, you will get privileged access to the unreleased videos of Lecture 2 as soon as the tilt (1000$) is reached.
If you haven’t seen Lecture 1, I would suggest watching this Youtube playlist that I just created.
On the 3rd video #2.3, you mentioned the latency is higher because of the extra hops in physical space.
If two people are very far apart in XOR space, isn’t latency exacerbated even more?
Is there a way to shortcut or reduce latency?
For example, a middle meetup node.
If Alice and Bob are literally on opposite ends of the XOR space, but Tim’s node is in between them. Can they send their encrypted msgs to Tim’s node. Would this cut the latency between them in half?
I hope I’m explaining this correctly.
It’s like sending a runner through the maze from point A to point B. Instead of 1 runner going back and forth between them, they send 2 runners to “meet” at the middle of the maze, which is point C.
Obviously point C would have to be an agreed upon meetup location. But once establish, it might improve their communication.
Either way, love the videos, it helps a lot!
EDIT: My question might have been answered here. Solution was direct IP connection.
If there are multiple hops in XOR space then each of these hops increases the latency. The efficiency guarantee provided by the routing layer is that there should be at most in the order log n hops compared to the number of nodes in the network.
The way the routing tables are built ensures that every node eventually knows about some of the nodes in the far away part of the network ((XOR-space) so the first hop should ensure that the message ends up in the right half of the network, the second hop in the right “quarter”, etc. So there is no need for dynamically finding middle men, the organization of the routing table does that for you.
I did not know there were plans to establish direct connections between nodes, in that case it would allow users to choose a tradeoff between privacy and latency that suits their needs. For highly critical information you use the routing layer for communication but for less critical information, you establish a direct communication channel.
We would like to change the terms of the campaign by releasing the videos and collecting the money soon even though the tilt amount has not been reached. We need the agreement of contributors for going forward with that proposal since we are breaching the initial “contract” between contributors and us.
If you contributed to the campaign, please participate in the discussion and vote on the issue here:
EDIT: Changed the link to migrate the discussion to a dedicated group rather than SAFE Pod Montreal
It seems all but one contributor replied and all those who did agreed to the change. The videos have been therefore published by @frabrunelle on Youtube, enjoy! For future contributions, we will go with a subscription model with patreon.com, and find a suitable solution for those who want to contribute in Bitcoins.
No really, it’s good to make the disclaimer, but we have 64 buckets (well looking at the RT linearly, some of these span many bucket ranges), with at least 32 kadmelia buckets (plus our close group). So this means we have a 32 bucket kademlia routing table. If we analyse existing DHT’s we can see many things
1: Many have duplicate ID’s (30% in emule for instance)
2: Older nodes begin to poison the network (which is bad as kadmelia favours these)
3: They rely on a refresh rate to handle churn (as they are not ‘connected’)
The biggest thing though is that in kadmlia networks to use 30 buckets (not even get 32) then you can calculate the network population would be 7 billion (we did this to confirm the maths of the routing table sizes). So until we have 7 billion nodes then our routing table (not close group which is super greedy) is a normal kademlia routing table, but with a refresh time of spotting a node disconnect (so no dead list notifications required etc.).
The address_space tool in common allows large scale simulations with this routing table so you can see how it works and measure the security and performance.
Erick is like the other researchers we work with and we encourage them to be as critical and questioning as possible, but like a true academic they need to point out these issues and it’s really good they do as it’s all true. But any system is unproven till it’s proven so no worries there We simulated the network with some Phd post docs over a year to make sure we had these parts correct, at least in theory.
