diff --git a/docs/webkeys.md b/docs/webkeys.md
index 7cfb215..80fe68c 100644
--- a/docs/webkeys.md
+++ b/docs/webkeys.md
@@ -78,9 +78,13 @@ fragment and the pattern got its standard form.
   minted by `newUniqueId()`, never derived from anything; all the
   authority, none of the log-trail
 - diigo-cache's ids are already webkeys in substance (bearer secrets);
-  the honest deviations, both known: keys travel in **POST bodies**
-  rather than fragment+XHR — same leak profile, simpler under a
-  form-driven UI with no skeleton page; and a hash of the id would
+  the cache page now follows the paper's form — `/cache/#<key>`, a
+  skeleton page, its script passing the key to the server — with the
+  XHR replaced by a [Cap'n Web](https://github.com/cloudflare/capnweb)
+  call that takes the key *in-band*, as a method argument
+  (`api.cache(key)`), returning a capability. The forms elsewhere still
+  carry keys in **POST bodies** (same leak profile as the fragment). A
+  hash of the id would
   stand in wherever log-correlation is wanted (the swissHash
   discipline; `shashKey`, whose prefix is also the on-screen
   fingerprint). The bug that prompted this note: a cache id briefly