Upon two users drawing at once, their lines will just connect

[off-by-some]

i need to fix some socket stuff too

[bla-opfuckmorsy]

Yeah, I think that is a result of all users having the same id currently. Also I probably put endPath instead of closePath somewhere

[ghost]

dem websockets.

On Wed, Jan 1, 2014 at 7:29 AM, bla-opfuckmorsy notifications@github.comwrote:

Yeah, I think that is a result of all users having the same id currently. Also I probably put endPath instead of closePath somewhere

— Reply to this email directly or view it on GitHubhttps://github.com/Pholey/Whiteboard/issues/4#issuecomment-31419815 .

[off-by-some]

You may spin up the backend and POST localhost:8001/whiteboard/username with some json

 {"username": "your username here"}

This will return the users ID

[bla-opfuckmorsy]

I've been thinking about that, I think you might have been right to have it so that users cannot know their own ID. Basically, the way it currently works, the user's own ID is part of the messages he sends, but that user also knows the IDs of other users, so if someone wanted to be malicious, they could change their ID to someone else's, and their messages would appear to be coming from someone else, and that would fuck up the whole thing for everyone.

I think, websockets.py should have like a map of ID's to sockets (if it doesn't already, I dread to look), and then when it receives a message from a socket, it looks up the ID, decodes the messages JSON, and reencodes it like this (example is for the action-data event) {id:user_id_here, message:{action:"action-data", data:[2, 3]}}

So, in python that would be (guesswork and magic here):

import json

#user_id is a variable holding the user's id, message is the string with the JSON message I sent to the socket
return_message = json.dumps({"id":user_id, "message":json.loads(message)})

I've got tons of shit to do today, so I probably won't be on until pretty late if I am on, but plan on making that change to websockets.py

[off-by-some]

I think, websockets.py should have like a map of ID's to sockets (if it doesn't already, I dread to look), and then when it receives a message from a socket, it looks up the ID, decodes the messages JSON, and reencodes it like this (example is for the action-data event) {id:user_id_here, message:{action:"action-data", data:[2, 3]}}

Yes and no. Managing multiple websockets would be awful, not to mention, unscalable.. However, i see why you would think that when it comes to rooms, and managing. i honestly think something like WebRTC would be the best approach, and not even have a third party socket to connect them. This could also lead to cool things like voice and video chat (if we so chose). Currently, a tad more research needs to be done in order to completely figure out rooms, etc. But i think a simple websocket for now should suffice.

[bla-opfuckmorsy]

WebRTC would make pushing data around less of a nightmare, but I think it would also make it even easier for people to spoof messages. We'd have to think of a decentralized way to make sure users can't do that if we go with WebRTC. I remember bittorrent's DHT protocol having some sort of mechanism to prevent such a thing, so maybe I'll read up on that later on and see if we could implement something like it.

[thepigeonoftime]

I don't know how important it is for you to use armet, but if not very, why not use node.js + socket.io for handling the server side instead? We could drop the database, replace python & mysql requirements with a nodejs install + (and socket.io via package manager), the whole project would be javascript and most of all, would probably solve a lot of the above issues.

Nodejs is completely asynchronous on IO & uses an event loop in a single thread for incoming requests (non-blocking), making it very fast + it can handle a ton of concurrent connections (about 1k-2k on an average server) and was basically built for realtime webapps.

Socket.io is a very lightweight API for Websockets / node.js, is browser independent (has a transport fallback on Flash-WebSocket, AJAX- long-polling / multipt. streaming, iframe & json polling) and it's API is spefically set up to easily handle requests between users and rooms: (https://github.com/LearnBoost/socket.io/wiki/Rooms)

There are a few collaborative drawing applications that use both node and socket, here's a very basic one to get the idea: http://tutorialzine.com/2012/08/nodejs-drawing-game/

As for spoofing, I would just include the users ip adress when generating / passing the userid to the server, or tie some pseudo-unique identifiers from browser data in there.

[off-by-some]

@kekebo, After discussion and thought, Its agreed that armet is a bit too much for what Whiteboard is trying to achieve. Since most data is non-persistent, Armet is simply an unnecessary complication to Whiteboard as a whole. I will be removing armet, @bla-opfuckmorsy, this means you can generate UUID's on the fly by doing something like:

function generateUUID(){
    var d = new Date().getTime();
    var uuid = 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
        var r = (d + Math.random()*16)%16 | 0;
        d = Math.floor(d/16);
        return (c=='x' ? r : (r&0x7|0x8)).toString(16);
    });
    return uuid;
}

Though im sure there are libraries out there that will do this for you, @kekebo can i leave it to you to implement Socket.IO? i have a feeling you'd be much more qualified to do so than myself.

[thepigeonoftime]

@Pholey, you may leave it to me, although I haven't done much than playing around with it myself, I just really liked the concept, I'm gonna try to get same base functionality working today, but I don't wanna just impose my stuff on you guys after you've been working on the server side so much more than me.

[bla-opfuckmorsy]

I'm going to close this, since we it technically isn't a bug anymore (we have no backend, hence no multi-user and no problems caused by that). Also the title isn't descriptive of the discussion at this point.

I will open another issue where we can discuss backend stuff.