As you all most likely know this is no ordinary dev update. This update announces the formal launch of Alpha 2! This release is called ‘the Authenticator’ and focuses on the network access mechanism of the same name. The Authenticator makes a number of improvement over its predecessor (the Launcher) not least mobile support in the shape of Android, which we previewed last week, while iOS support is well underway and will be released in the not too distant future.
The Authenticator, bundled with the SAFE Browser, provides account access control that is now enforced by the network as opposed to the Client. For developers, this release contains more fine-grained access control through the use of smart data types.
We continue to support the 3 major desktop platforms and the tutorial apps for this release are the Web Hosting Manager and SAFE Mail. In addition, on Android we have the Authenticator and SAFE Messages. These are all available to install directly from our new MaidSafe.net site. As you will notice this is a release specific website and hats off to @shona who came through with the design and @shankar for the very speedy implementation. We hope you like it!
As we tick of this next major milestone it would be remiss of us not to thank you all, the SAFE community, who have tested every release we have put out. Your continued feedback is hugely helpful to us. Without the insights this community provides, our releases would not be as usable or as fun to create. Our hats off to each of you from everyone at MaidSafe!
This is a new network, so trying to access data from Test 19 won’t work (you will need to create a new account). We are planning to take Test 19 offline this weekend.
The number of clients per account that can connect at a time has been increased to 8 clients instead of 4.
SAFE Browser v0.9.0
Browse public content and web applications in the SAFE Network using SAFE Browser.
Accounts can be created using the SAFE Authenticator which is bundled with the SAFE Browser. 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 1000 operations. It’s worth noting that 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 alpha network, wiping all data that is stored on it. We will announce this in a dev update (when possible) prior to taking it down.
- Upgrade beaker-plugin-safe-app to v0.4.5
- Upgrade beaker-plugin-safe-authenticator to v0.4.3
safe-node-apphelper constants in DOM API at
- Support providing additional options to
webFetchfunction, e.g. range of bytes
- Generate a handle for each sign key returned by the
listPermissionSetsDOM API function
- Upgrade beaker-plugin-safe-app to v0.4.4
- Upgrade beaker-plugin-safe-authenticator to v0.4.2
- Fix the safeMutableDataEntries.forEach function which was incorrectly returning the ‘key’ as an object
- Allow MutableData handles to be removed from the safe-app plugin’s Map through a ‘free’ function
- Minor fix in the DOM API documentation example for the safeCryptoSignKeyPair.getSecSignKey function
- Upgrade authenticator plugin to v0.4.1.
- Upgrade safe-app plugin to v0.4.3 with change in DOM API as per safe_client_libs API changes.
- Support for providing crust config path with SAFE_CONFIG_PATH env var. in dev mode.
- Issue related to revocation of apps fixed thanks to safe_authenticator upgrade.
- Issue with spending PUTs on each authorisation fixed thanks to safe_authenticator upgrade.
- Some additional automated tests created.
- Additional functions in DOM API are being exposed, e.g. sign keys handling functions, network connection state functions, etc.
- Compatible with Alpha-2 network data.
- Fix the issue with favicons which are now loaded and displayed for safe:// sites.
- Warn the user upon a network disconnection event in the browser, not only from the Authenticator page but in any open tab, and attempt to automatically reconnect every 30 secs if the user doesn’t explicitly do it.
- Assure that when reconnecting to the network, not only the Authenticator connection is re-established but also the ones for the safe_app plugin and the browser app so the browser state can be saved on the network afterwards.
- Functionality to run tests on the DOM API functions within the browser, and creation of a checklist document for manual testing.
- Fix URI scheme registration for dev mode so the browser can receive authorisation requests even when launched with yarn start.
- Minor enhancement to README for Windows build instructions.
- Fix minor issues when fetching sites with a relative path.
- Uses authenticator plugin v0.3.1.
- Uses safe-app plugin v0.3.2.
0.6.0 - 2017-09-21
- Storing history and bookmarks to network
- UI improvements
- uses authenticator plugin v0.3.0
- uses safe-app plugin v0.3.0
- Localisation is not supported.
- Unicode characters are not supported in public IDs, services names, or file names.
- When there is a network latency the browser can freeze for a few moments while it’s trying to communicate with the network for different operations, like reading/saving bookmarks & history entries, loading a website, etc.
Please note we are not supporting either localisation for the apps nor Unicode characters in the public IDs, service names, or file names for the web services, although they are supported in email IDs.
Web Hosting Manager v0.4.4
Manage web hosted contents in the SAFE Network using the Web Hosting Manager. Create services/websites and upload web content that can be hosted in the network. The hosted services can be viewed using the SAFE Browser.
When uploading files using Web Hosting Manager, the maximum file size is 20 MiB per file.
Note: To upload a website, you’ll need to upload the files and folders separately. This is because we added support for uploading subdirectories. Ideally, it would be possible to choose both files and folders at the same time, but it looks like Electron doesn’t provide the upload dialog option which will let users choose files and folders. Hence the current mashup of both options. So to upload your website, you might need to first upload the files from the root of the website by selecting all of them via the upload file feature and then choose the folders via the upload directory feature.
- fix/Make sure that all non-web services are filtered out from the list of services
- Uses safe_app_nodejs v0.5.1
- Compatible with SAFE Browser v0.8.0
- Fix upload website using a template issue
- Add tooltips for icons
- Fix the reconnect icon position
SAFE Mail Tutorial v0.4.3
Send secure messages using Messaging/Email Example app between users. Create an ID and send the messages between users from desktop and mobile.
- The update to
@maidsafe/safe-node-appfixes issue with malformed auth URI’s on Fedora, using default GNOME3 window manager
- Uses safe_app_nodejs v0.5.1
- Compatible with SAFE Browser v0.8.0
SAFE Web API Playground
The SAFE Web API Playground allows any developer to learn and experiment with the DOM API in a friendly and interactive way.
It is meant to help people aiming at creating websites/webapps that need to access the SAFE Network DOM API, which is available on the global
window object in the SAFE Browser.
Instead of having to upload your site to the network every time you want to test some code, you can simply use this tool to experiment and get a deeper understanding of how each API works.
In order to use it, follow the instructions found in its
README, and either upload it as a web app using the Web Hosting Manager application or just run it locally and access it from the SAFE Browser using the now supported
localhost protocol (see above for details).
Demo mobile applications that showcase some of the initial key features of the Alpha 2 SAFE Network. These apps can be used in conjunction with the Alpha 2 desktop apps; the SAFE Browser and the Email/Messaging App.
- Password fields enable a toggle to view credentials
- Android minimum supported version switched to 4.1.2 (API 16)
- Auto reconnect to network on app resume if user specifically opts to choose auto reconnect
- iOS device support has also now been integrated so devs would be able to test these applications on their devices, and we’re working on getting the apps through the application review process so community members will also be able to try these example on their iOS devices
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 Web Hosting Manager
- Report issues with SAFE Mail Tutorial
- Report issues with SAFE App Node.js API
- Report issues with SAFE App DOM API
- Report issues with SAFE Web API Playground
- Report issues with SAFE Mobile Examples
SAFE Authenticator & API
The biggest change this week comes to the Web Hosting Manager app, which has been updated and improved by @shankar and @shona with a new UI and UX. We’ve included some fixes based on the feedback from the previous release, as well as on findings and feedback from our internal testings performed in the last few days to make sure the new version is as stable as the previous one. We believe this new version is not only nicer but also easier for people who never used the tool or the SAFE Network before, since it provides hints of usage in different parts of the tool.
We’ve also set up the foundations of a test suite for the browser DOM APIs, which should help prevent problems as things evolve there. @joshuef has been trying to debug and improve the reliability of the authenticator test suite and npm package issues.
Some minor internal changes which don’t affect the API were made to the
safe_app_nodejs package in order to make use of the latest version of the
safe_client_libs which includes some minor fixes and several internal enhancements as explained in the next section below.
During the next few days, we will continue our efforts on automation of tests and artifacts packaging, and we will start reviewing and discussing tasks we have in our backlog to prioritise them and think of enhancements needed for next releases.
SAFE Client Libs
Yesterday, we released new versions of SAFE Client Libs: safe_app & safe_authenticator have been updated to 0.4.0, safe_core to 0.27.0, and ffi_utils to 0.3.0. These versions are published on crates.io now and they contain all recent changes in SAFE Client Libs.
We wrote a couple of NFS tests this week for reading and writing to files in chunks for MAID-2352 and MAID-2357. We also documented FFI callback parameters throughout our API, making it clear what each variable is, in MAID-2322. Previously they were unnamed, which wasn’t helpful to readers of our documentation. We are still waiting for Issue 44570 to get resolved on the Rust side, but each callback parameter in
safe_app has also been documented in doc comments. In addition, @marcin’s tasks from last week (C header generation and writing missing test cases) have been reviewed and merged.
There were many improvements and refactorings that are not visible on the surface (i.e., the API hasn’t been changed). With the help of the front-end team, we also discovered and fixed a bug in the way we handle the Object Cache, the storage tied to the App object that maps object handles to the actual objects. Currently, the Object Cache is implemented as an LRU cache, meaning the stale objects get freed automatically, and it was implemented in the same way in the SAFE Launcher and REST API times. This approach simplified memory management a lot, but nowadays we have switched from the REST API to the FFI API, and memory management became more straightforward. But the Object Cache remains, and the fact that it is limited to 100 entries for each object type can result in some obscure bugs, e.g. when you try to create more than 100 Mutable Data objects at once. We fixed this by raising that limit to 1000 entries temporarily, and we’ll be looking into resolving this problem in a more general way by switching from the LRU cache to a plain HashMap, thus making it the front-end apps’ responsibility to free stale objects and prevent memory leaks (and the Node.js library already does that, so it should not affect it). Also, @adam found that some FFI functions miss the
catch_unwind wrapper, which could have resulted in Rust panics not caught and propagated to FFI - or, in simple words, in crashing apps and the browser. This issue is fixed by this PR.
We improved error reporting for account creation, to help the user better determine the actions to take to recover from the error. We also fixed a couple of minor bugs that manifested themselves only on the nightly compiler. This compiler is used by docs.rs to generate the API docs, so by fixing those bugs, the docs are now being generated again.
Routing, Vault & Crust
Work this week has again been focused primarily on the design of the message flow. Several ideas have been explored and a lot of effort has gone into finding flaws in these and looking for ones with the potential for later optimisations. A long-standing idea to use a form of Information Dispersal Algorithm to increase the efficiency of message-passing (and perhaps also data-storage) is being explored further. There are still some unresolved issues around this proposal, but we’re hopeful that these can be addressed since the apparent benefits of this approach would be fairly significant.
Over the last couple of weeks, we’ve been improving our implementation of uTP (BitTorrent’s micro transport protocol). It’s now in a usable state and work has now begun on integrating it into Crust. At the moment, this means seeing how our existing code can be refactored as Tokio-style state machines, starting with our NAT traversal library.