Today we finally moved out of Troon to the nearby town of Ayr. The move has consumed a lot of the operations teams time over the past few weeks, but fortunately we have been able to minimise the disruption to the engineering team. As promised last week, here are some pictures of the exterior. Over the coming weeks/months, we will be customising the interior and making it more our own.
It has also been a busy week in development, we just released an initial version of the safe_app CSharp Library. The first version has been published on NuGet and the safe_mobile repo has been updated, so the SafeMessages app uses this package now. This makes it simple for people creating mobile apps as all they need is a dependency to this package and the authenticator and they should be good to start building for mobile right now.
It’s worth noting that the safe_app CSharp library lists specific TODO points that are our current highest priorities as this is by no means a feature complete package for Alpha 2 integration.
SAFE Authenticator & API
The openUri API in safe_app_nodejs had a cross-platform issue and we were relying on Electron’s shell.openExternal API during the development of Alpha 2 applications. We have resolved this issue and tested across all platforms.
Another issue that we were working on during the last few days was related to the URI scheme registration. Up until now, it was needed to package the browser every time we had to test the authenticator integration since the URI scheme wasn’t properly registered when running the browser in dev-mode, i.e. with yarn start. This was time-consuming and solving it was a bit more challenging than expected as we encountered different types of issues in each of the platforms. This should make it much easier for devs to test changes in the browser and plugins as the packaging step can be skipped during the development process.
@hunter has been refactoring the email app to simplify the code mainly by the use of async/await functions, and the PRs reviews are ongoing along with internal testing to ensure the app is as stable as before the refactoring. We are also adding more inline documentation to the example apps, to make it easier for devs to understand the design.
@shankar has resumed his work this week and has ported the Web Hosting Manager app to Electron Forge and SASS in order to use consistent tools across the apps. We are refactoring the Web Hosting Manager app in an analogous way to the refactoring made in the email app.
@joshuef is looking into options to scale the safe_browser to improve efficiency. This is still in the early stages and we will share a detailed plan once we have one in place.
@srini created a set of standalone Node.js example apps which make use of mock routing and the loginForTest testing function to demonstrate the @maidsafe/safe-node-app API usage. The loginForTest function creates a client app without sending authorisation requests to the Authenticator and allows running these samples as standalone targets, which should be helpful to learn about the safe_app Node.js API. Details of how to run these example apps can be found in this README file.
Web examples were being requested by community members; @srini has started working on a simple web example, a Disqus-like comments plugin which can be integrated into any web page.
@Rachit has joined the team this week. He is getting bootstrapped to the SAFE Network, he will be reviving the Java safe_app API soon. JNI integration using SWIG is being proposed for speed and ease of integration. More details in the next section 
SAFE Client Libs
Automatic generation of language bindings has been the focus this week. We’re considering using SWIG for this purpose: it is a tool that is commonly used to automatically generate interfaces for a wide variety of languages ranging from Java to Python, based on C headers. Currently, our primary targets are the common mobile development languages, Java and C# via SWIG (Obj-C/Swift will likely not even require a SWIG layer), but in the future we’re aiming at having more languages in our toolset, including community-supported ports.
We are still considering several other options and weighing the trade-offs, as we are balancing between providing the best possible user-facing API and saving on development time. One of the options is to use a SWIG feature called type maps, using which we can get the most idiomatic, automatically generated Java API, but at the same time it has a disadvantage of being tightly coupled with JNI, the Java binding interface - in practice this means that we can’t reuse the same SWIG interface for other languages and we need a lot of time to delve into language implementations to generate the best possible idiomatic APIs. Another option is to base APIs on a SWIG feature called directors, which provide the easiest automated way to generate bindings, and it is a recommended approach. But we are seeing some issues with it: the resulting APIs might not feel “native” to a particular language, and we want to get easy-to-use well-documented interfaces. That’s why we are also considering a third option, to code the bindings manually, which is a kind of a last resort. In general, our research progresses well, and the current progress and proof-of-concepts can be tracked in this repository.
Continuing our work on updating the API, we replaced all network-events callbacks in safe_authenticator and safe_app with a simpler callback, o_disconnect_notifier_cb, which signals that a disconnect occurred when called. This is a consequence of a previous simplification in the callbacks, when we removed the automatic reconnection (making the front-end responsible for this), effectively making the notification about the Connected state unnecessary. After long internal discussions, we ultimately decided to discontinue the use of value-type structs (namely, PermissionSet) in our function signatures. Value-type structs would hinder our options in generating the best possible SWIG bindings - e.g. see the “5.4 Other Practicalities” section in the documentation. Additionally, using pointers for all struct types is a more accepted C/C++ convention.
Routing, Vault & Crust
Routing efforts this week were still focused on secure message passing and resolving possible issues with it. We identified certain limitations and did some simulations to estimate their severity. Node Ageing and other features certainly influence such discussions quite a bit compared to just the code in the master branch. Apart from that, we are about to start discussions related to the implementation for the first part of Data Chains, which we are calling the “Section Graph”.
We are continuing to port Crust over to use Rust’s Tokio and futures libraries. The implementation side of things is almost done, though the code still needs to be reviewed, tested and battle-hardened. For those interested, the work-in-progress implementation can be found here. Once this refactor is finished we will be able to integrate our Tokio-based uTP library and have a Crust which runs over both TCP and UDP.
We will be branding it up with SAFE network and MaidSafe branding.
