Welcome to the first dev update of 2018! Here are some of the main things to highlight this week:
- The Marketing team has published some high-level thoughts about what they are planning to focus on over the next few months.
- We are planning to archive the /r/maidsafe subreddit and focus our efforts on /r/safenetwork instead. See this forum post for more info.
- The front-end team will mainly focus on developing the new custom browser (Peruse). Only critical issues will be fixed in the SAFE Beaker Browser from now on.
- Weāre making good progress on the Java and C# bindings.
Marketing
As we move into 2018, weāre keen to provide greater visibility of our marketing activities to the community. As a result, where weāre able to share the details of those activities publicly, weāll be including a marketing section within the Thursday Dev Update moving forwards. In addition, weāve laid out our thoughts about marketing in general over the next few months at a high level in this forum post. But letās kick things off by looking at some of the work that is currently being carried out.
Although we updated the MaidSafe website to support the launch of Alpha 2 in September 2017, weāre now looking to change the site more substantially as we move onto the next stage of the project. As a result, weāre wrapping up the final stages of a bid process and weāve chosen a website development agency to work with going forwards. This will be a key focus in Q1 for us and weāll update you as we make progress.
Next up, whilst the Forum continues to grow successfully (almost 6000 members and 30 new members joining a day), thereās an argument that this has been to the detriment of the conversation taking place elsewhere at times. Weād like to focus on Reddit initially for a number of reasons, not least of which is the fact that itās readily accessible and used by a huge number of technology early-adopters. Weāve included more details around our reasoning in this forum post but to, put it simply, itās a way to introduce newcomers to the SAFE Network that is far more available (and perhaps less intimidating). We need to focus our collective attention on a single subreddit for the largest impact. Therefore, after taking on board all of the forum comments and a fair bit of discussion, weāre going to archive the r/maidsafe subreddit in favour of the r/safenetwork subreddit. Youāll still be able to read the old posts on r/maidsafe but it will be closed to new comments. There are good arguments on both sides but ultimately we believe that the network itself is the message. Either way, the most important thing is that people subscribe (as opposed to simply visit) to r/safenetwork. We want to do our part to build the Reddit community and discussion significantly - so please join us there!
Speaking of helping newcomers get to grips with the SAFE Network, weāre also excited to announce that weāre in the early stages of developing āThe SAFE Network Academyā. The Academy will be a series of courses built up over time that are open to all and explain the details of how the Network and Safecoin will function. With the help of members of the community who are keen to get involved, weāll share more details in the coming weeks.
Improved resources and explanations that are coming soon will all help to support our plan to expand the availability of MaidSafeCoin across a number of new exchanges in the coming year. Although we know that financial gain is not the primary motivation for many within the community, itās still crucial to ensure that MaidSafeCoin retains its visibility - if only because it is a great way to attract the interest of developers who will help to spread the message. Again, weāre hoping to have some news to share on this front very soon.
Finally, following the successful relaunch of the Community Engagement Program before Christmas, we are also excited to see four strong proposals in response to our Request for Proposals for an animated Safecoin video. The CEP allows us to match the diverse skillset of the community with SAFE Network projects and we hope to see it continue to grow in the coming months - itās great to see so many ideas for the next project already on the forum. Tomorrow we will open a week-long voting poll on the forum for the community to pick their favourite proposal. We look forward to having a community-led Safecoin video very soon.
SAFE Authenticator & API
In the last couple of weeks, we were working on an internal plan with the tasks we will be prioritising in the next few weeks. This plan includes not only some new features and enhancements to our front-end applications but also fixes for some of the issues reported by the community on GitHub. However, since we are trying to migrate to the new custom browser (Peruse), all issues that were reported against the SAFE Beaker Browser will be fixed/verified against the Peruse browser instead, and only critical issues will be fixed in the SAFE Beaker Browser from now on. As an example of this, we are trying to normalise the DOM API (in Peruse) since there are some functions which are returning ArrayBuffer objects instead of Uint8Array, creating an inconsistency in the API.
Weāve also been working on enhancing our system_uri and safe_app_nodejs libraries to support whitespaces in the path of the applicationsā executable.
@srini has been working on documenting the parts that are manually tested at the moment and eventually we plan to automate everything. As a start, the web hosting example app is being integrated with a test suite for testing the backend API integration. Then, we will do the same with the email app. @srini is also planning to extend the test scope to e2e for all the apps and make it a standard practice to follow the same for all the apps.
@shona and @shankar have started to focus on UI/UX, and as a first step, they are working on putting together a design system that will be useful to maintain a common standard for the applications. The next immediate focus is to work on planning and improving the UI/UX of the Peruse browser. With @joshuef starting next week, we hope to get things planned by then. It is very early to say what would be our approach in regards to rolling out these changes. We will get back next week with more information on this.
The Java bindings that were autogenerated had some issues to convert the structs across the FFI boundary and that was primarily because of improper naming conventions while the code was generated. @nbaksalyar was quick to spot it and has fixed it in safe_bindgen. The safe_app_java master branch is not yet updated with this fix, but this will likely be done after the C# bindings are updated.
There were a few issues with the C# bindings, which are now fixed by Adam. Work to expand the API scope in safe_app_csharp and cover the full functionality provided from Rust (similar to safe_app_nodejs) is currently ongoing and should be getting to upstream soon. However, we are also working on minor improvements in safe_app_csharp. The APIs are not tested yet and we will be expanding the scope of test cases. Once the C# implementation is complete, we will be updating the mobile apps for integration testing before we publish safe_app in NuGet.
Our web API playground now has an embedded text editor with syntax highlighting, bracket matching, and a vim toggle if you prefer those key bindings.
SAFE Client Libs
During the holidays we took advantage of the break and updated most of our crates to the latest stable Rust compiler version (1.22.1). This process was hindered by a bug that weāve discovered in Clippy, the automatic Rust code quality checker that we use for all of our projects. This bug resulted in the inability to update the higher-level projects in SAFE Client Libs and itās been reported and fixed upstream. Now weāre finalising the upgrade, publishing the newer versions of crates comprising the SAFE Client Libs and getting back to improving things in SAFE Client Libs further.
Meanwhile, @adam is wrapping up the work on the C# binding generator. The API team helped him to identify some bugs in the bindings which he promptly fixed. He also cleaned up the code and is expecting it to be merged into the master branch quite soon.
With chores being done, we are now focusing on releasing the bindings generator project which should be now available in the organisation repo. Weāre also continuing to tweak the SAFE Client Libs continuous integration scripts to make sure that bindings for all supported languages and platforms are automatically released with each successful build. This should streamline integration with the safe_app_java and safe_app_csharp projects.
Routing & Crust
During these past two weeks, we have been fleshing out the flows for merges, splits and secure message passing. We are happy to say that most of the work seems to have been done, but as always, the devil is in the details, so it will still take some time to finalise everything.
Big shoutout to @mav for continuing to post very valuable contributions! He is developing his set of simulations, which overtook our own (@bart is currently working on updating it properly so that we have two independent sources of data), and he created a very interesting proposal, which is being actively discussed. Thank you again, the whole team is greatly appreciating your efforts! 
At the end of 2017, uTP was finally integrated into Crust which brought us much excitement. Unfortunately, not much time was left for testing which brings us to where we are now. Rigorous testing revealed some bugs which can cause uTP rendezvous connects to fail. Though we are rapidly closing in on them and work is continuing in Crust to make uTP more reliable. We have also put a lot of work into expanding our testing, as well as general code cleanup. In addition, we upgraded the Rust compiler to the latest version at the time - 1.22.1. Also, note that the port used for local service discovery has been changed to 5483, which is LIVE on a mobile phone keypad - gives some flavour of meaning to those plain numbers
. Except no mention of data chains 
.
