Peruse (the custom browser that will eventually replace SAFE Browser) has been updated, you can download the latest version here. It adds localhost support, as well as the ability to open http links in your clearnet browser of choice automatically.
Keep in mind that this is a proof of concept and has a few known limitations:
- Placeholder authenticator messages (the prompt doesn’t show the app’s info and/or permissions requested as the current authenticator does)
- Potentially slow startup (network connection occurs on startup as opposed to first fetch)
- No reconnect notifications (if you start without the invite IP updated, you’ll need to restart, for example)
- UI has not been a focus yet
- No page loading indicator right now
Community Engagement Program (CEP)
Followers of the project and regular visitors to this forum will have seen a lot of discussion on the forum about marketing, and as mentioned in previous updates this is something that is getting much more focus and resources with @SarahPentland joining the team a couple of months ago and @dugcampbell (Dug Campbell) joining this week. There are a couple of areas that we will be focussing on, but one is much more community involvement. The SAFE Network must have the strongest community in the space and even after 3+ years we continue to be astonished by the energy, intelligence, commitment and creativity of the people on this forum and it would be almost criminal for us not to use these skills to all our advantage. That is why next week we are bringing back the Community Engagement Program (CEP) as the first step in this process.
The purpose of the CEP is to match MaidSafe requirements with skills in the community, taking the form of a community funded ‘kickstarter’ like process to encourage community members, individuals and teams to bid for projects. Before this was more focused on technical requirements and longer standing forum members will recall that the CEP gave birth to the SAFE Browser, currently part of Alpha 2, and also led us to hire @joshuef. Our intention with this relaunch is to not only focus on development tasks but to also incorporate non-technical requirements, such as design, animations, videos, content management…etc…Sarah and Dug are currently working on an explainer video and some other resources to make the process clearer and to educate newer members about its existence and we look forward to launching this next week.
SAFE Authenticator & API
The DOM API playground tool was updated to the latest changes in the DOM API and it’s now fully compatible with the SAFE Browser v0.8.0. This update included a refactor where the code snippets were changed to make use of async/await as we hope it should make it simpler/easier for developers trying to understand them and to then use them in their own apps. Although intended for mock development, it has also been published at safe://codeplay.discover for initial discovery. Please keep in mind that it can quickly consume mutation requests.
The scripts to automate the SAFE Browser packaging process to generate versions for mock and non-mock routing have been merged and we are currently testing them to have them ready for our next release of the browser.
During the last few days, we were also going through the list of bugs reported for the browser and plugins, not only those reported on GitHub but also some others discovered internally, and we started fixing some of them to be able to release a patch for the browser soon.
Peruse has been updated, you can download the latest version 0.2.0 here. It adds localhost support, as well as the ability to open http links in your clearnet browser of choice automatically.
We’ve dropped the custom localhost protocol (as found in the SAFE Browser), as this was causing a number of issues in Electron. Now http://localhost:<port> and http://127.0.0.1:<port> are whitelisted HTTP URLs for use in Peruse. This sidesteps these Electron issues and enables more robust local development (most notably hot-reloading of your applications).
Otherwise, this week has seen a lot of refactoring of the Peruse store to enable syncing across browser windows and increasing test coverage, which puts us in a good position to implement history and favourites to round out a bit more of the basic browser functionality.
As a first step in integrating the JNI bindings, we are implementing a few minimal APIs, setting up the test suite and testing the desktop JAR files from a quick example app. Once these steps are covered, we will be starting to expand the APIs.
The Java project is structured such that the api project will be a dependency for safe_app (desktop) and safe_app_android. Only the platform-specific variations will get coded into the desktop or Android project. For example, the loading of the native library is different in desktop and Android. Hence this part will be handled in the platform-specific project while the majority of the API code will reside in the api project.
The progress with Java bindings has been good. We are well placed to cover these three steps and get it merged with the upstream master by this week.
A pull request adding ReSharper code inspection to the AppVeyor CI script and removing identified linter issues has been merged.
SAFE Client Libs
As we keep supporting more and more platforms and processor architectures, maintaining their releases has become tedious. To streamline the process, we came up with a plan to automate it as much as possible. The first step of this plan was to write a script which automatically builds and packages all necessary libraries and other support files for each supported platform and architecture. This script is now ready and is undergoing review and testing. After that is done, the next step will be to include it in our continuous integration system.
Today we are releasing a first community preview of the auto-generated Java bindings. It consists of two parts: the Java files, defining the API, and libsafe_app, which glues JNI functions to the Rust implementation of SAFE App. For now, the released version is available for the x86_64 Linux platform only, but as soon as we’re done with the build automation scripts, it should be available for all the platforms that we support.
We’ve also received some valuable feedback from the front-end team and started implementing it already, so there will be more news and updates in the coming days. The feedback concerns the minor stuff, so the Java bindings should be wrapped up pretty soon.
Routing & Crust
As we’ve been drilling down a bit further into the details of the proposed implementation of Data Chains, we’ve come across some problematic examples which have resulted in further team discussions and refining/updating the protocols. As expected, the chief culprit of the problems is the section merge procedure. That’s what happens when a section of peers becomes so small that it needs to join up with one or more neighbouring sections.
This has proved troublesome in the past, and we’ve learned a lot from previous work about how this can go wrong. That experience is invaluable, it’s made us all very aware of how easy it is to overlook edge cases which can hurt the network. This is just a symptom of decentralisation: if all the peers agreed simultaneously about how the network was changing around them, it would be relatively trivial to handle. However, at a given moment, since half the peers in a section can “see” one thing and the other half see something slightly different, it makes achieving eventual consistency in this case particularly tricky.
As a result of this, we’ve not progressed the code as we’d have hoped - instead, we’ve been largely focussed on resolving the remaining issues in the merge protocol.
We are also delighted to have our work closely scrutinised by forum members. Special shout out to @mav for his interest and contribution. Seeing so much interest from the community is awesome and gives us even more motivation to work on the project 
@mav’s interest in the project also led to him discovering a serious bug in our simulation - it was caused by relocated nodes not being actually removed from the source section, which resulted in their duplication and artificial increase in the number of older nodes. The results of the simulation changed dramatically after this bug has been fixed. This exposed a flaw in our current design which made the network accept barely any new peers. Fixing this flaw will be an important task for the near future. Summarising, @mav’s efforts are quite a significant contribution to the project - much appreciated!
uTP support has finally landed in Crust’s dev branch. uTP is a UDP-based transport protocol which has several advantages over TCP. Its congestion control algorithm is designed to use all the spare bandwidth on an internet connection while yielding to anything else which tries to use the same connection. This makes it a perfect protocol for peer-to-peer downloads from the SAFE Network. UDP hole-punching is also much more reliable than TCP hole-punching, meaning that we will be able to make direct peer-to-peer connections more often than we were able to with just TCP.
Some parts of uTP support still haven’t made it into Crust. Specifically, the rendezvous server implementation used for UDP hole-punching still needs to be integrated from our p2p crate. But we expect this to be completed within days.
The next stage for uTP support in Crust is, of course, testing. We plan to do some more internal testing first to make sure there are no glaring bugs, then release binaries to the community so that we can get some testing done in the real world.
I may be wrong but it looks like data chains and crust are heading down their respective tracks to come together in relatively short order for some much anticipated community testnets! Good luck 
glad to see that resurrected 
