An overview of WebId’s and RDF data use on SAFE.
Recently we published some proof of concepts (POCs) showcasing the use of semantic data on The SAFE Network.
We’ve taken the idea of using WebIds for online identity management and applied it to The SAFE Network.
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 publicName system.
Authentication
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…
‘Just’ Data
A WebId profile document, is a set of data describing a person or entity (name, nickname, email for example), and to be valid it has to have a resolvable URL. On SAFE, once we have content addressable data (something we're aiming to implement soon), any Mutable or Immutable Data (see the devHub for more on these datatypes) could have such an address. For now though, we're using SAFE's 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 subdomain RDF-MD...
Subdomains
Each publicName on SAFE points to a Mutable Data xorname, and it's this Mutable Data which is effectively a map of <subdomain>: <services>.
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).
Friendly Domains
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 xorname).
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
Helpers
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 publicNames, fetch 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’ app.web.getWebIds() function.)
Using WebIds
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, currentWebId has been updated. This is a javascript object that contains the full profile document data.
Each time the tab’s WebId is updated, an event is triggered in the DOM. Here’s how patter.js handles it.
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.
If you’re interested in finding out more about The Safe Network, head on over to the DevHub or join us on the forums!
