First, here’s an update on the status of the Alpha 1 network. As most of you know, it has been running nonstop since August 12, 2016, the date we released it. It’s been very stable over the last few months. It’s only a few days ago that we started noticing issues with it, such as the inability to login to some accounts, and to access some .safenet websites that had been previously created. The alpha network still works fine (e.g. you can create a new account and upload a new .safenet website), but you probably won’t be able to access accounts and websites created before last week.
@AndreasF explained what happened in this post:
Yes, several virtual servers on which the alpha nodes were running had shut down. We knew that this could potentially cause data loss (which is why we didn’t allow users to run vaults in that network), and that is what happened, unfortunately. We restarted the nodes on the rebooted servers and the network structure seems to be fine again. We’ll keep the alpha network running for now, but we can’t restore the lost data.
We are planning to implement ways to even completely restart a network and republish the data it had, and once that is in place, we will be able to make the content survive such failures, and even persist it between different alpha networks.
Short-term roadmap
We’re currently working on getting Test 12 ready. This will allow users to run vaults from home. This test won’t contain the new client API (with mutable data). It’s purely about the features related to the routing update (disjoint sections and resource proof). If this test is successful, we will move right to Alpha 2. If Test 12 shows issues, we’ll patch them and maybe have another testnet before Alpha 2.
After that, we will have other testnets (e.g. Test 13) until we reach Alpha 3, which will give us vaults from home along with the new client API and the updated SAFE Browser (which integrates the SAFE Authenticator directly so you won’t have to download a separate app).
SAFE Authenticator & API
Team leader: Krishna
The authenticator is now functionally complete and it’s been integrated with the SAFE Browser as planned. This makes it easier for users to download just one binary that contains both the browser and the authenticator. We will continue to test and improve the authenticator in the following week.
We have also made decent progress with the SAFE Node.js API for app developers. There were a few issues we faced while integrating with the FFI. We are hoping to wrap the API by early next week and then we’ll integrate it with a demo app. There are minor changes being made in the FFI exposed by the safe_client_libs to address the segfaults and ownership related problems. The authenticator will also be updated to use the FFI of safe_client_libs once these changes are completed.
SAFE Client Libs
Team leader: Spandan
This week we’re addressing concerns from the front-end team. With the C API, they are sometimes finding it difficult to not cause segfaults. We are trying to make it easier for them, considering that front-end developers don’t necessarily have a C background. Instead of giving the ownership of all heap-allocated data to the front-end and asking them to free it when they want, we are making it more restrictive in that everything that we give them (C-structs/strings, etc.), we expect them to immediately clone into their native types. We will free stuff as soon as control reaches back to us and leaves scope. That way, given less choice and a more restrictive approach, memory management becomes very simple (especially for memory-managed languages such as JavaScript, Java, etc.).
We are also discussing how to approach error recovery during composite operations. For example, if authenticator revokes an app, it has to perform a bunch of operations including re-encryption of data previously accessible to the revoked app and if this fails midway (because connection was lost or the user ran out of allowed number of mutations, etc.) then how do we recover this the next time authenticator starts. Do we store the state somewhere locally or restart from step 0, etc. It might not be either this or that kind of approach and might need to be taken case by case.
Routing & Vault
Team leader: Andreas
We implemented a simple recovery mechanism to synchronise sections that lost consensus during heavy churn, which is currently in review: The nodes in a section will now exchange their routing tables a while after a churn event, and any node that doesn’t agree with the quorum will update its own routing table accordingly. (Before disjoint sections we had something similar—“bucket refresh”, which is used in the alpha network and the previous test networks—, but this wasn’t applicable to the new paradigm anymore.)
With safe_core updated to work with the current routing library, and resource proof nearing completion, we are now testing everything together on droplets, including disjoint sections and the recovery mechanism, to expose any remaining issues and to calibrate the resource proof parameters.
Recruitment
Gabriel Viganotti (@bochaco) is the newest member to join the MaidSafe team! He’ll be working remotely from Argentina. He’ll be part of Krishna’s team (SAFE Authenticator & API).
Gabriel has been very active in the SAFE Network community over the last few months. He developed a few applications such as SAFE Wallet and SAFE Faucet. He’s also the organizer of the SAFEdev Córdoba meetup.
He’s planning to continue working on his own apps in addition to the work he’ll be doing for MaidSafe 
?? Nice to hear you’ll be working for Maidsafe.
