Advertisement
Guest User

swores comment on news.ycombinator.com/item?id=40284994

a guest
May 7th, 2024
30
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 3.04 KB | None | 0 0
  1. edit to add:
  2. I'm far from an expert in this stuff, but based on the pros and cons of various tools I've used down the years, I feel like an open source version could actually go a step further and not even need servers for the discovery / negotiation part either (if also not planning to offer relaying the whole thing the way the RPi TURN servers are).
  3. The missing step for discoverability could be handled with dynamic DNS - so the daemon on the server would, any time the server has a new public IP (checking on boot, on network change, and every X time period when turned on) it sends an update for a subdomain to point at it, so the client just needs to be introduced to that subdomain once and always be able to use it to reach the server.
  4. Traditionally, dynamic DNS providers of course are themselves running on a server, which is what their local client sends the "this is my new public IP" message to for the subdomain to be updated. But for people who own their own domain, they could host it with a provider that allows DNS records to be updated over API (so technically there's still a server involved but it belongs to the domain registrar and doesn't cost any extra money).
  5. And maybe there'd even be some way for the open source tool to have a domain (domain.com) and allow every user to create a subdomain of [md5-of-their-username].domain.com followed by letting each user have multiple sub-sub-domains (eg machine1.[user's-md5].domain.com, machine2.... etc). Well, if the open source project went back to having a server for it then this would definitely be possible, my "maybe" was because I'm not sure there's any domain providers who not only offer an API, but offer such granular access as to allow numerous different API keys to only have access to update A records that fall under a specific subdomain (i.e. letting the person who registered [md5-of-swores].domain.com create and update [*].[md5-of-swores].domain.com
  6. After that, I'm not familiar enough with WebRTC to say confidentially that having discovered the needed IP address is enough to also negotiate the best direct route to start the remote desktop session with, rather than still needing a server to help with that, but I think it would be fine?
  7. I think that should work fine for anyone who already owns a domain (and is happy to have it sitting with a company who allows DNS changes over API, such as Namecheap, DNSimple, and I'm sure quite a few others). Finding one that allows, both technically and not minding somebody paying for a single domain but potentially racking up thousands upon thousands of daily API calls to update DNS records, might be a bit harder... but might not be impossible!
  8. edit 2: and in fact, there still are free Dynamic DNS providers out there (from a quick DuckDuckGo, a couple of examples include https://www.dynu.com/ and https://freedns.afraid.org/ ), so if the more complicated version of my suggestion turns out not to be possible, and there's a DDNS provider that you trust, you could just piggy back off them rather than needing a new hosted service as part of the remote desktop tool.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement