Too bad they mostly seem to be focusing on go (for local) and google app engine (for remote) implementations. That's probably a serious barrier to excitement for most people I know, even if they plan to encourage other implementations in the future.
Go isn't the project's choice. It's my personal choice as I continue to love the language. The project encourages all languages.
At least, the broader principles:
* Disk is cheap and getting cheaper
* Put the user in control. Own your data.
* Privacy and paranoia
* Decentralization is important, but..
* End users won't be dorks. Must also be possible to be easy, hosted.
* Content-Addressability has so many awesome properties (validation, cachability, etc). Use it as much as possible.
* Redundancy and over-explicitness is fine. Compression will help. Redundancy and over-explicitness will be convenient for future digital archeologists, too.
If you don't look through the whole website, at least skim their vision for use cases: http://camlistore.org/docs/uses
The single feature of being able to keep a private store of different web services could make this really take off for a lot of people.
Then I looked at the camlistore sharing model. The proposal involves storing private data in blobs camlistore, protecting it behind a 401, and requiring the client to append a ?via=hash-2, where hash-2 is a claim that says "ok, let this data through". I'm not a big fan of that, because proxies won't reproduce your security model, and private data is stored in the clear.
What one should do, really, is store private data encrypted. Then, you can reference a "phantom blob", which is not actually an object in storage but represents the cleartext of the private data. Your claim could now be a recipe on how to reconstruct this phantom blob, i.e. get chunk X of ciphertext and decrypt it with this key.
Now, dumb proxies won't just store sensitive stuff in the clear (although, they would store enough data that the plaintext could easily be reconstructed), but at least your security model is preserved.
I spoke to Brad and Brett at OrdCamp here in chicago this weekend and it sounded pretty interesting. They plan to make the tooling around this hide the difficulties in dealing with public private keys from the average user. I suppose if it's done right this could do for sharing content what SSL did for Commerce on the web.
This is probably just a temporary notation, but perhaps it's clear enough for ongoing use?
Optional/required is handled by comments; JSON "[ ]" syntax indicates lists - but it's unclear if the contents represent a repeated group, like (abc)* , or alternatives, like (a|b|c)*; alternatives in general don't seem to be handled - in general, alternatives could also appear as the value of a field, not just in a list.
I've been working on a distributed, Venti-like archival filesystem, too. While plan9 never really caught on, it had many great systems within it that really deserve wider exposure.