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.
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 (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: safe://webid.josh.
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.](###Link to detailed data)
It is this WebId Profile document that we link to via our subdomain RDF-MD...
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:
https://gist.github.com/2336a2fabf594efd50b118f3f4a854bb
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 (although you'll need to access it via [the new RDF APIs](###LINK TO APIS)) to parse it out easily.
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
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.)
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:
window.currentWebId.
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.
window.webIdEventEmitter
Each time the tab's WebId is updated, an event is triggered in the DOM. Here's how patter.js handles it.
https://gist.github.com/3923db6c3b004519c2e5747794b86edc
And with this, you're ready to update your app with a user's desired identity. Pull in names, profile images, or their inbox. With these POCs, you're really free to just build a great decentralised application. No need to worry about your infrastructure, APIs, or login/authentication of users. Just build.