You have until April 2025 to fully migrate.
This is grasping for straws, lol. The stock could have changed for any number of reasons; you just want it to be because of this.
1 Like
Why not just move the textchatservice ui into the playergui so it is way easier for developers to customise it
As soon as you remove the ExperienceChatMain performance hog, I’ll switch.
Thanks, I was also concerned about issues that I experienced with it, which is why I made two of those bug reports.
Cool I hope this won’t break anything on a massive scale 
1 Like
That’s not entirely my point. I know there is some time but what i meant is that this is pretty much a thing we HAVE to do it regardless, aka they are focing this on us. I should have worded that better initially to be honest.
What could have been any other reason though? Big companies don’t magically get a jump in stock out of nowhere or because of some sort of unknown magical reason. And they especially don’t see any jump in stocks right after they announce something designed to fight back against the countless times they have been called a pedophile safe haven or whatever else terms.
It’s really hard for me to believe the jump in stock could have been caused by anything other than this announcement (not this SPECIFIC announcement to us but some sort similar announcement meant for share holders and other kinds of higher up parties derived specifically from this, or maybe vice-versa).
2 Likes
Hi Creators,
We appreciate everyone’s feedback. We recognize this is a major change, and wanted to follow up with some clarifications and changes that we’ve made based on your feedback. We’ve updated the body of the original post to reflect these changes.
Why are we doing this?
-
We want to reiterate, that the primary reason for this change is to ensure that all chat messages between users respect our upcoming parental controls which give more control to parents on who their children can speak with in experience.
-
We anticipate that in the future, we will have to make additional changes to the platform to support different safety or legal requirements, and migrating everyone to TextChatService, helps us ensure your experiences always follow these requirements and save you time for future updates.
Clarifying our policy on moderating non-compliant experiences: We will prioritize auto-migrating first, disabling chat second, and, only as a last resort, restricting access to experiences.
-
In addition to this post, we plan to reach out via multiple channels to affected creators to ensure that everyone is aware of this change.
-
We will attempt to automatically migrate creators to TextChatService as much as possible and provide more details in a little post.
-
Auto-migration may break custom functionality so we recommend migrating on your own if possible.
-
If we cannot auto-migrate an experience, we will attempt to disable the chat functionality.
-
As a last resort, in the case of custom chat implementations that do not use either legacy chat system or TextChatService, we may need to restrict access to your experience to only you and notify you that you will need to manually remove your chat integration and integrate TextChatService to restore your experience.
We anticipate that this situation will be very rare but we wanted to give you a heads up that this is a potential outcome if you don’t take any action. -
We’ve heard your feedback about inactive developers, and we will do our best to try to ensure their experiences are automatically onboarded to the TextChatService
-
Note: Private or archived experiences are not subject to moderation under this policy and there is no requirement for you to update them
-
We do not plan to enforce any moderation action on creators unless we see evidence of creators intentionally trying to bypass our chat systems.
-
We’ve updated the DevForum post copy to clarify this point.
TextChatService allows for custom UI:
- Clarifying that you need to use the TextChatService APIs but are welcome to design your custom UI and not use the default CoreUI for TextChatService.
- To disable the default TextChatService UI, set ChatWindowConfiguration.Enabled and ChatInputBarConfiguration.Enabled to false
- Additionally, some of the most requested features (ChannelTabs and UIGradients) will be launched next week.
Clarifying what is or isn’t a chat:
-
We’ve heard your feedback on Admin messages and those will not be considered chat. We’ve updated the post accordingly.
- We will update our guidelines to differentiate one-time broadcasts like these from equal back-and-forth chat.
- We will be clarifying in great detail what is and is not considered chat on our creator hub documentation at a later date.
-
We’ve added a section further explaining CanUserChatAsync and CanUserDirectChatAsync
More resources coming:
- We are working on more documentation and tutorials to help answer your questions about migration and more use cases using TextChatService. We apologize for not having those available yet but are working on those now and your feedback helps us figure out what to prioritize.
49 Likes
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?
3 Likes
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.
10 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
5 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??? 
4 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.
2 Likes
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.
4 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