Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
84 changes: 84 additions & 0 deletions proposals/4461-per-message-profile-storage.md
Copy link
Copy Markdown
Member Author

@tulir tulir May 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

  • Client that can create reusable profiles
  • Client that can use reusable profiles when sending messages

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gomuks/gomuks@2e5489a (+ gomuks/gomuks@4daa127 and gomuks/gomuks@fbe6fdb) is an implementation of sending profiles, no UI for creating yet

Original file line number Diff line number Diff line change
@@ -0,0 +1,84 @@
# MSC4461: Storing per-message profiles for users
[MSC4144] introduces per-message profiles, which allow users and bots to
override their profile info for a single message. The original use case was
primarily bots, but the feature is useful for humans too. However, humans don't
like re-entering their profile info every time they send a message. Therefore,
a method for storing reusable profiles is needed.

[MSC4144]: https://github.com/matrix-org/matrix-spec-proposals/pull/4144

## Proposal
A new `m.per_message_profiles` account data event is introduced. The event
content is a map from a user-defined profile "shortcode" to the per-message
profile data that gets sent in events. All fields inside the profile object
are defined by [MSC4144].

The shortcode is an arbitrary user-defined string, which can be used as a key
when selecting a profile to use. Arbitrary unicode is allowed, but spaces
SHOULD NOT be used, as clients that use a command-based UI might split
parameters on spaces.

```json
{
"type": "m.per_message_profiles",
"content": {
"meow": {
"id": "cat",
"displayname": "Cat 🐈️"
},
"mrrp": {
"id": "black_cat",
"displayname": "🐈‍⬛",
"avatar_url": "mxc://maunium.net/hgXsKqlmRfpKvCZdUoWDkFQo"
}
}
}
```

A client could then have a `/profile` command to pick a profile when sending
a message, such that `/profile mrrp hello` turns into

```
{
"type": "m.room.message",
"content": {
"msgtype": "m.text",
"body": "🐈‍⬛: hello",
"format": "org.matrix.custom.html",
"formatted_body": "<p><strong data-mx-profile-fallback>🐈‍⬛: </strong>hello</p>",
"m.per_message_profile": {
"id": "black_cat",
"displayname": "🐈‍⬛",
"avatar_url": "mxc://maunium.net/hgXsKqlmRfpKvCZdUoWDkFQo",
"has_fallback": true
}
}
}
```

## Potential issues
Users with lots of profiles can end up with a large account data event, but
it's unlikely to be larger than existing big account data like push rules or
`m.direct`.

Since it's a single account data event, editing can hit race conditions. It's
likely not a problem, as it's only edited directly by humans (as opposed to
something like `m.direct`, which clients may update in the background).

## Alternatives
There are various other places where profiles could be stored, like
Copy link
Copy Markdown

@onestacked onestacked May 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in room profiles (probably as state events) might be a better idea, as these could then also be shown in the user list. That would make MSC4144/non-appservice bridges nicer to use.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That wouldn't help normal users at all since users can't send state events in most rooms. It'd also mean profiles have to be added to every room instead of just once in global account data. Definitely not an option for this MSC, but I guess I should go into more detail in the alternatives section

[rooms](https://github.com/matrix-org/matrix-spec-proposals/pull/4201)
or multiple account data events. This proposal uses a single account
data event for simplicity.

## Security considerations
This proposal only adds a way to store reusable profile data.
Security considerations with per-message profiles are covered in [MSC4144]

## Unstable prefix
`fi.mau.msc4461.per_message_profiles` can be used instead of
`m.per_message_profiles` in global account data.

## Dependencies
This MSC builds on [MSC4144], which at the time of writing has not yet been
accepted into the spec.
Loading