Do you want to share publicly (via a URL for anyone) or privately (accessible only with an endpoint and identity)?
For the former, zrok frontdoor (by https://docs.zrok.io/docs/guides/frontdoor/) protected by OAuth could be the solution. Further, if you want to embed directly in your app, use the SDK - https://blog.openziti.io/the-zrok-sdk. Today we only have for Golang; Python and NodeJS/Javascript coming soon. More in the pipeline.
For the latter, use OpenZiti (which zrok is built on - https://github.com/openziti). We have SDKs in Go, C, Java, NodeJS, Python, and many more.
It's all FOSS under Apache 2.0. I work on the project.
I'm aware of zrok/openziti, but I'm looking for something with a protocol-first design. Does zrok have a well-specified protocol that can easily be implemented by others? If not, since you're running a company, you aren't incentivized to make zrok easy to self-host. You can also relicense at any point. Doesn't mean this will happen, but incentives aren't aligned.
Whats your definition of 'protocol-first design'? Incentives definitely exist for the company I work for, which develops OpenZiti and zrok, and we do have a SaaS offering for both, but fundamentally we lead with the open source and make it as simple as possible (always a work in progress) to self-host, or else you wouldn't have people adopt the open source.
FOSS, as a GTM strategy, mandates reducing the initial barrier to entry, with the majority consuming your products for free, and only a small subset (usually with large, complex, production-scale deployments) wanting the SaaS version or some sort of paid support.
I can only speak for myself, I am not that technical when it comes to a command line, and I have deployed zrok locally.
And you are right, technically we could relicense. But we will not. Our goal is to turn Ziti into the equivalent to Linux for secure-by-default, distributed networking. This is why we permissively OSS under Apache 2.0. This is why we help others to build their own hosted versions of Ziti/zrok. This is why I expect, in the future, we will create an open governance model. We all know how badly is goes when you create a popular tool and try to pull the rub (cough, Hashicorp).
> Whats your definition of 'protocol-first design'?
Developing an open protocol at the same time you develop the first implementation. This has a few effects. First, it tends to simplify the protocol, since you have to justify your design decisions much more. More importantly, it makes it easier for competitors to make implementations, which forces you to compete on quality of service, rather than depending on a technical moat.
> And you are right, technically we could relicense. But we will not.
But this is depending on the goodness of your hearts, rather than incentive alignment.
> Our goal is to turn Ziti into the equivalent to Linux for secure-by-default, distributed networking. This is why we permissively OSS under Apache 2.0
If this is your goal, why not use a copyleft license as Linux does?
> We all know how badly is goes when you create a popular tool and try to pull the rub
Again, you've done nothing to align incentives better than Hashicorp did. What reason do we have to believe you won't eventually do exactly what they have?
For the former, zrok frontdoor (by https://docs.zrok.io/docs/guides/frontdoor/) protected by OAuth could be the solution. Further, if you want to embed directly in your app, use the SDK - https://blog.openziti.io/the-zrok-sdk. Today we only have for Golang; Python and NodeJS/Javascript coming soon. More in the pipeline.
For the latter, use OpenZiti (which zrok is built on - https://github.com/openziti). We have SDKs in Go, C, Java, NodeJS, Python, and many more.
It's all FOSS under Apache 2.0. I work on the project.