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 15 commits into
base: main
Choose a base branch
from
Open
Changes from 12 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
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.
Comment on lines +16 to +20
Copy link
Member

Choose a reason for hiding this comment

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

I read this and thought "well, since there are no current room versions that support extensible events, we're not going to be able to use this anywhere".

Having read through a bit more and come across the "Transition" and "Notes" sections, I realise that's not really the case.

What's more: I am worried that any behaviour defined here for some mythical extensible-events-supporting room version is going to be forgotten by the time we actually come to define such a room version; and then we will find ourselves very confused about what is or is not specced. I would strongly argue that we should limit this proposal to the room versions we have today, with some non-normative suggestions about how how things might look in future room versions.

In other words: let's rephrase this a bit.

Suggested change
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.
Drawing from extensible events as described in [MSC1767], a new content block
`m.topic` is defined, which wraps an `m.text` content block that allows representing
the room topic in different mime types.
In current room versions, this content block is added to the content of
[`m.room.topic`](https://spec.matrix.org/v1.12/client-server-api/#mroomtopic) events as shown below.
See also (link to separate section) which discusses possible adoption in future room versions which
support extensible events.

Copy link
Member

Choose a reason for hiding this comment

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

Alternatively: we don't have to wait for the whole of extensible events to land to make m.topic events a thing: it's not even clear we need a new room version. (Room versions have historically focussed on server-side functionality, whereas topics are more a client-side thing. Clients generally accept unknown room versions and muddle through as best they can.)

Anyway, the point here is that there are options here. Let's just not define behaviour for a room version so far away that we'll forget about this in the meantime.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It sounds like this would mean rebasing this proposal onto the current spec (which doesn't know extensible events) and then creating another proposal to adapt it to the extensible events room version later?

I'd be ok with that but I feel like I'm being bounced back and forth a little here. @turt2live this would probably benefit from your input.

@richvdh I guess you might want to stick up a concern?


``` json5
{
"type": "m.topic",
"state_key": "",
"content": {
"m.topic": {
"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>"
}]
}
},
...
}
```
Comment on lines +22 to +38
Copy link
Member

Choose a reason for hiding this comment

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

replace with example of m.room.topic event


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

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.

In order to prevent formatting abuse in room topics, clients are
encouraged to limit the length of topics to at most two lines. Additionally,
Copy link
Member

Choose a reason for hiding this comment

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

At most two HTML lines? Or if one crafts a very long plain text topic that would be wrapped into more than two lines that should be limited as well?

I understand where this comes from but in its current reading the recommendation is a bit confusing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What I meant is two displayed lines – regardless of whether the lines resulted from actual newlines in the topic or from a long topic being wrapped onto multiple lines for display.

Does that make sense and if so, do you think "limit the length of topics to at most two displayed lines" would make this clearer?

Copy link
Member

Choose a reason for hiding this comment

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

It might make sense to just say that clients should be sure to limit it, e.g. by limiting the number of displayed lines.

Copy link
Member

Choose a reason for hiding this comment

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

At both entry and display time presumably?

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