Changes between Version 30 and Version 31 of NewCapDesign

Timestamp:

2013-09-11T06:33:51Z (12 years ago)

Author:

zooko

Comment:

"lafs" is more the protocol, "tahoe" is more the Python implementation, second edit

NewCapDesign

@@ -152 +152 @@
    non-word-breaking string. The next best will be to have a large
    non-word-breaking string at the start and end, with smaller segments (if
-   necessary) in the middle. Note that {{{tahoe:}}} is an easy target, but
-   {{{x-tahoe:}}} is not (you'd have to double-click on the "x").
+   necessary) in the middle. Note that {{{lafs:}}} is an easy target, but
+   {{{x-lafs:}}} is not (you'd have to double-click on the "x").
  * Usable in a browser. Specifically, it should be easy to actually use a
    filecap that you get in email or IM, and many email/IM clients will look
    for http URLs and make them clickable. If tahoe filecaps start with
    {{{http:}}}, then they'll be made clickable. This is at odds with the
-   IANA-friendly {{{tahoe:}}} prefix. Clients may make {{{tahoe:}}} URIs
+   IANA-friendly {{{lafs:}}} prefix. Clients may make {{{lafs:}}} URIs
    clickable too (I've seen them make other letters-then-colon strings
    clickable, even when the letters are not "http"), so perhaps a reasonable
-   solution is to provide an OS-level URI handler for the {{{tahoe:}}}
+   solution is to provide an OS-level URI handler for the {{{lafs:}}}
    scheme, which could embed the filecap in an http URL and submit it to a
-   webbrowser (i.e. when you click on {{{tahoe:foo}}}, a helper program is
-   launched with {{{tahoe:foo}}}, and that in turn launches your web browser
+   webbrowser (i.e. when you click on {{{lafs:foo}}}, a helper program is
+   launched with {{{lafs:foo}}}, and that in turn launches your web browser
    with {{{http://localhost:8123/foo}}}). (#52)
 
@@ -217 +217 @@
   * in addition, tahoe URIs should be distinguishable from local filenames by
     a CLI tool, so that {{{tahoe cp $CAP local/foo.txt}}} is unambiguous.
-    (unfortunately, the current practice of using "tahoe:" as a default alias
+    (unfortunately, the current practice of using "lafs:" as a default alias
     name collides with this badly, but perhaps if the new URIs include the
     double-slash, this won't be a problem:
-    {{{tahoe cp tahoe://CAP local/foo.txt}}} copies from a specific URI,
-    while {{{tahoe cp tahoe:blah local/foo.txt}}} copies from a child of
-    the "tahoe:" alias).
+    {{{tahoe cp lafs://CAP local/foo.txt}}} copies from a specific URI,
+    while {{{tahoe cp lafs:blah local/foo.txt}}} copies from a child of
+    the "lafs:" alias).
 '''Note that double-slash means "there is a naming authority" (see RFC 3986). I think most people's understanding of caps is that there is no naming authority (i.e. a remote server which you completely rely on to decide what value a name within its domain should denote). I suppose we might fit the semantics of RFC 3986 if we claim that the thing we have there (which will probably be a crypto value derived in complex ways from the plaintext of the file and/or a public key) *is* a naming authority.'''
   * I'd like to make it easy to layer uses on top of one another: since
@@ -228 +228 @@
     (mutable) file, let's make the directory cap be closely related to the
     underlying filecap. For example, if we end up using
-    {{{tahoe://MR/cryptobits}}} to describe a read-only mutable file
+    {{{lafs://MR/cryptobits}}} to describe a read-only mutable file
     referenced by "cryptobits", then we could use
-    {{{tahoe://D/MR/cryptobits}}} for the directory that uses it as a backing
-    store. The rule would be that {{{tahoe://D/$A}}} would be handled by
-    fetching {{{tahoe://$A}}} and then interpreting its contents as a
+    {{{lafs://D/MR/cryptobits}}} for the directory that uses it as a backing
+    store. The rule would be that {{{lafs://D/$A}}} would be handled by
+    fetching {{{lafs://$A}}} and then interpreting its contents as a
     directory structure. Then reading immutable-dirnodes (#607) would be
     trivial. Another way to think about this is that if our filecaps were
     verbose s-expressions, these caps could be expressed as "(readonly
     (mutable cryptobits))" and "(directory (readonly (mutable cryptobits)))".
-  * Don't provide an affordance for diminishing caps by editing them, or else make sure that the actual effect of doing so is the same as the intended effect. This actually happened to an LAE customer: they sent us a transcript of their shell session which had their write cap init, and they truncated off the right-hand side of the cap, intending to thus preserve confidentiality of their data. Unfortunately for them, the right-hand side of the (current) write cap format is the integrity-checking bits, not the write-authority bits! The remaining left-hand-side of the cap that they sent was enough to let us (or anyone else who saw their mail) read and overwrite all of their files. This wouldn't have happened if the cap had been a compact thing with no visible separations, like "tahoe:WD1WDDy975ZJkrU7XZTxAB39kmnfxYk3zDb", or if it had been ordered so that the most powerful bits were right-most.
+  * Don't provide an affordance for diminishing caps by editing them, or else make sure that the actual effect of doing so is the same as the intended effect. This actually happened to an LAE customer: they sent us a transcript of their shell session which had their write cap init, and they truncated off the right-hand side of the cap, intending to thus preserve confidentiality of their data. Unfortunately for them, the right-hand side of the (current) write cap format is the integrity-checking bits, not the write-authority bits! The remaining left-hand-side of the cap that they sent was enough to let us (or anyone else who saw their mail) read and overwrite all of their files. This wouldn't have happened if the cap had been a compact thing with no visible separations, like "lafs:WD1WDDy975ZJkrU7XZTxAB39kmnfxYk3zDb", or if it had been ordered so that the most powerful bits were right-most.
  * provide for verifycaps, repaircaps, and traversalcaps (#308, #217).
    Repaircaps in particular may require a grant of storage authority, which
@@ -251 +251 @@
    ciphertext. It should be possible to upload ciphertext directly.
  * provide for a grid-identifier, possibly on the MSB end, e.g.
-   {{{tahoe://grid1234/IR/cryptobits}}}. Perhaps let some contexts define a
-   "default grid id", such that {{{tahoe://IR/cryptobits}}} is expanded to
-   mean {{{tahoe://grid1234/IR/cryptobits}}}. Something like
-   {{{tahoe://grid1234/D/MR/cryptobits}}} should reference
-   {{{tahoe://grid1234/MR/cryptobits}}}. (#403)
+   {{{lafs://grid1234/IR/cryptobits}}}. Perhaps let some contexts define a
+   "default grid id", such that {{{lafs://IR/cryptobits}}} is expanded to
+   mean {{{lafs://grid1234/IR/cryptobits}}}. Something like
+   {{{lafs://grid1234/D/MR/cryptobits}}} should reference
+   {{{lafs://grid1234/MR/cryptobits}}}. (#403)
  * permit multiple encodings of the same file (same k, different N) to use
    each other's shares (#678, #711)