Here are some of the main things to highlight this week:
- The Marketing team published a new blog post to highlight the upcoming SAFE DevCon in April.
- The front-end team continued discussions regarding UX enhancements for Peruse and the Authenticator.
- The Routing team started the implementation work of JIRA tasks for Milestone 1.
This week, we’ve been working with @joeri and Hypercube on the scripts for both the Safecoin and the Consensus videos. We’re pretty much at the final versions now and we look forward to moving onto receiving the storyboards for both during the next week.
Update on SAFE DevCon 2018
We also put out a blog post today (Medium link, claps gratefully received…) to highlight the upcoming SAFE DevCon in April. We’re still receiving applications from developers looking to attend and we’re hoping to be in a position to directly respond to each to confirm places around this time next week.
We’ve also been working on the wireframes for the new MaidSafe website this week. The process is continuing according to the schedule laid out and we’re looking forward to having something to share with you all in a few weeks’ time.
We’ve continued discussions in the last week regarding UX enhancements for Peruse and the Authenticator, and how to streamline those, as well as considering how these changes might play out with the apps internal design. We’ve reached some conclusions and have started tasks to set up application flows for the various network connections inside the browser (for notifications, app state changes, and also for the data that goes back and forth from the renderer and main processes when interacting with the SAFE Network), which are prerequisites for some of the coming UX enhancements.
Work on the safe_app_csharp bindings is progressing. We had issues while executing the test suite on Android. We have fixed it now and all the tests from the work in progress code are passing on desktop, iOS and Android. The apps are being updated to adapt to the new URL encoding schemes for data exchange between the authenticator and the apps. After testing end-to-end on mobile, we will be able to get the upstream master branch updated with these changes.
On the safe_app_nodejs front, we are putting some effort to have some additional validations for input parameters to be able to return more specific and explanatory errors. In most of the cases we just rely on the validations made by the underlying safe_app lib, this is why we are also trying to spot cases where we think the safe_app lib should make additional validations to the input params.
We’ve been also reviewing some edge cases for the authentication flow, to make sure we are covering some error scenarios, as well as to understand how we could support some additional features for the Authenticator in the future, e.g. being able to not only list and revoke applications, but block them and possibly revoke specific permissions rather than the whole application, similar to the way this is already possible with mobile operating systems. This is just an early stage analysis with a view to working toward an implemtation plan.
This week we noticed that a PR we once merged to update our API, namely to refactor and rename several
*_for_each functions, missed one such function:
mdata_entries_for_each. We have raised a JIRA task and will be getting this function updated and in line with the rest of the API.
We started the implementation work of JIRA tasks for Milestone 1. The tasks completed so far are mainly refactoring certain parts of Routing to create the required foundation for the upcoming new data chain features. For example, the
PublicId used by nodes and clients to identify themselves on the network has been changed to
PublicInfo to allow the inclusion of node ages within their identifiers.
Thanks to @tfa’s work of improving the simulator, a network with much larger size (over 580,000 sections with on average 25 nodes per section) can now be simulated. And the result shows a nice growing curve.
We’re making efforts to get caught up with a slight backlog of tasks relating to rust_sodium, our crate which provides bindings to the excellent cryptographic library libsodium. As well as our own project, there are a few other crates which depend on rust_sodium, and it crops up in the odd article, so there’s an even greater responsibility to get through these tasks. The most recent work other than a couple of trivial bugfixes has been to improve the build process. The ongoing effort is in updating the crate to use the latest version of libsodium. This is a fork of the excellent work by dnaq on GitHub who still supports and updates the original crate. We do hope dnaq merges our changes upstream at some time in the future and allow us to deprecate this crate whilst maintaining the Rust Sodium community from both crates. Open source is great for this and forks are fine but also merges back are really nice when a fork proves an approach is acceptable and useful. In the meantime, we are happy to support the wider community with this fork.
In Crust, we aim for fully encrypted communication between two peers: everything starting from the very first connection messages, even echo address request/responses will be encrypted. That requires some structural changes in both the p2p and Crust crates and we’re working through those at the moment. Last week we hit some regression - hole punched connections were broken. That was spotted and fixed quickly and covered by tests to avoid any future regression. Luckily Andrew has progressed network simulator to a usable state and we should have more integration style tests by the next week - yay! We also made hole punched connections more reliable: now the window in which two peers must contact each other is 2 minutes. So the upper layers, like Routing, have more time to instruct nodes to connect to each other.