Soon we will be deprecating the use of Chat:FilterStringAsync and Chat:FilterForBroadcast from LocalScripts.
Calling these methods from server-side Scripts is still valid and will not be deprecated. Personally, I would recommend using the new TextService:FilterStringAsync API for new work.
We don’t have a set date for disabling support for text filtering from LocalScripts at this time. We’ll be evaluating how often this is actively used and working with developers to update their games before we have discussions about setting a date for disabling the feature.
Why are we deprecating text filtering from LocalScripts?
Even though supporting these text filtering methods from LocalScripts did make scripting easier in some cases because you could call it anywhere in your scripts without worry, there is a number of issues with it that led us to the decision to deprecate this usage.
Hidden redundant round trips: Filtering from client works by sending the text to the game server and waiting for the server to filter the text and send it back to the client. In most cases I’ve seen in scripts the client immediately sends the filtered text right back to the server. In these cases it would be more efficient to send the original unfiltered text to the server once, then filter it on the server and process it without any extra round trips. This redundancy is hidden from the developer.
It supports bad usage patterns that we don’t want to support
Trusting the client and not filtering on server: This supports the use case of filtering on client, then sending “filtered” text to server and assuming that the client already filtered it. If the server doesn’t redundantly “re” filter the text it is trusting the client to have filtered the text, which is potentially exploitable.
Filtering on client receive: This supports the use case of the server broadcasting the unfiltered text to clients and then filtering the text on each receiving client. To protect user’s privacy you should never transmit unfiltered text to other clients, even if it cannot be accessed without exploits. There’s also the hidden redundant round trip for each receiver.
Difficult to maintain: The internal C++ plumbing to support text filtering requests from local scripts is complex. It’s nontrivial to test and maintain as we make changes to text filtering and chat privacy, as well as requiring many bug fixes:
Currently always picks the most strictly filtered version of the text in all cases. There’s not an easy way to fix this.
Will this affect my game?
Only if you are calling FilterStringAsync from a LocalScript or a module script function invoked by a LocalScript on the client.
I was using this. What do I do now?
The quick-fix replacement is wrapping FilterStringAsync up in a Lua remote function. This is very easy to do, and also has the benefit of not hiding the extra round trip to the server from you.
Thanks for your understanding! Let us know if you have any questions.
I noticed that when my original chat system ran with it. I changed it over to server after due to the amount of lag it was able to create. Works much faster with TextService, so I recommend using that for speed and usage.
Do I need to filter text if the person who input it is going to be the only person to ever see it? It would probably be bad if a parent/guardian saw something their child had typed in which was bad but there is no filter function for just the one player and I am very resistant to have to go via a server to use for broadcast as I already feel I have too many remotevents…
If the text is only visible to the original player only for that play session: no, you do not need to filter it.
If it persists beyond that play session you do need to filter it. In that case our general advice is to store the original unfiltered text and filter it again the next time you load it; that way our latest filter rules are always used.
It will be showing to the same user in future sessions. I assume I need to use the “for broadcast” option, only this is often more restrictive than the to player one, unless there is a specific one for re-showing it to the same user?
Filtering for that user, to that same user will get you the least restrictive filtering that is appropriate. Using the same user for both fromUserId and toUserId is both perfectly acceptable and the best way to handle this.
“for broadcast” will always get you the most restrictive filtering, which is overkill when only being viewed by the same user.
I know I’m extremely late but will there be support for filtering in plugins? Even when running a plugin on a server script, it shows the warning that the localscripts using the api will be depreciated.
The reason I’m using text filtering is for custom chat plugin in team create.
Filtering is only currently only supported from ROBLOX game servers running
in our cloud so we probably won’t support this anytime soon. Studio doesn’t
do any filtering at all and non-LocalScript Scripts in plugins won’t run as
far as I’m aware.