From 659880eb1aa2ea453b8d772e565993b8e286e2fb Mon Sep 17 00:00:00 2001
From: amontero <>
Date: Fri, 13 Dec 2013 18:06:21 +0000
Subject: [PATCH] [Imported from Trac: page Capabilities, version 15]

---
 Capabilities.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Capabilities.md b/Capabilities.md
index d58a1f1..d64c3ea 100644
--- a/Capabilities.md
+++ b/Capabilities.md
@@ -59,7 +59,7 @@ share to be validated (hashes checked, signatures verified, etc). That means
 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}.
-Eventually we'll fix this limitation, and any verifycap should be usable as
+Eventually we'll fix this limitation (watch for #568), 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
 redesign of the server protocol.)