As a Roblox developer, it is currently too hard to create innovative communication methods within my experience. This is fueled by the recent announcement that TextChatService would be required to be used for all conversations in the near future.
Section 1: Debunking
Since there are a few common speculations about the reason for this update, let’s discuss them first.
This policy will solve situations like the 'Crosswoods incident' since Roblox can now validate if a message was actually sent by a player
This is sort of true, Roblox can technically validate messages sent via their CoreGui version of TextChatService however this most certainly isn’t the sole reason for this update since we are still allowed to use custom UIs with TextChatService and it wouldn’t be possible for Roblox to validate the authenticity of messages sent in such experiences.
Roblox said this is to make global compliance easier for developers
Yes, Roblox did say this, but I do have to wonder why TextChatService isn’t just the ‘preferred’ option if this were to be the case. What makes TextChatService so special as to the point that no other comparable API could exist for developers to use? There’d seemingly be no reason not to allow both methods to co-exist if this were the only reason. Many developers (such as myself) wouldn’t care if they’d regularly need to update their chat implementation for new compliance laws assuming their chat system gets to work in the way they envisioned it; why harm those developers by forcing it?
TextChatService is much more secure, and that's why Roblox is forcing a migration
If this were to be the case, Roblox has unfortunately done a terrible job of communicating it as I can not personally see any obvious security change between the two, which makes one more secure than the other.
Section 2: What this update ACTUALLY does
Many people don’t seem to exactly realise what problems this update actually introduces, so let’s discuss them.
Cross server communication possibly now banned!?
Yes, you heard that correctly, cross-server communication methods don’t have a valid TextChatService singleton that they can use and, as such, may no longer be possible if this policy goes into effect.
UIBlox theme will be heavily used
While many may argue that you can create your own custom UI. Most developers aren’t going to bother with that extreme effort, and since the default UI has very little customisation methods; most experiences are going to be forced with a UIBlox looking UI. This may not be within their vision of their ideal experience, but the effort may be too much for them to do otherwise; this all leads to a less innovative chat solution in some experiences.
Encourages developers to dance around the API, making everything less secure
The API design for TextChatService was almost certainly not made for anything beyond experience chatroom-like chats, and the API design speaks to that point with very little memory control if we have a lot of different conversations. We’ve even seen developers working around API stuff like this in the past with Roblox filtering, developers were not provided with a way to filter external API responses, so we just falsified it as coming from a random player in the server; this was (and still is) common practice because Roblox unfortunately failed to provide us with a suitable API for the situation. We are further encouraged to do this with this API for use cases such as efficient memory management for players who leave the experience yet still have their text visible in-experience.
Creates unnecessary abstraction
Say you want to make an in-game billboard where users can put up posts and reply to them. Well, good luck because while this previously would have been pretty easy, being a few simple calls to the filtering API, now you have to do the following:
- Create a TextChannel for each post and maintain it until the post is deleted in case someone replies.
- Add everyone to the TextChannel so they can see the message
- Anytime a new player joins the experience, you must repeat the above steps since Roblox doesn’t have any methods to retrieve existing messages
Why wouldn’t just one TextChannel be good enough? Well, you’d still end up needing to re-create the channel every time a new player joins, and you are likely to lose out on any context aware filtering that may exist.
Section 3: Why?
This section is, of course, just speculation given the info we’ve been given, but I thought I’d include it anyway.
Context aware filtering
One major benefit I can see for Roblox with TextChatService is that they now have more context on where a message was sent. Previously, filtering for chat was not connected to any particular channel, and there was no way for Roblox to determine whether two messages were sent via the same channel or not.
Easy to make on-the-spot changes
Changes could be easily tweaked behind the scenes to make chat in particular channels more strict if needed.
4. A possible alternative
Given my analysis, it seems the best solution would be to implement an API similar to TextChannel with four massive changes:
- It should only provide filtering (not sending messages to clients in itself).
- The sender should be a UserId (not a Player instance) and should be allowed to include players who have since logged offline or are in a different server.
- The API could provide a list of players in the current server who can see the message and their specific filtered copy.
- We shouldn’t need to keep these in server memory and should be able to reference them via a short-id to prevent memory leaks.
This API could still benefit from context-aware filtering (since each related message is connected to a particular conversation) without requiring developers to work around TextChatService; the only drawback with this API is that we could have duplicate conversations in the case of cross-server communication but this is already an issue with TextChatService so I think we can disregard that as a genuine issue.
This solution isn’t perfect and still falls for a pitfall, mainly around the fact that forked versions of the legacy-chat and custom chat systems would need to be revamped however regardless of what API Roblox adds that’d be required anyway.
If Roblox is able to address this issue, it would improve my development experience because it would allow me to continue to make innovative communication solutions in my experiences. Innovation most greatly shows when Roblox supports more than just the ‘common use cases’, and I hope Roblox sees that too.
