CIMBA decoupled the front end of the web application from the back end data such that the data can exist on any server and the front end application can exist on another server. Sandro Hawke posted several videos beginning with the title "Building Social Applications with Linked Data Platform (LDP) -- Crosscloud"
Part 2 of this video series  shows a demonstration of CIMBA by Dr. Andrei Sambra.
Although CIMBA was targeted towards microblogging, the personal data store can be targeted at any front end application. For microblogging, and other applications, a special standard pattern is developed that utilizes the linked data platform ,.
SOLiD, a platform that gained a lot of energy in mid-2015 with the Crosscloud project , is described on GitHub  and serves as a foundation in the initiative. It follows the Linked Data Platform standard that is used to build the LDP server Apache Marmotta  and in Fedora 4 in Islandora  for organizing library collections, amongst other things. One thing that is unique about SOLiD is its use of the WebID URI in the authentication and authorization process.
Athough many implementations of SOLiD exist , the one with present significant effort is for Node.js. This is available through the link at .
In a previous post , the use of databox.me to create a WebID, client certificate, and private key was presented. This is useful for authenticating as a user to a SOLiD based server and authorizing the user to access resources through the access control language .
In order to launch our own SOLiD server, we need a server side certificate to support HTTPS in order to verify the servers integrity to the client . We could run it without TLS/SSL, that is over HTTP, but this is risky. For proof of this, the author has run a SOLiD server (previously called ldnode) with a Linked Data File Manager called WARP ; and achieved an environment on localhost (i.e. on the local machine) that looked very similar to rww.io when it was operational.
Fortunately, the README for node-solid-server  goes into how to set this up. We already created a client side certificate and private key with databox.me and stored it in our browser. The public personal profile document created upon databox.me signup and used for FOAF+SSL authentication is available at http://bshambaugh.databox.me/profile/card .
To create the server side certificate (as opposed to the client side certificate to authenticate an entity with a WebID) to allow the SOLiD server to serve itself over HTTPS we have multiple options. We could purchase one online signed by a root certificate authority , obtain a free one through a service like letsencrypt , or create our own self-signed certificate with openssl (or the like).
Since we are testing SOLiD locally, lets try using a server side certificate. The README  suggests the following commands:
openssl genrsa 2048 > ../localhost.key
openssl req -new -x509 -nodes -sha256 -days 3650 -key ../localhost.key -subj '/CN=*.localhost' > ../localhost.cert
This creates a private key called localhost.key and a certificate called localhost.cert in the directory above the local one. I went ahead and added the extension .pem to both of them since they are already in the PEM  format.
cp localhost.key localhost.key.pem
cp localhost.cert localhost.cert.pem
Now that we have our server certificates, we need to have node-solid-server running. In order to do this, we need Node.js v6. I chose to also have the latest version of Ubuntu, 16.04 to run Node. N.B: I was running with Ubuntu 12.04 before but I discovered that this required a special configuration as the version of g++ included with the distribution did not support some of the recent additions in v8 requiring me to configure for another C compiler .
I found the instructions at Digital Ocean useful , specifically the section titled "How To Install Using NVM" .
Once I have Node.js Installed I can install node solid server. I do this by following the instructions in the README . Specifically:
npm install -g solid-server
Now that I have solid server installed with the -g flag (which means I can access it globally) I can tell it about my server side certificates. There are two ways to do this.
I can either use the solid-server installation to create a json file to point to them, or I can tell solid about then at each startup.
To create the json  file I use the following command:
I then follow by pressing enter for each input request except for those that prompt with a y/N option or a path the SSL private key or SSL certificate.
For the y/N options I select y (at least for "Enable WebID authentication"). For the path to the SSL certificate and SSL key I point to the relative path to them. Since the ones I created were in the present directory where initiated solid with "solid init" then they are simply localhost.key (or localhost.key.pem) and localhost.cert (or localhost.cert.pem or localhost.crt.pem, or localhost.crt) .
Going through this process creates a file called config.json . After this I can go ahead and start the solid server from the same directory using the command:
Alternatively, I may want to avoid using the config.json file and pass everything in as an input parameter in the shell at startup. I found it effective to delete the config.json file (if it exists) before trying this.
solid start ---port 8443 --ssl-key localhost.key.pem --ssl-cert localhost.cert.pem \
I am specifying port 8443, localhost.key.pem as private key for my server certificate, localhost.cert.pem as the server certificate, use of webid based authentication with --webid, and verbose output in the shell with -v .