As a Roblox developer, it is currently too hard to allow users (in-experience) to send direct messages to users who are either currently offline or in a different server. The intended API to check if two users can chat has a somewhat undocumented* limitation in-where it requires all users to be connected to the current server. This limitation is also present in the CanUsersChatAsync API, so it could be related to that restriction.
TextChannels in-themselves do not allow for cross-server communication, which I discuss in this topic. Although, even assuming that is fixed before April (in which I REALLY hope it is), we still have a problem for private-messaging features. Simply put, even if TextChannels receive support for offline users, we cannot comply with the CanUsersDirectChatAsync policy for any cross-server private messaging feature since the aforementioned API for checking if two users can chat doesn’t support users not currently in the same server.
This means players leaving messages for their friends alike an “inbox system” can not be supported given the current limitations. The CanUsersDirectChatAsync part of the policy also goes into effect much sooner than April (which is when the rest of the policy goes into effect), going into effect at end-of-January; so this is even more time-sensitive than the other policy-change.
If Roblox is able to address this issue, it would improve my development experience because I would be better equipped to create more unique communication features in my experience.
*The limitation is technically documented, albeit it is documented incorrectly. An error is produced if the request contains an offline user rather than the user simply being ignored as documented. It is possible that this behaviour is different if at least one user is in the server (as I only checked with one user, who was offline). However, the documentation still implies that a user is always ignored if they are not in the current server, which simply isn’t the case. On top of this, this limitation is documented in the parameters of the API rather than the description; I didn’t even notice it until I was finalising this post.