Currently, Snap! does not have cloud variables. This is because it is not very important, and it uses too much server space. However, I have a solution. Snap! could use wss? to allow a project to transmit messages, but not variables. This way, a Snap! project could use some part of cloud variables, but the Snap! server would not have to store any of the data: it would just be a proxy from one client to all others, and the server would not need to be modified at all.
It seems that these would not be nearly as powerful as cloud variables. Cloud variables can be used to transmit messages, but the same idea that says that messages will not take server space also means that they cannot be used to emulate variables. Cloud variables can store data even when there are no users at that project, where messages will be completely dormant. However, with the addition of another service, google apps script for example, that stores data but uses only https?, cloud variables can be made. The reason this is so much of an advantage, is that very few existing services can do full cloud variables, or even messages, while a https? file system is a very common service. The only example I can find of something that does messages is google firebase, while storage is available on firebase, but also on google docs (through apps script) and on whatever server the snap chatroom is on. The chatroom works, but its cloud variables take network bandwidth every time the project reads or writes to it, where proper ones will use the bandwidth of all clients when data is changed.
My opinion on this: I do think that message passing would be a far better solution than cloud variables, and the one that I wish Scratch itself implemented.
For Snap! specifically, we should make sure that cloud messages can carry some amount of data with them (like if broadcasts had inputs), but not so much that it can overload the server.
Isn't that what the message name is? The point of having messages instead of variables is to retain server space, but CPU and network are both taken by messages. However, it would require a lot of message passing to overload anything, so it should be fine. The reason that messages are better than variables, even when I am using them as variables, is that I have to make sure not to go over 15GB, or to buy some storage on google drive. On scratch, they limited cloud variables to 1280 digits (128 digits per variable times 10 variables per progect) of decimal (strings of [0-9]) per project. I don't want that for Snap!
Isn't that what the message name is?
The message name is just a string. A multiplayer game might want to pass more complex data, such as numbers and lists. Sure, you can encode them into strings and pass those, but that shouldn't be required.
The point of having messages instead of variables is to retain server space, but CPU and network are both taken by messages. However, it would require a lot of message passing to overload anything, so it should be fine.
Yes, that's my point. Cloud messages would mostly take up RAM, a bit of CPU power and network bandwidth, but only during transmission. Cloud variables would take up all of those, but also require long-term server storage. This long-term storage would require more stringent limitations, like those that Scratch has, even while the cloud variables are only being used for passing messages.
Of course, there should still be some limitation, but if the server doesn't have to store cloud data for every single project, it doesn't have to be nearly as stringent as Scratch's limitation.
Even if whatever system gets added to Snap! is too limited for your taste, you can host your own server and implement your own using the "JS function" block.
The reason that messages are better than variables, even when I am using them as variables, is that I have to make sure not to go over 15GB, or to buy some storage on google drive.
When I say "messages", I'm talking about the general concept of two systems sending information to each other, not Google Mail messages. Think broadcasts, but it can be between two sprites, objects or computers.
On scratch, they limited cloud variables to 1280 digits (128 digits per variable times 10 variables per progect) of decimal (strings of [0-9]) per project. I don't want that for Snap !
I agree, Scratch's cloud variables are very limited.
I believe that the reason for the strict limitation in Scratch is not primarily about server space but about preventing chat apps, to protect against child molesters.
oh and hackers too
There is the problem that people could send messages without an account on scratch. However, some more server-side security could prevent users from using cloud variables without a password. On scratch, even new scratchers can change cloud variables. Something like new scratcher, but where it actually prevents use of messages and has security on the server would be very helpful. (Yes, the scratch check for new scratchers using cloud is on the client side. So is the check if a project is shared.) In either case however, it is my job to moderate a project that I built, right? I don't see why scratch had to remove chat projects when they are not the ones tasked with moderation in the first place.
Nope. If you get molested, we get sued. Sad but true.
Oh. This makes things harder. This topic was meant to be about saving server space, but I can see that that isn't the main problem. You have to decide on a policy however. Eventually, google apps script will support websockets, and clever use of firebase could create cloud variables. Banning this type of thing is possible (not in snap, but just by making it not permitted) and so are cloud messages, (or variables) but leaving it as possible iff you run your own server or use firebase (with much more limited free plan) does not seem fair.
On some other topic, you said that a way to make cloud variables would be to use google sheets. However, their API could change. Google apps script would essentially be the same. It acts like an https? server that has access to your google drive. Combining that (or any other server like the German snap!chat server) with messages (from Snap! itself or elsewhere) would be full cloud variables, which is what I actually want.
Why do I keep reading snap!chat as an email address?
Because you're old enough to remember UUCP?
My personal plan is to let someone else on the team worry about this; I have too many other worries already! :~/
what I was going to say... because I'm old
:~P stupid forum software isn't letting me post this...My current age is less than 18.
I give up, then. (About the ! not about your age.)
:~P<p>
:~P
You could use a whitelist? Like scratch permited at some point
What would the whitelist do? Scratch used to (and still should) allow chats with whitelists. Snap definitely shouldn't allow completely free chats, but the question is what should it allow? I think that scratch would be better without cloud variables because they, in their current form, are good enough only for communication between users and a custom server. This is another example of “scratch is only good for os developers”, but it also requires the person to use their own server, meaning that there is a substantial disadvantage to kids, like myself, who cannot run a server. Snap must make a decision, and it must be either completely banning communication from one client to another, or having a supported, gratis system for that. This could be simply instructions for doing what I did with firebase, or it could be a system on the same server as snap itself, but it must be standardized.
You can run a simple server. Go on repl.it or Glitch.com and make a simple server like this (that you can refine to process HTTP requests):
const http = require('http')
http.createServer((req,res)=>{
if (req.method == 'POST') {
//process POST data
}
res.write('Hello World!')
res.end()
}).listen(8080)
But built in servers for those who don't know how to run one would be helpful.
I have the feeling that I'm seeing a lot of emotion that I don't entirely understand. ("Don't entirely understand" is not a euphemism for "disagree with"!) You started talking about whitelists, another thing I don't understand; does it mean we should get in the business deciding which of our users can be trusted to run a chat room? And then you present a stark choice between... banning communication (how do we enforce that?) and (I guess) implementing cloud variables?
Sorry; I'm lost.