I think working/not working is a different issue compared to whether a broker can be used as a "cloud" database
I was just defending the concept of a broker being able to be used as a cloud database. 
re
Your code seems to be more complex that it needs to be and so, TBH, I'd basically start again.
Keep it simple to just matching up your cloud variable names to a sub-topic (do you know about sub topics?) of your main topic
And completely scrap the x/y stuff (I've no idea what that is about!)
the x and y things are how I find variables and allow people to have names for the variables they kinda help make the whole thing work
also I have no clue what sub topics are
So check out
Basically, instead of using your own separators such as space and _ etc use / to subdivide your topic name
i.e. if you call you database name cloud - then call the topic name username/cloud and then if someone creates a variable call speed - refer to that as username/cloud/speed and publish and subscribe to that to write/read its value
That's why I'm suggesting starting again and just let the user choose their own cloud variable names rather than imposing a fixed structure
Just have a few blocks - one to create a cloud var name and then a set block to publish its value to the broker and a read block that subscribes to the same topic to read it's value back again
thay do make their own names its just how i scan for the variable's position in the cloud database
Lets say you create a cloud var called speed
So I'm suggesting that you publish its value to username/cloud/speed
So there is a one-one matchup between what is stored on the broker with the cloud var name
No scanning is needed - you can directly publish/subscribe to it
you havent told me how to make sub topics yet
So a simple topic name could be cymplecy or cymplecy_speed or cymplecy_speed_x
But it's better (as you'll find out later on) to use / as the separator
So the above topic names would be better written as cymplecy/speed and cymplecy/speed/x
I call speed a sub-topic of cymplecy and x a sub-topic of speed (which is a sub-topic of cymplecy
oh ok
but i dont know if your getting this right
all the variables are stored in the database table and then the table gets sent to the others that are connected to the database
I'm just trying to give you enough info on MQTT to let you use it for storing cloud vars
If your wanting to store a table, rather than individual values, then one option is to convert the table to JSON and then publish that to the broker
There's always many ways to achieve a goal.
oh
the info is helpful and i think it will help this database work better
i do not think mqtt is the best way to do this. it is very easy for a malicious user to screw things up and keep it that way. all you have to do to mess up an online game made with mqtt is publish to a topic and stick a forever loop on it. i still think programming a real cloud backend with some security measures (such as only allowing cloud variables to be set in the project page) is the best way to do this. at least with an http cloud backend, you can implement security features you wouldn't be able to with mqtt.
also, i'm not saying these things because I hate the project. i think it's great that you, @codegang, are thinking of ways to impliment cloud storage. i'm saying this because of past experiences i've had with malicious programmers.
i know malicious users would always be a problem
but the reason i used mqtt
is because no user-made cloud variables ever seem to work
That's because they aren't maintained.
Here's a tutorial on how to make your own cloud server for Snap! using Python:
you should probley remove the word replet from the title if it no longer uses replet
i didnt say it doesnt use replit
i meant that replit is severely limiting things used in the tutorial and recommending setting up a local server.
oh