They have three sample applications, yet all you can click on is somebody's blog entry. Clicking on the "publishing" app gets you a screenshot of the abstract of someone's paper. It's a single page web site, like all the cool kids have now. Clicking on the top menu items just scrolls the page.
It has MIT and Bernars-Lee behind it, so it can't be totally bogus. If those names weren't on this, I'd assume it was from someone either clueless or crooked.
There's a decent description of Solid on Github.[1] From there, you can see the real problem. It's only useful if the big players adopt it. Which they won't, because it breaks their walled gardens.
This looks like is another try at Bernars-Lee's "semantic web" - hammer as much content as possible into standard formats so it can be machine processed. This is an old idea, and tends to break down once you get beyond contact lists and library catalogs.
There have been major efforts to make that work in the business sector, where it's called "electronic data interchange", and parties want to exchange purchase orders, invoices, and bills of lading.[2] It's worth looking at that area to see how hard this is for even simple-seeming problems like that. And they have cooperation - buyer, seller, and shipper all want that data to flow smoothly between the parties. Trying to do this in today's world of competing closed web empires is much tougher.
The medical data records people have it even worse, I hear.
We wound up implementing something very similar, about the same time (I wish I had known about SOLID earlier), except using CRDTs and graphs (which can support Linked Data). Our implementation is live and functioning already, including:
- Realtime updates across a decentralized network.
- End-to-end encryption with P2P identities.
- Backs up to localStorage/disk (if you Electron-ify/etc. it) - Can also be backed up by remote storage services.
It is as if IPFS and Firebase had a love child, and we've tried really hard to reduce the API to just a couple lines of code to get fully working P2P social netowrking dApps in place.
Check out:
- Intro http://hackernoon.com/so-you-want-to-build-a-p2p-twitter-wit...
- 4min interactive coding tutorial https://scrimba.com/c/c2gBgt4
In our case, we have a tombstone delete method. So as long as every peer that saved your data (and people aren't gonna just save it for free) comes online at some point, after you've nulled/tombstoned the data, then it will be deleted.
This is only true because of our CRDT system that lets you update/mutate data. It is not true or a general property of other decentralized systems though.
I was about to say "but there's no information" but then you added the Github links. Thanks!
I don't see why that's not referenced on the main page. I mean it might be a marketing tool to get funding, but it still needs to have links to same prototypes for the technical audience (even a little github cat logo to the repo would have been good).
Even a non-tech audience would understand a link to "see the spec" and knows what Github is, even if they wouldn't be able to understand any of what's there.
I'm sure when they come back to this they'll change the SHA1 to SHA256 (I'd hope) .. might just do that myself and submit a pull request.
What's wrong with RSA? DSA has been depreciated in most tools. Do you think they should use ECDSA?
This project looks like it has huge potential, I just want to be able to understand at a glance what privacy controls are in place without reading the source code before committing my personal information.
EDIT:
Found the specifications documentation linked to from some of the example apps[0][1]. It would be great to have more of this information on the landing page for the project.
[0] https://github.com/solid/solid-spec
[1] https://github.com/solid/solid/blob/master/README.md