A new release of the SAFE Browser (v0.8.0) compatible with the Alpha 2 network has now been published. The changes are mostly related to the safe_app/DOM APIs while also improving the developer experience. We are also releasing new versions of the example applications, which have been updated to work with the latest API changes. See last week’s update for a summary of the API changes.
All changes were at the API level and they were planned to be backward compatible with the data that is already present in the Alpha 2 network, i.e. the emails or safe:// websites in Alpha 2 should be readable/accessible with these new versions without any problems. This means you should be able to use your existing Alpha 2 account to log in and access apps you had previously authorised.
Note that web apps may not work though, or partially work, as they’ll need to adapt to the few changes in the DOM API. Also, previous versions of the example apps won’t be able to connect to the network when receiving an authorisation URI from the new browser (v0.8.0) since they will face serialisation errors.
Changelog
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.
@whiteoutmashups, we would like to help if you have trouble in building the apps against mock. However, the mock version of the hosting app is hosted here. OSX is not uploaded yet. Will request @Shankar to upload the OSX mock version of the hosting app.
For browser it makes sense to have a mock version hosted because that is an application by itself and very much an integral part of the ecosystem. Also have nightly builds as we move forward.
Example apps are expected to be built by the devs. Example applications can be of a varied range and supplying mock versions for everything would be difficult. Since there is no other application at this point of time, we are building the mock versions for helping devs. Ideally, we would like the devs to build the mock versions themselves. We are more than happy to help if there is a problem building the applications.
This exercise would help the devs understand how the dependencies are managed, so that they can cater something similar to switch between mock/non-mock when they build applications.
Following the instructions in the README should help building the example apps. If there is something that is not working as explained in the README, then we will like to identify and resolve the issue. Only based on the feedbacks we can improve better. Hence, I would strongly encourage to try building the apps.
@Krishna_Kumar that makes sense except for the web_hosting app, at least in my opinion. Because it’s literally the only way anyone can upload anything to the network, which is essential when building anything, like web apps.
If devs only have the browser, they can’t make functional websites for SAFE.
I’m updating my website Demo App like I had for Alpha 1, which should allow for uploading through the browser via my website, but it’s not finished yet so the issue persists.
One can also use node to create a local server and test web apps without uploading to the mock network, as described here : How to develop for the SAFE Network (draft) - General - Safe Dev Forum
It is quite faster than uploading everything each time, but then you lack domain names, ID managment, and have to work on localhost://p:
This isn’t true, see @nice reply above. It’s much easier to use mock browser without uploading you website/web app, so Web Hosting Manager mock-routing build is not needed.
Apart from saving you the trouble of uploading every time you want to test a change, you can also set things up to automatically rebuild your Web app whenever you save an edit to your disk. I forget what that’s called, but it is very neat (‘live rebuild’ or something - available with webpack for example).
Having said all that, I’m still unable to do this with my RemoteStorage.js web apps because of a bug in electron, so I have to debug those apps live on alpha2 still. I’m hoping this will be OK with my Solid PoC but am not at that point yet, just starting to code.
Thanks @nice, gulp is another tool (like webpack) which supports this. I think the term I’m looking for is probably ‘live rebuild’ or something close.
Another thing which devs will find useful, especially if using the tools to bundle and minify their JavaScript or other source code, are source maps because these let you debug the bundle as if it were the original, nicely formated separate source files. Very useful for bigger projects.
Thank you for the surprise release
wonderful to see how things go forward and everything evolves =)
to login. Then select “Alpha-2” and you will be presented an invitation token.