line wrap and fix wording

proposals/2134-identity-hash-lookup.md

@@ -53,7 +53,12 @@ Then, clients making a request to `/lookup` must use the hashing algorithm
 defined in whichever version of the CS spec they and the IS have agreed to
 speaking.
 
-Identity servers can specify their own peppers, which can be handy if a rainbow table is released for their current one. Identity servers could also set a timer for rotating this value to further impede rainbow table publishing. As such, it must be possible for clients to be able to query what pepper an identity server requires before sending it hashes. Thus a new endpoint must be added:
+Identity servers can specify their own peppers, which can be handy if a rainbow
+table is released for their current one. Identity servers could also set a
+timer for rotating this value to further impede rainbow table publishing. As
+such, it must be possible for clients to be able to query what pepper an
+identity server requires before sending it hashes. Thus a new endpoint must be
+added:
 
 ```
 GET /_matrix/identity/v2/lookup_pepper
@@ -81,15 +86,15 @@ Thus, a call to `/bulk_lookup` would look like the following:
   "threepids": [
     [
       "email",
-      "user@example.org"
+      "vNjEQuRCOmBp/KTuIpZ7RUJgPAbVAyqa0Uzh770tQaw"
     ],
     [
       "msisdn",
-      "123456789"
+      "0VnvYk7YZpe08fP/CGqs3f39QtRjqAA2lPd14eLZXiw"
     ],
     [
       "email",
-      "user2@example.org"
+      "BJaLI0RrLFDMbsk0eEp5BMsYDYzvOzDneQP/9NTemYA"
     ]
   ],
   "pepper": "matrixrocks"
@@ -143,13 +148,14 @@ that needs updating every time a new bind is made. Further considered solutions
 are explored in https://signal.org/blog/contact-discovery/ Signal's eventual
 solution of using SGX is considered impractical for a Matrix-style setup.
 
-Bit out of scope for this MSC, but there was an argument for not keeping all
+While a bit out of scope for this MSC, there has been debate over preventing
-IDs as hashed on disk in the identity server, that being if a hashing algorithm
+3pids as being kept as plain-text on disk. The argument against this was that
-was broken, we couldn't update the hashing algorithm without having the
+if the hashing algorithm (in this case SHA-256) was broken, we couldn't update
-plaintext 3PIDs. Well @toml helpfully said that we could just take the old
+the hashing algorithm without having the plaintext 3PIDs. Well @toml helpfully
-hashes and rehash them in the more secure hashing algorithm, thus transforming
+added that we could just take the old hashes and rehash them in the more secure
-the algo from ex. SHA256 to SHA256+SomeBetterAlg. This may spur an MSC in the
+hashing algorithm, thus transforming the hash from SHA-256 to
-future that supports this, unless it is just an implementation detail.
+SHA-256+SomeBetterAlg. This may spur on an MSC in the future that supports
+this, unless it is just an implementation detail.
 
 ## Conclusion