MaidSafe Development Update
Hello, my name is Ross and I have been part of the MaidSafe team for over 2 years. Until recently, this was within QA; my job has now transitioned into a more customer support focused role and is still evolving as we grow as a company. SAFE forum regulars will know me best for collating and sharing the team’s weekly development updates. I am aware not everyone has the time or the inclination to regularly check the community forum, so I thought it would be useful to provide a less technical overview of our development progress during the last few months, here in the blog.
All of our energy and effort in the last few months has been focused upon delivering a Minimum Viable Product (MVP) as quickly as possible. What will the MVP look like and what will you be able to do with it? The MVP will enable users to install the software and connect to the network from their computer, store and retrieve files, browse sites hosted on the SAFE Network and message other users. Subsequent development sprints will see the addition of other extremely important features, such as Safecoin. We are very close to delivering the MVP and depending on which core developer you speak to, this can be measured in either days or weeks. We are aware that we have been ‘almost there’ for a while now, so allow me to update you specifically on our progress within our core libraries and hopefully this will allow you to come to an informed conclusion yourself.
A huge amount of effort and resource has gone into the core Routing and Crust libraries over the last couple of months. 75% of our engineering capacity has been focused on collating feedback from testing, peer programming to redress unanticipated observed behaviour and delivering a stable, functioning network that behaves as expected. At the same time both of these libraries have been heavily refactored; code refactoring means restructuring / reducing complexity within the code base, without changing the overall logic or behaviour of the code. Within Crust itself the library has been broken down into smaller modules called crates:
rust-utp — a crate that enables you to connect to the network from wherever you are.
service_discovery — discover other instances of your application on the local network.
config_file_handler — create, read and write configuration files.
crust (slimmed down and safer) — reliable peer to peer network connections. One of the most needed libraries for any server-less, decentralised project.
The guys have also been working on simplifying Crust’s API (application program interface) to make it more user-friendly and generally easier to integrate with. Routing was stabilised to allow the dependent crates (all the client modules) to utilise its functionality and interact with it more easily. Both libraries were also thoroughly documented during this period, which is essential for third party developers wanting to build upon the SAFE network.
Meanwhile, the Client guys have been working in parallel getting the upper layers prepared for the release of a stable base, focusing on the Launcher, creating solutions to allow users to bridge seamlessly between the old internet and the new SAFE network and beginning work on real end-user SAFE apps. Firstly, what is Launcher? Launcher is responsible for starting any SAFE Network compatible applications. Launcher acts as a server gateway between the application and the SAFE Network. The applications authorise and exchange data with the SAFE Network when the user allows them to, so in practice this means you only have to share your valuable credentials with Launcher and not every application you use, making this a far easier and massively more secure experience than we have on the current internet. It also means you need remember only one password in order to access all your Launcher enabled apps. This approach also lowers the barrier to entry for third party developers as well and will encourage further innovation on the SAFE platform.
Figure 1 — Example screen of SAFE Launcher on Windows
The team have also hatched a solution that allows you to browse sites on the SAFE Network without needing a browser plugin, just using the SAFE Launcher and your normal internet browser. We believe this will help enormously in terms of encouraging people to first try the network; this has been a topic that has seen a lot of community discussion. The discussion via the forums or the Request For Comment (RFC) process is input we all value very much and something we hope to see much more of as the network gains traction.
A lot of work has gone into creating, finalising and documenting the Launcher API. This API is crucial to the success of the platform in that it is the gateway allowing developers to integrate their products and services to leverage the power of the SAFE Network.
An example of one of the SAFE apps on which the UX and Client Devs are working together is a Messaging app. Below are some mock-ups of what we expect the app to look like.
Figure 2 — Example screen of SAFE Messaging app
Figure 3 — Example screen of SAFE Messaging app
When you have been working with CLI (Command Line Interface) examples for so long, the knowledge that well thought out, aesthetically pleasing and functional applications are coming is extremely exciting. Another application currently under development is a Drive VFS (Virtual File System) app; this is essentially a file storage application which will allow users to visualise and manage their files stored across the SAFE Network.
In the next few weeks a Minimum Viable Product (MVP) should be released and publicly available to be tested. We should begin to to see our internally developed and third-party applications become tangible and planning begin for a sprint to implement Safecoin into the network. From a personal perspective I shall endeavour to make these less technical blog updates a regular occurrence and as always your feedback and comments are very welcome.
Until next time…
