EDIT: Trust level 1 users can now claim an invite for Test 17. See this dev update for more info.
Today, we are pleased to be opening Test 17 to all forum users who are at least trust level 2 
Similar to the other tests, we’re hoping to lower the minimum trust level soon(ish) to allow newer members based on how this test progresses. At the end of last week, we added the rate limiter as well as the client whitelist feature (explained in last week’s update) to the internal testnet for Test 17 and it has been going great so far. There was a lot of feedback that has been addressed and some still in the process of being resolved. The releases indicate the current known limitations which we’ll hopefully be addressing soon and updating the binaries where required accordingly.
Yesterday, we updated the front-end binaries based on the feedback from this topic. Thanks again to everyone who participated in the internal testing!
SAFE Browser v0.3.0
SAFE Browser has the authenticator integrated. Accounts can be created using the authenticator by clicking on the Authenticator icon in the toolbar of the browser or from the homepage of SAFE Browser.
This testnet is limited to forum users who are at least trust level 1. See this topic for more information.
To obtain an invitation token, trust level 1 forum users can use this website which can also be accessed via the SAFE Browser itself when creating an account.
Each client account is limited to 500 operations. Currently the amount used is not displayed in the browser UI. We’re working on addressing this to be shown in the browser itself to allow users to keep track of this amount. Worth noting this number is just a temporary placeholder and is shared between all the apps on a given account.
Please be aware that we might need to restart this test network, wiping all data that is stored on it. We will announce this in a dev update (when possible) prior to taking it down.
Download
Changelog
- Integrates authenticator addon
- safe_app API injected as DOM APIs
- Compatible with Test 17
Known limitations
- History and bookmarks are not saved in the network right now.
safe:scheme is not opened by SAFE Browser from the hosting example.- Account usage stats are not available from the UI.
Example applications
Changelog
- SAFE Mail Tutorial updated to be compatible with authenticator
- Web Hosting Manager example added
- SAFE Mail can support multiple email IDs
- Compatible with Test 17
Known limitation
- Public IDs created via examples are not exchangeable between the apps.
- This is the error reported with the Access Denied / Requested Entry not found error. This issue is related to the permissions of the service/mail mutable data. The root folder with the default folders are designed for easier sharing and collaboration between apps. Applications can request access to these while the authenticator manages the app access levels. In case of the public IDs, the public ID is added as a key into the _publicNames container. A corresponding MutableData is created by the app and the permissions for the same is set by the app. This MutableData is then added as the value to the public ID entry. Now when the second app tries to add a service to the MutableData created by the first app, it doesn’t have the permissions to do so as this was not created by the authenticator. We’re currently discussing a few approaches to resolve this and also confirm if the paradigm we’ve got is what we need or potentially allow the authenticator to manage the public identities itself.
Web Hosting Manager v0.1.1
When uploading files using Web Hosting Manager, the maximum file size is 25 MB per file.
Download
SAFE Mail Tutorial v0.2.1
Download
Support
If you need help with anything related to SAFE Browser, Web Hosting Manager or SAFE Mail Tutorial, please use the Support category of this forum.
Where should I report issues?
If you know which component a bug is associated with, feel free to report it on GitHub in the corresponding repo.
- Report issues with SAFE Browser
- Report issues with SAFE Authenticator
- Report issues with safeApp DOM API
- Report issues with Web Hosting Manager
- Report issues with SAFE Mail Tutorial
New dev tutorial
@hunterlester made a step-by-step guide that explains how he uploaded a file to the network in the video he released last week:
Recruitment
As we have mentioned previously, we continue to be focussed on scaling the development team and we’re pleased to announce continued progress in this area. We recently hired a new core developer, Marcin, and many of you may remember Andrew Cann (@canndrew) who worked with us previously, pleased to report that Andrew will be back with us next week. We also have another core developer in the later stages of our recruitment process so fingers crossed that will work out as well.
On the business side we have 2 new people starting next week, Sharon will replace Linda in finance (Linda moved onto to work for another company) and Victoria will join as the Office Manager, with a focus on recruitment and HR. Victoria’s experience in these areas will enable us to work more effectively with our existing team while enabling us to proactively search for the talent we need moving forward.
And finally, Srinivasan (@srini) joined Krishna’s team yesterday. He’ll be working on continuous integration (CI) and quality assurance (QA). This takes our existing team to 22.
SAFE Authenticator & API
We have been fixing the issues that were raised based on the feedback that we got from the internal testing. Functional issues and many points regarding UI/UX improvements were raised. We have aggregated everything and are scoping it out as tasks in JIRA. The functional issues and minor nitpicks that were raised were fixed this week.
There is an issue which is pending to be addressed in regards to sharing MutableData. The issue has been detailed in the release post yesterday. As said, we will share the approaches with the community for suggestions.
SAFE Client Libs & Vault
As mentioned in the previous update, we’re focusing on adding new configuration options to simplify running local and test networks. This feature is currently being tested and reviewed and should be available soon. We’ve also reviewed and merged the NFS (Network File System) changes, which will streamline APIs for working with files and containers on the network.
Other than that, there hasn’t been much going on in the SAFE Client Libs implementation-wise because a large part of the team is involved in the design process. As hinted in some of the previous dev updates, we’re outlining the details of operation recovery for Mutable Data:
Previously we had operation recovery implemented for Structured Data, but now that this data type is removed, we need to implement the same thing for Mutable Data too. It’s required for composite operations (like revoking an application access) to fail gracefully and in a controllable fashion. For example, when an app is revoked from the authenticator, it’s executed as a sequence of operations rather than a single, atomic request — at least, we need to a) remove the app key from MaidManagers, b) remove the app key from containers permission sets, c) encrypt the containers that the app has access to with a new secret key (so that a possibly malicious app won’t be able to get data after it’s been revoked). But as computer networks operate in the real world, they’re inherently unstable and error-prone, so this sequence of operations can fail at any step, leaving the user’s data in an inconsistent and hard-to-recover state. Considering the multitude of RPC operations available for Mutable Data and its key-value store aspect, it takes some time to come up with a solution that makes it work. We’ve been trying several approaches now and hopefully we can share more details soon.
Routing & Crust
The simulation of Data Chains Option B has been further extended and optimised in a number of ways:
- The usage of RAM has been reduced significantly by making the simulated nodes refer to a common pool of blocks. This allowed for a successful simulation of a network with 300 nodes, which consumed far too many resources before.
- Nodes now manage their connections and are only connected to their own section and the neighbouring ones.
- The blocks that refer to the sections that aren’t our neighbours are now pruned, as would be the case in production, where we wouldn’t want every node to keep a full copy of the chain.
- A proof request algorithm has been introduced. Now, if a node receives a vote that refers to a block unknown to the node, it can ask the sender to prove that the block is indeed valid. It is very useful in cases where a node misses some votes for some reason (for example, because it was joining), as well as in one-sided merges, where some neighbours of the merged section may not receive the appropriate votes.
@qi_ma has been debugging a failing test, messages_during_churn. It failed because a newly joined node handled the section split it incurred in an order that wasn’t expected by our test case. For example, a new node got approved to join Section(0) and received a request targeting the section 0. But then the section splits into Section(00) and the node still handles the older request (targeting the parent section 0). This case wasn’t handled by the test properly and it failed. This is fixed now.
We also improved test coverage for client restrictions (one client per IP address and the rate limiter functionality).
(thanks 
I’m still waiting to see if your slack offline status works 
This is a client-only network (all Vaults are managed by MaidSafe).