In another thread…

Lightnin wrote:

…maybe some of you have ideas for creative alternative solutions to the [chat board] problem that are practical, and don't involve gagillions of dollars and massive mod armies? Whatever we end up doing, it has to work for 26k+ active contributors per week.

Here is my response:

I'm finding ☁cloud variables incredibly hard to work with. I know, that seems strange given the fact that they are so simple. But, hear me out…

You've probably read my other threads describing the issues I've had trying to implement a Leader Board (Link to post), (Link to post), (Link to post), (Link to post), etc. And, you are probably aware that the Scratch Team wants to prevent the creation of “Chat Board” projects (Link to post).

So, I thought I'd offer up my ideas on how to “fix” the problem. (I offer my ideas for free and I'm sure they're worth every penny!)

I think that cloud variables (as they exist today) are NOT the answer we are looking for. They're unreliable, they perform badly, and they're hard to use. Instead, I think we need to attack the problem from a different angle. I would like to look at the REASONS we want to share data between different runs of the project and come up with better solutionS. The reasons I want persistent data is three fold: I want to have a leader board in my games, I want to save game states between runs, and I want to make multi-player games. Let's take a look at each of these problems and my suggestions for each solution.


Leader Boards

I tried to implement a leader board with cloud variables (the results of which you can find linked above). This was my first foray into cloud variables and I found them to have MANY problems. Instead of using cloud variables, I think we should have a specific mechanism (blocks) for handling leader boards.

It would start with a block to submit a high score: [submit score (CurrentScore)]. This block would submit a single score to the score database. Included with that score would automatically be the project number and logged in user name. If the score is higher than the current stored score for that user, it would be updated in the database. By using the logged in person's username, this would prevent impersonation and also keep profanity off of leader boards. The project itself wouldn't need to know the user's name–the system itself would submit this info and keep it hidden from the project. If the user is not logged in, this block would simply do nothing.

Project where smaller scores are better would simply need to [submit score ((0)-(CurrentScore))]. And, projects that scored off of a timer would submit the number of seconds elapsed.

Next, we would need a way to display the list of the top 10 leading scores. To be more secure, we could have a Leader Board reporter that could not be read from or modified outside the high score blocks. This would prevent the program from discovering the user's name and prevent hacks where a phony Leader Board is used as a conduit for making a chat board. We could design a nice looking reporter that looks better than a standard list reporter. Something like this…

               

That would be a display right inside of the project that could be hidden or shown. OR, we could put it here, completely outside of the project:

               

This would offer the most security as far as a project itself is concerned.

Finally, there would need to be a way to reset the high score table: [reset scores]. This would delete all entries from the high score table that match this project id number. For security purposes, this block would only work for the project's developer. For other logged in users (or non-logged in users) this block would do nothing.


Saving Game States

Another important function of persistent data is the ability to save your place when playing a long game. For example, my adventure game might take a person as long as a week (or more) to solve all of the puzzles and win the game. It would be nice if the game had the ability to save your place and restore it when you ran the game the next time you visited. I think the best idea here is to use Laternenpfahl's idea of “user specific variables”. I imagine these to be like cloud variables that are unique for each person who visits a project. So, instead of sharing their contents between everyone who visits a project, the contents of these variables would be stored and restored only to the user who submitted them–like Personal Cloud Variables (or lists). The user's name need not be revealed to the project, only the data stored in the personal cloud variables. Unlike the current implementation of cloud variables, only your own personal data would be available to you and not available to everyone. Also, these variables would update when accessed. This would reduce the bandwidth requirements of saving and loading persistent data.


Multi-Player Games

Using cloud variables it is impossible to write a multi-player live action game. With the speed of cloud variables the way they are, only turn based multi-player games are a possibility (like checkers or chess, etc.). I think users would like to make multi-player, live action games. In order to do this, we need a MUCH faster solution. I propose that instead of storing multi-player cloud data on the server, we directly connect two players and transfer the data between them without storing it on the server. This would be similar to the way “mesh” works on the 1.4 development environment.

We would need a way to connect users. I imagine a player would add (or remove) themselves to a list of available players. Then, be able to challenge another player on that list to a game. Finally, they would be able to accept or decline that challenge. Once a challenge has been accepted, both players would be removed from the available players list and there would be a mechanism in place to transfer data between the players for the remainder of the game.

[add me to available players]
[remove me from available players]

Next, imagine a “cloud list” of available players.

[challenge (userName) to a game]

A couple of hat blocks:

[When challenge accepted] and [When challenge declined]

Each player would have a command stack (list) to read “moves” from in order to process them. Item 1 of the list would always be the current move. Users would delete that move off the stack when processed and new commands would be added to the bottom of the list. This list would be updated quickly as it does not need to go to the Scratch servers. Commands that contained profanity would not be sent over the connection.

Finally, there would be a way to terminate the connection:

[challenge terminated]

and the corresponding hat block:

[When challenge terminated]

In this script the winner of the game would be determined and the user would be given the option of returning to the list of available players.

Now, this idea only implements 2-player games instead of multi-player… but, we've not had any type of muti-player interaction before. So, I think 2-player would be a HUGE start in that direction.


Conclusion

As you can see, each of my solutions would be better performing, more private, and easier to use than cloud variables and have the added benefit of preventing “Chat Board” type projects. This also means that we don't need userid or username blocks!

Scratch Team, I urge you to consider my suggestions. I'm not saying that you would need to implement ALL of my suggestions all at once. In fact, I'm not saying that you need to implement all of them. I'm just asking you to review the ideas and implement the ones that make sense. With your goal of preventing chat projects, I'm trying to present alternatives to cloud variables. The fact is, if we have cloud variables we're going to have a rash of chat projects. I just don't want you to kill cloud variables and leave us with nothing. Thanks for reading this far.

Scratchers, I would like to hear your opinions of my suggestions. Let's get the discussion rolling. I think we all want the same thing: The Best Development Environment Ever!


EDIT: More thoughts here: http://mv.ezproxy.com.ezproxyberklee.flo.org/forums/topic/882/?page=2#post-6055

I've just blown your mind, haven't I?

(In this post I refer to ‘security’. I use this word as a measure of how to prevent a user from creating a chat type project or to prevent the project from discovering a person's username.)

You can use
instead of bolding the first character

More on topic: While I appreciate the need for a solution to the persistence/multiuser interaction problem, I don't think this is it. It allows some interactivity and persistence, but it does not have very wide walls, i.e., it only lets you do a very limited subset of the kinds of things Scratchers will want to do. It adds more blocks than all the other changes to Scratch 2.0 combined.

Thanks for sharing these ideas - there's plenty to consider up there! Given the various security concerns, it may be worth stepping back to strategize based on what a lot of Scratchers are interested in. For example, we could consider taking small steps into the world of cloud variables with something like the “Leader boards” idea you proposed above.

Just as a side note - many of the performance issues affecting use of cloud variables now are likely to get fixed / optimized in the not too distant future. So we shouldn't confuse these with the design issues - they are problems of a different sort.

nXIII
While I appreciate the need for a solution to the persistence/multiuser interaction problem, I don't think this is it.

Thank you for your feedback.

nXIII
It allows some interactivity and persistence, but it does not have very wide walls, i.e., it only lets you do a very limited subset of the kinds of things Scratchers will want to do. It adds more blocks than all the other changes to Scratch 2.0 combined.

I would be interested in hearing your ideas that would allow interactivity and persistence while preventing “Chat Board” types of projects.

This is a more difficult problem than most people realize. I did not simply rattle off this post in 5 minutes. I've been carefully thinking about this for several weeks. I know it's not perfect, but it is the best solution that I have come up with keeping in mind the Scratch Team's goals.

Lightnin
Thanks for sharing these ideas - there's plenty to consider up there! Given the various security concerns, it may be worth stepping back to strategize based on what a lot of Scratchers are interested in. For example, we could consider taking small steps into the world of cloud variables with something like the “Leader boards” idea you proposed above.

You're welcome. I'm glad I've given you something to think about.

Lightnin
Just as a side note - many of the performance issues affecting use of cloud variables now are likely to get fixed / optimized in the not too distant future. So we shouldn't confuse these with the design issues - they are problems of a different sort.

That's good to know.

BoltBait
I would be interested in hearing your ideas that would allow interactivity and persistence while preventing “Chat Board” types of projects.

This is a more difficult problem than most people realize. I did not simply rattle off this post in 5 minutes. I've been carefully thinking about this for several weeks. I know it's not perfect, but it is the best solution that I have come up with keeping in mind the Scratch Team's goals.

Firstly, your third solution (multiplayer games) can easily be abused to make a (private) chat board, and with a little more work a public one can be made using leaderboards.

I don't think there's going to be a solution that allows many kinds of multiuser/persistent projects while making chat boards impossible. Chat rooms are one of the simplest and easiest things to do with networking, and can be accomplished in many different ways. I think it has to be a policy.

nXIII
Firstly, your third solution (multiplayer games) can easily be abused to make a (private) chat board

True. But, there are some precautions in the solution I proposed.

nXIII
a real (chatboard) can be made using the first solution, leaderboards.

I disagree. I think the limits I've put on the system, that would be pretty much impossible.

nXIII
I don't think there's going to be a solution that allows many kinds of multiuser/persistent projects while making chat boards impossible. I think it has to be a policy.

I think a policy is important. But, there is much that can be done using the technology at hand.

BTW, I'm still waiting for your proposals.

Wow! Love all these ideas! I think these would add a lot to Scratch. Maybe there could be a new, Multiplayer section of blocks in Scratch if these were implemented.

BoltBait

nXIII
a real (chatboard) can be made using the first solution, leaderboards.

I disagree. I think the limits I've put on the system, that would be pretty much impossible.

The leaderboard is a 10-item persistent, shared stack that keeps track of senders for you. Since there's no limit on score length, you can send giant strings as numbers (with a counter prepended to ensure it floats to the top).

Also, you can fairly trivially build a (slightly unreliable) username block using leaderboards.

BTW, I'm still waiting for your proposals.

My proposal is that we stick with cloud variables and work on making them more reliable and performant.

I say we wait until Scratch 2.1.

mythbusteranimator
I say we wait until Scratch 2.1.

let's not start thinking about a 2.1 until 2.0 is fully out

Large numbers are VERY unreliable. I know, I've tried working with them.

EDIT: How about a Leader Board reporter that can not be read from? That would be secure. We could design a nice looking one.

nXIII

BTW, I'm still waiting for your proposals.

My proposal is that we stick with cloud variables and work on making them more reliable and performant.

And, how would that be more secure than what I proposed?

I think I've established pretty well that cloud variables just aren't working.

I think you're hating on my ideas simply because you didn't present them. Can we all just work together here?

BoltBait
Large numbers are VERY unreliable. I know, I've tried working with them.

Yes, but depending on how the leaderboard was implemented you could send join()ed numbers and get practically infinite length.

nXIII
My proposal is that we stick with cloud variables and work on making them more reliable and performant.

And, how would that be more secure than what I proposed?

Security has nothing to do with these proposals. I can edit anyone's cloud data with an external program. That's insecure, but it's not a flaw in the design of cloud data—it's a flaw in how it's implemented. There could just as easily be flaws like that in the implementation of your suggestions, and since there are more isolated functions, there's room for more security vulnerabilities in the implementation of each.

I think I've established pretty well that cloud variables just aren't working.

If you're referring to their speed:

Lightnin
Just as a side note - many of the performance issues affecting use of cloud variables now are likely to get fixed / optimized in the not too distant future. So we shouldn't confuse these with the design issues - they are problems of a different sort.

If you're referring to their design, I don't think there's anything wrong with it. I maintain that there are no solutions which are adequately flexible and chatroom-preventing, so I'd much prefer a system like cloud variables which lets me do almost anything I imagine (coupled with a policy banning chatrooms for the sake of moderation) to one of your systems, which only lets me do a very small subset of those things.

I think you're hating on my ideas simply because you didn't present them. Can we all just work together here?

I'm not hating on your ideas. I'm presenting my thoughts on why I think cloud variables are better, just like you're presenting your thoughts on why you think your suggestions are better. Please don't use ad hominem arguments.

BoltBait
Large numbers are VERY unreliable. I know, I've tried working with them.

EDIT: How about a Leader Board reporter that can not be read from? That would be secure. We could design a nice looking one.

nXIII

BTW, I'm still waiting for your proposals.

My proposal is that we stick with cloud variables and work on making them more reliable and performant.

And, how would that be more secure than what I proposed?

I think I've established pretty well that cloud variables just aren't working.

I think you're hating on my ideas simply because you didn't present them. Can we all just work together here?

Well, nothing will be “secure.” My I have the link to the post where you established that the variables aren't working?

My counterpoint to the first post is that cloud variables update well for me. It's just your internet connection. There's always lag.

Mokat

mythbusteranimator
I say we wait until Scratch 2.1.

let's not start thinking about a 2.1 until 2.0 is fully out

I've thought about 3.0!

Firedrake969
Well, nothing will be “secure.”

By ‘secure’ I mean ‘able to prevent chat projects.’

And, by that definition, cloud variables are COMPLETELY unsecure and the proposals I've given are MUCH more secure.

BTW, I've added a few graphics to my original post to illustrate what a Leader Board might look like.

I really like this idea! Except for the fact that it still doesn't display cloud data needed to display fully. There are ways to get around cloud data only displaying 8 characters, so there's no actual way to make it secure from chatroom projects. Maybe a global chatroom you can include in your project?

BoltBait

Firedrake969
Well, nothing will be “secure.”

By ‘secure’ I mean ‘able to prevent chat projects.’

And, by that definition, cloud variables are COMPLETELY unsecure and the proposals I've given are MUCH more secure.

BTW, I've added a few graphics to my original post to illustrate what a Leader Board might look like.

Much clearer.
I still have an idea of how you could modify a leaderboard to be a chat room.
And yes, by your definition of secure, nothing will be secure.

BTW, I've added a few graphics to my original post to illustrate what a Leader Board might look like.

Wow, I'm terrible at whatever game that is!

nXIII

BTW, I've added a few graphics to my original post to illustrate what a Leader Board might look like.

Wow, I'm terrible at whatever game that is!

I was just having a bit of fun at your expense.

What do you think about having a leader board that can't be read from? Wouldn't that solve the security problem?

I like them all.
but I would say to have the leader board to a tab not in the project.