I love this new feature! One thing I’d love to see would be the ability to publish a place to another place and then shutdown the servers of said place as well as the ability to update packages in a place.
Our update workflow relies on separate testing places which are essentially copies of their live counterparts and it is such a pain to open 5 different places, update all the packages in those places, publish them and then publish them again to the live counterparts.
Thanks for this!
Our service can now no longer have to manage painful user API keys and can just directly interact with Roblox’s API for some of my features.
Unfortunately, some of the features that we plan to provide need to be permanent so the DataStore API or internal requests to our API/database might be a better fit for the majority of our planned features.
Still, kudos!
It isn’t as insecure as you might think, the endpoint would still have to be authenticated against. Websockets work by making an initial http request to the endpoint, the server then upgrades the request into a websocket at which point a two way connection will be initialized. All this traffic will then be sent back and forth over a secure channel without much way to intercept it.
So it’s not possible for random people to listen into your MessagingService for your game (unless your API key is exposed)
This is the point you can now receive messages from external servers in the same way you would do with a normal MessagingService system among roblox servers
You need to read more carefully. He’s asking if external servers can receive a subscribing api point in the same way games can.
I should mention that my comment on websockets is Roblox’s stance, not my own: Web Sockets for servers - #5 by Silent137
This is Roblox’s stance on web-sockets for Roblox game servers, they likely have a different stance for allowing them through open cloud.
In both cases (game servers and open cloud), it would be originating from Roblox’s servers. The security risk in both are nearly if not completely identical. I don’t see how their stance would change.
Would be nice though.
Everything is TCP, HTTP underwater are TCP connections. The security risk for HTTP and TCP both are identical. Websockets over TLS still receive the same encryption that you’d get with HTTP requests so the security risks are all but mitigated.
However despite that I actually don’t think Websockets are useful for this, we already have an API to send in requests to the MessagingService, so having a Websocket (which is 2-way) is partially not usable.
A better alternative for listening to incoming requests could be a notification endpoint (something like webhooks), however instead of configuring them from inside the website you instead would create a notification endpoint by making a HTTP request to the API, providing the URL.
Roblox would then send a HTTP request to the provided URL to verify that the URL would be able to accept incoming requests, and Roblox would then proceed to send event of the requested topics the provided URL.
You could also have it so that the notification URL requires a daily refresh HTTP call, if not sent the notification URL will simply vanish from Roblox their side and not be called anymore, requiring a new one to be made.
A reason for this could be so that Roblox wouldn’t have to unnecessarily send notifications to provided URL if the service stops working, saving resources on Roblox their end.
Similar to how the Microsoft Graph Change Notifications API works.
Why don’t you just say that you’re the developer behind this… two new accounts its very obvious.
THANK YOU so much! Now i can do a livetime global message through a discord bot.
Is there a tutorial for discord bots to use this?
If there is a tutorial on how to use this with discord bot, can you please ping?
The only thing you need really is the API Reference (which they give in the announcement)
yeah but im kinda new to discord.js and really dont know my way around. I already have the bot setup, and some codes running, if anyone can help, that’ll be great.
The api key system is broken.
I kept regening the key and changing my code for the key, it always returns invalid api key.
Websockets are secure by design, they’re web sockets and have the same security as a typical HTTPs request. The wss protocol is the https equivalent for WebSockets, ws being the http equivalent. A WebSocket connection is initialized through a typicalHTTPs request where the server does something called a “protocol upgrade” which basically means that the server and client are agreeing to “upgrade” to the WebSocket protocol (because, ofc, they’re not the same thing as HTTPs).
There is no difference in security between the two, iirc they use the same encryption schemes, and they both are very similar, after all, they work in browsers and are designed to closely mesh with HTTPs.
In fact, though I wouldn’t really necessarily agree with this, you could likely make an argument that WebSockets are technically actually more secure since you’re not establishing new connections all the time, which means doing more handshakes, and that’s technically more possibilities for MITM attacks. But, that’s pretty much the whole reason a “secure” version of the http (and ws) protocol exists in the first place (to stop MITM attacks).
It’s more likely that the reason that WebSockets are not being utilized here is simply a technical limitation on Roblox’s end. A lot of older web software doesn’t support WebSockets, because, well, WebSockets are relatively newer. If I had to guess, it would take some special engineering to introduce WebSockets onto the platform.
However, I do sort of wish that MessagingService relied on WebSockets to begin with because it’s a pretty battle tested technology and I would imagine it would make a lot of aspects of MessagingService more streamlined to implement, such as being able to subscribe with the API here too.
Roblox is probably considering or has considered WebSockets, and given that the actual API docs mention subscribing to messages as if it’s a feature of the API, it’s probably something they want to do:
The Messaging Service API is the Open Cloud equivalent to the Lua
MessagingService, which supports live servers to send and subscribe to customized message channels called topics.
On a completely unrelated note, I’ve recently seen some arguments being made for adding some sort of WebAssembly support (partially or in full) for similar reasons. (One of the prerequisites to being able to do WebAssembly stuff in Roblox performantly would be some sort of limited jumping through scopes for example, which is something still being discussed on the luau repository)
WebAssembly is inherently secure, and extremely performant (after all, it’s meant to run in your browser, and browsers are probably one of the most security-focused pieces of technology you use, and are using right now to read this 
). It would make it possible to somewhat utilize endless normally native languages on Roblox the same way they are on the web, and would introduce a huge number of possibilities.
Some cool consequences of this:
Having WebAssembly on Roblox (even transpiled or interpreted via luau such as with the Wasynth project, but especially with native or near native speeds) might excel Roblox forward quite a lot in its power as a game engine.
Really, I strongly believe browser tech is something Roblox can utilize and benefit from immensely in a lot of cases, and at the very least, it’s a great place for them to take inspiration from in some regard considering many applications are now becoming browser based (For example, Discord is based on Chromium, it uses a “headless” Chromium called Electron)
Open Cloud is quite confusing for me. Does it simply let you use Roblox endpoints in other languages such as Javascript or Python?
Even from other posts here, I still don’t understand how to send a JSON payload. It doesn’t seem to work as expected.
On Roblox, it would look like this, as expected:
MessagingService:PublishAsync("MyTopic", {hello = 32})
MessagingService:SubscribeAsync("MyTopic", function(msg)
print("MESSAGE", HttpService:JSONEncode(msg)
end)
--> MESSAGE {"Sent": <timestamp>, "Data": {"hello": 32}}
But when I do the same thing from the Open Cloud API, it doesn’t work. If I leave the message payload as a JSON object, I get a 400 error. If I encode it as a string, it works, but the Lua code subscribing to the message does not decode it to a Lua table as expected.
For instance, I am sending the following payload via Postman:
{
"message": "{\"hello\":32}"
}
And the response I get in my Lua topic subscription is:
--> MESSAGE {"Sent": <timestamp>, "Data": "{\"hello\": 32}"}
You see how the Data payload is wrapped in a string? It didn’t get parsed as expected. Maybe I’m doing something wrong? But I suspect this is a bug.
No.
What makes Open Cloud so amazing is that it will eventually allow you to directly interact with the Roblox API without needing a ROBLOSECURITY Cookie. It’ll all be done through API Keys.
Open Cloud also supports an API key-based access to help automate your internal workflows, and the ultimate goal is to improve your efficiency creating content on Roblox through an application ecosystem of tools and services.
Their goal is to eventually support all Web APIS with Open Cloud