This week we have some new Android binaries (we’ve updated the binaries in the alpha-2 release on GitHub). This update has some new features such as a network opt-in auto reconnect on app resume (to test the reconnect feature, minimise the app and switch airplane mode on then off, wait for Internet connection to be reestablished and then switch back to the app) while the password fields enable a toggle to view credentials along with some minor UI changes. Also, the minimum supported version is now Android 4.1.2 (API 16). iOS device support has also now been integrated so devs should be able to test these applications on their devices, and we’re working on getting the apps through the application review process so community members will also be able to try these example on their iOS devices.
As we have mentioned in previous updates, we are looking to grow the number of developers in order to speed up development while also spreading the volume of work across the dev team while as part of our commercialisation strategy we also continue to recruit across non-technical roles. At present we have 6 opportunities available.
We’re happy to report that this week Rachit Dixit is joining Krishna’s team as a junior mobile app developer and we have another remote network engineer at the final stages of the interview process. We are also waiting on another network engineer (HQ based) to confirm his start date, and we have a dedicated digital marketer starting work from our new office (more on that in a moment) on the 23rd of October. All things going well our team will have grown to 26 by the end of this month. Of course, the aim is not just to increase numbers, but to improve the average capability of the team and with a much more robust recruitment process in place, this is something we remain focussed on.
As work continues in earnest across the various layers of the network and Client, the operations department has been busy planning MaidSafe’s move to new offices. After around 7 years or so we are moving to an office in the nearby town of Ayr (pronounced ‘air’). It truly is the end of an era to move from what has sometimes unkindly been called the ‘hut in Troon’. As a former boat chandlery, it could be a little cold in the winter, but it has looked after us well and we have been very lucky to have such an accommodating landlord (cheers Shaun!) during our time in Troon.
The new office is modern and comfortable and we think it will be well suited to accommodating our growing local team while creating the right impression with business partners. The official move date is one week from today (12th October) and over the coming weeks, we will be putting the MaidSafe stamp on the interior by integrating our brand and making the workspace a home from home for the existing team, and another tool in our armory for attracting new recruits. We’ll include some pictures in next week’s update.
SAFE Authenticator & API
We are continuing the refactor work as explained last week. The email example application is being refactored to improve the readability of API usage by switching to async/await instead of promises. Along with that, we configured asar to reduce the size of the packaged app. Also, the reducer functions are being refactored as explained in MAID-2373.
We had a minor bugfix in the SAFE Browser (favicons in web pages were not loaded previously). We don’t have a test suite yet for complete testing of the browser. We only have a test suite for the backend of the browser. Hence, we have added a checklist to the browser repository for manual testing until we have a UI test suite integrated. The CI scripts are updated for automated packaging of the browser on version changes/tags. Signing the binaries and also automatically packaging the browser with mock-routing is being discussed within the team. The test cases for the DOM APIs have been improved and would serve as a good reference for devs too.
safe_app_nodejs clears the handles when the objects are garbage collected. We did perform tests to confirm that the objects are cleared as expected. We have added a few basic examples to demonstrate the Node.js API usage using the test feature, where devs can run these examples without needing the authenticator. The instructions are detailed in the README of the examples in safe_app_nodejs. We will keep expanding the examples as we move forward.
SAFE Client Libs
Earlier this week, we finally merged the dev branch to master. From now on, we’ll be continuing all current development on the master branch. This makes the current FFI API incompatible with the Alpha 2 release, and we understand that it might break some of the existing apps. However, we strive to make the magnitude of these changes minimal: it is not as big as the transition from Alpha 1 to Alpha 2 was.
The recent and upcoming improvements are about refactoring rather than structural changes: for example, we’re replacing superfluous functions with value types, so that instead of calling e.g. mdata_permission_set_is_allowed you’ll just look up a field in the PermissionSet structure. The same idea applies to the MDataInfo type: now we just have structures instead of returning opaque pointers, so you can just look up mdata_info.xor_name without going a complicated route of extracting the type tag and name of a Mutable Data object with mdata_info_extract_name_and_type_tag. Further, we simplified enumeration functions, such as mdata_keys_for_each: now, instead of having two callbacks (which are called for each item and at the end of the keys sequence respectively), we just return a pointer to the entire list of keys. Soon, we’re going to replace all pointers in input and output parameters with value types. It will make the API less confusing in regard to dealing with memory management and copying of values. For now, to make the memory management simpler for the front-end side, we expect them to copy all output values and hand them over to e.g. a garbage collector. This approach is not too efficient and obvious, so by moving from pointers to Rust-allocated memory we intend to make the copying implicit in most of the cases. Overall, we hope that these changes will make the API more optimised, understandable, and simple to use, and we’re preparing a complete list of API changes to simplify the transition for the existing apps.
We added support in the SAFE Client Libs for setting configuration options through config files. We deprecated the SAFE_MEMORY_STORE environment variable, replacing it with the dev option mock_in_memory_storage, and added a new option which wasn’t there before: mock_unlimited_mutations, which turns off the limit on mutations in the mock vault. We stopped prepending schemes to URIs so that the SAFE Client Libs are decoupled from the URI scheme and only concern themselves with payload encoding/decoding. This PR also removed padding so that we no longer need special handling for URIs on mobile devices. Another change in the API is the removal of the mdata_change_owner FFI function, which was confusing, as currently apps cannot change the owner of a Mutable Data object and have no way to request that from the owners themselves, as some of the developers have noticed. This problem is connected to the multi-ownership/multi-sig feature, which is not currently implemented as well because for now we can request the owners’ signatures only out-of-band and it’s not yet clear how we should do that in a more automatic way. We intend to address both of these problems in the future.
Lastly, we merged fixes for bugs in the app revocation code. These bugs were found out during soak testing (running the test suite many times over) and fixed thanks to a change which made test runs deterministically. @adam also fixed a rare test failure (also found during the soak testing) caused by a mistake in the test itself.
Routing, Vault & Crust
Routing efforts are still focused on developing a secure mechanism for passing messages between sections. We keep hitting issues with every proposal that is being put forth, but we are constantly working on finding new solutions to every problem that pops up.
As mentioned in the previous update, we’ve been gradually rebasing Crust on the Tokio crate, which will allow us to use futures in the networking code. This will make the existing code cleaner and simplify our work on upcoming features (which include the uTP protocol integration). We’re steadily progressing with this huge refactoring. The current progress can be tracked in this code branch.
things are moving forward in a lot of ways at the same time 
no secret there, as many of the 
only kidding of course. The new space is well deserved and sounds like it is a strategic move that will garner some good interest from the right people. Always thinking 