diff --git a/ServerSelection.md b/ServerSelection.md
index 096ad21..6aac865 100644
--- a/ServerSelection.md
+++ b/ServerSelection.md
@@ -20,11 +20,11 @@ would be pretty easy to make the uploader use different classes according to
 a `tahoe.cfg` option.
 
 However, there are some additional properties that need to be satified by the
-sever-selection algorithm for it to work at all. The basic Tahoe model is
+server-selection algorithm for it to work at all. The basic Tahoe model is
 that the filecap is both necessary and sufficient (given some sort of grid
 membership) to recover the file. This means that the eventual
 **downloader** needs to be able to find the same servers, or at least have
-a sufficiently-high probability of finding "enough" servers within a
+a sufficiently high probability of finding "enough" servers within a
 reasonable amount of time, using only information which is found in the
 filecap.
 
@@ -37,12 +37,12 @@ track down and update all of the old shares: the chance of accidental
 rollback increases when it cannot reliably/cheaply find them all.
 
 Another potential goal is for the download process to be tolerant of new
-servers, removed servers, and shares which have been moved (possibly as the
+servers, removed servers, and shares that have been moved (possibly as the
 result of repair or "rebalancing"). Some use cases will care about this,
 while others may never change the set of active servers and won't care.
 
 It's worth pointing out the properties we were trying to get when we came up
-with the current "tahoe2" algorithm:
+with the current "TahoeTwo" algorithm:
 
  * for mostly static grids, download uses minimal do-you-have-share queries
  * adding one server should only increase download search time by 1/numservers
@@ -52,7 +52,7 @@ with the current "tahoe2" algorithm:
  * traffic load-balancing: all non-full servers get new shares at the same
    bytes-per-second, even if serverids are not uniformly distributed
 
-We picked the pseudo-random permuted serverlist to get these properties. I'd
-love to be able to get stronger diversity among hosts, racks, or data
-centers, but I don't yet know how to get that **and** get the properties
-listed above, while keeping the filecaps small.
+We picked the pseudo-random permuted serverlist [on the [StorageIndex](StorageIndex)]dependent
+to get these properties. I'd love to be able to get stronger diversity among
+hosts, racks, or data centers, but I don't yet know how to get that **and**
+get the properties listed above, while keeping the filecaps small.