This has showcased not only how self-authentication can simplify a lot of problems thrown up by the clearnet (see authentication below). But also how SAFE can lend itself to zero infrastructure app development, allowing anyone to easily build decentralized apps, that scale.
Here we’ll be talking through some of the data structures on SAFE that provide for our WebId POC.
What this means is that via a
url only, you can easily identify yourself on the network to applications, and provide information to those applications about yourself (like, eg... where your inbox is).
Now with this WebId setup, we’re using a standard RDF data setup and FOAF read more on RDF here and FOAF here. So I won’t dive into the whys of those. And you can see above an idea of how this could be beneficial.
What I am going to go into is where we’re storing WebId RDF data on SAFE, and how this all works with our
Before we get into the meat of data management, it’s worth noting how you authorise your WebIds on SAFE.
On the clearnet you’ll need a compatible SOLID server, certificates and a browser set up to use them. (See the wiki for more info)
On SAFE we avoid this complexity as all of your data is secured by the Self-Authentication system. Meaning your data is securely decentralised, without any need for servers to verify against, all you need to control your WebIds is to log in!
So on SAFE, WebId becomes much much simpler to use. It’s just data in the end…
A WebId profile document, is a set of data describing a person or entity (
publicName system to provide an easy, decentralized, human readable domain system. So your profile document is referenced from your domain, giving you a nice URL to give to people.
_That_ WebId Data
The WebId data itself can be represented thus (if you’re into JSON):
This is stored in a
#me graph of your profile document which is an RDF emulation of Mutable Data (more info on RDF on SAFE can be found over here).
It is this WebId Profile document that we link to via our
publicName on SAFE points to a Mutable Data
xorname, and it's this Mutable Data which is effectively a map of
So, for example the data stored could be:
www : <NFS container xorname>, // link to website data on the network
@email : <email inbox xorname>, // link to a MD used as an inbox,
myid: <WebId xorname>
Right now, with our WebId Proof of Concept (POC) branch, of safe_app_nodejs, the subdomain MD is an RDF-MD (and so self describing 🎉), which functions in much the same manner as RDF on the clearnet (though the best way to access it is via this fork of safe_app_nodejs’s RDF APIs).
On SAFE our DNS system is simply this subdomain MD, but it is located at the
sha3 hash of the domain name (which resolves to be a valid network
That’s how we achieve human-friendly URLs. For each
publicName that we create a reference is saved in the
_publicNames container of the user, so they can locate their MD (which only they have permissions to manage), for updating subdomains and onwards, services.
All of which enables us to easily store and reference your WebId at a human friendly url. And with this url, you can access yours, or other people’s identities. And interact with them via our simple social app
One final portion of the new WebId setup has been the use of a ‘directory’ to help with finding WebIds (to prevent having to iterate over and decrypt
subdomains and then check each
service to see if it's a profile document!)
So we opted to store each WebId created as a key in the
public container, providing an easy reference point for getting all WebIds (which can be done via the new DOM APIs’
Once we’d figured out just how to store WebIds on the network, we then faced a question of just how the hell would a user manage their new found identities (assuming they’d created some via the web-id-manager).
To this end, we implemented a dropdown in Peruse (our SAFE browser) to allow users to ‘select’ a webId for a tab to use. (The Peruse browser itself uses the above
getWebIds() to retrieve this list.)
And with this, we implemented another method for web apps to easily get a provided WebId from the DOM. So web apps don’t actually have to worry about managing WebIds at all, they can focus on consuming the data. No need to request permissions to
_public container if you don't need it!
There are two ways that WebIds are passed into the DOM:
If a WebId has been set or updated on the tab,
window.webIdEventEmitter.once( 'update', ( webId ) =>
console.log('WebId updated!', webId)
And with this, you’re ready to update your app with a user’s desired identity. Pull in names, profile images, or their inbox location.
With the WebId proof of concept applications and apis, you’re really free to concentrate on building a great decentralised application. You don’t need to worry about infrastructure, REST APIs servers, or user authentication. Just build.