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.

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

[turt2live]

Generally this lgtm - thanks for updating it :)

[turt2live]

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

[Johennes]

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

[ceearrbee]

This hasn't been touched for over a year, is there any ETA as to when it'll go live?

[Johennes]

Sorry, I'm not currently able to follow through on this myself. However, if you're interested, you could adopt ownership over this MSC.

[tmonz]

Sorry, I'm not currently able to follow through on this myself. However, if you're interested, you could adopt ownership over this MSC.

what would be the work that needs to be done? time effort? skills necessary? ...

[Johennes]

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.

[famfop]

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?

[tmonz]

it has been added to development/nightly, and seems to be working there flawlessly for a long time - from my own testing

[Johennes]

Suggested change

	## Unstable prefix
	While this MSC is not considered stable, `m.topic` should be referred to
	as `org.matrix.msc3765.topic`.
	## Other notes
	Normally extensible events would only be permitted in a specific room version.
	However, this proposal's event is permitted in any room version. The stable
	event type should only be sent in a room version which supports extensible
	events, however.
	## Unstable prefix
	While this MSC is not considered stable, `m.topic` should be referred to as
	`org.matrix.msc3765.topic`. Note that extensible events and content blocks
	might have their own prefixing requirements.
	### Implementation considerations
	Implementation authors should note that as a feature using the Extensible Events
	system, usage of the *stable* event type `m.topic` in regular room versions is not
	permitted. As of writing (August 2024), Extensible Events does not have a *stable*
	room version which supports such events. Therefore, implementations will have to
	use the *unstable* event type if they intend to support rich text in room topics in
	existing room versions.
	When Extensible Events as a system is released in a dedicated room version, clients
	will be able to use the stable event type there. The unstable event type should
	not be used in that dedicated room version.

[clokep]

Normally extensible events would only be permitted in a specific room version. However, this proposal's event is permitted in any room version. The stable event type should only be sent in a room version which supports extensible events, however.

So in this case you'd expect both the unstable version and m.room.topic? I'm not quite sure what this means.

[Johennes]

Hm, good question. Forbidding m.room.topic in existing room versions feels wrong. Maybe this situation calls for the coexistence of both org.matrix.msc3765.topic and m.room.topic with rules for reading and writing the topic in a room:

• If org.matrix.msc3765.topic exists, use that. Otherwise fall back to m.room.topic.
• When writing org.matrix.msc3765.topic, also write m.room.topic with just the plain text topic.

Does that sound sensible?

[clokep]

I think it sounds sensible, but it is just a bit finicky / complicated. E.g.:

1. You have both m.topic and m.room.topic set from a "modern" client, nominally the values are the same.
2. Someone using an "old" client updates the topic, but only m.room.topic is updated.
3. Users now see two different topics depending on what client they're using.

(This is also a potential security issue of presenting different information to different users, although it wouldn't be hidden per-say, just a display issue.)

[Johennes]

Yeah, true. 😕

The current implementation in Element Web actually has that problem even though it embedded the rich topic into m.room.topic (which was the first version of this proposal).

I don't think we can really avoid that unless we restrict m.topic to a new room version that forbids m.room.topic. Maybe pointing out the risk for early implementers in the proposal would suffice?

[clokep]

I don't have a better idea. Would be interested to hear from others though.

[Johennes]

In reconsidering this, I think it may be better to revert to not allowing the use of m.topic in current room versions. This was originally proposed in an attempt to mimic the approach taken for polls in MSC3381. However, polls introduce entirely new events and, hence, are not subject to the same compatibility and security problems that replacing m.room.topic causes. Instead of this, I think we should take the approach from MSC1767 and require a new room version for m.topic.

Therefore, I propose not to apply the suggestion at the start of this thread. I don't believe this should prevent this proposal from going through FCP and, if successful, be merged without being added to the spec yet (which is how MSC1767 itself was treated, too).

[tulir]

What's wrong with embedding the rich topic into m.room.topic for old room versions? That seems like the best option, since presumably old clients updating the topic would then clear the rich topic rather than leaving an old rich topic laying around.

[Johennes]

Hm, that's an interesting idea.

So new clients would write m.room.topic with both m.topic and topic (being the copy of the plain text body in m.topic) in content while old clients would only write topic (effectively deleting m.topic). If both behave correctly, we'd never have a situation where the old and new topic mismatch.

In places where the server needs the topic, it could read it from the plain text body in m.topic, falling back to topic if the former doesn't exist. On room upgrades, the server would also have to read the other mimetypes in m.topic.

Feels like relatively small risk and overhead that could enable using rich topics before extensible events land?