Here are some of the main things to highlight this week:
- The Marketing team created a new topic to start a discussion about how to support the various meetups that have appeared across the globe.
- We are delighted to announce that we have filled the UI/UX Designer role. Jim Collinson (@JimCollinson) will be joining the team and our Ayr HQ.
- Work on the C# bindings has been shaping up well. The auto-generated bindings are integrated with the work in progress code and now the tests are passing on all platforms (core, framework, Android & iOS).
- The Routing team has been picking off tasks from Jira for Milestone 1 of DataChains and making reasonable progress. They’re still very much in the realms of getting the raw building blocks coded and unit tested, but they’ll soon be moving on to the more complex integration tests.
- This week, the Crust team made the final changes related to encryption. They are still going through the review process, but apart from that everything seems to be functioning ok.
We’ve spent time over the past few weeks thinking further about how to support the various meetups that have appeared across the globe. We shared our thoughts in a post this week. If you’re interested in meeting fellow SAFE Network afficionados in person, please do comment there and let the community know where you’re based. We’re keen to coordinate the support between the groups, including hosting regular calls for meetup organisers to share resources where this would be helpful. If anyone is interested in becoming an organiser for a local meetup group, contact @dugcampbell or send an email to email@example.com.
SAFE DevCon 2018 Update
We’ve now got back to everyone who applied to attend DevCon this year which means that people can book their travel. The draft agenda for the day is shaping up - including a keynote from David and presentations from various developers in the community, together with talks on Routing, UI/UX and community building, amongst other topics. We’ll share the final Agenda once we have it. Finally, we’re happy to say that it looks like we may be able to add a few more attendees to the event - so if you’re interested in coming along, please get in touch (firstname.lastname@example.org).
The new maidsafe.net website is currently in the design phase and we’re looking forward to seeing the output of the agency’s work. More to follow.
Out and About
We have made some really good progress in recent weeks in growing the team and we’re happy to report that this success has continued, in no small part to the efforts of @victoria. One of the roles that we have been struggling with was the UI/UX Designer but we’re now delighted to confirm that Jim Collinson (@JimCollinson) will be joining the team and our Ayr HQ. We’ll let Jim introduce himself to you all when he starts with us in mid-April, just one week before DevCon - great timing Jim!
SAFE Authenticator & API
We are working on a simple WebRTC signalling example application. This is something we had from before (see this dev update) and this is merely an update of the integration APIs to showcase the same things as the previous example. We were hoping to release it today but we noticed a few bugs that need to be fixed. The purpose of this example is to demonstrate secure signalling of WebRTC on the SAFE Network. In this example, the signalling server is replaced with the SAFE Network for enabling exchange of connection information between peers. After successful exchange of connection information, the peers connect through a STUN or TURN server. Please do note that we rely on external servers for STUN and TURN protocols. We will be able to get the support for these in the CRUST layer eventually and at that point we can remove the external dependencies.
A refactor for some of Peruse’ internal network functionality has been underway in the last week and is going well. This has involved moving app functionality to a newly created Electron background process, where all intensive network functionality should eventually reside. This is a precursor to some of the UX enhancements and should help improve app responsiveness as we move work to this process.
An internal refactor to safe_app_nodejs has been made around the way we handle errors not only coming from the safe_app lib but also the ones generated at the safe_app_nodejs layer itself. This included the incorporation of error codes to each of the errors reported from safe_app_nodejs in a different range than the one used by the safe_app lib error codes.
In addition to this, we are now able to resume on the work to add a couple of binding functions to safe_app_nodejs and the DOM API which was blocked by an issue that we now were able to resolve. One of these functions allows an app to read the set of permissions granted straight from the authorisation URI without the need to connect with it beforehand. The other function is to allow an app to be able to read the number of mutations done and available for the account.
Work on the C# bindings has been shaping up well. The auto-generated bindings are integrated with the work in progress code and now the tests are passing on all platforms (core, framework, Android & iOS). Safe Authenticator on Android is the first app that is being updated to use these WIP bindings for testing. The Messaging app on Android will be updated next to test the application and the authentication flow between the messaging app and the authenticator. Once the apps are confirmed to be working as expected the WIP code will be merged with the upstream code.
SAFE Client Libs
In a previous refactoring task, MAID-2364, we simplified several iterator functions in our API to return entire vectors of data structures at once, rather than iteratively. When doing so we forgot to refactor one such
mdata_entries_for_each, which we have now refactored to
mdata_list_entries as per task MAID-2523. The result is a more consistent and easier-to-use API.
We also found and fixed a panic in the
test_create_app_with_access function which was occurring when passing in an
AuthReq object containing an invalid container name. In addition, we are returning a more descriptive error variant in this case named
NoSuchContainer, as opposed to
Unexpected. The PR is currently under review.
We’ve also started to update our crates to the latest stable Rust compiler version (1.24.0), which was released a week ago. It should bring some benefits like incremental compilation that should shorten time spent waiting on builds and increase the productivity. However, this process might take some time as we have to be careful about it: crates need to be updated one-by-one, starting from ones with the smallest number of dependencies, like e.g. config_file_handler.
Routing & Crust
In Routing this week, we’ve been picking off tasks from Jira for Milestone 1 of DataChains and making reasonable progress. We expected many of these to need to be tweaked as we progressed through them, and indeed that has been the case. But happily, there haven’t been any major hiccups on the road so far. We’re still very much in the realms of getting the raw building blocks coded and unit tested, but we’ll soon be moving on to the more complex integration tests where these new parts need to get
hammered elegantly woven into the existing Routing structures before we can tidy things up as we move through the later milestones.
Our policy of having at least two reviewers for each pull request to Routing is paying dividends too as this inevitably leads to discussions and further improvements to the overall team knowledge and to the quality of the code and tests being produced. As for the test-driven development approach; the jury’s still out… there don’t seem to be any significant wins using this approach, but neither has it made things worse.
In Crust this week, we made the final changes related to encryption. They are still going through the review process, which usually takes about a day to finalize, but apart from that everything seems to be functioning ok. Also, we put a lot of man-hours into our network simulator library. We’ve been reverting the smoltcp integration. smoltcp has a TCP/IP stack implementation, which we, as dedicated engineers, strived to reuse, but eventually it turned out to bring more work than actual value. smoltcp offers zero heap allocations while building/parsing network packets which is well suited for embedded systems with tight memory restrictions. Unfortunately, this comes at the cost of ergonomics and in our case memory is not an issue since this is a testing library. So we ended up implementing the TCP/IP stack on our own.