> In our actual world, I built it in about a week, and roughly half of that time was spent wrestling with different flavors of code-signing and identity provisioning and I don’t even know what. I burned some incense and threw some stones and the gods of Xcode allowed me to pass.
This resonated with me.
This is a major source of friction to "scratching your own itch" in modern software development. Makes it extremely painful to get started. And runs against an engineering mindset, as it's not understanding principles of computing or composing components in a sensible way to build a useful new thing. It's just banging your head spamming incantations found through Google until something finally works.
Indeed. The #1 thing I need from my platforms is that I don't need to get anyone else's permission to develop and install any programs on it that I wish. That basically rules out Apple and Microsoft.
I've run into lots of issues running my programs on Windows. Sometimes it will even delete the executables outright if it decides they are dangerous. This was mostly with networked and virtualization apps.
I've made several home-brewed apps for ios. I just make them webpages, host them for free with Github Pages, and on my phone I make that url into a home screen app and voila. No app store interaction needed.
> It's just banging your head spamming incantations found through Google until something finally works.
Yea, all the while hoping you don't mess up something even worse!
I feel like Apple has made some strides in this area - having Xcode manage a bunch of profiles + key signing and whatever else it does when I click "Yes, make it easier for me". But it also randomly forgets settings and breaks etc. which is fun to re-troubleshoot.
This is where a pi web server along with cloudflare tunnel and a website really shine. You don't need to ask anyone to run that service. I'm running a custom todo app off my pi without exposing my router. It's incredibly freeing.
We need something that goes one level beyond Tailscale. It should be built on a simple open OAuth2 protocol for establishing tunnels/VPNs so you can choose different providers. Then developers can implement tunneled networking directly into their apps.
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?
This resonated with me.
This is a major source of friction to "scratching your own itch" in modern software development. Makes it extremely painful to get started. And runs against an engineering mindset, as it's not understanding principles of computing or composing components in a sensible way to build a useful new thing. It's just banging your head spamming incantations found through Google until something finally works.