Summary

Here are some of the main things to highlight this week:

Marketing

Plenty of material for you this week from the Marketing Team! First off, we want to welcome Ceilidh Gray (@Cgray) to the team as Marketing Strategist! She’ll be working alongside @dugcampbell, @SarahPentland and @DGeddes and has written a post to introduce herself to the community. We’re delighted to see Ceilidh start and we’re all looking forward to having an expanded team in place, ready for 2019!

As announced yesterday, we’ve just released a new video and blog post explaining how Dynamic Membership works with PARSEC as we move ever further down the road to SAFE-Fleming.

On the topic of videos, we released another weekly Dev Update video as well after last week - still a work in progress but improving each time, we hope you agree. With a larger team, we’ll be putting these out more regularly from the start of next year. And if you need even more of a reason to visit our YouTube channel, you might want to check out another couple of videos we released this week from the most recent SAFE Network: London meetup: a Crust interview with @ustulation and a talk by @pierrechevalier83 titled ‘Rust: Beyond the Language - An Ecosystem’.

The first Newsletter went out today to email subscribers (please check your spam filters if it’s not arrived). We’re planning to use this to push out various things during the next year so please do sign up (at the bottom of safenetwork.tech) if you’d like to get those updates first in your inbox.

And there’s more … another great podcast from @fergish this week in SAFE Crossroads (Episode 48: A Reintroduction and Update on the SAFE Network with @dugcampbell). And @dugcampbell was also out speaking all things SAFE Network at The Cryptograph Meetup in Glasgow on Monday night, having some fascinating discussions afterwards.

We also wanted to update you all on the dev update schedule over the Christmas holidays. Although some of the teams and individuals will continue to work, many will use the opportunity to take a breath before attacking 2019 which would make co-ordination difficult. So, next Thursday (20th Dec) will be the last dev update of 2018 and our first update of the New Year will be on Thursday the 10th of January.

Last but not least, we’re delighted to see that there is now a SAFE Network page on Wikipedia! It’s very basic at this stage and could definitely benefit from some work in the near future - but the fact that it’s finally there gives us all a great new reference point. Kudos to those in the community who’ve worked hard to support getting this in place - you know who you are! Great work - and another great example of just how valuable the community is to the marketing (small ‘m’) of SAFE.

Recruitment

Following on from all of the new starts we had last week, we had another new team member join this week

As mentioned above, Ceilidh (@Cgray) is our new Marketing Strategist. We also have an update on a couple of the new starters from last week. @vigneshwara is working alongside @lionel.faber in the Java team and @murali (intern) is working alongside @AshwinKumar and @ravinderjangra in the C# team.

At present, the only open vacancy we have is the Network Engineer which as mentioned in previous updates is a challenging role to fill. If you know of anyone who would be suitable for the role, don’t be shy and send them our way

SAFE API & Apps

With the safe-app-android-dev snapshot release now available for the mock network, the example application and getting started guide that use this package are under internal testing. Developers are welcome to include the library into applications of their own using the API documentation as reference.

The safe-authenticator-mobile app has been updated to work with v0.9.0 of SAFE Client Libs. Some minor textual fixes were made in the authorisation popup. Also, a bug related to Share MutableData requests decoding was fixed to fetch the metadataresponse list for the requested mutable data. Now that the bug is fixed, we updated the authorisation popup to show the meta name and description for the mutable data.

On the SAFE Browser and safe_app_nodejs front, we continue testing and supporting QA team in their findings, filling issues in our GitHub repos to be prioritised for either this coming release or subsequent ones. There has been a lot of testing and troubleshooting activity in the last few days which has been really helpful.

We have also started working on some technical debts which are not part of the upcoming release, but which we will want to have ready for subsequent ones. Thus we progressed a bit on moving away from AppVeyor for the browser Windows CI process and we’ll also look at doing the same for safe_app_nodejs. This is just an ongoing task which will probably take us several more days as Travis for Windows is still in Beta stage, so we are not sure how well it will work for us right now, we are just proactively trying to migrate to it.

There are also several issues we still have to solve in the automated tests of the browser as well, apart from adding more automated tests to it, that we are also working on in parallel. We see a long way to go, with this yet to be where we would like it to be.

There is some really nice job being done also on the safe_app_nodejs documentation, which may be ready soon, that we believe will help developers when trying to understand our APIs, with more clear snippets for each of the exposed API functions.

SAFE Client Libs

@marcin has been continuing work on creating Rust bindings for Rasqal, the C SPARQL query library. It’s finished now and we’ve run several successful tests. The latest version is available in the rasqal-rs repository. The next milestone for us is the storage aspect: we want to run queries not only on RDF data stored in files but on RDF data stored in the MutableData objects on the network too. @marcin continues to work on the project implementing the new storage type for Redland, tying it with SAFE Core and the SAFE Network primitives.

We’re also continuing to work on the RDF-related RFCs. With the scope narrowed down and defined much more clearly, we’re on a good track and there should be more news soon.

Routing

As mentioned in last week’s update, the Routing team has now been split into two sub-teams.

The Fleming subteam’s aim is to bring much clarity into the design of the routing code by constructing distinct abstractions (we call them layers) with minimal coupling between them. Over a number of meetings last week, the team started building a collective picture of where the routing code is at the moment in the fleming branch. We started brainstorming around how to structure the various layers.

One interesting idea we are exploring consists of separating what we currently call Disjoint Sections into an Untrusted traversal layer and a Network structure layer. This would have the benefit of uncoupling Kademlia bucket size which shouldn’t be too large for performance and disjoint section size which shouldn’t be too small for security.

As we are still in an exploratory phase, we have been gauging many open-source projects (so far: Bitcoin, Ethereum, Algorand, IOTA, Tox and Gnutella) that face similar challenges in some areas to the ones we face. We are investigating how they tackle some of these issues for context against options we’d be using in SAFE.

The Parsec subteam is continuing to improve the current parsec codebase. We fixed a couple of issues in the testing framework. Some subtle bugs in parsec have been spotted and addressed. The documentation of the Parsec struct was also improved. Performance work is also ongoing and at the forefront of our priorities. A first fix that was merged today improved performance on two of our 3 benchmarks by 30-40% from the code that we used in routing/fleming, which is a good start

Communication between both subteams is important of course. The Fleming subteam has been keeping up-to-date with the Parsec’s subteam work by engaging in code reviews. A knowledge transfer meeting took place on Tuesday, where the Parsec subteam was caught up with the progress from the Fleming subteam over last week.

Crust

Since we started working with the Mio-based Crust version again, it has been going through many changes. We finally integrated the socket-collection library which reduced and simplified some code in Crust. socket-collection also made encryption changes a lot easier. We still had to set up appropriate encryption schemes in different scenarios: connection listener is expecting the first message to be anonymously encrypted and to carry the peer’s public key, then upgrade to authenticated encryption if all is ok, etc. So all of that was done and the PR is there waiting for review. During the process of developing encryption in Crust we also discovered a small but merciless bug regarding message decryption. Luckily the bug is already fixed!