Thank you for considering Matrix. We will start with why you should move from Telegram to Matrix, followed by comparisons of specific feature and some helpful tips.
In the scope of this guide, the key reasons to move from Telegram to Matrix are:
Despite recent studies, Telegram’s use of its own MTProto protocol remains a debated subject, which will be left up to you.
| Feature | Telegram | Matrix |
|---|---|---|
| Registration | Requires phone number or purchasing so called “anonymous numbers” to be used in place of phone number. | Phone number is usually optional. Depending on homeserver, email is commonly required. There is usually no human check after registration. |
| Username | Users are identified by phone number or username (if set up, 5~32 alphanumeric characters) to fellow users, and user IDs (around 9~10 digits) for programming purposes. A display name can be added (no limit). | Users are identified by their MXID (eg. @alice:example.com), composed of the username (must be ASCII characters, upper case letters are not allowed) and the server name (not exceeding 255 characters when combined, including the introducing at symbol and the colon separating the parts). A display name can be optionally added (up to ~65200 bytes)1. |
| Avatar | Static or animated; limit unknown. Can be zoomed; the returned avatar has a maximum definition of 640x640. | See “Attachments” for limits. Can be zoomed (at least in Element/SchildiChat), in which case the avatar will be shown in the uploaded definition. Animated avatars are supported and will be rendered (at least in Element/SchildiChat). |
| Profile description | Supported. | Will be supported using profile rooms. Not supported currently. |
| Room-specific nicknames | Group admins can talk on behalf of the whole group or have custom title shown next to their name. | Supported (/myroomnick). Up to ~65200 bytes. 1 |
| Room-specific avatars | Not supported. | Supported (/myroomavatar). See “Attachments” for limits. |
| 2FA | One-time token sent to another session. | Not required for login, but required (QR code, emoji verification, or Security Key) for viewing past encrypted messages. |
| Text messages | Maximum 4096 characters. Supports Markdown. | Up to ~65200 bytes (up to ~21270 bytes if a formatted message with plain text fallback sent).1 Supports Markdown and HTML. |
| Attachments | Maximum 2 GB for free users and 4 GB for Premium users. | Maximum 50~100 MB (for most homeservers; customizable if you run your own homeserver). |
| Reactions | Free users can use limited set of reactions, premium users can use custom emoji. | All unicode emotes and text. Custom emojis are supported in certain clients. |
| Stickers | Up to 200 packs of 120 static or 50 animated each. | Unlimited (static or animated) with setup. See here. |
| Public read receipts | Supported ambiguously. | Supported. |
| Direct messages | Not encrypted unless explicitly opted into secret chat, which cannot be carried across devices. VoIP is encrypted. | Encrypted by default, including VoIP. |
| Group chats | You can join up to 500 groups and channels. | You can join an unlimited amount of rooms. |
| VoIP in groups | Supported. | Limited Support via integration with Jitsi. Expected to be replaced by a better solution during 2022. |
| Organizing chats | You can pin or archive groups (similar to favourite and low priority on Element/SchildiChat). | Rooms can be included within an unlimited amount of Spaces. Spaces may also include other Spaces. |
| Group chat privacy | You may deny new members from reading more than 100 messages prior to them joining. | You may deny new members from reading messages prior to them being invited / joining. You may also allow or deny guest access (such as Matrix Static) from reading messages. You may also enable encryption2. |
| Publicity | Any group or channel set to public can be listed in search results, but how they are shown is arbitrary, as global search is not always visible to users. | Each homeserver has a room directory which anyone in that homeserver may publish to. |
| Invite | Through directly inviting users, or through generating invite links. | Through directly inviting users, or through shareable addresses. |
| Group chat permissions | Permissions of each administrator are set manually. All admins are equal (except owner). Permissions of a member do not survive leave and rejoin. | 2^54 power levels (I think it’s -2^53 to 2^53-1, however I highly doubt you will ever reach that limit). A user acquires a permission if their power level is equal to or higher than the power level required for the specific permission. Power levels of members survive leave and rejoin. |
| Size limits of group chats | Up to 100k members in groups, unlimited in one-to-many channels. | No artificial limits, albeit current implementations do not perform well with rooms having more than a few tens of thousands of members and a few dozens of homeservers. |
| Disabled and deleted account handling | Disabling an account is reversible until one year after disabling. Accounts that do not login for a year get automatically deleted. Messages from deleted accounts survive for one more year from deletion. | Disabling an account is usually irreversible. Messages from disabled accounts are not sent to further users and servers. Rooms created by disabled accounts stay. |
| Ads | Popular channels now show ads for free users. Users with premium subscription do not see ads | It is technically possible for a homeserver to insert ads, but there are no known occurrences. |
| Network access | IPv4 supported, IPv6 broken. | *Most if not all homeservers participating in the public federation have IPv4 connectivity but IPv6 connectivity varies from homeserver to homeserver.. |
There is a bridge that allows you to connect a Telegram group with a Matrix room.
Limited by Matrix event size limits. The current event size limit is specified to be 65536 bytes. Formatted message size limit assuming the formatted body takes approximately twice as much as plain text body. ↩ ↩2 ↩3
Enabling encryption is irreversible for security reasons. Note that it is pointless to enable encryption in a public room, with one exception: the case you want to have a persistent cryptographic trail of who read the messages. Furthermore, enabling encryption means users will not see messages before their invitation (if applicable) or their entry. ↩
Help improve its content by opening a Pull Request on GitHub.