Why does Beaker find a site, then lose it?

I’ve been having this recurring issue with Beaker where put in a dat url, load the site, I’m reading through it and suddenly - wham, “It doesn’t seem like anybody is sharing this site right now.”

Well, someone was sharing this site twenty seconds ago. I doubt they took it down. And if I open a new tab & navigate to the same dat, half the time it will load – briefly… before going down again.

What gives? This issue is really frustrating and, frankly, doesn’t make sense when you consider the fact that I can load sites in the first place, before losing them.

Honestly I’m having a lot problems with Mastodon too, can’t follow or reply to anyone from different instances. “Trouble looking up the remote account.” I guess P2P is harder than it looks. It’s making me wonder if it’s worth the effort, honestly.


I was experiencing a similar behavior when using dat and found and fixed a bug in discovery-swarm package that solved the problem.

Since Beaker Browser uses version “^5.1.3” of discovery-swarm and the fix was introduced in discovery-swarm “6.0.1”, Beaker Browser developers would need to upgrade discovery-swarm dependency version to benefit from this fix.

Other dat libraries and projects are in the exact same situation, depending on an older version of discovery-swarm. Cautious about the possible breaking changes introduced in discovery-swarm ^6.0.0 I guess.


Hey nice, great job tracking that down!

If you don’t mind me asking, what was your debug process? Did you figure this out in the command line or Beaker’s dev tools?

Thanks for sharing. Hopefully Beaker’s devs can integrate discovery-swarm 6.0.1 asap. It’s extremely annoying to lose a site you just loaded.

I was not using Beaker Browser but dat-node for creating a mobile app which uses dat protocol for realtime P2P communication.

My debug process:
When I noticed this behavior I added several listener to my code to trace and log every network event:

It was then when I noticed how some problem in the network, latency, a busy peer, could cause the connection to drop because of inactivity.
That was not the problem per se.
The problem was that when the connection was restored and the peer was found again and tried to reconnect it was detected as duplicate.

This would prevent any posible attempt to reconnect with that peer again until some of you closed the program and started it again luckily using a new port/peer identifier.

And then, as soon as any failure in the connection ocurred again the problem would reappear.