From 7ee1f5f85b674dbd5ddaf946b66d9e544632f01b Mon Sep 17 00:00:00 2001 From: Logan Devine Date: Mon, 30 Mar 2026 15:00:40 -0700 Subject: [PATCH 1/7] MSC4441: Encrypted User Profile Annotations via Account Data --- proposals/4441-user-profile-annotations.md | 129 +++++++++++++++++++++ 1 file changed, 129 insertions(+) create mode 100644 proposals/4441-user-profile-annotations.md diff --git a/proposals/4441-user-profile-annotations.md b/proposals/4441-user-profile-annotations.md new file mode 100644 index 00000000000..2b1e5f16f6b --- /dev/null +++ b/proposals/4441-user-profile-annotations.md @@ -0,0 +1,129 @@ +# MSC4441: Encrypted User Profile Annotations via Account Data + +Many platforms, such as Discord, provide a capability for a user to leave personal "notes" on a user's profile. Matrix, +however, has no similar functionality that can be shared between clients. This proposal builds User Profile Annotations, +a method of storing personal context on other users' profiles. This is made possible using a new `m.profile_annotations` +Account Data event, allowing the storage of free text (and other annotations) for a user's reference. + +The framework introduced within this MSC builds upon [Extensible Events][MSC1767] and provides room for future extension +into other forms of user context, such as contact labels or custom nickname overrides. The content stored within these +annotations is also encrypted using an account secret scoped specifically for account data. + +## Proposal + +### Plaintext `m.profile_annotations` + +A new event, `m.profile_annotations`, is stored in [`account_data`][account_data]. The `content` of this event is a JSON +mapping between MXIDs (user or room IDs) and annotations stored on that user/room. Within a user, the `m.text` +property represents a text annotation ("note") on that user. It follows the text format as defined in [MSC1767][MSC1767]. + +```json +{ + "@logn:zirco.dev": { + "m.text": [ + { "body": "Hello world", "mimetype": "text/html" }, + { "body": "Hello world" } + ] + } +} +``` + +### Account Data Key (ADK) + +A new secret, `m.account_data.key` is stored in [SSSS][SSSS]. This secret is 256 bits of cryptographic random data used +as the secret in HKDF when encrypting profile annotations (and potentially, in the future, other forms of account data). + +`m.account_data.key`: + +```json +{ + "encrypted": { + "key_id_1": { + "ciphertext": "...", + // ... other properties according to key_id_1's algorithm + } + } +} +``` + +### Encrypted `m.profile_annotations` + +Using the ADK bytes introduced above, contents of `m.profile_annotations` can be encrypted using +[`m.secret_storage.v1.aes-hmac-sha2`][SS_crypto]. The info property of the HKDF is the value `m.profile_annotations`, +an ASCII `/`, concatenated with the MXID of the user it represents (e.g. `m.profile_annotations/@logn:zirco.dev`. + +This encryption is applied individually to the Canonical JSON contents of each user's annotation. It MAY be mixed +alongside plaintext data. An example of the event `content` follows: + +`m.profile_annotations`: +```json +{ + "@logn:zirco.dev": { + "encrypted": { + "iv": "...", + "ciphertext": "...", + "mac": "..." + } + } +} +``` + +## Potential issues + +#### SSSS availability +Many users have not enabled SSSS. This would potentially require a client to either fall back to plain text or force a +user to set up SSSS to use encrypted annotations (not desired). Alternatively the ADK could be stored on the client. + +#### Concurrent writes +Account data is last-write-wins. The usage of one key representing all users may lead to a data race in rare scenarios +(although this tradeoff was accepted to keep the behavior similar to existing state like `m.direct`). + +## Alternatives + +#### Store annotations as a new API endpoint +Rather than using `account_data`, a new dedicated endpoint for annotations would be created. Rejected because it +requires substantial serverside changes for a simple interop. + +#### Encrypt the entire event as one blob +Rejected because encrypting each user's data individually allows for finer grained control, alongside providing +compatibility to users with no SSSS. + +#### Eliminate the ADK and simply use the SSSS master +Using the SSSS master would require re-encrypting notes and potentially change how users may interface with client +access to this information. Introducing a new key, potentially usable in the future for more information, is far +simpler. + +## Security considerations + +- The SSSS model does not provide forward secrecy in the case of key compromise. +- Plaintext fallback may not be immediately obvious to clients. + +## Trust and Safety considerations + +Profile annotations are the property of one singular user and are never shared with others by the server. Still, a +server does not gain any moderation visibility into the content potentially being hosted and accessible to their users. + +Because these are never transmitted, there should be no method for an annotated user to be harmed. + +## Future extensibility + +In the future, this MSC may be built on to implement nickname or avatar overrides, general user tagging functionalities, +etc. + +## Unstable prefix + +Before this MSC is accepted, implementations should use the unstable `account_data` events: + +| Stable identifier | Purpose | Unstable identifier | +| ----------------------- | ---------------------------------------- | --------------------------------------- | +| `m.profile_annotations` | Storage of User Profile Annotations | `dev.zirco.msc4441.profile_annotations` | +| `m.account_data.key` | ADK secret storage for encrypted content | `dev.zirco.msc4441.account_data.key` | + +## Dependencies + +None. + + [MSC1767]: https://github.com/matrix-org/matrix-spec-proposals/pull/1767 + [account_data]: https://spec.matrix.org/v1.18/client-server-api/#client-config + [SSSS]: https://spec.matrix.org/v1.18/client-server-api/#secrets + [SS_crypto]: https://spec.matrix.org/v1.18/client-server-api/#msecret_storagev1aes-hmac-sha2-1 From 65560f9f1eec43bf5f07891f2a07a1b8a61a7936 Mon Sep 17 00:00:00 2001 From: Logan Devine Date: Tue, 31 Mar 2026 10:19:18 -0700 Subject: [PATCH 2/7] adjust wording and clarify requirements --- proposals/4441-user-profile-annotations.md | 57 +++++++++++++--------- 1 file changed, 35 insertions(+), 22 deletions(-) diff --git a/proposals/4441-user-profile-annotations.md b/proposals/4441-user-profile-annotations.md index 2b1e5f16f6b..ec13cb4c182 100644 --- a/proposals/4441-user-profile-annotations.md +++ b/proposals/4441-user-profile-annotations.md @@ -1,7 +1,10 @@ # MSC4441: Encrypted User Profile Annotations via Account Data Many platforms, such as Discord, provide a capability for a user to leave personal "notes" on a user's profile. Matrix, -however, has no similar functionality that can be shared between clients. This proposal builds User Profile Annotations, +however, has no similar functionality that can be shared between different clients. This proposal builds User Profile +Annotations, a method for storing encrypted, private metadata on user and room profiles. + +This proposal builds User Profile Annotations, a method of storing personal context on other users' profiles. This is made possible using a new `m.profile_annotations` Account Data event, allowing the storage of free text (and other annotations) for a user's reference. @@ -11,12 +14,19 @@ annotations is also encrypted using an account secret scoped specifically for ac ## Proposal +This proposal introduces a new `m.profile_annotations` Account Data event, allowing the storage of free text (and other +future annotations) on users. The framework introduced within this MSC builds on [Extensible Events][MSC1767] and +provides room for future extension into other forms of user context, such as contact labels, custom nickname overrides, +or annotations on rooms. + ### Plaintext `m.profile_annotations` -A new event, `m.profile_annotations`, is stored in [`account_data`][account_data]. The `content` of this event is a JSON -mapping between MXIDs (user or room IDs) and annotations stored on that user/room. Within a user, the `m.text` +A new event, `m.profile_annotations`, is stored in [`account_data`][account_data]. The `content` of this event MUST be a +mapping between valid user MXIDs or room IDs and annotations stored on that user/room. Within a user, the `m.text` property represents a text annotation ("note") on that user. It follows the text format as defined in [MSC1767][MSC1767]. +Unknown keys within user annotations MUST be ignored. + ```json { "@logn:zirco.dev": { @@ -30,8 +40,9 @@ property represents a text annotation ("note") on that user. It follows the text ### Account Data Key (ADK) -A new secret, `m.account_data.key` is stored in [SSSS][SSSS]. This secret is 256 bits of cryptographic random data used -as the secret in HKDF when encrypting profile annotations (and potentially, in the future, other forms of account data). +Clients MAY choose to store a new secret, `m.account_data.key` within [SSSS][SSSS]. The secret key is 256 bits of +cryptographic random data used as the secret in HKDF when encrypting profile annotations (and potentially, in the +future, other forms of account data). `m.account_data.key`: @@ -50,10 +61,13 @@ as the secret in HKDF when encrypting profile annotations (and potentially, in t Using the ADK bytes introduced above, contents of `m.profile_annotations` can be encrypted using [`m.secret_storage.v1.aes-hmac-sha2`][SS_crypto]. The info property of the HKDF is the value `m.profile_annotations`, -an ASCII `/`, concatenated with the MXID of the user it represents (e.g. `m.profile_annotations/@logn:zirco.dev`. +an ASCII `/`, concatenated with the MXID of the user it represents (e.g. `m.profile_annotations/@logn:zirco.dev`). + +This encryption is applied individually to the Canonical JSON contents of each user's annotation. Not all user keys +within the event must be encrypted: some may still contain plaintext data, however a user annotation MUST NOT contain +both encrypted and plaintext data. -This encryption is applied individually to the Canonical JSON contents of each user's annotation. It MAY be mixed -alongside plaintext data. An example of the event `content` follows: +An example of the event `content` follows: `m.profile_annotations`: ```json @@ -64,16 +78,17 @@ alongside plaintext data. An example of the event `content` follows: "ciphertext": "...", "mac": "..." } + }, + "@sky:codestorm.net": { + "m.text": [ + { "body": "Hello, world" } + ] } } ``` ## Potential issues -#### SSSS availability -Many users have not enabled SSSS. This would potentially require a client to either fall back to plain text or force a -user to set up SSSS to use encrypted annotations (not desired). Alternatively the ADK could be stored on the client. - #### Concurrent writes Account data is last-write-wins. The usage of one key representing all users may lead to a data race in rare scenarios (although this tradeoff was accepted to keep the behavior similar to existing state like `m.direct`). @@ -82,33 +97,31 @@ Account data is last-write-wins. The usage of one key representing all users may #### Store annotations as a new API endpoint Rather than using `account_data`, a new dedicated endpoint for annotations would be created. Rejected because it -requires substantial serverside changes for a simple interop. +requires substantial serverside changes, this MSC aims to be entirely clintside. #### Encrypt the entire event as one blob -Rejected because encrypting each user's data individually allows for finer grained control, alongside providing -compatibility to users with no SSSS. +Rejected because encrypting each user's data individually allows for finer grained control, alongside preventing the +need to decrypt large blobs of data when viewing only a singular user's profile. #### Eliminate the ADK and simply use the SSSS master -Using the SSSS master would require re-encrypting notes and potentially change how users may interface with client -access to this information. Introducing a new key, potentially usable in the future for more information, is far -simpler. +Using the SSSS master would require re-encrypting notes whenever recovery keys change. Using a separate ADK is +extensible for further `account_data` events, alongside providing the ability to rotate the ADK independently of SSSS. ## Security considerations - The SSSS model does not provide forward secrecy in the case of key compromise. -- Plaintext fallback may not be immediately obvious to clients. +- Plaintext fallback may not be immediately obvious to users if their note contents are not encrypted. ## Trust and Safety considerations Profile annotations are the property of one singular user and are never shared with others by the server. Still, a server does not gain any moderation visibility into the content potentially being hosted and accessible to their users. - -Because these are never transmitted, there should be no method for an annotated user to be harmed. +Because the content is scoped to only a singular user, this is acceptable. ## Future extensibility In the future, this MSC may be built on to implement nickname or avatar overrides, general user tagging functionalities, -etc. +annotations on rooms, etc. ## Unstable prefix From 3c05a84e88becf5755eab0b56161340f2973501b Mon Sep 17 00:00:00 2001 From: Logan Devine Date: Wed, 1 Apr 2026 11:15:42 -0700 Subject: [PATCH 3/7] remove "room annotations" from this MSC Room annotations could use a different implementation via room account data and are out of scope for this MSC. Via review. --- proposals/4441-user-profile-annotations.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/proposals/4441-user-profile-annotations.md b/proposals/4441-user-profile-annotations.md index ec13cb4c182..4d1afadcd12 100644 --- a/proposals/4441-user-profile-annotations.md +++ b/proposals/4441-user-profile-annotations.md @@ -2,7 +2,7 @@ Many platforms, such as Discord, provide a capability for a user to leave personal "notes" on a user's profile. Matrix, however, has no similar functionality that can be shared between different clients. This proposal builds User Profile -Annotations, a method for storing encrypted, private metadata on user and room profiles. +Annotations, a method for storing encrypted, private metadata on user profiles. This proposal builds User Profile Annotations, a method of storing personal context on other users' profiles. This is made possible using a new `m.profile_annotations` @@ -16,13 +16,13 @@ annotations is also encrypted using an account secret scoped specifically for ac This proposal introduces a new `m.profile_annotations` Account Data event, allowing the storage of free text (and other future annotations) on users. The framework introduced within this MSC builds on [Extensible Events][MSC1767] and -provides room for future extension into other forms of user context, such as contact labels, custom nickname overrides, -or annotations on rooms. +provides room for future extension into other forms of user context, such as contact labels and custom nickname +overrides. ### Plaintext `m.profile_annotations` A new event, `m.profile_annotations`, is stored in [`account_data`][account_data]. The `content` of this event MUST be a -mapping between valid user MXIDs or room IDs and annotations stored on that user/room. Within a user, the `m.text` +mapping between valid user MXIDs and annotations stored on that user. Within a user, the `m.text` property represents a text annotation ("note") on that user. It follows the text format as defined in [MSC1767][MSC1767]. Unknown keys within user annotations MUST be ignored. @@ -121,7 +121,7 @@ Because the content is scoped to only a singular user, this is acceptable. ## Future extensibility In the future, this MSC may be built on to implement nickname or avatar overrides, general user tagging functionalities, -annotations on rooms, etc. +etc. ## Unstable prefix From 8b0dec41b87dee585ebc22de65d678a299e91ebd Mon Sep 17 00:00:00 2001 From: Logan Devine Date: Thu, 2 Apr 2026 10:48:43 -0700 Subject: [PATCH 4/7] Add unstable identifier for HKDF info --- proposals/4441-user-profile-annotations.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/proposals/4441-user-profile-annotations.md b/proposals/4441-user-profile-annotations.md index 4d1afadcd12..855c89c1d7d 100644 --- a/proposals/4441-user-profile-annotations.md +++ b/proposals/4441-user-profile-annotations.md @@ -127,10 +127,11 @@ etc. Before this MSC is accepted, implementations should use the unstable `account_data` events: -| Stable identifier | Purpose | Unstable identifier | -| ----------------------- | ---------------------------------------- | --------------------------------------- | -| `m.profile_annotations` | Storage of User Profile Annotations | `dev.zirco.msc4441.profile_annotations` | -| `m.account_data.key` | ADK secret storage for encrypted content | `dev.zirco.msc4441.account_data.key` | +| Stable identifier | Purpose | Unstable identifier | +| ------------------------ | ---------------------------------------- | ---------------------------------------- | +| `m.profile_annotations` | Storage of User Profile Annotations | `dev.zirco.msc4441.profile_annotations` | +| `m.profile_annotations/` | Prefix of HKDF `info` | `dev.zirco.msc4441.profile_annotations/` | +| `m.account_data.key` | ADK secret storage for encrypted content | `dev.zirco.msc4441.account_data.key` | ## Dependencies From 9f4151c7667ed13e93e3f34ff09e67e27fe535a0 Mon Sep 17 00:00:00 2001 From: Logan Devine Date: Mon, 25 May 2026 15:42:40 -0700 Subject: [PATCH 5/7] rewrite to use MSC4483 Signed-off-by: Logan Devine --- proposals/4441-user-profile-annotations.md | 110 ++++++--------------- 1 file changed, 30 insertions(+), 80 deletions(-) diff --git a/proposals/4441-user-profile-annotations.md b/proposals/4441-user-profile-annotations.md index 855c89c1d7d..50eccde0743 100644 --- a/proposals/4441-user-profile-annotations.md +++ b/proposals/4441-user-profile-annotations.md @@ -1,31 +1,25 @@ -# MSC4441: Encrypted User Profile Annotations via Account Data +# MSC4441: User Profile Annotations ("Profile Notes") Many platforms, such as Discord, provide a capability for a user to leave personal "notes" on a user's profile. Matrix, however, has no similar functionality that can be shared between different clients. This proposal builds User Profile Annotations, a method for storing encrypted, private metadata on user profiles. -This proposal builds User Profile Annotations, -a method of storing personal context on other users' profiles. This is made possible using a new `m.profile_annotations` -Account Data event, allowing the storage of free text (and other annotations) for a user's reference. - -The framework introduced within this MSC builds upon [Extensible Events][MSC1767] and provides room for future extension -into other forms of user context, such as contact labels or custom nickname overrides. The content stored within these -annotations is also encrypted using an account secret scoped specifically for account data. +Because profile annotations may contain sensitive information about the users they reference, the data is made +optionally encryptable using [MSC4483: Encrypted Account Data][MSC4483]. ## Proposal -This proposal introduces a new `m.profile_annotations` Account Data event, allowing the storage of free text (and other -future annotations) on users. The framework introduced within this MSC builds on [Extensible Events][MSC1767] and -provides room for future extension into other forms of user context, such as contact labels and custom nickname -overrides. +This proposal introduces a new `m.profile_annotations` Account Data entry, allowing the storage of free text (and other +future annotations) on users. The framework introduced within this MSC provides room for future extension into other +forms of user context, such as contact labels and custom nickname overrides. -### Plaintext `m.profile_annotations` +### `m.profile_annotations` -A new event, `m.profile_annotations`, is stored in [`account_data`][account_data]. The `content` of this event MUST be a -mapping between valid user MXIDs and annotations stored on that user. Within a user, the `m.text` -property represents a text annotation ("note") on that user. It follows the text format as defined in [MSC1767][MSC1767]. +A new [encryptable account data][] value, `m.profile_annotations`, is stored in [`account_data`][]. The `content` MUST +be a mapping between valid user MXIDs and annotations stored on that user. Within a user, the `m.text` property +represents a textual annotation ("note") on that user, with the object holding an ordered array as defined by [MSC1767][]. -Unknown keys within user annotations MUST be ignored. +`m.profile_annotations`: ```json { @@ -38,51 +32,16 @@ Unknown keys within user annotations MUST be ignored. } ``` -### Account Data Key (ADK) +As `m.profile_annotations` is encryptable, it may be optionally encrypted with the format specified within [MSC4483][]. -Clients MAY choose to store a new secret, `m.account_data.key` within [SSSS][SSSS]. The secret key is 256 bits of -cryptographic random data used as the secret in HKDF when encrypting profile annotations (and potentially, in the -future, other forms of account data). - -`m.account_data.key`: +`m.profile_annotations`: -```json -{ - "encrypted": { - "key_id_1": { - "ciphertext": "...", - // ... other properties according to key_id_1's algorithm - } - } -} ``` - -### Encrypted `m.profile_annotations` - -Using the ADK bytes introduced above, contents of `m.profile_annotations` can be encrypted using -[`m.secret_storage.v1.aes-hmac-sha2`][SS_crypto]. The info property of the HKDF is the value `m.profile_annotations`, -an ASCII `/`, concatenated with the MXID of the user it represents (e.g. `m.profile_annotations/@logn:zirco.dev`). - -This encryption is applied individually to the Canonical JSON contents of each user's annotation. Not all user keys -within the event must be encrypted: some may still contain plaintext data, however a user annotation MUST NOT contain -both encrypted and plaintext data. - -An example of the event `content` follows: - -`m.profile_annotations`: -```json { - "@logn:zirco.dev": { - "encrypted": { - "iv": "...", - "ciphertext": "...", - "mac": "..." - } - }, - "@sky:codestorm.net": { - "m.text": [ - { "body": "Hello, world" } - ] + "encrypted": { + "iv": "...", + "ciphertext": "...", + "mac": "..." } } ``` @@ -90,8 +49,13 @@ An example of the event `content` follows: ## Potential issues #### Concurrent writes -Account data is last-write-wins. The usage of one key representing all users may lead to a data race in rare scenarios -(although this tradeoff was accepted to keep the behavior similar to existing state like `m.direct`). +Account data is last-write-wins. The usage of one account data entry representing all users may lead to a data race in +rare scenarios (although this tradeoff was accepted to keep the behavior similar to existing state like `m.direct`). + +#### Clients that lack support for Encrypted Account Data + +If clients lack support for Encrypted Account Data, an edit to one singular entry will risk overwriting all other +profile annotations. ## Alternatives @@ -99,19 +63,6 @@ Account data is last-write-wins. The usage of one key representing all users may Rather than using `account_data`, a new dedicated endpoint for annotations would be created. Rejected because it requires substantial serverside changes, this MSC aims to be entirely clintside. -#### Encrypt the entire event as one blob -Rejected because encrypting each user's data individually allows for finer grained control, alongside preventing the -need to decrypt large blobs of data when viewing only a singular user's profile. - -#### Eliminate the ADK and simply use the SSSS master -Using the SSSS master would require re-encrypting notes whenever recovery keys change. Using a separate ADK is -extensible for further `account_data` events, alongside providing the ability to rotate the ADK independently of SSSS. - -## Security considerations - -- The SSSS model does not provide forward secrecy in the case of key compromise. -- Plaintext fallback may not be immediately obvious to users if their note contents are not encrypted. - ## Trust and Safety considerations Profile annotations are the property of one singular user and are never shared with others by the server. Still, a @@ -130,14 +81,13 @@ Before this MSC is accepted, implementations should use the unstable `account_da | Stable identifier | Purpose | Unstable identifier | | ------------------------ | ---------------------------------------- | ---------------------------------------- | | `m.profile_annotations` | Storage of User Profile Annotations | `dev.zirco.msc4441.profile_annotations` | -| `m.profile_annotations/` | Prefix of HKDF `info` | `dev.zirco.msc4441.profile_annotations/` | -| `m.account_data.key` | ADK secret storage for encrypted content | `dev.zirco.msc4441.account_data.key` | ## Dependencies -None. +This MSC depends on the following proposals not yet accepted: +* [MSC4483: Encrypted Account Data][] - [MSC1767]: https://github.com/matrix-org/matrix-spec-proposals/pull/1767 - [account_data]: https://spec.matrix.org/v1.18/client-server-api/#client-config - [SSSS]: https://spec.matrix.org/v1.18/client-server-api/#secrets - [SS_crypto]: https://spec.matrix.org/v1.18/client-server-api/#msecret_storagev1aes-hmac-sha2-1 +[MSC1767]: https://github.com/matrix-org/matrix-spec-proposals/pull/1767 +[MSC4483]: https://github.com/matrix-org/matrix-spec-proposals/pull/4483 +[`account_data`]: https://spec.matrix.org/v1.18/client-server-api/#client-config +[encryptable account data]: https://github.com/thetayloredman/matrix-spec-proposals/blob/encrypted-account-data/proposals/4483-encrypted-account-data.md#encrypted-account-data From 5e1a5dc57bb62f9d2eb4d677edd5773faec9ec47 Mon Sep 17 00:00:00 2001 From: Logan Devine Date: Mon, 25 May 2026 15:46:03 -0700 Subject: [PATCH 6/7] add JSON language tag to encrypted example Signed-off-by: Logan Devine --- proposals/4441-user-profile-annotations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4441-user-profile-annotations.md b/proposals/4441-user-profile-annotations.md index 50eccde0743..0dc59bc8f9c 100644 --- a/proposals/4441-user-profile-annotations.md +++ b/proposals/4441-user-profile-annotations.md @@ -36,7 +36,7 @@ As `m.profile_annotations` is encryptable, it may be optionally encrypted with t `m.profile_annotations`: -``` +```json { "encrypted": { "iv": "...", From ddf4bdb3215c662b1daee0b6e7126c5e3152f25f Mon Sep 17 00:00:00 2001 From: Logan Devine Date: Mon, 25 May 2026 15:46:28 -0700 Subject: [PATCH 7/7] fix link in dependencies section Signed-off-by: Logan Devine --- proposals/4441-user-profile-annotations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4441-user-profile-annotations.md b/proposals/4441-user-profile-annotations.md index 0dc59bc8f9c..f3c4fd107c2 100644 --- a/proposals/4441-user-profile-annotations.md +++ b/proposals/4441-user-profile-annotations.md @@ -85,7 +85,7 @@ Before this MSC is accepted, implementations should use the unstable `account_da ## Dependencies This MSC depends on the following proposals not yet accepted: -* [MSC4483: Encrypted Account Data][] +* [MSC4483: Encrypted Account Data][MSC4483] [MSC1767]: https://github.com/matrix-org/matrix-spec-proposals/pull/1767 [MSC4483]: https://github.com/matrix-org/matrix-spec-proposals/pull/4483