Why are the APIs being designed this way? Why are we being forced to use TextChatService instead of adding a new field to policy info via PolicyService:GetPolicyInfoForPlayerAsync()? Wouldn’t that be simpler for developers to migrate their custom chat systems?
1 Like
Thank you for clarifying on this
Thanks for the question. However, there is more to the TextChat service than just respecting account privacy settings or text-filtering. TextChannels will handle the following requirements for developers that I often encounter lua chat systems may fail to remember to implement:
- Respecting user blocked status
- Attributing messages to a user for moderation in abuse reports
- Hiding chat on platforms that aren’t supposed to have one (such as consoles).
These are just a handful of the requirements the API handles now and can be adapted to handle more in the future.
We don’t want creators to handle all of these requirements when they could be focused on making experiences. The TextChatService API allows developers to express their intent and let the service handle the rest.
4 Likes
Thank you for the clarification. Due to my lack of understanding on how TextChatService works, I was under the impression that chat had to be processed through Roblox’s chat UI which is not the case. As MaximumADHD has pointed out, migrating full custom chat UI to TextChatService is very very simple and I highly recommend anyone struggling with it to check out his post
2 Likes
will there be any way to facilitate cross-server communications through this?? that’s pretty much my main concern with this update and quite a few other people have expressed that too in this thread
i worry that the new filtering APIs might be restricted to only people inside the same server, it would be practically impossible to port things over to TextChatService properly if that’s the case. if there’s any official guidance or news around this please let us know!!
here are my use cases for cross-server communication
-
cross-server shouts, one player broadcasts a message to every server’s chat. in this situation both the sender and receiver would be online in the same universe, but not necessarily the same server
-
cross-server direct messaging, in this situation the sender would be online, but the receiver might not be. in the case where the receiver is offline, the message is stored in a datastore and not shown to them until they log in again and check
one of my biggest pet peeves is when an API takes a UserID as an argument but then complains when that player isn’t in the server… why not just use a Player object then??? 
2 Likes
This in no way shall be a reason to completely take our ability away and restrict our freedom over what we can implement and change within our experiences. A single unified API with ease of use that developers can use would be a great solution, rather than forcing developers to migrate to an under-performant and limiting service.
Freedom is what we ask for. I believe the response from the community would’ve been very different if this was handled in a way that didn’t force account moderation just because a developer doesn’t want to be forced to use TextChatService.
Your “freedom” would look something like Roblox deprecating the Legacy Chat API, and potentially even intentionally breaking it to the point when it’s just necessary to switch. Do you think this approach is better than what they are actually doing?
As for fully custom chat systems, developers could just simply bypass all of the privacy restrictions put in place by the user, their parent, or Roblox itself. This way, it makes sense for the company to take moderation action, because at this point you are literally not complying with Roblox’s legal obligations.
I don’t see this as a major issue. I do agree that there are problems with performance and lack of old features. But do you think that Roblox will leave all of that in the shadow?
The unfortunate aspect of cross server chat solutions is that there is not a way to report abusive behaviors from users not in the current server.
As you’ve pointed out, AddUserAsync accepts a UserId but complains when the user is not in the server. I’ve been vying to support cross server chat through TextChatService and we have designed its API to facilitate users outside of the server someday. However, we have not started formal designs to solve this gap, I’m hopeful that requests like yours can help us get their sooner.
2 Likes
They’re going to do that anyway? I don’t want the old Legacy Chat to remain, I want APIs to allow us to continue being compliant while still allowing our systems to remain.
The problem is, that moderation resources are going to be spent one way or another: When a developer creates their own chat system even after the deadline, moderation will have to spend resources to try to find and shut them down, the same goes when a developer does not implement necessary APIs.
I mean considering the past few updates, some certain core scripts still being very underperforming even after a long time of them being out, very much possible.
Legal obligations will always be the number 1 priority unfortunately. Due to the modern world literally becoming “a lawsuit for a simple insult”, things like in-game chat need stronger enforcement.
If this change wouldn’t be a thing, even more moderation resources would have to be used in order to comply with all legal obligations.
So, the enforcement of chat system migration would have to come earlier or later anyway.
That’s fair. But judging by the mere scale of this change, I would hope that they get things sorted out quick.
1 Like
i think that there could be a possible solution to the reporting issue: if the server knows what user the message is intending to come from, then maybe when a message is received from that user then the user can be displayed as an option in the report ui, whether that be temporarily (maybe like an hour or so?) or permanently for that game session
or maybe there’d be an option to report individual messages, like if you see something abusive you could go to report ui → report message, and it’d display a list of messages you’ve recently seen?
i’m just spitballing ideas, it really sucks to hear that it isn’t a supported use-case yet, but hearing that at least someone at Roblox has acknowledged it makes me a little hopeful for the future 
I mean, it is still very well possible to do the same thing meanwhile not limiting the freedom this much. Necessary APIs would’ve been implemented, and for those that did not use them, would face moderation action like how they would be if they didn’t properly implement filtering. Since this platform is built upon UGC content, a developer not abiding by the law or the ToS would not cause Roblox to be held liable. There are many ways Roblox could’ve gone by, many better for both sides.
1 Like
All I really want to know is; are these parental controls actually used by the target demographic? I recall hearing a great many fiascos on YouTube that would never have happened if the parental controls, kids’ app, etc over there were actually being used.
2 Likes
Why can’t you add a ParentalControlPolicy service so we can determine if we follow parental controls? that makes more sense than banning custom chat
See the immediately following bullet point:
The idea is to avoid having the same situation repeat itself over and over again. The belief is that there will be enough policy to deal with around chat that an increasing number of individual policy items wouldn’t be a sustainable solution.
I fully understand the need to ensure the ability to comply with global policy and regulations, but I don’t feel this is the best way to approach the problem.
It isn’t easy to migrate a completely custom chat system to using TextChannels, especially feature-rich systems that use mechanics that aren’t directly supported. Why can’t we just have a function that, given the sender, the recipient, and the chat string, returns if the message can be sent?
That would be 1,000,000x easier to implement, would not require completely recoding chat systems, and would be simpler to explain in documentation to amateur programmers.
It isn’t easy, and it’s unfortunate to have to do it on a constrained timeline, but it isn’t unreasonably difficult either. The hardest part of writing a custom chat system is all of the interaction design and GUI munging, which swapping out the underlying channel the messages are sent through to TextChatService doesn’t impact.
Think of it this way: At some point in your non-TextChatService system you’re inevitably sending messages between the Client / Server using RemoteEvents. Under the TextChatService your core primitive is just hooking up to TextChannel.MessageReceived instead of RemoteEvent.OnClientEvent on the client and moving your limitation logic to TextChannel.ShouldDeliverCallback on the server. Obviously there’s more to it than that if you need to juggle channels, but there should be sensible places to slot the TextChatService based implementation into most existing custom chats.
Perhaps I’m misunderstanding the implications in the original post, let me ask for clarification:
In the post, “CanUsersDirectChatAsync” is used to build a text channel with eligible participants. How do I handle this using “CanUserChatAsync”? Will there be scenarios where Player1 can chat with Player2 & Player3, but Player2 can’t talk to Player3? If so, will I have to create a channel for each pair of users, or can I route everything through 1 channel and Roblox will figure it out?
Additionally: my game uses a system to let console player’s use pre-written messages to point out vital information to their teammates. Does this constitute a “conversation” and have to be passed through a TextChannel?
One of the reasons I didn’t use the new chat and stuck with legacy chat was because there was not many tutorials for it, there was many tutorials for legacy. I am happy to hear that you will have tutorials on the new chat! Having many tutorials is like advertising the idea of a better chat system and will make more developers want to switch.
I see other developers are displeased with the new chat so I recommend extending the migration date if most of the features and bugs are not finished by then.
More customization = more developers will like it.
I also really appreciate Roblox Staff listening to feedback by developers. We developers also want the best for roblox! 