Another busy week in MaidSafe, as usual. We are in mid sprint now with the stabilisation sprint. This is to allow larger, although still only directly connected, networks. It will allow us to confirm vault, routing and client logic in a larger test across hundreds of nodes. While we wait on the NAT traversal appearing in Crust, this is an opportunity to include logic and test the network without being held up.
The team were delighted to have released the DNS examples and a first example application, however, we pushed straight into āRUST-4ā sprint with the following objectives:
- Code cleanup
- Run RustFmt on all codebases
- System stabilisation (API and tests to prove APIs)
- Client installers
- OSX vault installer
- Launcher RFC (see below for more info)
- Churn handling and testing (routing clients and vaults)
We didnāt want to run out of work, so we also added a few stretch goals as follows:
- Address relocation fully activated (i.e. moving a node once it connects, so that it doesnāt get to choose where it connects to the network - making it harder for attackers to try and form authority groups)
- Further work on Windows vault installers. We have working installers for Windows 8.1, but we need to do a bit more work to get these polished and we also need to ensure they work for Windows 7 onwards on 32-bit and 64-bit systems.
- Implement UTP hole punching
- Design TCP hole punching
- Update Routingās connection management to accommodate NAT traversal
The final three points will likely be added to the upcoming RUST-5 sprint. These will allow Vaults to be run and tested from behind most routers - i.e. from your home - so another big step forward.
As usual, you can follow the ongoing progress of the sprint in the Jira dashboard. Despite Jiraās burndown chart (normal pattern for middle of sprint), the developers are generally confident that weāll meet the objectives of the sprint on time.
Both Routing and Crust have seen a few more changes to their APIs, but weāre hopeful that there shouldnāt be as many ongoing changes to library APIs in the future - indeed thatās one of the points of this sprint!
The Launcher RFC has now been submitted. The Launcher is effectively the gateway to the SAFE Network for any app. Among other things, it will allow end users to create accounts, log-in, and store and retrieve data via their apps. Iād encourage anyone interested in developing client apps for the SAFE Network to have a look and add any pertinent comments or concerns.
Weāve seen a lot of activity in the form of Community members offering pull requests. Weāve paid out six bounties totalling $220 so far to four devs, who should all be getting a T-shirt for their efforts too. While this scheme is still in its infancy and will doubtless change over time, I think weāre off to a very promising start. The more eyes we have on the core codebase, the better the end result will likely be.
This is a great way of sharing the knowledge and has shown us that we do need to specify our tasks in a more detailed manner. At the moment many tasks read more like Engineer mental notes, which is fine for the in-house team, but we are now larger than that. So a great start and lessons learned; we suspect this will increase in popularity in the next few sprints.
A final note, you may notice the forum a bit quieter in the next two weeks as David is going off line and taking a break. He says he will switch off the computer and get some real rest, which is probably overdue. He never takes breaks from the work and this is now the calm before the storm and it makes sense to be fully recharged for the next step.
As always, here is the transcript of the weekly meeting.
i apologize for my incorrect statement =) (i should have mentioned i donāt have access to any 32bit linux pc ā¦ and didnāt invest the time to test it with a VM)
makes updating so comfortable!