Take into account the 1 is case

proposals/2229-rebind-existing-3pid.md

@@ -29,19 +29,28 @@ currently have bound to their Matrix ID, and bind/unbind addresses as they
 desire.
 
 When implementating this functionality, a technicality in the spec was found
-to prevent the ability to bind the same 3PID to multiple identity servers.
-The line "The homeserver must check that the given email address is **not**
-already associated with an account on this homeserver." appears under the
-[POST
+to prevent certain abilities for a user. A user could not add a 3PID to their
+homeserver before binding it to an identity server. It also prevents users
+from binding the same 3PID to multiple identity servers. The line "The
+homeserver must check that the given email address is **not** already
+associated with an account on this homeserver." appears under the [POST
 /_matrix/client/r0/account/3pid/email/requestToken](https://matrix.org/docs/spec/client_server/r0.5.0#post-matrix-client-r0-account-3pid-email-requesttoken)
 endpoint description. The same goes for the [equivalent msisdn (phone)
 endpoint](https://matrix.org/docs/spec/client_server/r0.5.0#post-matrix-client-r0-account-3pid-msisdn-requesttoken).
 
-When a user binds their 3PID through a homeserver to identity server A, the
-homeserver keeps a record and attaches the address to the local account.
-Then, if the user switches to identity server B to try and do the same, the
-homeserver will reject the second request as this address has already been
-bound.
+When a user adds an email to their account on their homeserver, they can
+choose to bind that email to an identity server at the same time. This is
+specified through a `bind` boolean. If the user first adds the 3PID with
+`bind: false`, then decides they want to bind that 3PID to an identity server
+to make themselves discoverable by it, by making another request with `bind:
+true`. The homeserver will reject the second request, because this 3PID is
+already tied to the user's account.
+
+Similarly, when a user initially sends their 3PID with `bind: true` through a
+homeserver to identity server A, the homeserver keeps a record and attaches
+the address to the local account. If the user then switches to identity
+server B to try and do the same, the homeserver will reject the second
+request as this address has already been bound.
 
 ## Proposal
 
@@ -56,15 +65,16 @@ Homeservers should reject the binding of a 3PID if it already been bound,
 **unless** the requesting user is the one who originally bound that 3PID. If
 so, then they should be able to bind it again and again if they so choose.
 
-In doing so, users would be able to bind their 3PIDs to multiple identity
-servers, even if the homeserver has already been made aware of it.
+In doing so, users would be able to rebind their 3PIDs, even if the
+homeserver has already been made aware of it.
 
 ## Tradeoffs
 
 Identity servers will still let 3PIDs be rebound to another Matrix ID, while
 a single homeserver won't let a 3PID transition between two users. If one
 thinks about typical internet services however, you aren't allowed to simply
-take an email address from another account even if you have control of it.
+take an email address from another account even if you have control of it, so
+this shouldn't be too unintuitive.
 
 ## Potential issues
 
@@ -86,7 +96,9 @@ None.
 ## Conclusion
 
 By lifting the restriction of not allowing a user to bind a 3PID multiple
-times, we unlock the ability to interact with multiple identity servers on
-the same account. This not only allows the user to play around and gain a
-better understanding of the purpose of an identity server, but it is also one
-step towards further decentralisation in the identity server space.
+times, we allow the basic ability of publishing a 3PID after associating it
+with an account, as well as allow users to interact with multiple identity
+servers on the same account with the same 3PIDs. This not only allows the
+user to play around and gain a better understanding of the purpose of an
+identity server, but it is also one step towards further decentralisation in
+the identity server space.