Hi All,
My name is Brian Smith, I’ve been part of the core development team at maidsafe for four years. I’m the primary maintainer of maidsafe_types and self_encryption, and secondary maintainer of drive.
An improved task planning and estimation process saw the successful completion of the RUST-2 sprint at the end of last week. In summary, the main sprint objectives were, the implementation of the REST interface of network file system for maidsafe_client, to run a routing network over TCP to test communication in conjunction with crust, and the initial draft documentation and determination of farming rate based on network activity in maidsafe_vault. The schedule further included, the addition of account transfer for each persona in maidsafe_vault, updates to Sentinel along with it’s integration with routing, the last part being postponed until the next sprint, updates to the main types required by maidsafe in maidsafe_types as well as the initial implementation of safecoin, a move to the sodiumoxide library in self_encryption, and a commitment to self contained, explanatory documentation for each component on behalf of the library maintainers. A number of examples have been included/updated as proof of concept and to further test the respective libraries.
This week has been reserved to tackle outstanding issues reported on GitHub, and for QA to discover any lingering bugs preventing the successful operation of a routing network. Many thanks to those of you who are trying out the examples and reporting their findings/failings it’s very much appreciated. Provided all goes as expected this week, we’d be grateful thereafter for your further involvement to confirm things are working as they should, and the next sprints’ planning can begin.
As most of you are probably aware the updated roadmap was published by Nick a few days back. The discussion and links can be found at New Roadmap Published. We have also added a new repository, GitHub - maidsafe/rfcs: Request for Comment (RFC) papers and discussions on Project SAFE core libraries and APIs, whose purpose is the pre-cursor to pull-requests that would otherwise introduce features affecting compatibility, consistency or security constraints required to maintain a stable network. This should allow much more community inclusiveness in the ongoing design and improvements to the network, enabling the various SAFE POD’s to get tightly integrated in discussions, while also allowing experts in various fields to make valued contributions. Already, the best use of our API’s has been the subject of much investigation, again changes there will require an RFC and process to get community ‘buy in.’ We will finish the initial network in the next two sprints, but foresee the RFC process becoming critical to changes after that, apart from internal non-critical issues of course. Full details can be found in the repository’s readme.
Regards,
Brian
