- From: ibsusu via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Apr 2019 21:19:27 +0000
- To: public-webrtc-logs@w3.org
Let's theorycraft for a bit: 4 users have public & private certs, ice username fragments, passwords, candidates. user 1 connects the normal, handshake way to user 2 and then sends all of his info to user 2. user 3 connects the normal handshake way to user 2 and then sends all of her info to user 2. User 2 says he knows user 1. user 3 wants to connect to user 1 and starts the negotiation process with user 2. User 2 uses everything received from user 1 then sends the sends the final connection information like the chosen candidate and whatever to user 1 to let them know user 3 is going to try to connect. user 3 connects to user 1 and gets all of his information as well. user 4 connects to user 3 normally and says they also want to connect to user 1. Repeat. so to reiterate: user 1 -> user 2 user 3 - > user 2 user 3 -> user 2(1's creds) -> user 1 user 4 -> user 3 user 4 -> user 3(1's creds) -> user 1 I believe this is doable for native->native and brower->native connection attempts but not native->browser or browser->browser connection attempts. Every connection is still one to one but we skip half of the relay and allow for a much quicker PEX lookup and dht process. To be perfectly honest I wanted to go one step further and have a user sign for the remote user of the connection themselves locally and just try to connect with a single signal call. I don't know if this qualifies as a hack but It seems fairly straight forward. As for being persistent, that's fine. We can remove them. I doubt they change often enough to make this technique useless. -- GitHub Notification of comment by ibsusu Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2179#issuecomment-486430917 using your GitHub account
Received on Wednesday, 24 April 2019 21:19:29 UTC