We’re excited to announce an update to the SAFE Browser and are releasing version v0.11 today. Since migrating from the original SAFE Browser (a fork of the Beaker Browser) to the Peruse (Electron) version, we’ve been working at improving the user experience and adding functionality. This update focuses on three main areas:

SAFE Browser (v0.11)

Example applications using experimental APIs

Updated DOM API (safe-app-nodejs v0.10.3)

Download it now!

You’ll also need the latest Web Hosting Manager if you want to upload sites to the network!

Gabriel (@bochaco) & Josh (@joshuef) walk us through the update in the sections that follow.

SAFE Browser

We’ve been working to improve the UX of the browser in a few key areas. We’ve clarified the experimental nature of some features we brought on board as part of the RDF proof of concept apps, and on the whole just improved the browser’s stability.

General enhancements and issues fixed

Some enhancements have been made to the icons and visual components of the address bar, along with some fixes to the functionality of the navigation buttons (backward/forward buttons). We’ve resolved some 35+ issues for this new release, most of them were bugs, but many others are functional enhancements or minor features added to the Browser. There’s also been a large internal refactor of the Browser’s SafeApp code, which now uses one safeApp instance (instead of two!) for handling the communications with the SAFE Network for authorisation of applications, and for fetching files that belong to websites/webapps being accessed by the user. Please see the following sections for more details of new main features, and you can always check out in the changelog for a full list of the changes made for this version of the SAFE Browser: https://github.com/maidsafe/safe_browser/blob/master/CHANGELOG.md

Visual Indicator for Mock Network connection

We’ve added a visual indicator showing if you, the user, is connected to the Mock network.

There are two different packages of the SAFE Browser, one is for connecting to the Alpha2 network, and a second one intended to be used by developers which works with a Mock network. With this new version of the SAFE Browser we are introducing an enhanced visual indicator in the address bar, on the left hand side of the URL address bar as shown in the image below. Therefore, if you are not seeing this red label in the browser, it means you are connected to the live Alpha2 network! This is a very important feature since it makes sure the user can be fully aware that in the case of using the Mock network the data won’t be stored in the secure, autonomous and decentralised SAFE Network, but just in a local temporary file.

Experimental APIs/features toggle exposed

This is one of the major new features being introduced by this version of the SAFE Browser. In many circumstances there are features and/or APIs being developed which are not fully finalised, or perhaps, the functionality can still change in the future as things evolve. In this case it’s very beneficial to get community feedback early in the process, allowing them to use, test, play and provide feedback about these new features. As such, we’ve exposed a toggle to enable/disable these types of experimental features or APIs, while at the same time clearly labelling the fact that they are still in an experimental stage. Every time this toggle is switched on/off, all tabs will be refreshed automatically. These experimental features and APIs are by default not enabled when the browser is launched, this is to make sure the user is aware of the fact that the Browser and webapps/websites could be using experimental features and/or APIs when they are explicitly being enabled. You can find the toggle on a new menu located on the right hand side of the address bar, as shown in the following image:

Visual indicator showing if the experimental APIs and features are enabled

As explained above, with this version of the SAFE Browser, any feature or API which is in an experimental state or in early stages of development will only be available after switching the toggle from the right hand side options menu. When the user enables this, a visual indicator will be displayed on the right hand side of the URL address bar. If you don’t see this indicator, experimental APIs are not enabled or available to neither the browser nor to any website/webapp.

The WebID switcher is now hidden when the experimental APIs are not enabled

The WebID switcher/selector exposed in the browser makes use of some experimental APIs, and it’s in itself still in an experimental stage, therefore this feature is only exposed in the browser when the experimental APIs are enabled using the toggle from the options menu as detailed above. This is the only feature currently being exposed as experimental in the browser.

Access any type of data using XOR-URLs

The new DOM API allows not only SAFE applications to link/reference any MutableData/ImmutableData on the Network using its XOR-URL, but also the SAFE Browser is now able to fetch any website, webapp, or random file from the Network using a XOR-URL. Even HTML tags can reference content from a src attribute using XOR-URLs, e.g. an image tag can have a XOR-URL in the src attribute, and the Browser is capable of fetching and rendering it as usual.

As shown in the following screenshots, the SAFE Browser is capable of decoding the XOR-URL to extract the location of the content, content type (if the mimeType is also encoded in the XOR-URL), fetch it, and render it accordingly as it does with any publicName-URL (i.e. the URLs which make use of the SAFE DNS system). A good resource to learn and understand a bit more about XOR-URL (as a user) is available within the XOR-URL tutorial where it explains different cases for how to share websites and files with publicName-URLs and XOR-URLs, just access the following safe-URL and follow the links: safe://xorurl.tutorials.

For more details/information about the XOR-URLs you can read the proposed RFC, the discussions taking place in our dev forum, or by watching this screencast.

Note:

The experimental APIs need to be enabled for this feature.

There is a known issue with the browser considering a XOR-URL invalid when the typeTag part is greater than 65535 (see issue #429)

A MutableData viewer

When a URL (either publicName-URL or XOR-URL) is targeting a MutableData, which happens to not have an ‘index.html’ file, or which is probably not even a files container (a.k.a. an NFS container) but simply a MutableData created by any application to store data on the network, a MutableData viewer is rendered by this version of the SAFE Browser. This web-based viewer displays the list of MutableData entries, showing the key, version and value of each of them, and it also displays the permission sets defined for such a MutableData. This is a very basic first version, which can hopefully evolve into a SAFE data browser in the future (You can see some ideas being discussed around this in the screencast as well):

Example applications using experimental APIs

Patter: File sharing

Note: The experimental APIs need to be enabled for this feature.

Share files with Patter (safe://patter.dapp) by attaching them when publishing a new post on some WebID’s wall. This version of Patter now works with the new SAFE Browser features, allowing users to link a file with every post which is displayed as a XOR-URL link that can be clicked to view the attached/shared file (or download it, depending on the content type). Note that the Patter application needs the experimental APIs to be enabled in the SAFE Browser to function correctly:

WebIDs: compliant with linked-data standard

WebIDs (safe://webidmgr.dapp) are now fully compliant with linked-data standard using URLs for all contained links (e.g. image/avatar and inbox links):

Web API Playground Tool

The API Playground Tool (safe://playground.dapp) has been updated to work with the new experimental APIs and it provides more examples for users to get to grips with them! Remember that you need to enable the experimental APIs from the SAFE Browser using the toggle to be able to use these APIs within the tool.

The SAFE Toolbox:

Introducing the The SAFE Toolbox (safe://toolbox.dapp) which provides the following three tools:

safe-URL analyser

If you’re curious about what data is hiding inside of the new XOR-URL, what type of content is being referenced by either a XOR-URL or a publicName-URL, you can paste any safe-URL in this tool and get the decoded output.

subName remapper

We are painfully aware of the PUT limit which can cause issues maintaining a SAFE website at a specific Public Name. As such, with this tool any account can be used to remap a given Public Name to any other XOR-URL or publicName-URL. This means that you can even upload an updated version of a website with a new/different account, but remap a Public Name owned by another account to point to it (and only costing two PUTs!), saving accounts precious PUTs on data upload. We’ll be using this tool internally to help keep Patter and the WebIdManager webapps published at the same Public Name, no matter how many times we update it! (well… up to 500 times, 2 PUTs each time from a 1000 PUT limit).

JSON to MutableData

Another simpler tool to help anyone quickly get some JSON data onto the Network to make some tests and play around with the APIs. This will perform all the basic MutableData saving steps to give you some live network data, along with the XOR-URL of the newly created MutableData.

Updated DOM API

The safe_app_nodejs package has been upgraded to v0.10.3. This new version 0.10.x of the safe_app_nodejs package exposes a set of experimental APIs behind a flag/option that can be set by any application, and it’s what the browser does when the user decides to switch the toggle. Once the user has enabled the experimental APIs using the toggle from the options menu, any website/webapp open in a tab can make use of the exposed experimental APIs. The complete list of changes made in the safe_app_nodejs package can be seen in its changelog, the following is a summary of the experimental APIs available and the purpose of each of them:

XOR-URLs can be obtained for any ImmutableData and MutableData on the Network

As mentioned above, applications can now fetch any MutableData/ImmutableData from the Network using its XOR-URL. The APIs are now capable of generating and returning the XOR-URL for any MutableData and ImmutableData the application has access to. For more details/information about the XOR-URLs you can reference directly from the proposed RFC, from the discussions taking place in our dev forum, or by watching this screencast. The following snippets are examples of how an application can obtain the XOR-URL for a MutableData and an ImmutableData respectively:

Get MutableData XOR-URL

const typeTag = 15015; const md = await safeApp.mutableData.newRandomPublic(typeTag); await md.quickSetup({ key1: 'value1', key2: 'value2' }); const info = await md.getNameAndTag(); console.log('MutableData\'s XOR-URL:', info.xorUrl);

Get ImmutableData XOR-URL

const imdWriter = await safeApp.immutableData.create(); const cipherOpt = await safeApp.cipherOpt.newPlainText(); await imdWriter.write('my text'); const getXorUrl = true; const info = await imdWriter.close(cipherOpt, getXorUrl); console.log('ImmutableData\'s XOR-URL:', info.xorUrl);

RDF Emulation API

It allows applications to create and manipulate data in RDF format. Using this API the applications can see data as RDF triples. The API takes care of then storing the data on the network, and the developer doesn’t need to worry about how to serialise/format it to store it or fetch it from the Network. The following snippet shows how an application can emulate a MutableData as an RDF and make use of this API:

Emulate MutableData as RDF

const typeTag = 15015; const md = await safeApp.mutableData.newRandomPublic(typeTag); await md.quickSetup(); const rdfEmu = await md.emulatedAs('RDF'); const uri = 'safe://hunter'; const hunter = rdfEmu.sym(uri); rdfEmu.setId(uri); const foaf = rdfEmu.namespace('http://xmlns.com/foaf/0.1/'); rdfEmu.add(hunter, foaf('knows'), 'Josh'); rdfEmu.add(hunter, foaf('knows'), 'Gabriel'); await rdfEmu.commit(); const rdfJsonLd = await rdfEmu.serialise('application/ld+json'); console.log('RDF serialised as JSON-LD:', rdfJsonLd);

WebID API

Abstraction for creating/updating WebIDs on the SAFE Network, even allowing the application to publish them with a publicName-URL (“safe://…”). Analogously to the RDF APIs, the developer doesn’t need to take care of either the serialisation for the data or how to fetch and/or store the WebIDs on the Network. As can be seen in the following snippet, the API also takes care of using the expected RDF schema/ontology as defined by the WebID spec:

Generate and store a WebID on the SAFE Network

const profile = { uri: 'safe://mywebid.mypubname', name: 'My Name', nick: 'My Nickname', website: 'safe://mywebsite.mypubname', image: 'safe://mywebsite.mypubname/images/myavatar', }; const typeTag = 15015; const md = await safeApp.mutableData.newRandomPublic(typeTag); await md.quickSetup(); const webId = md.emulateAs('WebID'); await webId.create(profile); const webIdTurtle = await webId.serialise(); console.log('WebID serialised as Turtle:', webIdTurtle);

Fetch data using publicName-URLs or XOR-URLs

Apart from the webFetch function which can be used to retrieve content compatible for an HTTP client, like the browser, it is now also possible to use the fetch function for retrieving a MutableData or ImmutableData from a URL, and be able to use the MD/IMMD API to manipulate it e.g. for mutating entries in a MutableData fetched with a URL. The following snippets shows how a MutableData can be fetched using its XOR-URL and apply a mutation to its entries:

Fetch MutableData with XOR-URL

const typeTag = 15015; const md = await safeApp.mutableData.newRandomPublic(typeTag); await md.quickSetup({ key1: 'value1', key2: 'value2' }); const info = await md.getNameAndTag(); const mdResource = await safeApp.fetch(info.xorUrl); const mutation = await safeApp.mutableData.newMutation(); await mutation.insert('key3', 'value3'); await md.applyEntriesMutation(mutation);

Web Hosting Manager

With this new browser/safe-app version, you’ll need a new version of the Web Hosting Manager to be able to upload sites to the network.

Providing Feedback

As always, we’re looking to hear from you. If you think that we can improve on any of the features then please get in touch.

If something isn’t meeting your expectations then it’s probably best to log it as an issue on GitHub.

Section GitHub Issues SAFE Browser Issues https://github.com/maidsafe/safe_browser/issues API / Node.js issues https://github.com/maidsafe/safe_app_nodejs/issues WebID App https://github.com/maidsafe/safe-web-id-manager-js/issues Patter Web App https://github.com/maidsafe/safe-patter-js/issues

General Feedback

If you’ve got any general comments or feedback that you’d like to give us then simply post a reply to this topic.

Timescales

We’ll be looking to address all issues in as timely a manner as possible but sometimes we’ve got to prioritise one issue over another so our responses may not come straight away. Please note that the office will be shut between 25th December - 1st January but we’ll be checking for replies on a regular basis and we’ll get back to you as soon as we possibly can.