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 2 It takes about 30 days of being active on the forum to become Trust Level 2. See this topic for more information
To obtain an invitation token, Trust Level 2 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 SAFE Browser v0.3.0 on GitHub
ChangelogIntegrates authenticator addonsafe_app API injected as DOM APIsCompatible with Test 17
Known limitationsHistory 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
ChangelogSAFE Mail Tutorial updated to be compatible with authenticatorWeb Hosting Manager example addedSAFE Mail can support multiple email IDsCompatible with Test 17
Known limitationPublic 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.
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 BrowserReport issues with SAFE AuthenticatorReport issues with safeApp DOM APIReport issues with Web Hosting ManagerReport issues with SAFE Mail TutorialHow to upload a file to the network
This will be a step-by-step guide for uploading a file to the network and be able to view it in SAFE browser. You can always simply use web hosting manager to upload files to the network, however, if you go through this tutorial, you'll learn a...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.
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:
Here are some of the topics you can expect to see on the Dev Forum in the next few days/weeks:
[…] Operation recovery for Mutable Data from the network. So a transaction-based process (for some operations initially) to allow rollback in case of failed operations midway (this one is likely going to take a while longer as the guys are still in the early stages of working out the details)
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).