We are currently looking at Redis for a model of storing data on the server side. However you have a good point. An easy way to identify what data should be easily stored is a good idea. We will look into that. As an initial thought maybe we can use C2 Dictionary as a model of storage.
We are not using socket.io, we are currently working with raw websocket. Go language does not support socket.io. :( socket.io however is mostly a wrapper of transports to have all the transports look like websocket. It's a nifty piece of tech :)
We will be making tutorials once we have the first development release to share.
newt I understand your pain. I have lost posts too :D
Well BubbleBath.exe is a raw message handler that forwards messages to clients or nodes and then back and forth. At that level there is no need for authentication. However and often any game with persistent player data requires protection and access by security. So I am actually keen on considering how this can be provided to the C2 developer.
Now this is just an initial thought that been floating around. BubbleBath won't handle authentication. Often Facebook, google login, twitter and all these other sites tend to use proxy logins. A request is made by the client side to login. This is linked directly to to the authentication site and not through visiting site. This validates a cookie for the site to access limited data from FB/Google/Twitter...
Now I have thought about this already because I wanted to possibly integrate Clay.io. We shouldn't get the user password, instead we need a proxy pass that the client sends to bubblebath to use.
The other alternative is that we can look into providing a local user account system. In this model we would build this in C2 so that developers could customize an authentication system.