diff --git a/proposals/2229-rebind-existing-3pid.md b/proposals/2229-rebind-existing-3pid.md
new file mode 100644
index 00000000..83883c78
--- /dev/null
+++ b/proposals/2229-rebind-existing-3pid.md
@@ -0,0 +1,101 @@
+# Allowing 3PID Owners to Rebind
+
+```
+3PID
+    noun
+
+    A "third-party identifier" such as an email address or phone number, that
+    can be tied to your Matrix ID in order for your contacts outside of
+    Matrix to find you, typically with the help of an identity server.
+
+Identity server
+    noun
+
+    A queryable server that holds mappings between 3PIDs and Matrix IDs.
+
+Bind
+    verb
+
+    Create a mapping between a 3PID and a Matrix ID. Useful for people to
+    find a user based on their existing third-party contact information.
+```
+
+As part of the on-going privacy work, Matrix client applications are
+attempting to make the concept of an identity server clearer to the user, as
+well as allowing a user to interact with multiple identity servers while
+logged in. In facilitating this, Matrix clients should be able to allow
+logged-in users the ability to pick an identity server, see what 3PIDs they
+currently have bound to their Matrix ID, and bind/unbind addresses as they
+desire.
+
+When implementing this functionality, a technicality in the spec was found
+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 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
+
+This proposal calls for allowing 3PID owners to rebind their 3PIDs using 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)
+and [`POST
+/_matrix/client/r0/account/3pid/msisdn/requestToken`](https://matrix.org/docs/spec/client_server/r0.5.0#post-matrix-client-r0-account-3pid-msisdn-requesttoken)
+endpoints by extending the definition of what homeservers should check before
+rejecting a bind.
+
+Homeservers should reject the binding of a 3PID if it has 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 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, so
+this shouldn't be too unintuitive.
+
+## Potential issues
+
+Newer clients will expect homeservers to allow them to switch between
+identity servers and bind/rebind emails as they please. If dealing with an
+older homeserver, clients will receive an `HTTP 400 M_THREEPID_IN_USE`.
+Clients should be prepared to understand that this may just mean they are
+dealing with an old homeserver, versus the 3PID already being bound on this
+homeserver by another user.
+
+## Security considerations
+
+None.
+
+## Conclusion
+
+By lifting the restriction of not allowing a user to bind a 3PID multiple
+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.