First of all we would like to welcome Nikita Baksalyar to the team, he has started and is up and running very quickly. The expansion continues with two more developers starting in October and of course @lightyear is working one day a week in September and full time in October. Ben is already working on a very interesting example app that will showcase some of the capabilities of SAFE.
Since the first alpha release, there has been a massive amount of work in the Client libraries, especially in
The Launcher UI has been updated to use React & Redux instead of Angular. This makes the UI code much easier to manage. With the previous Angular code, when there was heavy UI updates occurring such as the logs on the UI getting updated…etc… The Angular code was becoming an issue to manage and lacked performance. React which uses virtual DOM is proving to be a significant improvement in speed and simplicity.
Launcher’s FFI code has been updated to match with the new safe_core API, which is now a standard C-style interface instead of a JSON interface.
Launcher’s FFI code now uses a single process instead of multiple child processes.
Introduction of the Appendable Data type.
Implementation of the Low Level API
Launcher API v0.6. The main focus right now is on the API endpoints that are needed for the first example. The implementation will be completed as we add additional examples in the Dev Tutorials series.
These changes needed to happen because we want to enable developers to build dynamic applications that work entirely on the SAFE Network.
With all these changes in place, the next testnet certainly should be interesting to try and we’re also excited to see the apps that devs will be creating with these new APIs. As always, this is a testnet and especially with the scope of current changes, some bugs might occur and hopefully they can get addressed quickly and removed from future tests.
Also, we are planning to freeze (stabilize and hopefully get as close to v1.0 asap) the network’s data APIs once we are finished implementing RFC 38 – Appendable Data and RFC 41 – Low Level API. Freezing the APIs will allow us to focus on getting the network stable. As discussed on the Dev Forum, there are a few limitations with the current implementation of Appendable Data, but these should not be blockers to trying out the API itself. For now we want devs to use these new APIs and to give us feedback. The Client team will be focussing on integration, documentation and testing of the client libraries.
It is our pleasure to announce the first of several upcoming client tutorials. To help demonstrate to the wider world that we are not only a storage network, the first tutorial we are going to release is an email app that works entirely on the SAFE Network.
This tutorial will showcase how to:
- Create an email ID
- Send emails to other users
- Check for new emails
- Read your emails
This is intended for developers who want to learn more about the following APIs:
The user interface is built using the following front-end libraries:
Since it’s built using Electron, it can be distributed as a desktop app (Windows, OS X and Linux). For the non-devs out there, we will release binaries for this tutorial because we know you guys love testing new features, but we want to make it clear this is not a standard app. It’s an example app for devs and it’s meant to be built from source.
The code examples have been added to the first tutorial and we are currently reviewing/improving the tutorial. As per last weeks update these tutorials will be available in GitBook. We also need to test the example app with the new Launcher internally. Due to the scope of changes, this is going to take some time and then when the initial tests are good, we will release a new testnet. We are hopeful for this to happen during this week.
We have pushed the client APIs very quickly and we do expect bugs, but are very keen that developers and users alike start to see the capabilities of SAFE well beyond storage. To aid this we will get through example applications (not release applications, but examples for developers to copy/extend/learn from etc.) as quickly as possible over the next few weeks.
SAFE as a secure signaling mechanism, communications platform and eventually compute is a huge proposition. We will take this a bit at a time though and these current APIs will take us well beyond storage and static websites and basic applications into the realm of NoSQL and dynamic web-based and native applications and data management (wallets/exchanges and much more).
However we do wish to stay in this level of API for a while and let our team assist and push forward third-party developers with time, better documentation, API tweaks and of course security implications. This will settle in the coming weeks as we clean up the very fast work this week and of course increase the client teams at the same time.
Busy days at MaidSafe, but we do have a few quiet ones
There will be a few client-only testnets before the next alpha release. For example, TEST 9 will only allow
safe_launcher to connect, not
safe_vault. The reason for this is that we are not getting any new feedback from letting users run vaults from home (TEST 8). The issues highlighted so far need to be resolved first with the ongoing RFCs before we integrate them into a future testnet.
Until vaults are at a stage where we can learn from testnets again, we will be releasing client-only testnets. This will allow Launcher API v0.6 to progress and for the additional functionality to be utilised by app devs.
Crust & Safe Core
We are adding a whitelist feature in Crust. Nikita is currently working on implementing it.
The whitelist feature ensures that a vault running in a droplet allows only other vaults running on the droplets to connect (and form a network), while not allowing the ones running otherwise (in various user machines) to bootstrap. Clients will not be filtered however, so people running Clients can still bootstrap to vaults on the droplets. We will use this whitelist feature until Vaults are stable as we want to test Vaults from various configurations (bandwidth / machine type). Also, developers will be able to build
safe_core from source if needed and connect to client-only testnets.
A big amount of work has gone into
safe_core. We have finished coding both the low-level APIs and the appendable data. All test cases pass and Launcher and apps can freely take advantage of the flexibility and power of these.
Routing & Vault
The core functionality for Appendable Data has been implemented in both
safe_vault and is now being tested. Regarding the Disjoint Groups RFC, we are planning to finish the new routing table implementation this week. We will integrate it with the core routing code next week, and finally add handling for the new group merge and split events to
safe_vault the week after that.
With the work for appendable data RFC coming to an end (for now), Data Chains integration meetings are also expected to continue again while the current ongoing RFCs are completed.
MaidSafe’s funding round on BnkToTheFuture went live yesterday. £153,987 has been raised so far.
There are a few additions and announcements being planned to increase awareness as this funding round progresses.
SAFE Browser RFP
Here’s a developers preview of the Safe Beaker Browser candidate with
Right now, within the window var, you can access safeAuth, safeNFS and safeDNS objects, with their respective functions coming from safe-js https://github.com/joshuef/safe-js/tree/master/src
See this topic for more info: SAFEBBrowser Pre-release: 0.2.4 Test the API!
We’re aware that there are very good RFCs that have been submitted by community members (e.g. Vault RPC), but we don’t have the bandwidth right now to focus on them. We’re sorry we can’t take them forward. After the next alpha and once we have a bigger team, that will change