Summary
Here are some of the main things to highlight this week:
- We have been working on delivering and running a test of Crust that should help us to see how the NAT traversal works for different people using all kinds of operating systems in a variety of cities, countries, and continents. So far we have been running this test internally at the company, with some encouraging results: 75% of connections are successful. Further to some tweaks and bug fixing we will be looking for your help to run a public test in the very near future!
- Hereâs a sneak peak at what weâre building to support the tests. Have a poke about, and kick the tyres of the evolving frontend UX prototype of the Crust Testnet analytics dashboard.
- @goindeep has posted a really good article titled âThe Problem with MoneyâŚOnlineâ to the SAFE Network publication on Medium. Have a read⌠give it some claps!
- We had an internal review of the progress that has been made on a PoC for XOR URLs we started working on a few weeks ago. We recorded this meeting and we are happy to share it with you all.
- For those whoâve been digging into the APIs (or maybe those whoâve been put off by some complexity), thereâs a preRFC on API improvements/additions over on the Dev Forum, where eyeballs and ideas would be greatly appreciated.
- We got the Malice in PARSEC RFC agreed and added to the GitHub repo.
Marketing
Weâve been busy bees again this week with a few things to update you onâŚ
Big news is the internal (meaning internal to the company and including all remote members of the team) Crust test we have been running. Broadly speaking we saw around 75% of nodes successfully connect via hole punching. While this very early result is really encouraging the sample size is very small and further to some tweaks and bug fixing we will be looking for your help to run a public test in the very near future! For the remaining 25% it will still be possible to port forward to connect. Great to see the hard work of @ustulation and @povilasb pay off, so we can almost forgive Povilas for daring to take a holiday 
(seriously though great job guys!)
This represents the start of several releases that weâll be making as we roll out Alpha 3 and we will keep you updated each step of the way via a series of posts and articles. Each will focus on a different feature(s), and at times will accompany new pieces of software for you to get your hands dirty with.
As you may be aware, Crust is a critical part not only of Alpha 3, but also to our vision of the decentralised web as it enables users, in a very non-technical plug and play way, to join the network with commodity PCs from behind home routers. @dirvine recently highlighted how important this layer is with one of his customary and very colourful explanations when asked how fundamental Crust was within the network ââŚyou wouldnât build a skyscraper on sand, would youâ!
Our approach to a decentralised network is clearly distinct from all other projects for whom a decentralised web means running servers from home and/or going through the complexities and risks of configuring a home Router. Their approach is not wrong, it is just a different approach which can sometimes become blurred in the marketing noise of ICOs and YouTube interviews. But when one of your objectives is to build a new fully inclusive and secure web, then we believe our technology is better suited.
It is important to note that the entire MaidSafe team have been contributing towards Alpha 3 which is something that has not always happened given the diversity of roles here at MaidSafe. Great to see even the HR, Finance and Admin peeps all involved in Crust testing!
We got the Malice in PARSEC RFC agreed and added to the GitHub repo. While weâre discussing RFCs itâs probably best to highlight that currently weâre looking to focus on critical-path RFC items where possible so the team arenât distracted away from their work on Alpha 3 features.
We will be seeing a few more RFCs being published soon to kick the tyres of some new planned features. @Joshuef is already working on a DNS RFC which is soon to drop, and a Web ID RFC after that, along with others from the back end team.
We would like to take this opportunity to shout out to @mav, @neo, @happybeing, @jlpell, @draw and others who are extremely generous with their time and really engage in the RFC process. The community is surely much stronger for having you guys involved.
@pierrechevalier83 attended the second London meet-up on Wednesday at the Flying Horse pub. Thanks to Oscar (@opacey) for taking command here. It looks to have went really well with community superstar @JPL even doing an impromptu SAFE Network demo!
Read Oscarâs summary of what was covered here.
Last weekend @dugcampbell gave a talk to the Modern Heroes Conference in Italy entitled âThe Internet is Broken: Welcome to the SAFE Networkâ. The conference was a good opportunity to get exposure to many different influencers so we were glad that Dug could represent the SAFE community.
Very pleased to see one of our forum regulars (@goindeep) has posted a really good article titled âThe Problem with MoneyâŚOnlineâ to the SAFE Network publication on Medium. Have a read⌠give it some claps!
Recruitment
Since the last recruitment update there has been a lot going on. At the end of August we had offered a candidate the role of Dev Ops Engineer, however, the applicant decided to accept a role closer to home taking us back to square one in the recruitment process. We have been busy trying to find a replacement for this role which has not been an easy task. We are however excited to announce that we found another candidate who really impressed @StephenC and @ustulation. The candidate has been offered the role and accepted (watch this space for more information). @StephenC is delighted to have an additional member to his team and hasnât stopped smiling since he heard the news the candidate accepted :). Now that we have successfully filled the Dev Ops Engineer role, Victoria will be switching her attention back to the other role for Stephenâs team which is the Software Test Engineer position.
@nicklambert and @victoria have been kept busy interviewing potential applicants for the Marketing Strategist position this week. We have met some really interesting candidates so far, each bringing something unique to the table. These interviews will continue this week and we hope to progress to the next stage shortly - tune in next week for more information.
The other role we are recruiting for at present and probably the most important is that of a Network Engineer to join the wonderful @povilasb in the Crust team. Adding an additional body to the team to work alongside Povilas will enable us to ensure the library is moving towards its strategic aims of being fully asynchronous, with less dependencies and providing greater platform coverage.
Recruitment will be making a regular appearance on the dev updates going forward to keep you up to date with all the goings on.
User Experience
What a fun week. Full speed, hands dirty, pixel smithing. Itâs all about the Crust Testnet that youâll soon be able to get up close and personal with, helping us punch a few holes from all corners of the globe.
But how do we make the results and data produced by this test as useful and meaningful as possible? Sure everyone loves digesting raw log files before bed, but to make things really fly we need a dashboard to slice, dice and analyse.
So hereâs a sneak peek at what weâre building to support the tests. Have a poke about the evolving frontend UX prototype of the Crust Testnet analytics dashboard.
Questions and critique welcome. You know what to do.
SAFE API & Apps
Now that the major issues with safe_app_java have been resolved, we have raised a pull request to get these fixes upstream. With the CI passing and the code under review, we are putting together a sample Android application that demonstrates the safe_app APIs on mobile. In parallel, we are also working on the getting started guide for developing Java/Android apps for SAFE Network.
We started working on having all the experimental APIs be exposed only when a specific flag/argument is set, and hide them by default. We are planning to implement this on both the safe-app-nodejs package and the SAFE Browser. The idea is that after having such a feature in the safe-app-nodejs package, the SAFE Browser should be able to expose a switch in the UI to enable the experimental APIs, and/or even experimental browser features.
We continued working on fixing some issues in the SAFE Browser towards having a new release in the next few weeks. Apart from whatâs mentioned above about the flag for experimental APIs/features, we are focusing on further stabilising it now, as we see the community has been actively using it and a few bugs were reported, which we really appreciate.
In addition to this, as many of you may remember, we shared a post a few weeks ago about a proposal related to how to share data through URLs without the need to use public names, i.e. by simply sharing a URL which contains the information needed to fetch the data from any location on the network (which we started calling XOR URLs). This week we had an internal review of the progress that has been made on a PoC we started working on since then, that we recorded and that we are happy to share with you all.
The recording is just a meeting in which we review some scenarios where the XOR URLs would be used, and how they open up possibilities for other things we believe will make a difference, and allow users to browse native linked data. We hope this shows what the vision is and how we are proposing to move forward with these specific aspects of the network. Please note we had an issue and @hunterlesterâs voice was not recorded, but we are still sharing the recording as is, since the answers to his questions should let you know what the questions were. The following are screenshots of some of the things we reviewed during that meeting:
Finally, for those whoâve been digging into the APIs (or maybe those whoâve been put off by some complexity), thereâs a preRFC on API improvements/additions over on the Dev Forum, where eyeballs and ideas would be greatly appreciated.
SAFE Client Libs
This week we finished integrating SAFE Crypto into SAFE Core (MAID-2725) and we have been working to replace Rust Sodium in SAFE Authenticator and SAFE App with SAFE Crypto (MAID-2726). The work is actually finished, but a single test has started to fail and required investigation. In addition, we finished adding new required functionality to SAFE Crypto, having the PRs reviewed on GitHub, and responding to review comments.
Routing
As expected, our focus has continued to be testing of dynamic membership in PARSEC this week. We finished implementing the smaller functional tests for this part, and fixed the few minor issues in the production code that we detected last week.
As we have been writing more functional and integration tests, we found opportunities to improve the testing framework.
That work has now been completed too and creating future functional and integration tests will become somewhat simpler and produce higher quality tests.
Work has also gone into larger integration tests for peer addition and removal, and these have begun to bear fruit in that we have identified a couple new issues in the production code. Weâve already addressed these issues. The integration tests have been written and are being reviewed. We expect to reach feature completion on the dynamic membership part of milestone 2 soon. This will be followed by a longer period of soak testing where we hope to catch any outliers before being able to call these features âproduction readyâ.
As anticipated last week, weâve managed to make some parallel progress on the next main batch of work; namely handling malice within PARSEC. A couple of tasks involving the detection and handling of incorrect Genesis blocks have been tackled.
We also had discussions on some key aspects of the upcoming tasks. These discussions lead us to notice the need to adjust the way we handle meta-voting in preparation for detecting gossip from invalid creators. Work has begun on that task also.
Next week, we expect to make progress on malice detection. There is a lot of work to be done there, as you can see by reading the RFC so this should keep us busy for a little while. Onward and upward!
Crust
Povilas is also finally back from vacation and working full speed. This week, we have been working on delivering and running a test of Crust that should help us to see how the NAT traversal works for different people using all kinds of operating systems in a variety of cities, countries and continents. Nikita volunteered to develop the Crust client and proxy apps, both Rust CLIs and in collaboration with the rest of the team, has done a great job with a quick delivery of the same. The test works as follows: we have a proxy that runs on one of our droplets and clients have it as a hardcoded contact. Once clients are connected with the proxy, they send their connection information which is subsequently forwarded to other clients. With that information, the clients can attempt to connect with each other: once complete, they send the statistics to the proxy that are then aggregated and from which we can infer the percentage of successful connections. So far we have been running this test internally at the company, with some encouraging results: 75% of connections are successful. David Geddes managed to (not-so) secretly click Spandan, Stephen and Nikita, with Povilas on a Hangout, going through some test results:
Weâve also been extending the Crust and p2p crates to expose some connection related information to cater for the test weâve been running internally. Weâve updated the p2p crate to return detected NAT type during hole punching (PR) and public address (PR). Then we implemented a couple of helper methods in Crust: Service::probe_nat() and Service::connect_all(), which will allow to use Crust to build some diagnostics tools that collect useful information about misc connections: direct, hole punched, uTP, TCP, etc.
. Iâm saying nothing!
).