diff --git a/RFCs/MEOW_RFC_0001.md b/RFCs/MEOW_RFC_0001.md
new file mode 100644
index 0000000..e872b45
--- /dev/null
+++ b/RFCs/MEOW_RFC_0001.md
@@ -0,0 +1,73 @@
+# MEOW protocol RFC 0001
+
+Last updated 2026-02-25
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119.
+
+## Status
+
+RFC 0001 has not been adopted and SHOULD NOT be considered final, binding, or even that good of an idea. We gotta start somewhere though.
+
+## Abstract
+
+RFC 0001 describes a method of storing and sending messages, so that accounts (used for authentication and encryption) and alters / user infos (used for information like display names, profile pictures, pronouns, descriptions, etc) are decoupled, and stored separately on the homeserver.
+
+## Description
+
+For the purposes of this document, let "account" refer to the data structure used for authentication by the server, and let "alter" refer to a data structure, the details of which are beyond the scope of this RFC, containing cosmetic user data, such as display name, profile picture, pronouns, bio, accent color, or similar.
+
+RFC 0001 proposes that messages SHALL contain, as part of their data, both an account UUID and an alter UUID. Thus, a message object would look something similar to the following:
+
+```
+{
+	"sender-account": "ACCOUNT-UUID-HERE",
+	"alter": "ALTER-UUID-HERE",
+	"message": {message payload data structure, beyond the scope of this RFC}
+}
+```
+
+This entire message object MUST then be end-to-end encrypted, rendering it only readable to those to whom it is sent. In addition, since the alter UUID is encrypted alongside the message, the alter is only visible to those to whom the message is sent.
+
+Alters MUST be stored on the same homeserver as the accounts they belong to. In addition, homeservers MUST NOT expose an API allowing for fetching all alters from an account, except by the account that owns them; all requests for alters by accounts other than those the alter belongs to MUST be by UUID. Thus, the users file on the homeserver might look something like this, though with specifics not yet finalized:
+
+```
+{
+	"users": [
+		{
+			"publickey": "JUNE-PUBLICKEY-HERE",
+			"uuid": "JUNE-UUID-HERE",
+			"rooms": [
+				"groupchat-summer",
+				"groupchat-winter"
+			]
+			"alters" : [
+				{
+					"uuid": "ALTER-A-UUID-HERE",
+					"name": "june",
+					"pronouns": "she/her"
+				},
+				{
+					"uuid": "ALTER-B-UUID-HERE",
+					"name": "july",
+					"pronouns": "it/its"
+				},
+				{
+					"uuid": "ALTER-C-UUID-HERE",
+					"name": "november",
+					"pronouns": "they/them"
+				}
+			]
+		}
+	"
+}
+```
+
+To see what this would entail, we consider what various parties can see in a hypothetical scenario: assume the JUNE account (the example above) is in 2 rooms: groupchat-summer and groupchat-winter. Furthermore, assume both groupchats are hosted on separate homeservers, and the JUNE account is on a third. JUNE sends a message to groupchat-summer as "july", and a second as "june". JUNE then sends a message to groupchat-winter as "november".
+
+All of JUNE's messages to groupchat-summer and groupchat-winter MUST be end-to-end encrypted, so neither the message content nor the alter used are exposed to either of those homeservers. The other members of groupchat-summer can decrypt JUNE's messages, which provides them with the UUIDs for the alters "june" and "july", allowing them to fetch the corresponding details from JUNE's homeserver (and, assuming a competently-designed client, cache those details for future messages). However, as long as JUNE does not send a message as "november" to groupchat-summer, the members will not be able to get the UUID of, or even discern the existence of, the "november" alter. Similarly, the members of groupchat-winter will be able to decrypt JUNE's messages and subsequently fetch the "november" alter, but will not be able to fetch "july" or "june" since they will not have the necessary UUID.
+
+Note that, while secure from outsiders, a member of groupchat-summer could share the UUID of "june" or "july" with a member of groupchat-winter, allowing them to discern its existence. The author of this document deems such a possibility a non-issue; it exposes the same information as a screenshot of groupchat-summer, albeit with the possibility of confirmation via a request to JUNE's homeserver.
+
+---
+
+by june@linuxpost.ing