tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

formatting 

[Imported from Trac: page Capabilities, version 13]
davidsarah 2011-08-07 15:37:32 +00:00
parent b5abc5c4d9
commit 4021a2daae
1 changed files with 17 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
Capabilities.md

@ -21,15 +21,16 @@ but updated to take into account literal caps and immutable directories:
12: mutable directory verify capability string URI:DIR2-Verifier: 12: mutable directory verify capability string URI:DIR2-Verifier:
13: unknown/future capability strings <anything else> 13: unknown/future capability strings <anything else>
```
In Tahoe-LAFS, mutable directories are built out of mutable files (a mutable directory is really In Tahoe-LAFS, mutable directories are built out of mutable files (a mutable directory is really
just a particular way to interpret the contents of a given mutable file), and just a particular way to interpret the contents of a given mutable file), and
non-directory mutable files aren't used very much. All normal data files are non-directory mutable files aren't used very much. All normal data files are
uploaded into immutable files by default. uploaded into immutable files by default.
Some capabilities can be used to derive others. If you have #1, you can Some capabilities can be used to derive others. If you have !#1, you can
derive #2 (but not the other way around). The full table is: derive !#2 (but not the other way around). The full table is:
```
write read verify write read verify
-------------------- --------------------
#1 -> #2 } #1 -> #2 }
@ -39,27 +40,28 @@ derive #2 (but not the other way around). The full table is:
#7 -> #8 } #7 -> #8 }
#9 } dircaps #9 } dircaps
#10 -> #11 -> #12 } #10 -> #11 -> #12 }
```
Deriving a weaker capability from a strong one is called "diminishing" the stronger one. Deriving a weaker capability from a strong one is called "diminishing" the stronger one.
So we use "filecap" to talk about #1..6, but (since most files are immutable) So we use "filecap" to talk about !#1..6, but (since most files are immutable)
we're usually talking about #1. We use "dircap" to talk about #7..12. we're usually talking about !#1. We use "dircap" to talk about !#7..12.
We use "readcap" to talk about #{1,3,5,7,9,11}, but usually we refer to We use "readcap" to talk about !#{1,3,5,7,9,11}, but usually we refer to
#{7,9,11} as a "directory readcap". We use "writecap" to talk about #4 and #10. !#{7,9,11} as a "directory readcap". We use "writecap" to talk about !#4 and !#10.
A "literal cap" or "LIT cap" stores the contents of a small file (#3) or A "literal cap" or "LIT cap" stores the contents of a small file (!#3) or
directory (#9) in the capability itself. directory (!#9) in the capability itself.
A "verifycap" is the weakest capability that still allows every bit of every A "verifycap" is the weakest capability that still allows every bit of every
share to be validated (hashes checked, signatures verified, etc). That means share to be validated (hashes checked, signatures verified, etc). That means
#{2,6,8,12}. !#{2,6,8,12}.
When we talk about a "repaircap", we mean "the weakest capability that can When we talk about a "repaircap", we mean "the weakest capability that can
still be used to repair the file". Given the current limitations of the still be used to repair the file". Given the current limitations of the
repairer and our webapi, that means we're talking about #{1,4,7,10}. repairer and our web-API, that means we're talking about !#{1,4,7,10}.
Eventually we'll fix this limitation, and any verifycap should be useable as Eventually we'll fix this limitation, and any verifycap should be usable as
a repaircap too. (There's much less work involved to let #2 repair a file or a repaircap too. (There's much less work involved to let !#2 repair a file or
#8 repair a directory... it's just an incomplete API, rather than a fundamental !#8 repair a directory... it's just an incomplete API, rather than a fundamental
redesign of the server protocol.) redesign of the server protocol.)
We then use the somewhat-vague term "rootcap" to refer to a cap (usually a We then use the somewhat-vague term "rootcap" to refer to a cap (usually a
@ -67,8 +69,6 @@ directory write cap) that is not present inside any directory, so the only
way to ever reach it is to remember it somewhere outside of a Tahoe-LAFS way to ever reach it is to remember it somewhere outside of a Tahoe-LAFS
filesystem. It might be remembered in the allmydata.com rootcap database filesystem. It might be remembered in the allmydata.com rootcap database
(indexed by account name plus password), or it might be remembered in a (indexed by account name plus password), or it might be remembered in a
~/.tahoe/private/aliases file, or it might just be written down on a piece `~/.tahoe/private/aliases` file, or it might just be written down on a piece
of paper. The point is that you have to start from somewhere, and we refer of paper. The point is that you have to start from somewhere, and we refer
to such a starting point as a "rootcap". to such a starting point as a "rootcap".
```