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

wiki syntax 

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

8
Capabilities.md

@ -46,19 +46,19 @@ Deriving a weaker capability from a strong one is called "diminishing" the stron
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 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.
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.
A "literal cap" or "LIT cap" stores the contents of a small file (!#3) or
directory (!#9) in the capability itself.
A "verifycap" is the weakest capability that still allows every bit of every
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
still be used to repair the file". Given the current limitations of the
repairer and our web-API, 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 usable as
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