diff --git a/proposals/3915-owner-power-level.md b/proposals/3915-owner-power-level.md
new file mode 100644
index 00000000000..71776173c39
--- /dev/null
+++ b/proposals/3915-owner-power-level.md
@@ -0,0 +1,71 @@
+# MSC3915: Owner power level
+
+## Problem
+
+Matrix today does not distinguish between 'room admins' who have permission to do privileged operations in a room
+(set PLs, ACLs, tombstones, history visibility, encryption, create/remove moderators)... and the 'owners' aka 'founders'
+of a room, who have overall responsibility and ownership for it and appoint (and deappoint) admins to help them run it.
+
+As a result, it's common for a room founder to promote a set of users to be admins at PL100 to share responsibility
+for administering the room... but then regret that they have effectively relinquished ownership of the room, given there
+is no way to revoke admin permissions (short of coercing the other admins to demote themselves).
+
+This is particularly problematic for users migrating from other communities such as Discord or even IRC where room
+permissions distinguish owner from admin, and so apply the same terminology in Matrix, accidentally promoting users to
+admin thinking they can revoke it (despite the UI warnings to the contrary).
+
+Finally, the current workaround of having to manually assign 'admins' to PL99 and manually rewrite the PL event
+thresholds is incredibly uninuitive and bad UI (for instance, many clients will show the PL99 as 'Moderator' in the UI,
+confusing it with PL50).  Moreover, you can't apply the workaround in retrospect; the owner either has to create a
+whole new room with the correct permissions or anticipate the problem before you accidentally assign a user to PL100.
+
+This closes the embarassingly long-standing https://github.com/matrix-org/matrix-spec/issues/165 spec issue, and
+replaces the previous flawed [MSC3510](https://github.com/matrix-org/matrix-spec-proposals/pull/3510) proposal.
+
+## Proposal
+
+ * We expand the recommended range of PLs to 0-150, with 150 described as 'Owner'.
+ * The room creator defaults to PL150.
+ * We tighten the language in the spec which says "Clients may wish to assign names to particular power levels." to
+   specify the threshold names more concretely, to avoid divergent implementations.
+
+Everything else stays the same (e.g. the `trusted_private_chat` prefix would still give invited users Owner too, to
+share ownership of the DM with them).
+
+This clearly differentiates owners from their delegated admins, is compatible with existing rooms without a room version
+bump, and lets clients implement cmopletely different UI for appointing/deappointing admins to the special-case of
+transferring/sharing ownership.
+
+## Potential issues
+
+None?
+
+## Alternatives
+
+ * We could add an `owner` field or `owners` field to the PL event. However, this breaks compatibility, and has no
+   obvious benefit from simply having a higher PL number for owners.
+
+ * We could redeclare the Admin PL threshold to be 75 or 99 or similar, thus showing all existing Admins as being Owners
+   in the UI.  However, this will cause confusion with older clients, as well as confusion over users being seen to
+   apparently suddenly changing power levels.  It's better to reflect the current reality: that historically we haven't
+   had the concept of owners, rather that retconning the historical admins into being owners.
+
+ * We could workaround it with an 'adminbot' with PL100, which is the sole robot owner of the room, and ensures that
+   human admins don't accidentally promote each other.  This is a horrible hack, given the protocol itself should
+   intrinsically support basic features such as access control.
+
+ * We could ignore it, and try to educate admins into understanding that admin = owner, and they should set custom PLs
+   if they want something else.  In practice this simply hasn't worked, hence this MSC.
+
+## Security considerations
+
+Clients or servers which incorrectly assume that PLs range from 0 to 100 may get confused.  This would clearly be
+an implementation bug however.
+
+## Unstable prefix
+
+None
+
+## Dependencies
+
+None