Show HN: Lynk – Securely expose local TCP and HTTP services to the web
1–10 of 53 posts
Re: Show HN: Lynk – Securely expose local TCP and HTTP services to the web
#2We're excited to announce that the Lynk Beta is now live!
We've been hard at work building out Lynk's tunnelling protocols to make them faster, more stable, and all around better. We're happy to announce that vs. Ngrok our tunnels perform up to 6 times faster (source: https://medium.com/@shivanshvij/building-a-better-ngrok-dbc1...) and support technologies such as HTTP/2 (with HTTP1 fallback) and Websockets.
Check out our open beta and documentation here: https://lynk.sh
Re: Show HN: Lynk – Securely expose local TCP and HTTP services to the web
#3Hi Hackernews, We're excited to announce that the Lynk Beta is now live! We've been hard at work building out Lynk's tunnelling protocols to make them faster, more stable, and all around better. We're happy to announce that vs. Ngrok our tunnels perform up to 6 times faster (source: https://medium.com/@shivanshvij/building-a-better-ngrok-dbc1... ) and support technologies such as HTTP/2 (with HTTP1 fallback) and Webs…
Re: Show HN: Lynk – Securely expose local TCP and HTTP services to the web
#4Hi Hackernews, We're excited to announce that the Lynk Beta is now live! We've been hard at work building out Lynk's tunnelling protocols to make them faster, more stable, and all around better. We're happy to announce that vs. Ngrok our tunnels perform up to 6 times faster (source: https://medium.com/@shivanshvij/building-a-better-ngrok-dbc1... ) and support technologies such as HTTP/2 (with HTTP1 fallback) and Webs…
I'm curious about the note that you apply compression. Are you proposing your customers rely on your encryption rather than doing their own E2E encryption? If not how significant are the compression savings if you're just compressing encrypted data.
Re: Show HN: Lynk – Securely expose local TCP and HTTP services to the web
#5Re: Show HN: Lynk – Securely expose local TCP and HTTP services to the web
#6Is this a mistake?
Re: Show HN: Lynk – Securely expose local TCP and HTTP services to the web
#7To tunnel your whole infrastructure traffic through a third party is one of the dumbest ideas I have ever heard of.
Re: Show HN: Lynk – Securely expose local TCP and HTTP services to the web
#8Hi Hackernews, We're excited to announce that the Lynk Beta is now live! We've been hard at work building out Lynk's tunnelling protocols to make them faster, more stable, and all around better. We're happy to announce that vs. Ngrok our tunnels perform up to 6 times faster (source: https://medium.com/@shivanshvij/building-a-better-ngrok-dbc1... ) and support technologies such as HTTP/2 (with HTTP1 fallback) and Webs…
Re: Show HN: Lynk – Securely expose local TCP and HTTP services to the web
#9Hi Hackernews, We're excited to announce that the Lynk Beta is now live! We've been hard at work building out Lynk's tunnelling protocols to make them faster, more stable, and all around better. We're happy to announce that vs. Ngrok our tunnels perform up to 6 times faster (source: https://medium.com/@shivanshvij/building-a-better-ngrok-dbc1... ) and support technologies such as HTTP/2 (with HTTP1 fallback) and Webs…
But i can't sign up using mail only.
Re: Show HN: Lynk – Securely expose local TCP and HTTP services to the web
#10Earlier quoted context omitted.
I'm curious about the note that you apply compression. Are you proposing your customers rely on your encryption rather than doing their own E2E encryption? If not how significant are the compression savings if you're just compressing encrypted data.
Yes, we are doing E2E encryption and compression between the Lynk Infrastructure and Lynk Clients. As with Ngrok, for a quick hosted tunnel our encryption will be more than suitable, and we are working to release a self-hosted version soon that will allow you to bring your own certificates (for both ingress traffic and the traffic between the Lynk Client and the Lynk Infrastructure).
1- If people are using their own E2E encryption below your tunnel, then your compression provides essentially zero value, since properly encrypted traffic should not have repeating patterns to compress.
2- If you are telling people to not use their own E2E encryption, and instead rely on the Lynk tunnel's E2E encryption (with Lynk applying compression before encryption) then people are exposing their raw traffic to you, a seemingly random person on the internet.