From 6c727660fa75b477d7a12aea95cc022614c54cd1 Mon Sep 17 00:00:00 2001
From: davidsarah <>
Date: Sun, 7 Aug 2011 15:38:32 +0000
Subject: [PATCH] wiki syntax

[Imported from Trac: page Capabilities, version 14]
---
 Capabilities.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Capabilities.md b/Capabilities.md
index 5d2d482..d58a1f1 100644
--- a/Capabilities.md
+++ b/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