Here are some of the main things to highlight this week:
- We released a video with @JimCollinson as part of a new series of interviews with team members.
- We are starting the discussion on the RFC for RDF support in SAFE Client Libs, which is now raised as a proposal.
- @marcin made a post on the Dev Forum called Client Libs: Help Wanted! which describes the efforts of the SAFE Client Libs team to make it easier to contribute to the project.
- There is a SAFE Network meetup in Brighton tonight, @dugcampbell, @Pierrechevalier83 will be in attendance and @bart will be joining via Hangout.
With a view to improving the DevHub, @dgeddes has been speaking with community developers, MaidSafe developers and external developers that are unfamiliar with the project. The objective is to identify common themes and then look to enhance the features and user experience for visitors to the site so they get what they need with the minimum of effort.
In amongst the ongoing knowledge transfer work, we’ve also today released the first video in a new series of quick interviews with team members discussing their background, how they came to MaidSafe and their daily routine. The first (willing) victim was @JimCollinson. They’re meant to be short and sweet so please let us know if you find them interesting!
@dugcampbell and @Pierrechevalier83 are heading to the SAFE Network meetup in Brighton tonight, where Dug will be providing an Introduction to the Network and @bart will be joining via Hangout to talk about PARSEC in its new fully asynchronous guise. It promises to be a great event; if you’re in town check it out.
SAFE API & Apps
Last week we added a few more tests to demonstrate how developers can use the Java API to perform client actions that will allow them to use features such as custom
MockVault path, unlimited mutations etc. for a mock network. With this, we are wrapping up active development in the safe_app_java project until the next milestone.
We have been receiving positive feedback from last week’s release of the SafeAuthenticator mobile application with enhancements to the UI and UX. If you haven’t tried it out, head over to this forum post and give it a shot. Additionally, we have a bug reported regarding support on lower platforms. We have tackled this and a patch release is coming your way soon.
We are preparing a new release of the
safe-app-nodejs package. It won’t bring anything particularly important but there are a few minor enhancements we’ve worked on since the last release that we want to make available. We expect this to happen next week.
A first safe_authenticator CLI proof of concept was implemented and we are now planning to have some internal reviews to better understand how to proceed. We are expecting people from the safe_client_libs team to helps us in reviewing it as it makes use of the Rust API directly. There are still many open questions in relation to how such a CLI will work with the rest of the front-end components and this is why we are still not sharing too many details on our thoughts, but just a heads up for those interested in such a thing.
The browser is receiving an Electron version bump after the Chrome bug exposed last week. This should make it into the next release. Alongside this, we’ve started to overhaul some of the tab logic to stabilise it and hopefully remove some of the niggling bugs therein. We’re also taking a look at how we’re incorporating the Rust libs into the repos to hopefully better support our CI systems. And we’re trying out a new end-to-end test system that may prove to be less brittle than our current Spectron implementation.
SAFE Client Libs
Today we are starting the discussion on the RFC for RDF support in SAFE Client Libs, which is now raised as a proposal. We are aiming to collect some feedback for it, iterate on the proposal, and after it’s finalised and accepted, we will start planning out the implementation.
We’ve also been expanding the wiki and added several new pages, including a high-level introduction to Client Libs. We hope the new introduction page, in particular, will make it more clear how Client Libs works at a high-level, something we realise has been lacking in our documentation until now. In addition, @marcin made a post yesterday on the Dev Forum called Client Libs: Help Wanted! This post describes our efforts to make it easier to contribute to the project and gives concrete steps on taking the first plunge into the codebase.
In continuation with last week’s work on RDF proof of concepts, @nbaksalyar has completely immersed himself with the integration of the SPARQL query language into an experimental version of SAFE Client Libs. We’ve made some good progress in interfacing with the underlying C libraries (librdf and Rasqal), but there are still some stumbling blocks concerning the thread safety. We already know how to resolve them though, so we’ll be continuing to work on examples which should demonstrate how developers can query, drill down, and get insights on the Linked Data stored on the SAFE Network.
This week the Fleming team took the focus more onto node ageing for their discussions. One decision reached was that we’ll associate work units with nodes and use this as a measure of when a node should be relocated. This is less random than the previous approach and shouldn’t cost any real overhead. For now a work unit will likely just be defined as handling a churn event, but this will give us scope to extend the definition later.
There were also discussions around new nodes joining the network; i.e. finding a balance between moving these less trusted nodes frequently and early, and on the other hand not causing the Network undue stress, especially when the Network is young. The team also agreed that we’d continue with the paradigm of not allowing more than a single node at a time to be relocated in or out of a section, since this avoids needing a section to resource proof multiple nodes concurrently.
On the PARSEC front, the reworking of the whitepaper has been largely completed, but we can’t quite share it publicly yet as we’ve secured academic review and are considering creating a formal publication. More details to follow in the coming weeks.
Regarding the code, a few further significant improvements have been made in performance. Possibly the most significant, as mentioned in last week’s update, was the idea to bundle multiple observations into single gossip events. This was done in PR #273 and yielded more huge improvements in some of the benchmarks. Other than this one, @Jean-Philippe has done some excellent work in the last few weeks profiling the code and making the majority of the recent PRs which improve performance.
As we continue evaluating the requirements from Crust for Fleming, in parallel we’re looking into detailing out the tasks for dynamic connections and looking into the quinn crate for figuring out missing components and how those can help us. Dynamic connections, among other things, presents the illusion to the upper layers that Crust is connected to 1000s of peers when in reality Crust is actually doing quite a bit of work to make sure we don’t run out of resources by constantly shuttling peers between an active and a passive list. The QUIC protocol, on the other hand, has built-in features like multistreaming and has an ability to use a single UDP socket for as many connections as we want thus keeping the socket-descriptor usage to a bare minimum. There are some pending issues in Quinn like here and we are monitoring if it has enough of what we need. We are setting up a proof of concept to test this and if it’s stable and suitable for our purposes we would be in a much better position to decide whether to go for our own implementation of dynamic connections or switch to QUIC instead in the road to Fleming.