MSC3765: Rich text in room topics #3765
Conversation
Signed-off-by: Johannes Marbach <[email protected]>
Johennes
changed the title
turt2live
added
proposal-in-review
proposal
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. |
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
mscbot
added
finished-final-comment-period
and removed
disposition-merge
final-comment-period
turt2live
added
spec-pr-missing
| On the server side, any logic that currently operates on the `topic` field is | ||
| updated to use the `m.topic` content block instead: | ||
|
|
||
| - In [`/_matrix/client/v3/createRoom`], the `topic` parameter should cause `m.room.topic` | ||
| to be written with a `text/plain` mimetype in `m.topic`. If at the same time an | ||
| `m.room.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`. | ||
| - In [`GET /_matrix/client/v3/publicRooms`], [`GET /_matrix/federation/v1/publicRooms`] | ||
| and their `POST` siblings, the `topic` response field should be read from the | ||
| `text/plain` mimetype of `m.topic` if it exists or omitted otherwise. | ||
| 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. | ||
| - The same logic is applied to [`/_matrix/client/v1/rooms/{roomId}/hierarchy`] | ||
| and [`/_matrix/federation/v1/hierarchy/{roomId}`]. | ||
| - In [server side search], the `room_events` category is expanded to search | ||
| over the `m.text` content block of `m.room.topic` events. |
There was a problem hiding this comment.
@Johennes this bit doesn't seem to have been implemented in mainline synapse (unless I'm missing it): do we have a sample server-side implementation?
There was a problem hiding this comment.
Hm, no. I actually never made a server implementation. Initially this proposal didn't have any server parts and then I guess I forgot the implementation when adding these later. 🤦
There was a problem hiding this comment.
Better late than never: element-hq/synapse#18195
The advantage of having shunted the implementation is that it now can use stable identifiers directly. 😇
| `m.room.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`. | ||
| - In [`GET /_matrix/client/v3/publicRooms`], [`GET /_matrix/federation/v1/publicRooms`] |
There was a problem hiding this comment.
For reference: MSC3266 adds /room_summary, defined to behave the same as /publicRooms, so that will also need updating if the code isn't shared.
|
Spec PR: matrix-org/matrix-spec#2095 |
tulir
added
spec-pr-in-review
turt2live
moved this from Requires spec writing
to Requires spec PR review
in Spec Core Team Workflow
|
Merged a while ago: matrix-org/matrix-spec#2095 (comment) |
turt2live
added
merged
turt2live
moved this from Requires spec PR review
to Done to some definition
in Spec Core Team Workflow
This implements matrix-org/matrix-spec-proposals#3765 which is already merged and, therefore, can use stable identifiers. For `/publicRooms` and `/hierarchy`, the topic is read from the eponymous field of the `current_state_events` table. Rather than introduce further columns in this table, I changed the insertion / update logic to write the plain-text topic from the rich topic into the existing field. This will not take effect for existing rooms unless their topic is changed. However, existing rooms shouldn't have rich topics to begin with. Similarly, for server-side search, I changed the insertion logic of the `event_search` table to prefer the value from the rich topic. Again, existing events shouldn't have rich topics and, therefore, don't need to be migrated in the table. Spec doc: https://spec.matrix.org/v1.15/client-server-api/#mroomtopic Part of supporting Matrix v1.15: https://spec.matrix.org/v1.15/client-server-api/#mroomtopic Signed-off-by: Johannes Marbach <[email protected]> Co-authored-by: Eric Eastwood <[email protected]>
Tested on NetBSD 9 amd64 (federation, multiple clients) # Synapse 1.135.0 (2025-08-01) ## Features - Add `recaptcha_private_key_path` and `recaptcha_public_key_path` config option. ([\#17984](element-hq/synapse#17984), [\#18684](element-hq/synapse#18684)) - Add plain-text handling for rich-text topics as per [MSC3765](matrix-org/matrix-spec-proposals#3765). ([\#18195](element-hq/synapse#18195)) - If enabled by the user, server admins will see [soft failed](https://spec.matrix.org/v1.13/server-server-api/#soft-failure) events over the Client-Server API. ([\#18238](element-hq/synapse#18238)) - Add experimental support for [MSC4277: Harmonizing the reporting endpoints](matrix-org/matrix-spec-proposals#4277). ([\#18263](element-hq/synapse#18263)) - Add ability to limit amount of media uploaded by a user in a given time period. ([\#18527](element-hq/synapse#18527)) - Enable workers to write directly to the device lists stream and handle device list updates, reducing load on the main process. ([\#18581](element-hq/synapse#18581)) - Support arbitrary profile fields. Contributed by @clokep. ([\#18635](element-hq/synapse#18635)) - Advertise support for Matrix v1.12. ([\#18647](element-hq/synapse#18647)) - Add an option to issue redactions as an admin user via the [admin redaction endpoint](https://element-hq.github.io/synapse/latest/admin_api/user_admin_api.html#redact-all-the-events-of-a-user). ([\#18671](element-hq/synapse#18671)) - Add experimental and incomplete support for [MSC4306: Thread Subscriptions](https://github.com/matrix-org/matrix-spec-proposals/blob/rei/msc_thread_subscriptions/proposals/4306-thread-subscriptions.md). ([\#18674](element-hq/synapse#18674)) - Include `event_id` when getting state with `?format=event`. Contributed by @tulir @ Beeper. ([\#18675](element-hq/synapse#18675))
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