I just started thinking about improving this bridge and getting it up to speed with the IRC bridges.

Before I start writing code, I wanted to be certain the concepts were well mapped between the two worlds, so that we do not end up being stuck by a lack of consistency. So first, I believe this bridge should remain a pupetting bridge, and given the current state of Telegram APIs, there is no way we get a full two-way bridges without a bot on the Telegram side.

Inventory

Here are the concepts that I think are interested to map from Telegram:

registration and authentication (I don't see why we should not be able to create a Telegram account from Matrix!)
users, of course, which can be identified by username or after sharing one's contact list, have a profile and avatar;
direct chats with users;
group chats, with multiple users, including description and group picture;
channels;
message edition and deletion;
attached files.

On the other end, the following concepts should not be mapped:

history, I don't see how we can map history and scrollback properly;
end to end encrypted chats, at least for now, the bridge breaking the encryption anyway;
voice/video call, there is no way we can map that in the near future.

I am hesitating for the following concepts, still thinking maybe about planning to include them but not short-term:

geochat (I even have no idea what they are);
self-destructing messages (doable, but not that easy to implement).

Registration and authentication

I think the overall process should be self services. It could be made available through a bot, or through a widget, or a combination of the two. I still have to dig into the features widgets provide to see what can be implemented through a widget exactly.

Multi-step authentication should be mapped to a multistep questoin/response on Matrix.

Users

Telegram has a distinction between multiple types of users:

the current user;
a user from the contact list;
a user not from the contact list, from which a phone number is known;
a user not from the contact list.

Users can be discovered by username, or by other means (uploaded contact list), in which case they are identified by an integer. Unfortunately, usernames, despite being unique, can vary (a user can switch username). Also, the user integer identifier is unique across all types of users.

Therefore, a suggestion would be to use @prefix_<id> for every user, and have a separate mechanism to discover users by username (bot command, or anything else).

I guess we could implement something for discovering new users based on their phone number, but I do not believe that should be mapped to mxids or room aliases.

Direct chats and group chats

There are two dinstinct kinds of chat on Telegram, that one cannot mix (impossible to invite additional members to a direct chat). Also, both direct chats and group chats are identified by an integer id, only unique in its scope (either the user id, or the room id). Additionally, a direct chat can only be opened once with each user.

There is no strong obligation on using aliases to map these rooms: the appservice should automatically invite the Matrix user to rooms that he is not part of. Leaving a room should leave the actual Telegram room.

Also, to match the distinction between direct chat and group chats, two conditions should be applied:

one should not be allowed to invite people to a room mapped with a direct chat (this can be accomplished with room permissions I believe)
one should not be allowed to have two different rooms open for direct chat with the same user.

Channels

Channels are simple group chats with access restrictions. They are identified by name, so one should be able to find them at #prefix_#<name>.

Message edition and deletion

Editing a message on Telegram is only allowed for the latest messages. It could be reflected on Matrix as deleting and posting again until we have proper message edition.

matrix-org / matrix-appservice-tg

Mapping Telegram concepts to Matrix concepts #11