Here are some of the main things to highlight this week:
- We released a new Medium post yesterday to accompany @lionel.faber’s new video explaining how to develop native Android DApps on SAFE.
- @dugcampbell was interviewed on the popular CryptoBeadles show.
- @lionel.faber created a new post on the Dev Forum to help developers get started with using the Java API on desktop platforms.
Couple of things to mention from the Marketing Team this week. We put out a new Medium post yesterday to accompany @lionel.faber’s new video explaining how to develop native Android DApps on SAFE. This is a new approach and we’d love to get your feedback: was the video useful? Did you feel it covered the questions you’ve got about what’s required? And if we could make one change, how would you improve the next video that we release in the ‘hands-on developer explanation’ genre?
One other question for you all: if you do start to develop using this tech, please do let us know. We’d love to support your efforts wherever possible - not least by ensuring that the documentation gives you the answers to the questions that you might have. So please don’t be shy about suggesting any improvements that you’d like to see, or what you are working on.
There were also a few interviews recorded last week. First up, @dirvine was interviewed by Manoush Zomorodi for the popular IRL Podcast, produced by Mozilla for an episode that should be released in February - suggest you subscribe now to get it when it’s live! Then @dugcampbell was interviewed on the popular CryptoBeadles show. It goes without saying how powerful some of this video content can be in both attracting newcomers that are fresh to the project and also answering their questions - so if you only do one thing this week, please do like, share and comment on this post if possible! Finally, Dug was also on Ernest Hancock’s ‘Declare Your Independence’ radio show at the end of last week.
SAFE API & Apps
The last week has seen us further refining our reconnect process in the browser, which in turn led us to the never-quite-as-simple-as-you’d-hope task of upgrading the major version of Electron. This in turn has seen us working on safe-app-nodejs compatibility with newer Node versions, which while theoretically working against versions 8, 9 and 10 in our branch (previously we were confined to
^8), has caused (or unearthed) some curious bugs in Electron when attempting to use safe-app-nodejs in the upgraded browser.
In tandem, we’ve also been further exploring some of the concepts from the RDF / Public Name System RFC and what APIs might look like. And in doing so have managed to get a workaround for command line / script auth receipt on macOS (which has previously been a sizeable pain). The specifics of the problem/workaround are described over on the Dev Forum.
After a small break this week for a regional festival, the Chennai office is back, resuming UI/UX enhancements for the SAFE Authenticator mobile application. After last week’s release of the packages to support native Android development on SAFE, a few questions were raised with regard to desktop support for the Java API. This forum thread should help you get started.
SAFE Client Libs
This week, we have started to focus more on the documentation for SAFE Client Libs. While documentation for individual API functions has been available for a while on docs.rs, the internals and high-level concepts are not well described. And while app developers don’t need to learn much about how SAFE Client Libs are structured internally, such documentation will be valuable for core developers and internally for MaidSafe. So far we have made available our documentation for building SAFE Client Libs in the official README, and have made substantial progress on internally documenting topics such as the event loop, the NFS (Network File System), and the FFI. Once we’re happy with the quality of the documentation and when it’ll be complete, we’ll make it publicly available.
Routing efforts are still split between the ongoing development of PARSEC and the design work in the Fleming subteam.
On the design front, we have been further investigating issues such as network restarts, resilience to sybil attacks and scalability aspects of different design decisions.
We also considered network restarts in some depth. We analysed a simple scenario in which most of the nodes (a supermajority per section) are guaranteed to eventually reconnect after a restart and drafted a solution for such a situation. We intend this to be the first step towards a more general solution, able to handle more complex scenarios, too. As for the Sybil attacks, we are working on a detailed analysis of how hard would it be for an attacker to disrupt the network and how node ageing affects it.
We are starting to accumulate some nice insight into the design of Routing that we would like to share with you, the community. We are currently working out the best way to share that information with you, be it a series of blog posts, articles on the forum with discussions, some alternative approach or all of the above. Keep your eyes out, content may be coming soon
On the PARSEC front, there are a few directions in which the work is progressing. We have continued looking for bottlenecks and opportunities for improving performance. One such opportunity that was identified consists in reducing the amount of processing done by removing the requirement that every node must keep all previous meta-elections ongoing while they haven’t seen other nodes reach consensus. This information was convenient for precise identification of an event relaying gossip from a node they shouldn’t have knowledge of; but we managed to keep most of the benefit of such checks without incurring the cost by accepting a small amount of false negatives that don’t offer a significant opportunity to harm the network.
Other than that, we discovered a vulnerability in our
responsiveness_threshold mechanism where nodes could game it by introducing gossip events recording fake
Requests. We engaged in brainstorming and agreed on a solution that was documented in the task raised to tackle the issue. We are now working on actually fixing this issue.
Finally, work on handling other documented types of malice is still ongoing.
This week we did some refactoring to simplify the codebase. Since Crust is running on a single thread, we eliminated all of the mutexes used in Crust which is supposed to make the code easier to reason about and the runtime itself should be faster. In addition, we split the Connect message into two:
ConnectResponse. It’s an internal detail of Crust and is invisible to its users but makes it easier for Crust developers to understand the flow of various messages. We also expanded the docs and improved Crust log messages.
This week again we were glad to accept a PR from our community. Luka solved one of our potential bootstrap issues and made sure we were not trying to bootstrap off the same peer twice which would have been wasteful.
We are approaching the end of our current milestone which was mainly backporting features from the Crust Tokio-based implementation into the Mio one. It’s time to check Crust for any regressions not caught by our CI checks, which is done via Routing end-to-end tests as they use Crust to transfer data over the wire.