Show HN: P2P remote desktop – an alternative to TeamViewer / AnyDesk

Post by theblazehen » Wed, Dec 08, 2021, 1:20 PM UTC

francislavoie wrote: post #24

eins1234 wrote: post #6

Am I the only one that has long since given up traditional desktop streaming software like TeamViewer/AnyDesk and the like for game streaming software (Parsec, Rainway, Steam Remote Play, etc) that just happen to offer desktop streaming because they can? The actual streaming tech in those feels worlds ahead in terms of quality/efficiency/stability/latency. And the UX has generally felt better as well with much more s…

Parsec doesn't support remoting into a Linux machine, so that was the dealbreaker for me.

Post by ipython » Wed, Dec 08, 2021, 1:40 PM UTC

donmcronald wrote: post #17

jeroenhd wrote: post #5

This is one thing I'm surprised the open source community hasn't developed a popular alternative for: Teamviewer. The core idea is simple: a video stream from one computer to another, with mouse and keyboard controls sent the other way. Connection negotiation can be done Magic Wormhole style, via basic STUN, encryption can be done in a number of ways. Add some clipboard and P2P file transfer features and you've got m…

Code signing for Windows is a pain for anything self hosted. I tried every open source, self-hosted option I could find last week and none of it was usable. IIRC the only one that had signed executables was Remotely and it was a 150MB client that bundles .NET. All the rest seem to copy the terrible design of on demand code signing and that doesn’t work. If you get an EV certificate for instant SmartScreen reputation…

Post by harvie » Wed, Dec 08, 2021, 1:53 PM UTC

apankrat wrote: post #50

The NAT traversal logic here is really basic and won't hold up well in practice. A good chunk of NAT devices will pick external port based on [src ip/port, dst ip/port] combo, not just [src ip/port], so "WAN IP/port" you get from STUN will get you nothing useful. Not by itself. STUNs should be used for discovering the pattern in NAT port overloading logic and then using it to predict which port your peer will use tow…

Post by BitPirate » Wed, Dec 08, 2021, 2:42 PM UTC

harvie wrote: post #75

apankrat wrote: post #50

The NAT traversal logic here is really basic and won't hold up well in practice. A good chunk of NAT devices will pick external port based on [src ip/port, dst ip/port] combo, not just [src ip/port], so "WAN IP/port" you get from STUN will get you nothing useful. Not by itself. STUNs should be used for discovering the pattern in NAT port overloading logic and then using it to predict which port your peer will use tow…

These are very cool p2p projects with nice NAT traversals. https://syncthing.net/ https://github.com/hyperswarm/hyperswarm (whole family hypercore, hyperdrive, hyperswarm, ...)

Post by electroly » Wed, Dec 08, 2021, 3:01 PM UTC

jeroenhd wrote: post #26

donmcronald wrote: post #17

Earlier quoted context omitted.

Code signing for Windows is a pain for anything self hosted. I tried every open source, self-hosted option I could find last week and none of it was usable. IIRC the only one that had signed executables was Remotely and it was a 150MB client that bundles .NET. All the rest seem to copy the terrible design of on demand code signing and that doesn’t work. If you get an EV certificate for instant SmartScreen reputation…

SmartScreen becomes less of a pain when people start downloading the software more. In fact, if you don't have a lot of downloads, SmartScreen will block your executable even if you pay for the privilege of signing your executables! If you sign your executable + config files on the fly, you end up with SmartScreen warnings all over the shop! A possible solution would be to distribute the client through something like…