MSC3765: Rich text in room topics

[Johennes]

Rendered

Implementations:

• Add support for different renderings to topic events matrix-events-sdk#5
• Add support for HTML renderings of room topics matrix-js-sdk#2272
• Add support for MD / HTML in room topics matrix-react-sdk#8215

---

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

[turt2live]

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

[turt2live]

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

[turt2live]

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

[richvdh]

@mscbot concern binds behaviour of future unspecified versions

[richvdh]

@mscbot resolve binds behaviour of future unspecified versions

changes made

[ara4n]

Not a blocking concern, but I'm a little worried that the m.topic wrapper on the content block is unnecessary and just makes things more verbose and clunky - see #3765 (comment) for context. Thoughts welcome on whether this should be a blocking concern or not. (i'm happy with everything else and have ticked anyway to avoid blocking)

[richvdh]

@mscbot concern which order are the representations in?

[richvdh]

Non-blocking comment:

I don't entirely follow why we need an m.topic block as a place to put extra fields (unless we think that we're going to end up with topics inside other event types?) but maybe that's my lack of familiarity with extensible events.

@ara4n as the person that proposed this (I think?) can you clarify?

[richvdh]

@mscbot resolve which order are the representations in?

[richvdh]

Thanks, this LGTM now, other than the outstanding question at #3765 (comment)