MSC3765: Rich text in room topics #3765
Conversation
Signed-off-by: Johannes Marbach <johannesm@element.io>
Johennes
changed the title
turt2live
added
proposal-in-review
proposal
Co-authored-by: Travis Ralston <travisr@matrix.org>
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
| @@ -0,0 +1,96 @@ | |||
| # MSC3765: Rich text in room topics | |||
There was a problem hiding this comment.
@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.)
There was a problem hiding this comment.
|
@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. |
what would be the work that needs to be done? time effort? skills necessary? ... |
|
The unresolved comments need to be addressed and afterwards I think it could be sent through FCP which might yield further comments. Update (2024-02-23): I've resolved the remaining comments and raised the proposal with the SCT. |
* Clarify and simplify transition logic * Clarify the case of HTML-only topics
|
Hi, what is the state about this PR? AFAIK, Markdown in Room topics (my use-case) is not yet supported. This conversation looks like everything looks good, is there anything stopping it from getting merged? |
|
it has been added to development/nightly, and seems to be working there flawlessly for a long time - from my own testing |
|
@mscbot fcp merge |
|
Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people: Concerns:
Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for information about what commands tagged team members can give me. |
mscbot
added
proposed-final-comment-period
proposals/3765-rich-room-topics.md
Outdated
| text topic is sufficient such as the public rooms directory. | ||
|
|
||
| In order to prevent formatting abuse in room topics, clients are | ||
| encouraged to limit the length of topics to at most two lines. Additionally, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
It might make sense to just say that clients should be sure to limit it, e.g. by limiting the number of displayed lines.
| In [`/_matrix/client/v3/createRoom`], the `topic` parameter causes `m.topic` | ||
| to be written with a `text/plain` mimetype. If an `m.topic` event is supplied | ||
| in `initial_state`, the `topic` parameter overwrites its `text/plain` mimetype | ||
| but retains any other mimetypes. |
There was a problem hiding this comment.
This feels like a footgunny way to end up with a text and html part that don't match. I would expect specifying a topic event in initial_state would take precedence completely rather than require the server to edit parts of the event.
There was a problem hiding this comment.
Hm, that sounds sensible but then we'd have to swap the order of steps 6 and 7 in https://spec.matrix.org/v1.12/client-server-api/#post_matrixclientv3createroom depending on the room version?
There was a problem hiding this comment.
Ah yep, good point. It feels like the right answer to me.
There was a problem hiding this comment.
If we want to preserve the current behaviour, then it seems to me like it would be better to have the topic parameter overwrite the whole m.topic event.
|
|
||
| It is recommended that clients always include a plain text variant when | ||
| sending `m.topic` events. This prevents bad UX in situations where a plain | ||
| text topic is sufficient such as the public rooms directory. |
There was a problem hiding this comment.
Not a blocker but this feels like an odd example as I don't see what the public room directory would necessarily choose not to use rich text. Text-only clients maybe?
There was a problem hiding this comment.
Blocking on https://github.com/matrix-org/matrix-spec-proposals/pull/3765/files#r1812651036 where we're discussing whether we'll include all mime types everywhere. If so, this would make this whole paragraph obsolete.
proposals/3765-rich-room-topics.md
Outdated
| text topic is sufficient such as the public rooms directory. | ||
|
|
||
| In order to prevent formatting abuse in room topics, clients are | ||
| encouraged to limit the length of topics to at most two lines. Additionally, |
There was a problem hiding this comment.
At both entry and display time presumably?
| 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 have the same need for rich room topics as users who already | ||
| reside in the room. |
There was a problem hiding this comment.
Hmm, I see why you might say this but I'm not sure I agree, and this is going to mean the public room list topics are full of weird looking markdown syntax. I'm inclined to think that if we want topics to be HTML, they ought to be HTML everywhere.
There was a problem hiding this comment.
We could maybe achieve that by cutting a new version of the endpoint and including all mimetypes in the topic field (similar to m.text in the event itself)?
{
"chunk": [
{
"avatar_url": "mxc://bleecker.street/CHEDDARandBRIE",
"name": "CHEESE",
"topic": [{
"body": "All about **cheese**"
}, {
"mimetype": "text/html",
"body": "All about <b>cheese</b>"
}],
...
}
],
...
}This would also have to be applied to the SS endpoints as well as the space hierarchy endpoints. I had not considered this so far because it felt slightly invasive. I agree that it's a bit odd to not have rich topics everywhere though.
There was a problem hiding this comment.
Yeah, this would feel quite reasonable. It could be left for a separate MSC though, so this MSC ends up being the same technically, just with a, "public rooms list doesn't support html topics yet" rather than, "we've decided that public room list doesn't support html topics".
There was a problem hiding this comment.
Yeah, I think that it's reasonable to not want to change those endpoints at this time, but the current wording makes it sound like we don't ever want to change it to support rich-text topics. I think that tweaking the wording here (possibly just by adding something like "A future MSC may update these endpoints to support rich text topics.") would be helpful.
Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>
| 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 have the same need for rich room topics as users who already | ||
| reside in the room. |
There was a problem hiding this comment.
| 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 have the same need for rich room topics as users who already | |
| reside in the room. | |
| 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. |
@dbkr / @uhoreg does this sound better and if so, could one of you apply it in my stead?
| In [`/_matrix/client/v3/createRoom`], the `topic` parameter causes `m.topic` | ||
| to be written with a `text/plain` mimetype. If an `m.topic` event is supplied | ||
| in `initial_state`, the `topic` parameter overwrites its `text/plain` mimetype | ||
| but retains any other mimetypes. |
There was a problem hiding this comment.
If we want to preserve the current behaviour, then it seems to me like it would be better to have the
topicparameter overwrite the wholem.topicevent.
I think I like that best as it's quite easy to do and may still be improved by a future MSC generalizing (or possibly even eliminating) the topic parameter.
@dbkr / @uhoreg how does this sound?
| In [`/_matrix/client/v3/createRoom`], the `topic` parameter causes `m.topic` | |
| to be written with a `text/plain` mimetype. If an `m.topic` event is supplied | |
| in `initial_state`, the `topic` parameter overwrites its `text/plain` mimetype | |
| but retains any other mimetypes. | |
| In [`/_matrix/client/v3/createRoom`], the `topic` parameter causes `m.topic` | |
| to be written with a `text/plain` mimetype. If at the same time an `m.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`. |
Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>
| 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. |
There was a problem hiding this comment.
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.
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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>" | ||
| }] | ||
| } | ||
| }, | ||
| ... | ||
| } | ||
| ``` |
There was a problem hiding this comment.
replace with example of m.room.topic event
|
@mscbot concern binds behaviour of future unspecified versions |
mscbot
added
the
unresolved-concerns
Rendered
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