MSC3765: Rich text in room topics #3765

Johennes · 2022-04-03T12:26:44Z

Implementations:

In line with matrix-org/matrix-spec#1700, the following disclosure applies:

I am a Systems Architect at gematik, Software Engineer at Unomed, Matrix community member and former Element employee. This proposal was written and published with my community member hat on.

FCP tickyboxes

Signed-off-by: Johannes Marbach <[email protected]>

proposals/3765-rich-room-topics.md

Co-authored-by: Travis Ralston <[email protected]>

turt2live · 2022-04-17T19:35:37Z

proposals/3765-rich-room-topics.md

@@ -0,0 +1,96 @@
+# MSC3765: Rich text in room topics


@alphapapa says:

On one hand, I can see some elegance in repurposing room topics for general-purpose, long-term room reference information. OTOH, it seems like overloading the purpose of topics with what, in other systems, would go in "pinned" topics or messages, or a wiki, etc.

So IMHO I would consider implementing support for pinned messages/events before overloading topics like this. It would seem relatively straightforward for a room's state to have a list of pinned events, which could be sent in initial sync by the server or be retrieved manually by clients. Clients could then display these pinned events in a room's timeline view, optionally hiding them, compressing them, etc. And the pinned events could be edited by room moderators using existing event-editing tools. (Forgive me if there's already a proposal for something like that.)

@Johennes replies:

Interesting idea. Pinned events seem to already exist. However, in their current form, these are not fit to be used for what you describe because, depending on room settings, users joining the room after the events were sent could be unable to see them.

proposals/3765-rich-room-topics.md

turt2live · 2022-04-17T19:37:34Z

@alphapapa and others: please use threads on the diff to have your comments considered. This can be done by adding a line comment.

If there's no obvious line for where to put a comment, please use the line containing the title.

proposals/3765-rich-room-topics.md

Updates MSC from feedback,

turt2live · 2024-10-22T19:42:52Z

@mscbot fcp merge

mscbot · 2024-10-22T19:42:55Z

KitsuneRal

Not a blocking concern but it would be great to polish the wording a little.

proposals/3765-rich-room-topics.md

Co-authored-by: Johannes Marbach <[email protected]>

proposals/3765-rich-room-topics.md

Co-authored-by: Johannes Marbach <[email protected]>

proposals/3765-rich-room-topics.md

richvdh · 2024-11-06T14:25:50Z

@mscbot concern binds behaviour of future unspecified versions

Co-authored-by: Johannes Marbach <[email protected]>

…4240)

richvdh · 2024-12-17T17:31:26Z

proposals/3765-rich-room-topics.md

+Details of how `m.text` works may be found in [MSC1767] and are not
+repeated here.


I hadn't really expected m.room.topic events to be the way that the m.text stuff makes it into the spec, but I guess that's ok.

richvdh · 2024-12-17T17:31:28Z

proposals/3765-rich-room-topics.md

+uploads as defined in [MSC3551]. It avoids clients accidentally rendering
+the topic state event as a room message.


It avoids clients accidentally rendering the topic state event as a room message.

Is this actually necessary?

It seems to me that the reason for m.caption in MSC3551 is quite different to the reason for it here: in that case, m.text at the top level has a very different meaning to m.text within m.caption, whereas here there is no ambiguity.

This might be a good thing to do anyway, for consistency for example, but I'm unconvinced this paragraph captures a good reason for it.

The extra wrapping block was based off of @turt2live's comment from an earlier review. I don't feel strongly either way but am curious what Travis thinks.

proposals/3765-rich-room-topics.md

richvdh · 2024-12-17T17:36:54Z

proposals/3765-rich-room-topics.md

+      "m.text": [{
+        "body": "All about **pizza** | [Recipes](https://recipes.pizza.net)"
+      }, {
+        "mimetype": "text/html",
+        "body": "All about <b>pizza</b> | <a href=\"https://recipes.pizza.net\">Recipes</a>"
+      }]


Aren't these the wrong way round? According to MSC1767, the first supported representation should be used, so nobody will ever use the html representation.

(clients can also optimize and pick a preferred represenation, but indeed the preference should be to order them. I remain unconvinced that MSC1767 picked the right order here though, because everyone (including me) keeps putting plaintext first)

proposals/3765-rich-room-topics.md

richvdh · 2024-12-17T17:45:04Z

proposals/3765-rich-room-topics.md

+On the server side, any logic that currently operates on the `topic` field is
+updated to use the `m.topic` content block instead.


Am I right in understanding that the next four paragraphs are examples of this change? If so, it would be good to make that a little clearer:

Suggested change

On the server side, any logic that currently operates on the `topic` field is

updated to use the `m.topic` content block instead.

On the server side, any logic that currently operates on the `topic` field is

updated to use the `m.topic` content block instead. For example:

... and make the following paragraphs bullet points.

It's actually meant to be a conclusive list. I hope I didn't miss anything. Maybe ending with a colon (without "For example") and making the next paragraphs bullets would be clearer?

Have captured it into https://github.com/matrix-org/matrix-spec-proposals/pull/3765/files#r1890019768 which I'll need you to push the button on once more. Sorry for the hassle.

richvdh · 2024-12-17T17:46:00Z

proposals/3765-rich-room-topics.md

+as `org.matrix.msc3765.topic`. Note that extensible events and content
+blocks might have their own prefixing requirements.


Note that extensible events and content blocks might have their own prefixing requirements.

I don't really know what this means, as it pertains to this MSC?

This is stolen from MSC3381. It was originally intended to make m.text into org.matrix.msc1767.text. However, I suppose we don't need this anymore because MSC1767 has since been accepted?

richvdh · 2024-12-17T17:46:36Z

@mscbot resolve binds behaviour of future unspecified versions

changes made

Johennes · 2024-12-18T10:43:54Z

proposals/3765-rich-room-topics.md

+On the server side, any logic that currently operates on the `topic` field is
+updated to use the `m.topic` content block instead.
+
+In [`/_matrix/client/v3/createRoom`], the `topic` parameter should cause `m.room.topic`
+to be written with a `text/plain` mimetype in `m.topic`. If at the same time an
+`m.room.topic` event is supplied in `initial_state`, it is overwritten entirely.
+A future MSC may generalize the `topic` parameter to allow specifying other mime
+types without `initial_state`.
+
+In [`GET /_matrix/client/v3/publicRooms`], [`GET /_matrix/federation/v1/publicRooms`]
+and their `POST` siblings, the `topic` response field should be read from the
+`text/plain` mimetype of `m.topic` if it exists or omitted otherwise.
+A plain text topic is sufficient here because this data is commonly
+only displayed to users that are *not* a member of the room yet. These
+users don't commonly have the same need for rich room topics as users
+who already reside in the room. A future MSC may update these endpoints
+to support rich text topics.
+
+The same logic is applied to [`/_matrix/client/v1/rooms/{roomId}/hierarchy`]
+and [`/_matrix/federation/v1/hierarchy/{roomId}`].
+
+In [server side search], the `room_events` category is expanded to search
+over the `m.text` content block of `m.room.topic` events.


Suggested change

On the server side, any logic that currently operates on the `topic` field is

updated to use the `m.topic` content block instead.

In [`/_matrix/client/v3/createRoom`], the `topic` parameter should cause `m.room.topic`

to be written with a `text/plain` mimetype in `m.topic`. If at the same time an

`m.room.topic` event is supplied in `initial_state`, it is overwritten entirely.

A future MSC may generalize the `topic` parameter to allow specifying other mime

types without `initial_state`.

In [`GET /_matrix/client/v3/publicRooms`], [`GET /_matrix/federation/v1/publicRooms`]

and their `POST` siblings, the `topic` response field should be read from the

`text/plain` mimetype of `m.topic` if it exists or omitted otherwise.

A plain text topic is sufficient here because this data is commonly

only displayed to users that are *not* a member of the room yet. These

users don't commonly have the same need for rich room topics as users

who already reside in the room. A future MSC may update these endpoints

to support rich text topics.

The same logic is applied to [`/_matrix/client/v1/rooms/{roomId}/hierarchy`]

and [`/_matrix/federation/v1/hierarchy/{roomId}`].

In [server side search], the `room_events` category is expanded to search

over the `m.text` content block of `m.room.topic` events.

On the server side, any logic that currently operates on the `topic` field is

updated to use the `m.topic` content block instead:

- In [`/_matrix/client/v3/createRoom`], the `topic` parameter should cause `m.room.topic`

to be written with a `text/plain` mimetype in `m.topic`. If at the same time an

`m.room.topic` event is supplied in `initial_state`, it is overwritten entirely.

A future MSC may generalize the `topic` parameter to allow specifying other mime

types without `initial_state`.

- In [`GET /_matrix/client/v3/publicRooms`], [`GET /_matrix/federation/v1/publicRooms`]

and their `POST` siblings, the `topic` response field should be read from the

`text/plain` mimetype of `m.topic` if it exists or omitted otherwise.

A plain text topic is sufficient here because this data is commonly

only displayed to users that are *not* a member of the room yet. These

users don't commonly have the same need for rich room topics as users

who already reside in the room. A future MSC may update these endpoints

to support rich text topics.

- The same logic is applied to [`/_matrix/client/v1/rooms/{roomId}/hierarchy`]

and [`/_matrix/federation/v1/hierarchy/{roomId}`].

- In [server side search], the `room_events` category is expanded to search

over the `m.text` content block of `m.room.topic` events.

Add rich room topic MSC

9b914c6

Signed-off-by: Johannes Marbach <[email protected]>

Johennes changed the title ~~MSC3677: Rich text in room topics~~ MSC3765: Rich text in room topics Apr 3, 2022

Johennes added 2 commits April 3, 2022 14:28

Rename to reflect propper MSC number

06d315d

Fix typo

09c7014

ShadowJonathan reviewed Apr 3, 2022

View reviewed changes

proposals/3765-rich-room-topics.md Outdated Show resolved Hide resolved

turt2live added proposal-in-review proposal A matrix spec change proposal client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff labels Apr 3, 2022

ara4n reviewed Apr 3, 2022

View reviewed changes

proposals/3765-rich-room-topics.md Show resolved Hide resolved

ara4n reviewed Apr 3, 2022

View reviewed changes

proposals/3765-rich-room-topics.md Outdated Show resolved Hide resolved

turt2live reviewed Apr 4, 2022

View reviewed changes

proposals/3765-rich-room-topics.md Outdated Show resolved Hide resolved

turt2live reviewed Apr 4, 2022

View reviewed changes

proposals/3765-rich-room-topics.md Outdated Show resolved Hide resolved

Johennes and others added 3 commits April 4, 2022 19:49

Explain why m.topic is kept separate from m.message

1d0031a

Use json5 for formatting code snippet

3b572e7

Co-authored-by: Travis Ralston <[email protected]>

Remove unneeded unstable room version

6270109

This comment was marked as duplicate.

Sign in to view

turt2live reviewed Apr 17, 2022

View reviewed changes

proposals/3765-rich-room-topics.md Show resolved Hide resolved

emorrp1 reviewed Apr 18, 2022

View reviewed changes

proposals/3765-rich-room-topics.md Outdated Show resolved Hide resolved

turt2live removed the proposal-in-review label May 5, 2022

Johennes added 2 commits January 5, 2023 15:50

Adapt to latest version of MSC1767

af184dd

Add paragraph about preventing formatting abuse

aa373d1

Johennes mentioned this pull request Oct 17, 2024

Update MSC3765: Rich text in room topics #4215

Merged

Update MSC3765: Rich text in room topics (#4215)

385bf0b

Updates MSC from feedback,

mscbot added proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. disposition-merge labels Oct 22, 2024

KitsuneRal reviewed Oct 23, 2024

View reviewed changes

proposals/3765-rich-room-topics.md Outdated Show resolved Hide resolved

dbkr reviewed Oct 23, 2024

View reviewed changes

Johennes commented Oct 24, 2024

View reviewed changes

proposals/3765-rich-room-topics.md Outdated Show resolved Hide resolved

tulir mentioned this pull request Oct 26, 2024

MSC4221: Room Banners #4221

Open

Accept suggestion

bb726db

Co-authored-by: Johannes Marbach <[email protected]>

Johennes commented Nov 4, 2024

View reviewed changes

proposals/3765-rich-room-topics.md Outdated Show resolved Hide resolved

Johennes commented Nov 4, 2024

View reviewed changes

proposals/3765-rich-room-topics.md Outdated Show resolved Hide resolved

Clarify length / display limits.

1b4682e

Co-authored-by: Johannes Marbach <[email protected]>

richvdh previously requested changes Nov 5, 2024

View reviewed changes

proposals/3765-rich-room-topics.md Outdated Show resolved Hide resolved

proposals/3765-rich-room-topics.md Outdated Show resolved Hide resolved

mscbot added the unresolved-concerns This proposal has at least one outstanding concern label Nov 6, 2024

Apply clarifications from author

d42f0e3

Co-authored-by: Johannes Marbach <[email protected]>

sumnerevans mentioned this pull request Dec 6, 2024

web/roomview: render room topic in header tulir/gomuks#538

Merged

3 tasks

Johennes mentioned this pull request Dec 11, 2024

Make MSC3765 independent of extensible events and new room versions #4240

Merged

turt2live self-requested a review December 11, 2024 18:51

Make MSC3765 independent of extensible events and new room versions (#…

fda22d8

…4240)

turt2live requested a review from richvdh December 12, 2024 21:11

turt2live approved these changes Dec 12, 2024

View reviewed changes

richvdh reviewed Dec 17, 2024

View reviewed changes

mscbot removed the unresolved-concerns This proposal has at least one outstanding concern label Dec 17, 2024

Apply suggestions from code review

ac5c6fc

Johennes commented Dec 18, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MSC3765: Rich text in room topics #3765

MSC3765: Rich text in room topics #3765

Johennes commented Apr 3, 2022 •

edited by turt2live

Loading

This comment was marked as duplicate.

This comment was marked as duplicate.

This comment was marked as duplicate.

turt2live Apr 17, 2022

turt2live Apr 17, 2022

turt2live commented Apr 17, 2022

turt2live commented Oct 22, 2024

mscbot commented Oct 22, 2024 •

edited

Loading

KitsuneRal left a comment

richvdh commented Nov 6, 2024

richvdh Dec 17, 2024

richvdh Dec 17, 2024

Johennes Dec 18, 2024

richvdh Dec 17, 2024

turt2live Dec 17, 2024

richvdh Dec 17, 2024

Johennes Dec 18, 2024

richvdh Dec 18, 2024

Johennes Dec 18, 2024 •

edited

Loading

richvdh Dec 17, 2024

Johennes Dec 18, 2024

richvdh commented Dec 17, 2024

Johennes Dec 18, 2024

		Details of how `m.text` works may be found in [MSC1767] and are not
		repeated here.

		uploads as defined in [MSC3551]. It avoids clients accidentally rendering
		the topic state event as a room message.

		On the server side, any logic that currently operates on the `topic` field is
		updated to use the `m.topic` content block instead.

		as `org.matrix.msc3765.topic`. Note that extensible events and content
		blocks might have their own prefixing requirements.

MSC3765: Rich text in room topics #3765

Are you sure you want to change the base?

MSC3765: Rich text in room topics #3765

Conversation

Johennes commented Apr 3, 2022 • edited by turt2live Loading

This comment was marked as duplicate.

This comment was marked as duplicate.

This comment was marked as duplicate.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

turt2live commented Apr 17, 2022

turt2live commented Oct 22, 2024

mscbot commented Oct 22, 2024 • edited Loading

KitsuneRal left a comment

Choose a reason for hiding this comment

richvdh commented Nov 6, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Johennes Dec 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

richvdh commented Dec 17, 2024

Choose a reason for hiding this comment

Johennes commented Apr 3, 2022 •

edited by turt2live

Loading

mscbot commented Oct 22, 2024 •

edited

Loading

Johennes Dec 18, 2024 •

edited

Loading