What is "hub.bugout.link"? Why might a connection fail?

[a-type]

First - this is a great little tool. I've done a lot of experimenting with web P2P tech and this is the first one which makes things simple and accessible enough to get off the ground immediately. I've rigged it up with QR codes for address transfer between devices for my app Food List and after just an hour or so I've already got devices connected and sharing data! Amazing!

That said, I've had some hiccups with the WebSocket connection to hub.bugout.link. This appears to be a server you're hosting. Sometimes things work fine, but other times the connection drops prematurely or I get a 500 error during handshake.

browser.js:181 webtorrent [2d57573] new webtorrent (peerId 2d5757303030372d52333079456f6c3272713866, nodeId 418d41531dc91961543de04d93254f2b21d240e4, port 0) +0ms
browser.js:100 bugout address +0ms bEg8ZiAnzkrnyPqm5eFS4LZRy43jCMG8ds
browser.js:100 bugout identifier +1ms bEg8ZiAnzkrnyPqm5eFS4LZRy43jCMG8ds
browser.js:100 bugout public key +1ms GoCi8GfjeTZFZysgoRa2ZHJCtookHSm4SmCuc13dJ5jx
browser.js:100 bugout encryption key +0ms 4QnP2Xy2KXXXb9rDRCrHoApBzyCCffjZr9fuyAZV3vQk
browser.js:181 webtorrent [2d57573] seed +77ms
browser.js:181 webtorrent [2d57573] add +1ms
browser.js:181 webtorrent [2d57573] new webtorrent (peerId 2d5757303030372d6e4972717148736157417a50, nodeId 1d81e5144a55be043e0762ca97e87cbda8d7aa7d, port 0) +3ms
browser.js:100 bugout address +34ms bWL4vvnkhUBh3V4Sf4rk6y5YunQ4P9o6AB
browser.js:100 bugout identifier +1ms bWL4vvnkhUBh3V4Sf4rk6y5YunQ4P9o6AB
browser.js:100 bugout public key +1ms 6Jid9jijajiEkwFFrobz6QYmN9z67j14UZr2GZPimhrm
browser.js:100 bugout encryption key +1ms 8nGo5b45SUxjtPVgAH2wrZ9FWJjMBYB5nQkyWRZWnC3T
browser.js:181 webtorrent [2d57573] seed +32ms
browser.js:181 webtorrent [2d57573] add +1ms
browser.js:181 webtorrent [2d57573] listening +716ms
browser.js:181 webtorrent [2d57573] listening +2ms
browser.js:181 webtorrent [2d57573] on seed +267ms
browser.js:100 bugout torrent +987ms bEg8ZiAnzkrnyPqm5eFS4LZRy43jCMG8ds Torrent {_events: {…}, _eventsCount: 2, _maxListeners: undefined, _debugId: "44981bb", client: WebTorrent, …}
browser.js:181 webtorrent [2d57573] on seed +3ms
browser.js:100 bugout torrent +2ms bWL4vvnkhUBh3V4Sf4rk6y5YunQ4P9o6AB Torrent {_events: {…}, _eventsCount: 2, _maxListeners: undefined, _debugId: "de9a2b5", client: WebTorrent, …}
index.js:60 WebSocket connection to 'wss://hub.bugout.link/' failed: Connection closed before receiving a handshake response
Socket @ index.js:60
_openSocket @ websocket-tracker.js:179
(anonymous) @ websocket-tracker.js:341
2index.js:60 WebSocket connection to 'wss://hub.bugout.link/' failed: Error in connection establishment: net::ERR_CONNECTION_RESET
Socket @ index.js:60
_openSocket @ websocket-tracker.js:179
(anonymous) @ websocket-tracker.js:341
index.js:60 WebSocket connection to 'wss://hub.bugout.link/' failed: Error during WebSocket handshake: Unexpected response code: 500
Socket @ index.js:60
_openSocket @ websocket-tracker.js:179
(anonymous) @ websocket-tracker.js:341
index.js:60 WebSocket connection to 'wss://hub.bugout.link/' failed: Error in connection establishment: net::ERR_CONNECTION_CLOSED
Socket @ index.js:60
_openSocket @ websocket-tracker.js:179
(anonymous) @ websocket-tracker.js:341

I'm trying to determine a few things:

1. Could the problem be on my end? Filtering on my network, etc? Doesn't seem likely since the connection occasionally works fine.
2. If this is your infrastructure, is it having issues? If so I completely understand, but I'm curious as to whether there is a way to self-host this so I can more effectively control uptime.

Edit: just noticed there are pub keys in the logs - a note to anyone trying to connect to my app, I rotated my address already 😬

[a-type]

For anyone interested, I read the source code a bit and determined I could stop trying to connect to hub.bugout.link (which appears to be a redundant, self hosted tracker URL) by passing ['wss://tracker.openwebtorrent.com', 'wss://tracker.btorrent.xyz'] to options.announce. This reduces redundancy I suppose, but it does remove the errors.

[chr15m]

As you've correctly deduced, hub.bugout.link is a WebTorrent tracker which I host myself (the other two in the list are hosted by WebTorrent people).

Over here I started a project for a "WebRTC signaling mesh" which will decentralize signaling itself so we no longer have to rely on centralized single points of failure during signaling.

[chr15m]

As far as the connection failures go, uptime on that box currently reports loadavg at 0.0 0.0 0.0, however in recent weeks it has had a number of usage spikes due to the release of Slingcode. It could be that during one of those spikes the connectivity issues started. I should probably up the resources on that box. Thanks for pointing this out.

By the way Food List looks great!

[a-type]

I'm excited you're still working on decentralization tech! I'm just now getting into this space and as I said, this has been my favorite library so far, the easiest to get started with, and the only one I was able to actually launch in an app!

It's a shame we still require centralized signaling to establish P2P, although it makes sense given the way the web works. Glad to see folks working past that. I'll be following your progress 👍🏻 Maybe at some point I'll get enough of a handle on this tech to help out.