Although this last week was a planning week for the upcoming sprint, the team still managed to get through a bit of code and as a result we have the routing example running (with caveats: routing does not interface with sentinel and at the moment the example can only be run on a Local Area Network). We don’t need to provide instructions now as Mark has done so for us here. Thanks Mark, nice steal 
A lot has been changed recently in our development process. The re introduction of development sprints and more focussed planning is enabling us to re iterate frequently and provide you with system components to play with and for us this is really important. It is vital that we all see and appreciate the progress that is being made. David is really pushing us all very hard for a ‘feature complete’ network as soon as possible, packaging the components in a modular and generic way. This not only enables them to be used by other decentralised projects, it also allows the community to continually feedback at a library level.
We are aiming to improve the speed of delivery of this very important network and with speed can come errors. We think we are now striking the right balance with much of this and the reason we think so is YOU, the community. It’s really important to us to get feedback on each iteration and this modular approach will help the community to see all the building blocks as opposed to being hit with a wall of new code and a bunch of new inventions that are difficult to pull together with any ease.
A current limitation has been that we ask you to build the examples, which is nice in some ways, but for many, it would be better to download binaries and even better to do so as part of an installer. With this in mind, we have this set up and will now build binaries for OSX/Linux and Windows. We will also be creating an examples installer which will contain pre-built examples for all modules, packaging them with the appropriate documentation to run them. This should be even more inclusive and accessible.
The modular approach also means other projects can and should grab our modules and not be scared. For instance what P2P project would not love CRUST, or what DHT project would not like to have a secured DHT with much higher performance? All of us would appreciate better, faster more secure projects and with real collaboration, the open source dream is to not write code you do not need to. So this approach we now have should also strengthen ‘competing’ projects and that is pretty nice, especially if they help us improve SAFE Network code along the way.
David has had a bit of a mantra going on this week “what we do not code makes us stronger” and this is actually deeper than you first imagine. It means share as much as possible (as above), but it also means, think and think hard: something coded means it is created, but is there a way this thing can happen naturally? Attacking a problem from a different angle may reduce the need for extra code in the first place and if we’re on the right track and our design is better, what you do not code does not break :-). It’s actually pretty nice on many levels.
Anyway, as Mark has done most of the work for this update (great, thanks Mark) I can leave it here. I will add that the routing example is pretty limited at the moment as you will see, but it will quickly develop as sentinel and address relocation are integrated. Then we can truly say it is secure enough. Then as CRUST gets reliable UDP and NAT traversal we can then say routing works across the Internet as it should. So again, the modular approach shows us exactly where we are and what we still need to do. Thanks to everyone for their continued support!
One last thing I almost forgot, here is the weekly dev update transcript.
