Summary
Here are some of the main things to highlight this week:
- MAID coin is listed on the Bitker exchange.
- This week’s SAFE Buzz video is with @lionel.faber all the way from our Chennai office.
- The safe_auth CLI receives some new features.
- SAFE Client Libs continue to make API improvements such as managing and revoking a user’s apps and adding a new
runmethod, as well as a move to a stable Rust. - The final issues for PARSEC are nearly completed and the team are working on node ageing and message relay.
Marketing
First up this week, the biggest news is the MaidSafeCoin listing this morning on the Bitker Exchange. The exchange, based in Singapore, now has MAID/BTC, MAID/ETH and MAID/USDT pairs available and we’re delighted the community now has further options when it comes to exchanges that are available. Bitker have confirmed they charge 0% on deposits into the exchange and charge 0.1% commission on all trades with a small charge on any coins withdrawn (currently 3 MAID per withdrawal but we’d advise you to confirm this yourself).
We also released a new SAFE Buzz video. Slightly different set-up on this one as this week we’ve crossed continents and spoken to @lionel.faber, one of our developers based in our Chennai office in India. Hope you enjoy this one - you’ll find out how Lionel came to join the team and get the low-down on his exciting new role.
Next, we’re looking to crowdsource some inspiration from the community! Hopefully you’ve seen this week’s edition of our regular Wednesday tweetstorm covering a few of the key stories each week that we think might be interesting and relevant to the folk that choose to follow the MaidSafe Twitter account. However, we’re still working out what to call it (and need a short, relevant hashtag as well) - so please do let us know if you have any inspiration on this front!
SAFE API & Apps
As we get ready for the next release of the SAFE Browser, we’re also in the midst of a push to upgrade electron from v2 to v4. These changes should make subsequent major version upgrades easier, with the goal of keeping up with Chromium releases. The next crucial step we’ve been working on in parallel is replacing webview with BrowserView, as recommended by the Chromium team for increased stability and security.
A new feature was recently added to the safe_auth CLI, this time to allow the use of either a config file, or environment variables (SAFE_AUTH_SECRET and SAFE_AUTH_PASSWORD), to read the SAFE account credentials from, so the user doesn’t need to type them in each time the CLI is executed. This should also allow the safe_auth CLI to be easily integrated with other tools or applications.
Another feature being finalised for safe_auth CLI (which is currently in review) is to prompt the user every time an authorisation request is received, either allow or deny, just like the popup shown to the user by Authenticator in the SAFE Browser. This will happen for all incoming authorisation requests received both as part of the command line argument or as a GET request from the webservice. However, an argument could also be provided to have the safe_auth CLI automatically allow them all without querying the user, which again is analogous to the functionality provided by the SAFE Browser Authenticator when its padlock is unlocked.
SAFE Client Libs
This week we’ve been continuing the work on the front of Rust API improvements for SAFE Client Libs. We’ve merged a pull request from @lionel.faber that introduced non-breaking changes to the Authenticator API, adding Rust functions to manage and revoke user’s apps.
We’ve also merged another pull request with further improvements to the Rust API: adding a new run method which allows interacting with the network in a simpler way. It encapsulates a common idiom found in Rust programs: blocking on an asynchronous operation and sending a result through an MPSC channel. It should make writing simple apps in Rust more straightforward. We intend to continue with these changes, making our APIs more approachable and better documented.
Another small change is the move to a stable Rust in SAFE Client Libs. Now it doesn’t fail with the latest compiler versions, and this change also paves the way for moving to the latest Rust edition (2018). We plan on updating SAFE Client Libs to latest changes in the language and soon we’ll release a new version with all the latest changes.
In other news, @marcin is taking a one month holiday, but with the new team members we expect to continue with full steam ahead.
Routing
The work in PARSEC has been winding down this week. We improved the performance of the code when malice detection is enabled, we also have a PR up that will add tests for the recently introduced Requesting/Request/Response pattern.
With these final issues being addressed, PARSEC is reaching the point where we are ready to call it good for Fleming, so the PARSEC and Fleming subteams have been merging back into a single Routing team over the past week, which means that our efforts are now focussed on bringing Routing up to speed.
On one side, we are preparing for the Node Ageing implementation. Work is ongoing in documenting and modelling the flows we are planning to have once Node Ageing is implemented. In order not to couple these models with Routing itself too tightly, we extracted a separate crate for this purpose. A rendered version of the current design of the flow is available here.
On the other side of preparations for Node Ageing, we decided to leverage the state machine we have in Routing to make the code cleaner. This state machine reflects the role of a node in the Network at various stages in its lifetime. Every node begins in the Bootstrapping state. If it’s intended to be a Client, it then transitions into the Client state. If it should be a full Routing node, it transitions to JoiningNode, and then into Node. This last state was so far a catch-all for everything that happens after a node contacts a particular section: the resource proof, the initial relocation, all of it happened with the node being in state Node. The current effort aims to refactor that state into multiple ones, and a PR is already up for the first one of such new states.
In adition to the work on Node Ageing, the Routing team are also working on a new Message Relay scheme. The attempt to replace the Ack-timeout model with N/3-to-N/3 model (described in a recent Dev Update) uncovered multiple issues related to nodes not being in sync. The previous model was masking these problems with timeouts - if some nodes were lagging and failed to pass the message, they had time to catch up before the sender would try again. This isn’t happening in the new model and we are looking for ways to fix it.
Last but not least, we would like to give a shout out to @oetyng for his huge contribution to the issue of naming in Routing! He took the time to share some very thoughtful and excellent feedback on naming inconsistencies in our routing code: Thoughts about naming and structure in SAFENetwork libraries. - General - Safe Dev Forum. Well worth a read for anyone interested in good software engineering practices. We are not forgetting about it - you can be sure that we will take action on this as soon as we can allocate the time 
Crust/Quic-p2p
We have been continuing to stabilise the networking library that uses the QUIC protocol, which has been renamed to quic-p2p now. We’re working on improving the API and want to increase the test coverage to confirm it works as expected in different conditions and scenarios, including the malicious behaviour of clients. Also the bootstrapping functionality remained so we are completing that as well.
At this point we should also keep in mind the quick response time inclusive of bug fixes by the quinn team without which it could have taken us much longer to get to the kind of stability we have just now. They will soon be publishing all the work done (together with bug fixes) to crates.io as version 0.3.0
as always the magnificent 
