Summary
Here are some of the main things to highlight this week:
- Last week the Routing team finished implementing Dynamic Membership and this week they started to focus on detecting and handling malice.
- @dugcampbell gave an interview to the new CyptoQuest podcast
Podcast. - We provided comments to the news website Verdict for a news article that investigated the viability of blockchain-based social media alternatives.
- @shriram2301 joined MaidSafe this week. He is based in the Chennai office and is working with the front-end team.
- We have a new Rust Engineer starting in the next few weeks based in Ayr.
Marketing
In amongst all of the marketing work in preparing for the releases leading up to the Alpha 3 Network over the next few months (much more to come on this, a recurring focus that we’ll be mentioning more than once in the coming weeks we suspect), there have been a couple of items about the SAFE Network this week. First up is an interview @dugcampbell gave to the new CyptoQuest podcast
Podcast. We also provided comments to the news website Verdict for a news article that investigated the viability of blockchain-based social media alternatives. And finally, @dugcampbell was the guest on a new episode of the Talking Cryptocurrency podcast - the recording should be released in a couple of weeks.
Recruitment
First of all, before the recruitment update, we would like to welcome @shriram2301 on board. @shriram2301 will be based in the Chennai office and will be working alongside @bochaco, @joshuef and @hunterlester. Welcome to the team 
Once again there has been a lot going on with recruitment and things have moved on nicely from last week’s update. Our new Dev Ops Engineer has confirmed he will be able to start work with us on October 22 in just over 2 weeks. @victoria is still working on the Software Test Engineer role and will hopefully be able to update on progress soon.
Last week @nicklambert and @victoria were busy conducting 1st stage interviews for the Marketing Strategist position. This week it has been the turn of @dugcampbell and Victoria to conduct 2nd stage interviews. We are hoping to be in a position to progress to final stage interviews in the next week and hopefully get the role filled soon
We have offered a candidate the role of Rust Engineer with the Routing Team and the candidate has accepted 
and even better they will be based here at HQ in Ayr. We are in the process at the moment of finalising details and will have more information for you next week.
There have been some internal changes this week with @nadia being promoted from Technical Executive Assistant to Project Manager - well done Nadia We are now recruiting for an Executive Assistant to replace Nadia.
As you know we are looking for a Network Engineer to join the Crust team and we have enlisted the help of the team in Chennai to find this elusive engineer. Over and above the Network Engineer role, the team in Chennai are looking to recruit an Assistant Manager to provide support to @krishna.
SAFE API & Apps
With the safe_app_java pull request in place and under review, we are putting together a tutorial to get developers started with creating apps for the SAFE Network. Along the way, we are identifying potential improvements in the API and implementing them.
A PR which will allow us to hide experimental APIs behind a flag has been recently reviewed and merged into the safe_app_nodejs repo. With this in place, we can now start merging the APIs we are experimenting with on the dev branch onto the master branch. The first function we will be trying to merge is a fetch API which can be used by applications to find data on the network from a URI, in the same way as the webFetch function, with the difference that instead of returning a compliant HTTP response with the data serialised, it returns an API object. As an example, when calling this function with a URI which references a MutableData location, a MutableData object is returned so all the MD API functions are available and can be used by the app to traverse its entries. We are thinking this will be useful for linked data applications which are intended to read and follow URI links.
SAFE Client Libs
We’re continuing to work on the SAFE Crypto improvements and integrations. While we have completed the SAFE Client Libs part, it still depends on other libraries which haven’t been completely integrated with SAFE Crypto yet, so while Crust and Routing are already done and available in their respective dev branches, some other fundamental libraries like Self-Encryption are not. @marcin has been working on fixing that and the PR for Self-Encryption is now complete and undergoing a review.
We have also discovered that while we provide support for attached signatures in the SAFE App Crypto API, they are not available in the SAFE Crypto implementation. However, as the front-end team really doesn’t use this API for any of their apps, we’ll not be adding that to the SAFE Crypto API but phasing it out from Client Libs instead because attached signatures provide little benefit over the detached ones. As this breaks the API on some level, app developers need to check if they use the sign or verify functions: they’re going to be switched to detached signatures in the upcoming Client Libs release.
Last but not least: the required changes in SAFE Crypto have been reviewed & merged and SAFE Crypto 0.5.0 was released.
Routing
Last week was an exciting week for the Routing team as we finished Dynamic Membership, the commits fixing the last few bugs and introducing the last integration tests were merged on Friday . This has allowed us to start soak testing the integration tests, yielding no failures so far after running the tests continually for a couple of days.
This week we started to focus on detecting and handling malice, something that’s crucial we correctly cover. Why is malice handling important? In a permissionless and decentralized network like SAFE, malicious agents are an unfortunate reality which needs to be accounted for. If a node is identified as malicious, it will be kicked out of the section and replaced with a new, hopefully honest node. This helps the network to be self-healing. The first set of PRs has already been merged, and more are on the way.
Crust
This week we kept testing the Service::connect_all() and probe_nat() functions as they allow us to collect miscellaneous connectivity information which is very important to us at this stage. We discovered some fundamental issues with the NAT probing function and fixed them. Also, at the same time we discovered some undesired behavior in both the p2p and Crust crates:
- We now make sure the connection bootstrap happens only over TCP (PR). We only bootstrap off directly accessible peers and in such case TCP should always be available. TCP is a lot more robust and reliable than uTP. So there’s no real motivation to use uTP for bootstrapping.
- The p2p crate was doing some redundant work: along with the hole punched connections it was attempting direct connections too. This functionality is already implemented in Crust and we want to keep the p2p crate solely responsible for hole punching. As a result, a lot of code was removed. This makes it easier to reason about the p2p behavior and the code got simpler
Extensive internal testing revealed some bugs in connect_all(): direct incoming connections were never properly accepted. This is now fixed but we need to do more testing to be sure
In parallel, we have been working on a test based on the older p2p crate implementation. The old implementation serves as a good benchmark for the NAT traversal: it should help us to uncover lurking regressions and bugs in the dev version of Crust in case there are more of them. With data collected from both clients, we can be certain that if the results differ then there is a high probability of a bug needing a fix. So far, we’re seeing a higher percentage of hole punching successes with the client based on the old p2p crate version. We’ll keep investigating and trying to understand the discrepancy between the statistics.
