Sharing

TODO: finish documenting this.

The basic summary is that you create a claim that a user has access to something, and then your blobserver's public frontend authenticates (if applicable) a remote user and gives them access as permitted by your claim.

Reproducing an email from this thread for some background:

*

This is an example walk-though of (working) sharing on Camlistore. Brett and I got this working last night (the basic "have a link" use case with no addition auth)

Let's say I have a private blobserver:

http://camlistore.org:3179/

And I have a file, "Hi.txt".

Its bytes are blob sha1-3dc1d1cfe92fce5f09d194ba73a0b023102c9b25
Its metadata (inode, filename, etc) is blob sha1-0e5e60f367cc8156ae48198c496b2b2ebdf5313d

You don't have access to those, even though you know their names. Verify the 401 errors:

http://camlistore.org:3179/camli/sha1-3dc1d1cfe92fce5f09d194ba73a0b023102c9b25
http://camlistore.org:3179/camli/sha1-0e5e60f367cc8156ae48198c496b2b2ebdf5313d

(hm, those are returning Unauthorized errors, but no Content Body... will fix later)

Note also that any errors you get from my private blob server always delay for at least 200 ms to mask timing attacks that could otherwise reveal the existence or non-existence of a blob on my private server.

Now I want to share Hi.txt with you, so I create a share blob (e.g camput --share ).

I've created this, and its name is sha1-071fda36c1bd9e4595ed16ab5e2a46d44491f708

Note that you can fetch it without authentication, because my blobserver knows I have it and that it's a share blob that doesn't require auth (authType == "haveref" ... like "Share with others that have the link")

Here's you getting the blob:

$ curl http://camlistore.org:3179/camli/sha1-071fda36c1bd9e4595ed16ab5e2a46d44491f708
{"camliVersion": 1,
  "authType": "haveref",
  "camliSigner": "sha1-f019d17dd308eebbd49fd94536eb67214c2f0587",
  "camliType": "share",
  "target": "sha1-0e5e60f367cc8156ae48198c496b2b2ebdf5313d",
  "transitive": true
,"camliSig":"iQEcBAABAgAGBQJNQJGuAAoJEIUeCLJL7Fq1EuAIAL/nGoX8caGaANnam0bcIQT7C61wXMRW4qCCaFW+w67ys5z4ztfnTPKwL9ErzMF8Hd32Xe/bVcF6ZL38x/axqI7ehxN8lneKGQNoEdZDA9i752aAr0fkAba6eDehoOj9F4XxOzk3iVrq445jEXtu/+twamHV3UfRozWK1ZQb57dM+cRff47M/Y6VIBRSgW2BrABjuBs8G6PiKxycgh1mb+RL8f9KG+HB/yFuK37YJqZ0zU2OTRp6ELiOgTxbeg99koV9Duy4f4mQgxQgli46077Sv/ujzIeVbmdFL3OenGEzQnyKG0fhf8fa5WkED0XfH7zibAHLiSq3O7x11Q0406U==ANug"}

Note the "target" and "transitive".

Now we present this proof of access in subsequent requests in the "via" parameter, with the in-order path of access.

Here's the first hop to the metadata, in which we discover the blobRef of the bytes of the file (in this case, just one part is the whole file bytes...) I already told you this earlier in the email, but assume you're just discovering this now.

$ curl http://camlistore.org:3179/camli/sha1-0e5e60f367cc8156ae48198c496b2b2ebdf5313d?via=sha1-071fda36c1bd9e4595ed16ab5e2a46d44491f708
{"camliVersion": 1,
  "camliType": "file",
  "contentParts": [
    {
      "blobRef": "sha1-3dc1d1cfe92fce5f09d194ba73a0b023102c9b25",
      "size": 14
    }
  ],
  "fileName": "Hi.txt",
  "size": 14,
  "unixGroup": "camli",
  "unixGroupId": 1000,
  "unixMtime": "2011-01-26T21:11:22.152868825Z",
  "unixOwner": "camli",
  "unixOwnerId": 1000,
  "unixPermission": "0644"
}

Now let's get the final bytes of the file:

$ curl http://camlistore.org:3179/camli/sha1-3dc1d1cfe92fce5f09d194ba73a0b023102c9b25?via=sha1-071fda36c1bd9e4595ed16ab5e2a46d44491f708,sha1-0e5e60f367cc8156ae48198c496b2b2ebdf5313d
Hello, Camli!

That's it.

Now imagine different authType parameters (passwords, SSL certs, SSH, openid, oauth, facebook, membership in a group, whatever... )