MSC4482: Ability to bookmark messages by Gernomaly · Pull Request #4482 · matrix-org/matrix-spec-proposals

Gernomaly · 2026-05-23T16:44:06Z

Init Bookmark MSC

…y-to-bookmark-messages.md

Gernomaly · 2026-05-23T16:54:03Z

turt2live

This MSC appears to be a work in progress, so I haven't done the normal "implementation requirements" comment yet. When ready, feel free to request such a comment in the SCT Office.

IT-ess · 2026-05-23T21:27:33Z

I completed the proposal part. Tell me if I'm too verbose @Gernomaly
We probably need to elaborate the last parts too.

Gernomaly · 2026-05-24T08:00:20Z

Love the additions! I am going to elaborate on the alternatives parts later today. Including the comparison that travis suggested 👍

IT-ess · 2026-05-25T10:44:08Z

+### New room type
+
+This MSC introduces a new room type called `m.bookmarks`.
+This kind of room SHOULD only hold some `m.bookmark` events defined below. 


@Gernomaly I'm not sure anymore about this one.
As said in private, I want to adapt my Refs client so it supports this MSC. However, when I need to create a personal bookmark ex-nihilo (not from an existing Matrix event), I need to send my custom Ref event somewhere, and then reference it with our new m.bookmark "pointer event".
Currently I'm using my own custom room type to store my custom events, so using just this m.bookmarks instead would be nice.
So my proposition is that instead of SHOULD only we put MAY ? Does that sound good ?

i think should is fine, its not a must and may is too soft imo

Is SHOULD without only ok for you ?

id just stay with should only tbh, its not like the should only prevents you of not adding anything else imo, and from my point of view your events are a kind of bookmark as well :P . To me it its important to at least for the moment keep the scope together a bit and adapt it if needed in the future if the protocol develops into that direction (referencing msc guide)

Ok I will put back the only then. You're right we should keep it scoped to the generic usecase for now

Johennes · 2026-06-01T06:15:40Z

+      }
+    ],
+    "m.pointer": {
+      "roomId": "<roomId>",


Since room IDs alone are not routable in Matrix, would you also need a via property possibly? I assume you'd normally already be in the room so maybe not? 🤔

Our approach of pointers is kinda simple, we are ok if some pointers are just "dead". It should be up to the client to eventually clean up dead pointers (bookmarks pointing to rooms you're no longer in for instance).

Also, I guess if you don't clean a bookmark to a public room you're no longer part of, having the via parameter could help you joining this room back, so I have mixed opinions on this.

Since room IDs alone are not routable in Matrix, would you also need a via property possibly? I assume you'd normally already be in the room so maybe not? 🤔

you should be in the room, or at the very least join via the server of the user who created the bookmark event. if their homeserver isn't participating in that room anymore, any via's you'd have set would also likely be useless.

if you really want to, we could use the most popular server by users that's in that room, hence having a decent chance of still being part of that room?

I don't particularly care either way, for my use case it's not necessary but I'm open to adding it.

Johennes · 2026-06-01T06:18:40Z

+## General
+
+If the client support the `m.bookmarks` room type, it should'nt be displayed as a normal room in the regular room list. Instead the client could display bookmarks in dedicated sections of the client. 
+The client should ensure that only one `m.bookmarks` room is existing at once.


Could an account data event help to let clients store the room ID of the one bookmarks room?

We imagined that but it would probably require extra work if we need to upgrade the m.bookmarks room at some point.

Johennes · 2026-06-01T06:19:59Z

+
+## Room creation
+
+The room should be created upon first bookmark creation.


This feels like it could be an implementation detail. Would there be any issues with letting clients create the room prematurely?

When we discussed it IRL I remember two arguments :

waste of ressources

zero click creation of a room that contains nothing yet, so it could be weird for a user that also uses a client that does not support m.bookmarks rooms, and thus display the fallback room containing nothing.

We're aware that the first bookmark creation should be a little longer, but that is probably up to the client to make it smooth.

@Johennes is that a sufficient answer to that question or do you still think we should change it?

IT-ess · 2026-06-11T13:10:49Z

+  } 
+}
+```
+


Suggestion: Add the fact that each message of a room should be bookmarked at most once (maximum one m.bookmark event pointing to an event). This ensures that we have a binary state for each message: either bookmarked or not.

agreed tho i dont really know how we should implement this

I already started implementing it on the rust-sdk if you're curious. That's why I'm coming with all these questions and precisions.
Implementation is not that obvious tbh.

IT-ess · 2026-06-11T13:14:28Z

+      "event_id": "$EVENT_ID",
+      "via": ["$SERVER_NAME"]
+
+  } 


Suggestion: add a m.relates_to block on this event so we can handle editing the event with m.replace relations. This isn't very useful as is because editing the pointer or the fallback text isn't very useful, but since it is an extensible event, one may want to add extra blocks to this bookmark. We want to have a future proof event.

sounds reasonable to me!

stefanceriu · 2026-06-24T17:10:31Z

I'm sorry I didn't notice this sooner but you should have a look at MSC2437: Store tagged events in Room Account Data too:

The first use case would be to let him mark some events as favorites to keep a reference on important messages or attachments. Clients would then be able to handle a global bookmark of these favourite events, or display a list of them at the room level.

IT-ess · 2026-06-24T18:54:57Z

I'm sorry I didn't notice this sooner but you should have a look at MSC2437: Store tagged events in Room Account Data too:

The first use case would be to let him mark some events as favorites to keep a reference on important messages or attachments. Clients would then be able to handle a global bookmark of these favourite events, or display a list of them at the room level.

This is a different approach. We describe why we think it is a better way from line 108, but here are the main points:

Account data is fetched in one go, we don't have a way to paginate it. When we store this kind of data in account data, we push data to clients that don't even need it.
Our approach provides a fallback "free" implementation for clients that implements Extensible Events. I admit they are few right now, but it will improve over time.
This implementation is way more extensible, thanks to extensible events again. One could imagine adding additional blocks to the bookmarks to implement folders for instance.

Let us know if you think this different approach is valuable enough ! @stefanceriu

stefanceriu · 2026-06-25T07:19:33Z

I mostly wanted to link the two together. We prototyped message bookmarks ourselves in one of our hackatons (based on bnjbvr/bookmarks) in which we decided to go against #2437 and store everything in the account data, as it made building the UI we wanted easier to build.

Your solution on the other hand would take care of both paths but I do wonder if it is a specialisation of message forwarding i.e. something like #2723 in which m.forwarded is your m.pointer.

IT-ess · 2026-06-25T07:44:32Z

I missed that (great) demo, thank you for the link. I was aware of this other MSC implementing things through account data, but I never saw it landing in Element X (I don't have access to the branch you mentioned), so my guess was that no effort was made in the rust sdk to implement this already.
For the record, I've made an implementation of this MSC for the Rust SDK here, there is also a small video demo linked. I may open smaller PRs to the upstream, but I'm not sure if its required or necessary since there is already a concurrent implementation 🤷

About the m.forwarded block, they are indeed very similar except we don't require the sender and timestamp in m.pointer. We could eventually reuse the same block, but I'm afraid that in terms of naming m.forwarded feels pretty specific related to m.pointer.

Gernomaly · 2026-06-25T21:08:11Z

About the m.forwarded block, they are indeed very similar except we don't require the sender and timestamp in m.pointer. We could eventually reuse the same block, but I'm afraid that in terms of naming m.forwarded feels pretty specific related to m.pointer.

It might actually be an idea to think about as a protocol if we should resuse "m.pointer" for "m.forwarded" in the future

Create 9999-ability-to-bookmark-messages.md

c7dccf5

Init Bookmark MSC

Gernomaly marked this pull request as draft May 23, 2026 16:47

Update and rename 9999-ability-to-bookmark-messages.md to 4482-abilit…

18d7c79

…y-to-bookmark-messages.md

turt2live reviewed May 23, 2026

View reviewed changes

Comment thread proposals/4482-ability-to-bookmark-messages.md

IT-ess reviewed May 23, 2026

View reviewed changes

Comment thread proposals/4482-ability-to-bookmark-messages.md Outdated

Complete 4482-ability-to-bookmark-messages.md proposal section

855dec2

IT-ess and others added 4 commits May 24, 2026 12:57

Elaborate 4482-ability-to-bookmark-messages.md alternatives section

96b00cc

Fallback text blocks should contain a Matrix URI to the message

a5a6610

Added Comparison to other MSCs

7500221

Added unstable prefix disclaimer

49d5c3a

IT-ess reviewed May 25, 2026

View reviewed changes

IT-ess reviewed May 29, 2026

View reviewed changes

Comment thread proposals/4482-ability-to-bookmark-messages.md

Johennes reviewed Jun 1, 2026

View reviewed changes

Comment thread proposals/4482-ability-to-bookmark-messages.md Outdated

Johennes reviewed Jun 1, 2026

View reviewed changes

IT-ess added 4 commits June 4, 2026 11:39

Clearer example body with correct parameter casing

324633d

Mention that the room should only contain m.bookmark events

10cccfa

Better example of fallback text in the custom event

e4e217c

Fix invalid JSON in example event body

fcbfd5e

IT-ess reviewed Jun 10, 2026

View reviewed changes

Comment thread proposals/4482-ability-to-bookmark-messages.md

IT-ess reviewed Jun 11, 2026

View reviewed changes

Learnings from rust-sdk implementation

cd24f35


		## Room creation

		The room should be created upon first bookmark creation.

Uh oh!

Conversation

Gernomaly commented May 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Gernomaly commented May 23, 2026

Uh oh!

turt2live left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

IT-ess commented May 23, 2026

Uh oh!

Gernomaly commented May 24, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stefanceriu commented Jun 24, 2026

Uh oh!

IT-ess commented Jun 24, 2026

Uh oh!

stefanceriu commented Jun 25, 2026

Uh oh!

IT-ess commented Jun 25, 2026

Uh oh!

Gernomaly commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Gernomaly commented May 23, 2026 •

edited

Loading