4 ms·

I like it. Here's how I see the marketplace: Quick demonstrations & development: ngrok Low-resource environments (IoT, embedded): rathole Privacy-focused dep

I like it. Here's how I see the marketplace: Quick demonstrations & development: ngrok Low-resource environments (IoT, embedded): rathole Privacy-focused deployments: connet Production with active community: FRP Self-hosting with direct connections: connet https://gist.github.com/andrewarrow/d0e41dd954485a8574b9ea74fbfc017f https://gist.github.com/andrewarrow/d0e41dd954485a8574b9ea74...

srichard16 1y ago
Curious: why do you see ngrok as just for testing and dev when thousands of users use ngrok in production? Full disclosure I work there.
- ghoshbishakh 1y ago
  Why route all traffic through a tunnel for a production setup? On-premise solutions will use static IPs from their ISPs. Full disclosure - I work at https://pinggy.io https://pinggy.io
Ingon 1y ago
Very cool comparison, thank you! One new feature I haven't highlighted yet, is that you can, in addition, encrypt traffic as it goes through relays (both via tls or noise-inspired protocol, dhxcp). This enhances privacy, even when you are using public (e.g. not owned by you relays), covering a case like https://connet.dev https://connet.dev nicely.
- PLG88 1y ago
  Sounds like what zrok.io does ... do you also support completely E2E private shares like it does - https://docs.zrok.io/docs/concepts/sharing-private/ https://docs.zrok.io/docs/concepts/sharing-private/. This means the resource does not have a public IP at all (note, zrok also does public shares).
  - Ingon 1y ago
    If I understand correctly the terminology/case, all shares in connet a private. You access a remote resource as it was local, but that doesn't mean the resource is publicly visible. For example, my local network clients, do not need public IP or special firewall rules to communicate with remote clients. What I was describing above is a specific way to route traffic - by default if direct connection between clients can be made (e.g. peer-to-peer), connet uses that. However, in cases where this is not possible, connet can use relays to send traffic between peers. In this scenario, you can in addition encrypt traffic end-to-end, so if you are using a public/untrusted relays, the relay itself cannot inspect/see traffic between peers. Of course, you can also configure peers to never use relays and always communicate directly. A relay (or a third-party) is only used when both peers allow it and no direct route can be used.
yair99dd 1y ago
I'm a zrok.io fan
PLG88 1y ago
I would say zrok.io is more privacy-focused, particularly with its frontdoor and private sharing features.
- Ingon 1y ago
  connet itself doesn't have a notion of public share at all - you need clients/peers on both ends (destination and source) to "project" a remote service. connet.dev do enhance this, by running the source clients publicly, but you need to specifically enable this, and it is best used as a break-glass option, since obviously makes things less-private. In any case, zrok.io is cool, it is certainly more mature and feature rich project.
  - PLG88 1y ago
    Ahh, interesting, thanks for making it clear to me. You should check out OpenZiti too, that's what zrok is built on.

srichard16 1y ago

Curious: why do you see ngrok as just for testing and dev when thousands of users use ngrok in production? Full disclosure I work there.

ghoshbishakh 1y ago
Why route all traffic through a tunnel for a production setup? On-premise solutions will use static IPs from their ISPs. Full disclosure - I work at https://pinggy.io https://pinggy.io

Ingon 1y ago

Very cool comparison, thank you! One new feature I haven't highlighted yet, is that you can, in addition, encrypt traffic as it goes through relays (both via tls or noise-inspired protocol, dhxcp). This enhances privacy, even when you are using public (e.g. not owned by you relays), covering a case like https://connet.dev https://connet.dev nicely.

PLG88 1y ago
Sounds like what zrok.io does ... do you also support completely E2E private shares like it does - https://docs.zrok.io/docs/concepts/sharing-private/ https://docs.zrok.io/docs/concepts/sharing-private/. This means the resource does not have a public IP at all (note, zrok also does public shares).
- Ingon 1y ago
  If I understand correctly the terminology/case, all shares in connet a private. You access a remote resource as it was local, but that doesn't mean the resource is publicly visible. For example, my local network clients, do not need public IP or special firewall rules to communicate with remote clients. What I was describing above is a specific way to route traffic - by default if direct connection between clients can be made (e.g. peer-to-peer), connet uses that. However, in cases where this is not possible, connet can use relays to send traffic between peers. In this scenario, you can in addition encrypt traffic end-to-end, so if you are using a public/untrusted relays, the relay itself cannot inspect/see traffic between peers. Of course, you can also configure peers to never use relays and always communicate directly. A relay (or a third-party) is only used when both peers allow it and no direct route can be used.

yair99dd 1y ago

I'm a zrok.io fan

PLG88 1y ago

I would say zrok.io is more privacy-focused, particularly with its frontdoor and private sharing features.

Ingon 1y ago
connet itself doesn't have a notion of public share at all - you need clients/peers on both ends (destination and source) to "project" a remote service. connet.dev do enhance this, by running the source clients publicly, but you need to specifically enable this, and it is best used as a break-glass option, since obviously makes things less-private. In any case, zrok.io is cool, it is certainly more mature and feature rich project.
- PLG88 1y ago
  Ahh, interesting, thanks for making it clear to me. You should check out OpenZiti too, that's what zrok is built on.