It's the Dropbox Show HN from 2007 before Show HN was a thing. Someone made a comment with the same feel as this one.
The "joke" is that of course a developer can replicate the early version of most products, but that doesn't mean the product will fail (see Dropbox).
below that bandwidth, the latency is getting into the annoyingly high territory. and of course I'm taking about using it in approved quality mode.
it nicely handles HiDPI resolutions too, but unfortunately the built-in macOS vnc viewer can only scale down the screen, not up.
another issue is that zerotier doesn't work in China, but that's more of a social than technical issue unfortunately...
what I found is that Tuple.app makes a more useful compromise between latency and image quality. on low bandwidth your image might look like a balls of random pixels on first glance, but on a second look you can surprisingly still read it. meanwhile latency remains below 0.5s, so you can keep thinking together with your pairing partner.
screen.so over low bandwidth keeps the image quality significantly higher than just-above-unreadable, but then you are experiencing jittery 1-6 second screen update frequency.
In addition to latency and legibility, I also value trust (so non-open-source clients are negatively treated), and CPU efficiency (WebRTC screen-sharing fails on this).
Thus, I cannot use Tuple.app (macOS only) and screen.so (which, on the surface, appears to be using Electron, and thus WebRTC).