Bugout: Browser-to-browser networking built on WebTorrent(github.com)
github.com
Bugout: Browser-to-browser networking built on WebTorrent
https://github.com/chr15m/bugout
33 コメント
Two things bewilder me:
1. Why is video conferencing in 2022 still such a disaster?
2. Why is it still so freakin’ hard for me to send a file of arbitrary size to someone?
I’m really getting optimistic about #2. But I worry it’ll be limited to nerds or attacked by established parties using the usual means (like making it impossible on popular devices in the name of anti piracy)
1. Why is video conferencing in 2022 still such a disaster?
2. Why is it still so freakin’ hard for me to send a file of arbitrary size to someone?
I’m really getting optimistic about #2. But I worry it’ll be limited to nerds or attacked by established parties using the usual means (like making it impossible on popular devices in the name of anti piracy)
For #2, see https://wormhole.app which is built with the same WebTorrent library mentioned in the original link. Works on iOS, Android, etc. all platforms as far as I know.
Disclosure: worked on WebTorrent and Wormhole.app
Disclosure: worked on WebTorrent and Wormhole.app
Wow thanks! I’m going to set it up with my wife and see if it passes the “don’t need to be a nerd” test. :)
Edit: there’s nothing to set up. Despite what the TLD might imply, there is no app. It. Just. Works. Remind me to complain more about things that have historically sucked.
Edit: there’s nothing to set up. Despite what the TLD might imply, there is no app. It. Just. Works. Remind me to complain more about things that have historically sucked.
This is awesome, maybe I can finally stop texting myself links to PDFs to read on my laptop.
For #1 I think it's simply a bandwidth and latency issue.
Say you are using webrtc to do a video call. Now imagine the same thing but with 10000 peers sharing their video. That means each participant has to upload their feed 9999 time while at the same time download 9999 videos from random peers around the Internet, each one with their own bandwidth and latency restrictions and each one doing the same thing as you (uploading and downloading to/from 9999 peers)
Say you are using webrtc to do a video call. Now imagine the same thing but with 10000 peers sharing their video. That means each participant has to upload their feed 9999 time while at the same time download 9999 videos from random peers around the Internet, each one with their own bandwidth and latency restrictions and each one doing the same thing as you (uploading and downloading to/from 9999 peers)
Very interesting.
As well as other usages it seems this would be one way to host online games. The app itself being the only thing served centrally and then instances of the app get served by website visitor's to host their own private workspace/gamespace. So all data created in that instance would remain private to that instance and the clients that connect to it. Is that a reasonable use case or am I misunderstanding?
As well as other usages it seems this would be one way to host online games. The app itself being the only thing served centrally and then instances of the app get served by website visitor's to host their own private workspace/gamespace. So all data created in that instance would remain private to that instance and the clients that connect to it. Is that a reasonable use case or am I misunderstanding?
Imagine a card game with a deck and two players. The deck knows which player got which card. Each player knows its own cards and the ones on the table. The deck should not run in the browser of one of the players because that player could inspect the status of the deck and know which cards were handed to the other one.
To answer your question: maybe, but for almost any game you need a trusted third party that holds the secret state of the game. A third browser somewhere or a headless server?
Exceptions: complete information games like go, chess and checkers. Everything is public.
Games with a dice like backgammon starts to be problematic because how can one player trust the dice of the other player? A shared random seed would let them know in advance all the rolls.
To answer your question: maybe, but for almost any game you need a trusted third party that holds the secret state of the game. A third browser somewhere or a headless server?
Exceptions: complete information games like go, chess and checkers. Everything is public.
Games with a dice like backgammon starts to be problematic because how can one player trust the dice of the other player? A shared random seed would let them know in advance all the rolls.
> "how can one player trust the dice of the other player?"
I have an algorithm for that. To roll a dice: 1. both players create a random x bytes long number.
2. both players make a hash from their number and then send it to the other one.
3. players exchange their random numbers and check if hashes are correct
4. concat both players random numbers and hash it to get the final random number
By exchanging hashes, both players can be sure that other player didn't tamper with their random number after getting yours.
(edited formatting)
I have an algorithm for that. To roll a dice: 1. both players create a random x bytes long number.
2. both players make a hash from their number and then send it to the other one.
3. players exchange their random numbers and check if hashes are correct
4. concat both players random numbers and hash it to get the final random number
By exchanging hashes, both players can be sure that other player didn't tamper with their random number after getting yours.
(edited formatting)
I'm currently working on a multiplayer game and I really really wanted to do this, but even if it works in principal, it fails in practice.
On step 3, this exchange does not happen exactly at the same time. If I'm playing with someone and we reach step 3, I could intentionaly hold myself from sending my data over, wait for the other player to send their data, and if their data wins against my (unsent) data, then I can simply choose not to send my data over (abort), forcing a tie.
This is easy enough to detect and you could just ban people that do this repetidly, but these people would just create new accounts whenever they get banned.
Hence, a cheater can either force a tie or win.
If you go down the rabbit whole on how you could theoricaly do this exchange fairly, you'll discover that this is provably impossible if you do not control the computational power of all parties (if you did, you could employ a time-locked puzzle with proof of work, for example).
This is known as a fair exchange with a fail-stop or secure-with-abort model.
See: http://www.cs.utexas.edu/~shmat/courses/cs395t_fall04/pagnia...
https://crypto.stackexchange.com/a/25458
https://crypto.stackexchange.com/a/26624
https://crypto.stackexchange.com/questions/8333/is-there-a-w...
http://www.iacr.org/archive/eurocrypt2010/66320221/66320221....
On step 3, this exchange does not happen exactly at the same time. If I'm playing with someone and we reach step 3, I could intentionaly hold myself from sending my data over, wait for the other player to send their data, and if their data wins against my (unsent) data, then I can simply choose not to send my data over (abort), forcing a tie.
This is easy enough to detect and you could just ban people that do this repetidly, but these people would just create new accounts whenever they get banned.
Hence, a cheater can either force a tie or win.
If you go down the rabbit whole on how you could theoricaly do this exchange fairly, you'll discover that this is provably impossible if you do not control the computational power of all parties (if you did, you could employ a time-locked puzzle with proof of work, for example).
This is known as a fair exchange with a fail-stop or secure-with-abort model.
See: http://www.cs.utexas.edu/~shmat/courses/cs395t_fall04/pagnia...
https://crypto.stackexchange.com/a/25458
https://crypto.stackexchange.com/a/26624
https://crypto.stackexchange.com/questions/8333/is-there-a-w...
http://www.iacr.org/archive/eurocrypt2010/66320221/66320221....
Hmm, "exchange is at least as hard as consensus". Guess you need to run your game on a blockchain? :)
Yeah blockchain could work as a trustable 3rd party impossible to manipulate. Although I'm not sure there's any blockchain out there capable of handling realtime games, but can work for other types of games for sure.
Maybe there are well known attacks against this scheme. Let's try a naive one.
Conditions first: it's a 6 sides die. I need 1 to win, you need 2. The final number will be the hash of step 4 modulo 6.
Let's try a naive implementation with 1 byte long numbers, no random bits to fill out the unused 5 bits of that byte.
When I receive your hash I compare it with the only 6 possible hashes (micro rainbow table.) I know your number is 4. The possible pairs will be 14, 24, 34, 44, 54, 64 (how we mix the bits of those pairs is deterministic so let's do a simple n*10+m.) If the hash of one pair modulo 6 is 1, I'll give you the hash of the first number of that pair otherwise maybe you cheated and sent me a hash that will at least ensure that I don't win now ;-)
We can add random bits, a lot of them, with the idea of making sure that the time I must spend is a very long one and exceed a timeout. However I must know where your number is in those bits.
Let's say the number is at position 5 and you sent me the hash for 9999499999. I can try to be lucky and find your number by hashing random ones, then try to find a number with a digit <= 6 in its fifth position so that I win and send you that hash.
Occasionally I will be able to generate a good number for me, not all the times.
As a side note, a friend working with inmates told me that when they play backgammon they share the same dice because they don't trust the other player not to have loaded dice. Those dice become a trusted third party. If they are loaded, the distribution is the same for everybody.
Finally, is the random distribution of your method still uniform? I didn't reason about it.
Conditions first: it's a 6 sides die. I need 1 to win, you need 2. The final number will be the hash of step 4 modulo 6.
Let's try a naive implementation with 1 byte long numbers, no random bits to fill out the unused 5 bits of that byte.
When I receive your hash I compare it with the only 6 possible hashes (micro rainbow table.) I know your number is 4. The possible pairs will be 14, 24, 34, 44, 54, 64 (how we mix the bits of those pairs is deterministic so let's do a simple n*10+m.) If the hash of one pair modulo 6 is 1, I'll give you the hash of the first number of that pair otherwise maybe you cheated and sent me a hash that will at least ensure that I don't win now ;-)
We can add random bits, a lot of them, with the idea of making sure that the time I must spend is a very long one and exceed a timeout. However I must know where your number is in those bits.
Let's say the number is at position 5 and you sent me the hash for 9999499999. I can try to be lucky and find your number by hashing random ones, then try to find a number with a digit <= 6 in its fifth position so that I win and send you that hash.
Occasionally I will be able to generate a good number for me, not all the times.
As a side note, a friend working with inmates told me that when they play backgammon they share the same dice because they don't trust the other player not to have loaded dice. Those dice become a trusted third party. If they are loaded, the distribution is the same for everybody.
Finally, is the random distribution of your method still uniform? I didn't reason about it.
If the random numbers can be 1-6, then yes, it would be trivial to attack. If the numbers are 300 bytes long, then it's impossible to predict.
> "I can try to be lucky and find your number by hashing random ones," If we were using sha-256, then you would be very impossibly lucky. There are 2^256 possible hash values for sha-256. It's extremely unlikely, that you would find a collision in the lifetime of the universe.
> "I can try to be lucky and find your number by hashing random ones," If we were using sha-256, then you would be very impossibly lucky. There are 2^256 possible hash values for sha-256. It's extremely unlikely, that you would find a collision in the lifetime of the universe.
Most games just accept this. One of the most profitable games in history (GTA Online) is trivially hackable because there is no server maintaining state, it's just peers telling each other what they did.
Cryptography can solve this, see: https://en.wikipedia.org/wiki/Mental_poker
Although promising, I don't see how this umbrella concept helps solve the issue. Could you be more precise on the exact step by step protocol that would allow for a fair exchange of two random numbers and subsequent result without allowing the parties to cheat?
Sorry, not my area of expertise. I wasn't aware of the caveats brought up in your other post.
In this instance the server is the browser of whoever started the session and the others are clients?
I was imagining a browser based Maptool. https://www.rptools.net/toolbox/maptool/
I was imagining a browser based Maptool. https://www.rptools.net/toolbox/maptool/
Multiplayer games of old where usually p2p. DoS attacks from sad losers an cheating put an end to that.
A lot of things did, not just what you mentioned. It's a lot harder to replicate a high amount of data to a high amount of players in p2p, since you have to send that data to everyone you're playing with, and you're basically limiting yourself to residential connections/wifi which are still crappy and have a high amount of lag. For the kind of fast-paced games people make/expect nowadays, this isn't really acceptable anymore.
Recent and related:
WebTorrent - https://news.ycombinator.com/item?id=33790186 - Nov 2022 (137 comments)
WebTorrent - https://news.ycombinator.com/item?id=33790186 - Nov 2022 (137 comments)
This is rekindling an interest I had in doing exactly the same thing. Nice to see another implementation. I’ll have to revive my old code. I think the key to getting uptake would be making it easy for anyone to live edit their copy and have the changes propagate to peers. Also some easy way of browsing what connected peers are hosting.
> // javascript why
The question I ask myself whenever I enter a JS codebase lol
This is really cool. Actually serverless apps!
The question I ask myself whenever I enter a JS codebase lol
This is really cool. Actually serverless apps!
I sometimes wonder how long until we come full circle by integrating enough features in a browser to make them fully replace your usual everyday OSes.
At which point they will be so complicated, and each browser will be subtly different, that we will invent yet another abstraction layer. Devs will stubbornly only target it, and we will add more and more features until....
ChromeOS would seem to be the answer to this question, no?
I'm shocked (and a bit upset) we aren't taking the mid-way step and treating browser tabs as comparable to apps in DE taskbars.
Disclosure: I’m the original author of WebTorrent