Thank you for considering Matrix. Many Discord users have migrated to Guilded after their accounts or communities have been shut down, but this is not recommended, explained below.
Matrix has been a popular alternative to Guilded, but many people still don’t get the why. We will start with why you should move from Guilded to Matrix, followed by comparisons of specific feature and some helpful tips. But before we do that, let’s start with…
Recall the computing definition of the word “server”:
A program that provides services to other programs or devices, either in the same computer or over a computer network.
A computer dedicated to running such programs.
The definitions can hold true for a server for a multiplayer game (eg. Minecraft), a server reserved for a group of people for communication (eg. Mumble & TeamSpeak), and a server where Guilded bots are being operated from. In each case, the server software (such as the Minecraft server jar file) meets definition #1, whereas the server infrastructure (eg. VPS) meets definition #2.
But that’s not the case for a Guilded “server”: it’s just some data, together with data of other “servers,” resting on Guilded’s computational servers. A Guilded “server” is not a program on its own, nor has any computational infrastructure been dedicated to any specific “server,” thus violating both definitions. Presumably to attract gamers who often utilizes the correct “server” concept, Guilded attempts to equate it to a chat group, muddying the waters for the definition of this technical term. (Hence Guilded refers to “servers” as teams in API documentations.)
In Matrix, a homeserver is a server, in that it meets both definitions: Dedicated infrastructures (definition #2) running a server software (definition #1). Furthermore, these homeservers, while operated independently of each other and not under the control of a single entity, communicate (transmitting messages and such) with each other using an agreed-upon protocol, thereby keeping the Matrix platform alive. Platforms that use such structure, such as Matrix, fediverse and email, are called federated platforms.
In the scope of this guide, the key reasons to move from Guilded to Matrix are:
Matrix addresses all of the above.
Matrix uses free software for its server and client softwares.
In Guilded, a place that allows sending text messages is called a channel (if belongs to a “server”) or a DM.
In Matrix, a place that allows sending text messages is called a room.
In Guilded, text channels that are not DMs must be associated with a “server.” Thus a “server” can be understood as a collection of channels that share certain settings.
In Matrix, rooms can be included in a Space. A Space can be used in similar fashion to a Discord “server” (controlled by the admins of the constituent rooms) or a “server” folder (controlled by anyone). A Space may also include another Space. Rooms do not share settings with Spaces, although rooms can require Space membership for joining.
Note that Matrix does not (and cannot, due to its decentralized nature) paywall features.
| Feature | Guilded | Matrix |
|---|---|---|
| Registration | Requires Roblox account since April 2024. | Depending on homeserver (especially if you’re running your own), email may be optional, and phone number is usually optional. There is no automated human check after registration. |
| Price | Free, effectively subsidized by Roblox the game. | Free for most homeservers (but please consider donating to them). Hosting a private homeserver may also incur cost (could be free). Note that paying (not donation) only affects where your data is hosted and (to a much lesser degree) server performance; it has no effect on features. |
| Username | Users are identified by display name (maximum 32 characters) to fellow users, and user UUIDs and roblox user IDs for programming purposes. | 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, maximum 25 MB. Can be zoomed. | 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. |
| Profile description and background | Supported. | Not supported currently, will be supported using profile rooms. |
| Profile status | Supported. Guilded even has a custom status generator. | Effectively not supported2. |
| Nicknames3 | Not supported. | Supported (/myroomnick). Up to ~65200 bytes. |
| Forum channels | Supported. | Not supported. |
| Media-only channels | Supported. | Not supported. |
| Specific avatars3 | Not supported. | Supported (/myroomavatar). See “Attachments” for limits. |
| 2FA | Email or TOTP. | Not required for login, but required (QR code, emoji verification, or Security Key) for viewing past encrypted messages. |
| Text messages | Maximum 36608 characters (main body section can have up to 4000 characters, the rest has to be placed in the embed cards). Formatted in Markdown. | Up to ~65200 bytes (up to ~25260 bytes if a formatted message with plain text fallback sent).1 Supports Markdown and HTML. |
| Attachments | Maximum 500 MB (25 MB for still images), limited to multimedia and document filetypes4. | Maximum 50~100 MB, no artificial file type limitations (for most homeservers; customizable if you run your own homeserver). |
| Reactions | Only emotes (Unicode or custom ones). | Unicode emotes and text. |
| Stickers | Not supported. | Unlimited with setup. See here. |
| Public read receipts | Not supported. | Supported. |
| Direct messages | Not encrypted. | Encrypted by default, including VoIP. |
| Starting a DM | Depending on privacy settings of the recipient. Friendship and/or mutual “servers” may be required by the recipient. | Initiating a DM solely requires the recipient to accept the request5. Users can leave DMs anytime they wish. |
| Group chats | A channel is associated with a “server.” You can only join 100 “servers” and own 20 at a time. | A room is standalone, but can be optionally included and associated with a Space, which is just a room linking to other rooms. You can join unlimited amount of rooms. |
| VoIP in groups | Supported. | Real-time data using WebRTC, signalling using room state. |
| Organizing chats | Channels in a “server” can only be organized by the “server” owner and moderators with “manage channels” permission, in a many to one fashion into categories and groups, and cannot be moved to another “server” or group once created. A team can have up to 100 groups in it, with up to 350 channels in each. | Rooms can be included within an unlimited amount of Spaces. Spaces may also include other Spaces (similar to Guilded’s channel categories and groups). |
| Group chat privacy | You may deny new members from reading messages prior to them being invited / joining. Private threads are only visible to their own members and group/team members with “moderator access” permission to that channel. Teams can choose to make their chat history public, with per-channel granularity. | 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 encryption6. |
| Publicity | Team URLs are first come first served, however, unused names are reclaimed so often. Teams are searchable by name unless explicitly disabled. | Each homeserver has a room directory which anyone in that homeserver may publish to. Room aliases are usually first come, first served. |
| Invite | Through generating invite or application links, or through shareable addresses. | Through directly inviting users, or through shareable addresses. |
| Permissions in group chats | Single-owner. How long did it take for you to learn role hierarchy? A “server” can only be shut down by its owner, and that affects everyone. Members cannot demote their own permissions. Roles of a member are reset when a member leaves hence do not survive rejoin. | Up to 2^54 power levels (-2^53 to 2^53-1, however I highly doubt you will ever reach that limit), with minimal permissions. A user acquires a permission if their power level is equal to or higher than the power level required for the specific permission. Rooms are not owned by any user or server, hence cannot usually forcibly be shut down without coordination. Members can demote their own permissions. Power levels of members survive leave and rejoin. |
| Size limits of group chats | No artificial limits, albeit current implementation behaves badly past approximately ten thousand members. | 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. |
| Bans | Bans are only visible to “server” moderators. One can also see their own ban when they attempt to join a “server”, but not the ban reason. | Bans are public to all members, along with the reasons. |
| Disabled and deleted account handling | Deleting an account is irreversible. Messages sent to a “server” from deleted accounts stay unless explicitly removed by somebody else. User name and user settings from deleted accounts are removed. “Servers” owned by accounts deleted by T&S are automatically shut down. “Servers” owned by a manually deleted account is not possible to exist as the account delete API has a precondition of no “server” ownership at the time of the request. | Disabling an account is usually irreversible. Users can cause their messages to be forgotten while disabling their account: in that case, their messages are not sent to further users and servers. Rooms created by disabled accounts stay. |
| Running a bot | Public bot API exists, self-botting seems to be tolerated as long as it stays within Guilded and does not propagate to Roblox the game. | You can run bots on any user accounts7 8. Selfbotting is permitted (but be nice). |
| Network access | IPv4 and IPv6 supported. | Most if not all homeservers participating in the public federation have IPv4 connectivity but IPv6 connectivity varies from homeserver to homeserver. |
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
Element and SchildiChat has status available as a lab feature, but it is only visible to those who you have a DM with. Statuses are not encrypted. ↩
The client and the server rejects upload when you attempt to upload a disallowed file type. ↩
Note that Matrix has no concept of “friends” or “contacts” per se, although the DM list can serve the same purpose. However, user-based contact ignoring exists on Matrix, using two different methods. The former method prevents any and all messages from reaching the recipient, and the latter method using policy rooms hides them client-side by interpreting an ignore list. The latter method is currently only available in Element as a labs feature. ↩
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. ↩
Matrix has no distinction between user and bot accounts (nor is there any dependency between the two). Unless specifically exempted by the homeserver (not needed in most cases), bots have the same ratelimit as other users. In Element and SchildiChat, the user token of an account is available by accessing “User Settings” then “Help & About.” When running an autonomous bot, please be courteous and indicate to others (in username or display name) that the account is a bot. Bots that want to control other user accounts need to create an application service, which needs to be approved by an administrator of the homeserver that the bot is using. ↩
If your app/bot is good, then matrix.org would love to hear from you (with the potential possibility of featuring you on their blog)! ↩
Help improve its content by opening a Pull Request on GitHub.