2,685 karma · joined January 2, 2013
These are differentiating from most VPN and zero trust:
+ fully self-hostable open source
+ avoid ACL complexity (default closed architecture)
+ sovereign identity-based
OpenZiti is similar in those – how do you compare and contrast the two since very few others share those differentiators (I am an OZ maintainer)?
it is brilliant business strategy from China so i expect it to continue and be copied - good things.
reminds me of Google's investments into K8s.
If we believe the AI-influenced system will be faster, more prolific and more experimental (cheaper experiments), then it seems human attention and the rate at which humans can change (individually, processes, tools, teams, etc) becomes the bottleneck.
In that system, the designer and PM functions become more important in addressing that bottleneck - in producing solutions to best overcome those bottlenecks?
agree - when code is increasingly difficult to control, take control of the network.
but how to do the "openclaw-restricted" network itself in practice?
of course gcp is the smallest of the three but not small as it approaches $20B.
do the #s track with what HN community has seen in comparing the three largest hyperscalers in function, pricing, reliability, etc?
+ spacex already is the best way for many payloads to get to space.
+ starlink is already the best low orbit based connectivity solution.
+ x is already a great way to train virtual world AI.
+ tesla (and its robots) is a great way to train physical world AI.
+ space takes big $ and talent - this combo would have both.
the IF at the top is just that. but feels like an interesting convo for this crowd.
are OpenZiti, Headscale, Nebula the 3 closest?
great resource here (no affiliation) for HN community:
github.com/rochecompaan/openziti-nix
if your focus is trying it rather than distributing consistent versions to many folks, you can also use the ziti-edge-tunnel binary, define a systemd service and add identities (a given app or device can belong to (n) OpenZiti overlays via (n) different identities).
100%. even more robust if paired with an overlay network which provides identity based s3 access (rather than ip address/network based). else server may not have access to s3/cloud resource, at least for many enterprises with s3 behind vpn/direct connect.
ditto for cases when want agent/client side to hit s3 directly, bypassing the server, and agent/client may not have permitted IP in FW ACL, or be on vpn/wan.
+ e2ee via netfoundry's zero trust products
+ non-e2ee via netfoundry frontdoor
1. End-to-end encryption.
2. Performance and reliability. 100+ PoPs in all major clouds running their data plane routers if they host (still E2EE), or run routers anywhere if you self-host. Dynamic routing to find best paths across the routers.
https://techcrunch.com/2025/07/09/openai-is-reportedly-relea...
Microsoft AI browser next announcement?
i would rephrase as "incumbents don't usually make more money if things are opened up".
if consumer gets materially better value, then challenger ecosystem around MCP will evolve. it will be open at first - great for startups and challengers, innovator's dilemma for market leaders.
and then it will close as the new wave establishes their moats. but, similar to web, even though the current web leaders are now much more closed than we would like, the overall ecosystem is more open than it was.
Sustainable business model? Check.
Top cybersecurity VCs supporting open source model? Check.
Yes, it is possible to make the world a more secure place by helping both the open source community and the world's largest companies. Arguably, it is the best way.
And, no, we did not change our licensing. Apache 2.0, purposefully permissive.
Disclosure: founder.
1. If you actually need strong security, you are likely to go with open source zero trust or their commercial versions.
2. If you don't need strong security, you will often view VPN an insurance policy (TS simplifies but is still more difficult than 'do nothing').
So you end up with a relatively narrow band of 'use cases' like NAT traversal; semi-privacy; access to private IP hosted services. Enough to sustain a venture funded company?
>2025-01-29: Hirsch replies stating that these vulnerable systems are not following manufacturers’ recommendations to change the default password
this is why i like the 'secure by design' or 'secure by default' responsibility being put on connected product providers, e.g. EU CRA and implied in US M-22-09.
i am always fearful of unintended consequences of regulation like this, but it does seem necessary in today's world.
Meaning ecosystems around Caddy to make it even simpler and more secure, e.g. keep your server private while serving Internet clients. So VPNs like Tailscale (1) or zero implicit trust like OpenZiti (also Apache v2; (2)). Similar to what we have seen with open source k8s ecosystem for example.
(1) https://tailscale.com/blog/caddy (and other VPNs but the proprietary bits in the commercial TS service make it easier to use)
(2) https://github.com/openziti-test-kitchen/ziti-caddy (disclosure: maintainer...there may be other open source zero implicit trust options with these types of Caddy integrations)
Until 2015's 'net neutrality', ISPs could have theoretically prioritized or deprioritized certain packets, e.g. favor their own video streaming service over Netflix (my understanding of the stated purpose of NN was to prevent that type of ISP behavior; I am not commenting on how achievable that might be, what else may have been included, and/or unintended consequences): https://archive.is/jPAKV
FCC repealed "net neutrality in 2017: https://archive.is/7wMMW
FCC restored NN in April 2024, and now we are back to the pre-2015 and 2017-2024 era states.
So I am wondering if we saw any changes in practice during these different eras? Not saying the past predicts the future, but curious on what we have seen so far.
adjacent but lots of experts here - independent of Cyphernetes or specific tooling, what are you doing to secure k8s api / kubectl / k8s control plane?
>If you're self-hosting and you want to access the signaling server remotely via mobile data, you may need to set up DDNS and port forwarding if your ISP provides a dynamic IP.
this also exposes your server to the internet. instead you can use one of the open source solutions which creates a private connection between your Pi and server (so there is no network access to the server - make it unreachable), and doesn't require static IPs or port forwarding.
Not that all risk can be eliminated, but this simplifies management while reducing the attack surface area by orders of magnitude.
The good news is companies are increasingly doing it now that technology has finally caught up - now that implementing a private* network with each vendor (or a private extranet across all vendors) is actually viable and sensible.
* Usually a software-only, zero implicit trust overlay network
Think of the dev ecosystem effects in all the various permutations, e.g. from Windows or Apple to AWS to more granular like PyTorch.
Those advantages aren't easily eliminated just by more competitors or even 'better' competitors.
It seems there are two sides of the spectrum for secure SSH access:
+ Relatively infrequent access by limited # of people to servers which are not top targets for attacks. Solutions like the one above are great for this.
+ More frequent, more users, more sensitive servers. Close all the inbound ports, permanently. Example: https://github.com/openziti-test-kitchen/zssh (or with an integrated OIDC like KeyCloak - https://youtu.be/NZJtzSoS_g0?si=Qg6p6Hdkaq1ahefg)
an open source example: https://blog.openziti.io/no-listening-ports