Actually, (after a lot of testing) the float based crap killed it. At first it works fine, but sooner or later it got out of sync anyway (with multiple devices).
I did all kinds of NASTY tricks to avoid the float based crap, I only executed steps with a delta of 1/60 (this alone already counters the frame rate thing you spoke of) and I attempted to kill the float difference by multiplying velocities/positions by 1000, making an integer of them, and divide it by a thousand again, but even if I only used small forces (or do even more really nasty tricks like checking how big the velocity is, and based on that do some multiplying/dividing), it gets out of sync after a certain amount of collision happens.
I also wanted to keep track of the game with my server (kills etc.), so you need to simulate the game anyway. And I found out that just sending positions etc. eats less bandwidth (on both sides) than sending inputs does.
Its better to just send positions etc. from the simulating server to the client so you are 100% sure each client is synchronized. Another problem were joining players, I did send all input from the beginning of the game to the player, so the client could update the game to the current state, you probably can imagine how much that is if the game is already going on for 10 minutes ... (And then I haven't even spoken of simulating the 10 minutes)
It was just not worth it, so many nasty tricks, ugly code (and processor overheating
) to just get them synced on inputs, and it turned out to be worse for both sides.
It was an interesting time occupation though, I learned so much.