Today we are releasing TEST 8
The Vault binaries are the same as the alpha network, but they won’t connect to the alpha network. TEST 8 is a completely separate network. It has the same restrictions as TEST 6 & TEST 7 and will offer similar performance.
To connect to TEST 8, you need to use SAFE Launcher v0.8.1. You won’t be able to connect to TEST 8 by using SAFE Launcher v0.8.0 (Alpha 1), even if you try to change the config file for Crust. There are no major changes in SAFE Launcher v0.8.1, just a few bug fixes
As for the demo app, you can continue to use the same binaries as Alpha 1: SAFE Demo App v0.6.0.
We are planning to bring TEST 7b down tomorrow at around 10:00 am GMT.
SAFE Launcher v0.8.1
Each client account is limited to 500 PUTs. A PUT is a request to store a single chunk on the network (a file may contain many chunks). The maximum chunk size is 1 MB.
Please be aware that this test network will be reset periodically, wiping all data that is stored on it. We will announce this in a Dev Update (when possible) prior to taking it down.
- Package identifier updated to match correct reverse DNS identifier
- Updated the forum link
- Fixed empty file handling in NFS
- Fixed ffi process crash during unauthorised access
- Fixed fetch file with metadata via DNS
SAFE Demo App v0.6.0
When uploading files using SAFE Demo App, the maximum file size is 25 MB per file.
SAFE Vault v0.11.0
You can run only 1 Vault node per LAN – running more than 1 will result in this message “More than 1 routing node found on LAN. Currently this is not supported” – for the objectives of this test please respect this restriction.
- Use rust_sodium instead of sodiumoxide.
- Upgrade to routing 0.23.4, with merged safe_network_common.
If you need help with anything related to SAFE Launcher, SAFE Demo App or SAFE Vault, please use the #support category of this forum.
Where should I report issues?
GitHub is the best place to report issues and bugs. Using GitHub will help us (MaidSafe) manage issues and prioritise work within the Dev team faster.
We are now ready to share our plans for the client-side deliverables.
Firstly, we will start by proposing two new RFCs, one for appendable data and one for exposing a low level API in SAFE Launcher. Many developers currently looking at, or building applications right now (like Decorum for example) will see very quickly the use cases these RFCs will cover. This is an exciting time as we feel we will showcase to everyone some vital capabilities of the network that goes way beyond simple storage. Capabilities will include further helpers for dynamic data, information passing between clients and more. We plan to release these capabilities in batches over the coming weeks.
After the RFCs have been implemented, we will roll out a series of tutorials to present different use cases of the SAFE Launcher API. We anticipate releasing an example and tutorial in roughly two week intervals. This will greatly help developers understand how to build dynamic applications. The tutorials will showcase APIs that the demo app hasn’t utilised so far. We will give more details on the first example and tutorial very soon
Apart from refactors (which is a big chunk of work by itself but internal to the client modules) the interesting work from Client side will be putting up and discussing in details the following two RFCs:
Motivation: AppendableData will help users exchange information. While read operations are already possible for unencrypted StructuredData by non-owners, now we are looking to also provide appendable operations for allowed users. There is a whitelist/blacklist mechanism in this RFC that allows blocking or explicit allowing of users to add to this data type. AppendableData will allow mutation of data owned by someone else. This makes many use-cases of information exchange realisable and interesting apps to be built straight away. Once flushed via RFC we will hopefully come up with interesting tutorials to demo its usefulness.
Low Level API
Motivation: Now that we will have new data types (AppendableData) and lot of use-cases, it will be impractical to provide helper functions to carry out composite tasks as there can be many permutations. Instead, we plan on giving the app the ability to manipulate StructuredData, ImmutableData, AppendableData etc. directly as they please, so that they have complete flexibility and freedom to create their own data structures and representations on the network. The operations can be done in any order and can be customised to suit their use case. This functionality will be showcased via some basic (non-fancy/non-optimised) yet exciting tutorials and examples.
There are already RFCs that are underways (namely secure name and disjoint groups). These are required for data chain integration which is the most promising solution to coping with many vaults of varying capabilities. Routing and Vault teams will be concentrated in this area during this iteration with the hope of getting Alpha 2 all on one network.
The areas of increased security, data resilience (from partial segmentation through full network restart) and the ability to secure data republish across the network are being worked on and tested. These are not small issues, but the RFCs do identify the areas of focus.
With that team expanding in 4 weeks or so the increased head count should allow a more lean development process to continue while finalising Routing and Vault to a release candidate level. This is when we will consider further safecoin integration as work there right now will simply get in the way of any refactoring we must do to enhance the libraries to cope with data security and resilience.
These next few weeks will see a lot of background work here and possibly many weeks between test networks with updated versions of Routing. This is good from a client perspective as it allows the focus of the community to be on building apps. We will release more frequent test network upgrades to confirm new client API additions and capabilities, but not necessarily with the advanced data resilience measures.
With the proposal and selection process now complete an estimated £3,000 has been donated by the community to the building of the SAFE browser. Thanks for everyone who gave so generously, you guys really put your money where your mouth is!
MaidSafe will fund the £7,000 balance and will transfer the 87,500 MAID shortly. This will enable @joshuef to build not only the browser, but also integrate the stretch goal functionality of toggling between SAFE and clearnet browsing, as well as SAFE browser sync.
Also, the recording of the SAFE Browser Q&A (which happened last Wednesday) is available here.
The SAFE Dev Forum is now open for registration. Just go to forum.safedev.org and create an account.
The goal of this new forum is to make it easier for developers to communicate with the MaidSafe developers.
Here are a few examples of how the Dev Forum can be used:
Developers who want to contribute to the core libraries can use this forum to talk with the developers responsible for a specific core library (e.g. #routing).
Developers who need help with the SAFE Launcher API can ask questions in #launcher:api.
Discussions about pre-RFCs and RFCs can happen in #rfcs.
Feel free to suggest ideas on how to improve the Dev Forum in #site-feedback.