Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC3765: Rich text in room topics #3765

Open
wants to merge 21 commits into
base: main
Choose a base branch
from
Open
Changes from 12 commits
Commits
Show all changes
21 commits
Select commit Hold shift + click to select a range
9b914c6
Add rich room topic MSC
Johennes Apr 3, 2022
06d315d
Rename to reflect propper MSC number
Johennes Apr 3, 2022
09c7014
Fix typo
Johennes Apr 3, 2022
1d0031a
Explain why m.topic is kept separate from m.message
Johennes Apr 4, 2022
3b572e7
Use json5 for formatting code snippet
Johennes Apr 4, 2022
6270109
Remove unneeded unstable room version
Johennes Apr 4, 2022
af184dd
Adapt to latest version of MSC1767
Johennes Jan 5, 2023
aa373d1
Add paragraph about preventing formatting abuse
Johennes Jan 5, 2023
ea93852
Introduce wrapping m.topic content block (#4111)
Johennes Feb 23, 2024
a6b1555
Clarify the case of HTML-only topics and transition logic (#4112)
Johennes Feb 23, 2024
95fb38a
Make it more explicit that m.topic replaces m.room.topic without depr…
Johennes Aug 26, 2024
f915cc4
Remove line-based formatting logic and limit length of topics (#4182)
Johennes Aug 27, 2024
385bf0b
Update MSC3765: Rich text in room topics (#4215)
Johennes Oct 17, 2024
bb726db
Accept suggestion
dbkr Oct 29, 2024
1b4682e
Clarify length / display limits.
clokep Nov 4, 2024
d42f0e3
Apply clarifications from author
clokep Nov 26, 2024
fda22d8
Make MSC3765 independent of extensible events and new room versions (…
Johennes Dec 12, 2024
ac5c6fc
Apply suggestions from code review
richvdh Dec 18, 2024
79e3f5d
Update proposals/3765-rich-room-topics.md
richvdh Jan 21, 2025
a64a825
Properly explain why the m.topic content block is needed (#4251)
Johennes Jan 21, 2025
c83f56d
Apply suggestions from code review
richvdh Jan 23, 2025
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
104 changes: 104 additions & 0 deletions proposals/3765-rich-room-topics.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,104 @@
# MSC3765: Rich text in room topics
Copy link
Member

Choose a reason for hiding this comment

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

@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.)

Copy link
Member

Choose a reason for hiding this comment

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

@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.


## Problem
Johennes marked this conversation as resolved.
Show resolved Hide resolved

Topics are a central piece of room meta data and usually made easily
accessible to room members in clients. As a result, room administrators
often extend the use of topics to collect helpful peripheral information
that is related to the room’s purpose. Most commonly these are links to
external resources. At the moment, topics are limited to [plain text]
which, depending on the number and length of URLs and other content,
easily gets inconvenient to consume and calls for richer text formatting
options.

## Proposal

Drawing from extensible events as described in [MSC1767], `m.room.topic`
is prohibited in room versions that support extensible events and replaced
with a new `m.topic` event type. The latter contains a new content block
`m.topic` which wraps an `m.text` content block that allows representing
the room topic in different mime types.
turt2live marked this conversation as resolved.
Show resolved Hide resolved

``` json5
{
"type": "m.topic",
"state_key": "",
"content": {
"m.topic": {
Copy link
Contributor

Choose a reason for hiding this comment

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

Just for clarity here (since we've always failed to spec this behavior outright). Should m.topic be omitted if the topic was removed from the room, or empty array (or both because it amounts to the same thing?).

The implementation doesn't allow for this currently, and I'm just doing some cleanup.

"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>"
}]
}
},
...
}
```
turt2live marked this conversation as resolved.
Show resolved Hide resolved

Details of how `m.text` works may be found in [MSC1767] and are not
repeated here.
richvdh marked this conversation as resolved.
Show resolved Hide resolved
richvdh marked this conversation as resolved.
Show resolved Hide resolved

The wrapping `m.topic` content block is similar to `m.caption` for file
uploads as defined in [MSC3551]. It avoids clients accidentally rendering
the topic state event as a room message.
richvdh marked this conversation as resolved.
Show resolved Hide resolved

In order to prevent formatting abuse in room topics, clients are
encouraged to limit the length of topics to at most two lines. Additionally,
Johennes marked this conversation as resolved.
Show resolved Hide resolved
Johennes marked this conversation as resolved.
Show resolved Hide resolved
clients should ignore things like headings and enumerations (or format them
as regular text). A future MSC may introduce a mechanism to capture extended
multiline details that are not suitable for room topics in a separate field
or event type.
clokep marked this conversation as resolved.
Show resolved Hide resolved

A change to `/_matrix/client/v3/createRoom` is not necessary. The
Johennes marked this conversation as resolved.
Show resolved Hide resolved
endpoint has a plain text `topic` parameter but also allows to specify a
full `m.topic` event in `initial_state`.
Johennes marked this conversation as resolved.
Show resolved Hide resolved

Room topics also occur as part of the `PublicRoomsChunk` object in the
responses of `/_matrix/client/v3/publicRooms` and
`/_matrix/client/v1/rooms/{roomId}/hierarchy`. The topic can be kept
Johennes marked this conversation as resolved.
Show resolved Hide resolved
plain text here because this data should commonly only be displayed to
users that are *not* a member of the room yet. These users will not have
the same need for rich room topics as users who are inside the room. If
no plain text topic exists, home servers should return an empty topic
string from these end points. Since this will inevitably lead to bad UX,
client implementations are encouraged to always include a plain text
variant when sending `m.topic` events.
Johennes marked this conversation as resolved.
Show resolved Hide resolved

## Transition
Johennes marked this conversation as resolved.
Show resolved Hide resolved

As this MSC replaces `m.room.topic` for an extensible alternative,
clients and servers are expected to treat `m.room.topic` as invalid in
extensible event-supporting room versions.
Johennes marked this conversation as resolved.
Show resolved Hide resolved
Johennes marked this conversation as resolved.
Show resolved Hide resolved

## Potential issues

None.

## Alternatives
Johennes marked this conversation as resolved.
Show resolved Hide resolved

The combination of `format` and `formatted_body` currently utilised to
enable HTML in `m.room.message` events could be generalised to
`m.topic` events. However, this would only allow for a single
format in addition to plain text and is a weaker form of reuse than
described in the introductory section of [MSC1767].

## Security considerations

Allowing HTML in room topics is subject to the same security
considerations that apply to HTML in room messages.

## Unstable prefix

While this MSC is not considered stable, `m.topic` should be referred to
as `org.matrix.msc3765.topic`.
Comment on lines +114 to +117
Copy link
Member

@turt2live turt2live Sep 6, 2023

Choose a reason for hiding this comment

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

@jplatte says:

The current implementation in the JS SDK adds "org.matrix.msc3765.topic" as a content field to the existing m.room.topic event, but this MSC documents a new m.topic event type. Is the JS SDK implementation just outdated?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The JS SDK implements an earlier version of this MSC, yes.

Johennes marked this conversation as resolved.
Show resolved Hide resolved

## Dependencies

- [MSC1767]

[plain text]: https://spec.matrix.org/v1.2/client-server-api/#mroomtopic
[MSC1767]: https://github.com/matrix-org/matrix-spec-proposals/pull/1767
[MSC3551]: https://github.com/matrix-org/matrix-spec-proposals/pull/3551
[`/rooms/{roomId}/upgrade`]: https://spec.matrix.org/v1.5/client-server-api/#post_matrixclientv3roomsroomidupgrade