Just to let you guys know, we’ve updated the frontend binaries you’ve been using for the past few days (same location as where the originals were downloaded from). This is just for frontend apps and doesn’t impact accounts held in the network. So you should find your old accounts intact. These changes mainly include fixes based on the feedback from this thread.
Shona is currently working on the UI for the hosting example. I know we say that often and it is hard to not see them as apps when there aren’t many apps around just yet, but the purpose of these examples are to more highlight API features to devs rather than to end users, but that of course doesn’t mean devs cannot get a decent UX 
, which is why we’re working on addressing those issues as well after the browser app itself is sorted.
Change Log:
SAFE Browser: (v0.2.2)
- Resolved multiple unregistered clients being created
- Auth pop-up typo fix in description
- Allow and Deny option will now get pinned to the bottom of the window when text requires scrolling.
- Minimum width and height set for the landing page
- Removed safe-js dependency
- Login page size reworked to fit to screen to prevent the create account link getting hidden in small screen sizes
Email Example: (v0.2.1)
- Can switch between multiple email accounts
- Minor UI updates with loaders
Hosting Example: (v0.1.1)
- Typo fixes
safe_app_nodejs, beaker-plugin-safe-app and beaker-plugin-safe-authenticator updated to use the latest published safe_app and safe_authenticator native libraries
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. - 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 doesnt 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.