Telegram Topics

[FarisZR]

Telegram announced a new Topics feature in the latest update, something similar to Matrix Spaces. https://telegram.org/blog/topics-in-groups-collectible-usernames

It would be great if the bridge would support it as separate room, so each topic would be treated as a new room.

So users could create a space on matrix and use Topics on Telegram to deliver the same experience.

[kn0wmad]

Topics seems to make the bot close to unusable for us, unfortunately. It does still function, but carries an annoying amount of messages about version support issues.

It would be ideal if the bot could map room-to-room, then we could mirror Matrix/Telegram

[valerio-bozzolan]

I agree to handling a specific "Telegram group topic" to a specific Matrix room.

If developers need to do tests, feel free to ask me and I can invite you in a public Telegram group with topics enabled.

[joepie91]

From a glance, it seems like the mapping works something like this:

• If a message is a Matrix-side reply to another message, it is grouped under the Topic that the original message was in, as a Telegram-side reply to that original message
• If a message is a Matrix-side reply to the "pseudo-event" that represents the creation of the Topic, it is grouped under that Topic as a non-reply on the Telegram side (this is what all the replies to version errors are coming from, they're just topic-tagged messages)
• If a message is not a Matrix-side reply, it ends up in what seems like a "default" Topic

I do feel like a Space of rooms, one per Topic, would probably be the most viable approach here.

[FarisZR]

Is there a way to push this feature to get implemented?, a bounty of some sort maybe?

[git-bruh]

Gonna take a shot at it, stumbled upon some useful leads wrt topics and their interaction with the TG api

[git-bruh]

Hmm, turned out to be a bit more involved than I first thought. The API stuff with topics shouldn't be a huge issue, but integrating the logic of mapping topics to rooms seems to be a problematic task, since the whole codebase is modeled around the assumption of 1 TG group -> 1 Matrix room. Some of the issues I faced:

• The portal table https://github.com/mautrix/telegram/blob/master/mautrix_telegram/db/upgrade/v00_latest_revision.py#L34-L58 has a UNIQUE constraint on tgid, so that needs to be removed and another column for topic_id be added. But it adds some redundant data, eg peer_type, tg_receiver etc irrelevant for a topic since they're the same as the "parent" group. Creating a separate table would be unmaintainable since each query would have to be special cased.

• Bans / kicks would be an issue aswell since you'd have to make them reflect across each room corresponding to topics in a TG group

• Some stuff would need to be special cased to not run for rooms that are topics, eg. backfilling

• A conditional for topic_id needs to be spammed everywhere where data from the telegram API is involved

So far I only have the logic for getting the topic ID from a TG message https://github.com/git-bruh/telegram/commit/1dc0fc6ad96cfe8cc820f81710e035c3063d8e30

[ashledombos]

Is it possible to somehow associate a topic on telegram side, to a thread on Matrix side? This feature seems closer to topics than Space/rooms.

[git-bruh]

I did think of that aswell as it would save a ton of hassle but the UX didn't feel right, like an empty room with just N threads. Probably better to do it this way though, makes it possible to avoid handling membership event for every topic room

[KF-Art]

So for now it not possible to implement cleanly bridge a group which has topics?

For now the only workaround I could think about was to use threads which each one corresponds to one topic. Of course this is not practical, because I would have to tell users to use only those threads and not replying outside them, but also it makes that all messages sent from Matrix in a Topic would be marked as reply of the first message.

I know that these things are complicated but it would be great that the bridge supports topics in the future, regardless if it's through spaces+rooms or threads, even if I have to manually manage some things per each topic.

[valerio-bozzolan]

Maybe as a workaround we can just have one Matrix destination chat, and the bot can have a mode where it puts the topic as prefix of the message body. Like:

A: [Tech] Yeah how are you
B: [Communication] We have a problem with the bill
C: [Tech] Fine thank you
D: [Communication] Oh gosh

This would be a first integration to receive the upstream context, leaving space for better improvements in the future.

[ManDay]

What about the other direction, though? The bridge can only be useful if it works in both.

[valerio-bozzolan]

Well, I guess:

• if we are replying to a message that starts with [XXX] try sending to the XXX Telegram topic
• if we are not replying to anything but the message body starts with that prefix, try sending there too
• send to the main topic otherwise

[TomTheDragon]

It would be great if we had the support for topics, since more and more groups switch over to just one single one with topics. We recently switched over from Matterbridge to Mautrix-Telegram for most of our groups, since it integrates so much better between Matrix and Telegram. But we also have one group that we cant bridge, since it uses topics.

I am not sure if this helps but thats the commit that gave Matterbridge its topics support https://github.com/42wim/matterbridge/commit/601f48a50ea31a9631011766c680ecef931ddafc

[cyrneko]

What about the other direction, though? The bridge can only be useful if it works in both.

Telegram (IIRC) automatically handles displaying replies in the correct topic. So if the bridge replies to a user that is chatting in a topic, Telegram will automatically assign that message the correct topic.

Normal messages without replies will always be in the main topic unless otherwise specified

[ayoahha]

Is there any update on this feature ? Matching Telegram topics with rooms

[Gredin67]

@git-bruh

So far I only have the logic for getting the topic ID from a TG message https://github.com/git-bruh/telegram/commit/1dc0fc6ad96cfe8cc820f81710e035c3063d8e30

Could you use that to implement that ? :

puts the topic as prefix of the message body.

[Gredin67]

• The portal table https://github.com/mautrix/telegram/blob/master/mautrix_telegram/db/upgrade/v00_latest_revision.py#L34-L58 has a UNIQUE constraint on tgid, so that needs to be removed and another column for topic_id be added. But it adds some redundant data, eg peer_type, tg_receiver etc irrelevant for a topic since they're the same as the "parent" group. Creating a separate table would be unmaintainable since each query would have to be special cased.

• Bans / kicks would be an issue aswell since you'd have to make them reflect across each room corresponding to topics in a TG group

@git-bruh as far as I know a Matrix Space is nothing else than a room containing rooms. Wouldn't the solution be to modify the Matrix Spec to allow binding rooms state (state_events/permissions/participants) to that of the Space it belongs to ?

• Bridge state events from the telegram group to the space
• Bridge message events to one room per telegram group topic

see. https://spec.matrix.org/latest/#room-structure

[Gredin67]

We should have a canonical space, from which the "topic rooms" would inherit their state.

m.space.parent events can additionally include a canonical boolean key in their content to denote that the parent space is the main/primary space for the room. https://spec.matrix.org/v1.9/client-server-api/#mspaceparent-relationships

[Facni]

Any update?

[NepNep21]

Wouldn't it make more sense to bridge topics as threads rather than rooms in a space?

[maltee1]

Both approaches have their pros and cons UX wise, but bridging as threads is probably a lot less effort.