Here are some of the main things to highlight this week:
- Continuing the series of posts started three weeks ago, the Routing team released this post to highlight the main questions their current brainstorming sessions are centered around.
- @douglas.santos has joined the team this week to work alongside @povilasb in the Crust team.
As mentioned last week, the Marketing team has been focused almost exclusively on continuing its deep dive into Fleming Tech. Meanwhile, @dirvine was interviewed on Mozilla’s IRL Podcast and @nicklambert was quoted in an article on the Verdict website.
Following our long search, we are delighted to announce that we have found another Network Engineer, to work alongside @povilasb in the Crust team. Please join us in welcoming @douglas.santos to the team!
SAFE API & Apps
We are currently at the end of the third development sprint for the UI/UX enhancement milestone for the SAFE Authenticator mobile application. Issues reported by QA from the second sprint are being resolved this week. @vigneshwara is riding solo for the safe_app_java milestone, which will include exploring the new features available in JUnit 5 to improve the test suite. The team is also looking into the pain points around app authentication and the IPC mechanism currently followed across platforms. We will be investigating alternative approaches to improve the authentication experience.
This week the first release candidate of the SAFE Browser was made available and is currently in our usual internal testing phase. Based on the findings during this phase, we will be able to share the new release (v0.11.2) fairly soon. As usual, we’ll be preparing the changelog for sharing it with you when ready.
There has been a lot of internal discussions and brainstorming sessions trying to agree on our next steps for the Browser, Authenticator, and other components of the front-end team in general. As part of these sessions we were also trying to share knowledge across different teams to be able to make decisions which consider several perspectives, e.g. what’s required in the long run for the authentication process when thinking not just about desktop applications or web apps but also mobile apps, and how to move forward in the direction of making the process easy and clear for the end user.
SAFE Client Libs
This week we came up with a definite plan for making our extensive Client Libs documentation public. We’ve chosen to use a GitHub wiki on the repository to host all the docs in one place, which we can link to from the Readme, source code, and the Dev Hub (with summaries). We have collated all of our docs into a private list and have marked the ones which require review versus those that are still WIP. We plan to review and publish about three new pages per week. This week we will be publishing our “Introductory Concepts” pages, starting with “Building Client Libs”. Next week will be about more technical core concepts as we feel that this is the most important information to publicise first.
Next week we will also move some of the content of the Client Libs Readme to the wiki, and add links from the Readme to the relevant wiki pages. This should make the Readme easier to navigate, containing only the most important information, while letting more inquisitive users know where they can find more details. The Readme will be updated sometime next week.
In the meantime, Yogeshwar finished a first major milestone in the transition of SAFE Bindgen to the new parsing framework
syn, which supports the latest additions to the Rust syntax, so eventually we can finally switch all of our repositories to use the latest stable version of Rust. This work is being reviewed now and should be merged upstream soon. See the safe_bindgen project boards for more details.
This week the Fleming sub-team have again been concentrating on producing more detailed figures relating to the Network’s resistance to Sybil attacks, and in discussing more of the “big picture” issues surrounding the Fleming release. These discussions have included topics such as hot restart of nodes (nodes being allowed to restart in order to upgrade their binary without suffering a normal relocation penalty), network restart, network upgrades and message delivery through the network (especially in a situation where a less than ideal connectivity could be expected).
Continuing the series of posts started three weeks ago, we released this post to highlight the main questions our current brainstorming sessions are centered around.
There was further effort put into bringing the Parsec whitepaper in line with the current idea of using a distributed key generation algorithm in order to make Parsec fully asynchronous. This work is still proceeding well, and in fact it has revealed an implementation bug in our current implementation of the concrete coin calculation.
The other sub-team have been pressing on with resolving issues and seeking performance improvements in the current Parsec codebase. We have identified a couple of new issues related to malice-handling which are being addressed at the moment, and the benchmark suite has again been improved to make it more relevant to our expected usage of Parsec by Routing.
The Crust team is very happy with the latest reinforcement - @douglas.santos. We’ve started the onboarding process and soon enough we will see some contributions from Douglas as well
The QA team has started aggressively testing the Crust bootstrap cache implementation and these guys are not joking - already found a few bugs! The fixes are on the way.
We had a lot of discussions about the very next piece of work in Crust which should aid Fleming release goals. We decided that dynamic connection management is the highest priority at this moment and started defining more specific tasks on GitHub.