Today, we are releasing updated binaries for SAFE Browser and Web Hosting Manager (to fix a few minor issues):
As you can imagine there is a lot happening in the background with Alpha 2 and Alpha 3 release planning. We have multiple teams all working on the various components now to ensure we deliver these next two releases promptly and professionally. You will have seen recent recruitment drives to aid us in these next few steps.
Alpha 2 is not far away as we all know, but a timely release is imperative now and must tie up with other parts of the project such as PR, marketing and business relationship building. The Alpha 3 meetings this week have been very productive and allowed us to find some really pleasing numbers regarding network or overhead cost of some network actions. All in all, this has been a very good week.
SAFE Authenticator & API
Since the release of the front-end applications with Test 19, no major issues have been reported, neither internally or from the community. This is a good sign that the applications are quite stable and it is encouraging us to keep working on the minor issues we have in the backlog. We really appreciate the feedback and also the issues that the community has been reporting, and it’s very important and very helpful to have all issues reported, even if they are minor, in order to enhance the applications and make them more stable and usable.
The following issues/tasks were resolved during the last few days:
- MAID-2327: minor refactor to safe_app_plugin to remove the queue for auth requests as the Authenticator already provides one.
- MAID-2326 & MAID-2325: issues with either browsing or downloading empty files were solved.
- MAID-2307: solved the issue that causes a crash in the browser when browsing a deleted service
- MAID-2306: uploading empty directories is now correctly handled.
- MAID-2305: crash when uploading empty files is now fixed.
- safe_app_nodejs PR #140: display the correct error when failing to load the dynamic libraries (thanks a lot @cooperka!)
- Improvements to the README files of safe_browser and safe_app_nodejs (also by @cooperka)
The issue with saving the state of the browser on the network (MAID-2318) is fixed but still undergoing internal testing. It should be solved in the next version of the browser.
As anticipated in last week’s dev update, @shankar resumed the effort to enhance the UI/UX of the Web Hosting Manager application; we hope to be able to start our internal testing within the next couple of days.
@joshuef is now working on trying to automate our release/packaging process since we’ve been doing it manually so far, which is not only a time-consuming task but also very error prone. This will help us in the short term to be able to spend less time on this process and also allow us to be able to quickly respond if an urgent patch is required for any of the front-end applications.
Additionally, @hunterlester is working on creating tools/mechanisms to automate our tests for the DOM API. This is also in line with our goal of being able to quickly provide patches/fixes without risking the quality of the software.
SAFE Client Libs
We improved the app authentication process: the response from the Authenticator now includes the full Access Container Entry (a structure that contains details about the containers the app has access to), saving the app a network request. We also simplified and optimized the API for working with
MDataInfos (structures that contain the network identifier and encryption keys of a mutable data).
MAID-2313 is nearing completion which will allow us to automatically generate C header files to interface with our FFI. As part of this task, we refactored the FFI modules of safe_core and safe_authenticator. We also caught several FFI functions that were either not marked
#[no_mangle] or were missing an
Routing & Vault
We are continuing to focus our research efforts on message broadcasting strategies, or in other words - strategies for ensuring that every intended recipient of a message eventually receives it. In addition to the simulation we developed last week, a further investigation on what additional penalty cost our current approach incurs is being carried out. We hope this will clarify our current situation and could provide us with a clearer comparison to any future proposal. Some other metrics, such as the total amount of traffic or number of messages in various approaches, are also being calculated.
Work this week has focused on tracking down bugs in our uTP implementation. Currently, the SAFE Network uses TCP for all peer-to-peer communication, though there are many advantages to using a UDP-based transport protocol such as speed and easier hole-punching through home routers. Our aim is to have uTP in a state where we can deploy it alongside TCP sometime in the next couple of weeks.