dovholuknf

Sounds like I shouldn't be so hard on AI when it hallucinates things based on this data? :)

I appreciate your thoughtful reply and I didn't think you were tossing any shade for what it's worth. I was just arguing that to me, both are "app embedded". IMO, the fact that traffic relays or not to me is non-consequential, what's important is where the encryption starts and where it ends (and where authorization happens but that's also separate). If it starts the client and ends at the 'server' then it's fully e2ee -- it doesn't matter if traffic traverses only IP-based underlays or if it traverses over an overlay at that point.

I very much appreciate the "outsider" perspective though and thank you very much for sharing it. That perspective is impossible to obtain after you work on a project for long enough! :)

Cheers!

At this time OpenZiti still operates in relay pattern. All your traffic travels through an OpenZiti router. It's also a zero trust overlay so having an external server is important to make policy decisions about whether an identity is authorized to dial a service or not. OpenZiti also allows for bespoke pathing via OpenZiti routers so that path traversal over the overlay is also coordinated.

The project has been moving to supporting directly connecting to other identities but it hasn't been a priority yet.

The connections an OpenZiti identity makes to another OpenZiti identity are direct-over-OpenZiti (not direct over IP underlay) if that makes sense. I don't know if you'll ever be able to have two process communicate without that third 'arbiter' process (I'll call it). It might happen, but right now it seems less likely than the direct connect approach.

hope that helps. But you can definitely have an SDK app client connect to an SDK app "server" and be fully zero trust, fully app embedded, fully end to end encrypted, peer-to-peer (over the overlay) connections.

OpenZiti has numerous SDKs. If you are a developer and you can integrate an SDK into your application, it 100% is application-embedded. It is incorrect stating that it can't be app-embedded... (i am a maintainer on the project). Perhaps I just don't understand the response?

FINALLY. This is actually exciting to me... Mind you the linux ports (cygwin, msys2, git bash) are all great to have and I make sure one version or the other is always on my path but having MS maintain them (assuming they continue to do so) is great news

Tailscale and Wireguard are great. I'm an OpenZiti maintainer and I've written/spoken about application embedded zero trust for many, many years. Still it seems most devs don't think it's important for whatever reason... It'll make me happy if Tailscale is successful here and can spread the word out to get more devs interested in embedding the secure connectivity directly into the apps instead of relying on the classic underlay network and bolting on security. If that sort of thing interests you, you could check out OpenZiti. It's not Wireguard-based for better or for worse you can decide (if you do end up checking it out)

That's good to know. Can you point me to the peer relay code? I'd like to look at what and how it works. thanks!

You are correct, zrok doesn't support mutual TLS. zrok is the free offering that NetFoundry supports so it's easy to see why you looked there for information.

The productized version, NetFoundry Frontdoor (doc here https://netfoundry.io/docs/frontdoor/how-to-guides/create-mt...) is what offers mutual TLS support.

It'll still terminate TLS at the servers, though. It's not mTLS all the way through to the endpoint.

The project I am a maintainer on, OpenZiti is an open source project that has high-quality MacOS, iOS, Windows, Android and linux clients https://openziti.io/docs/learn/introduction/

OpenZiti underpins the private connectivity from zrok, another opensource project and is one of the ones that is __not__ riding on wireguard which many people think is a good thing, but sometimes people are interested in a wireguard-based approach.

There is a huge list of alternatives as well you can find at https://github.com/anderspitman/awesome-tunneling. You can find OpenZiti and zrok on there but the github urls if interested are https://github.com/openziti/ziti and https://github.com/openziti/zrok

Maintainer here. Yes. The routers and the controller will have a port that can accept mTLS traffic.

> "feeling like it's not a good fit for me, and indiehosters in general."

Maintainer here so I'm gonna be biased with this hot take, but I really don't agree with this particular sentiment.

I would turn it around instead and say that most indie hosters are maybe not looking for the levels of protection a zero trust overlay network provides. That is a believable reason for me why it might be perceived as not a good fit. If you're not looking for the sort of security that OpenZiti affords the operator, it will certainly feel less of a fit than a classic VPN-like solution. It also focuses on a different paradigm wrt connectivity centered around individual services. That does mean the learning curve is absolutely steeper because it's not "just IP" and all our years of ip-based-know-how are useful, but not to make the most of the system. While one can use IP/L3/L4 just fine with OpenZiti, it's certainly not trying to be an IP-based VPN (like many of the other solutions are). That also might lead to feeling like it's not a great fit.

For the people who want the sort of security OpenZiti provides, however. It really is an easy-to-use (my bias showing) solution that plenty of indie hosters use already. :)

Not trying to sound too defensive here (a little is ok, right?) but I also appreciate the comments and feedback, thank you!

Couple of additional small notes (maintainer here)

> In a similar sense, why should enterprises trust OpenZiti?

you don't have to. It's open source - so you go look at all the code and judge for yourself but perhaps better than that (well different anyway) is that OpenZiti allows you to use your own PKI for identities if youlike. With third-party CA support, you can make your own key/cert and deploy them to identities if you desire. https://openziti.io/docs/learn/core-concepts/pki/#third-part...

> If services do not use e2ee

with OpenZiti you basically get this by default between OpenZiti clients. (once offloaded from the OpenZiti overlay, it's up to the underlying transport protocol)

OpenZiti maintainer here if anyone has any questions.

The post demonstrates how to build a very simplistic ssh client using the Golang standard library and the golang.org/x/crypto extended packages. After that, it demonstrates how to remove the IP-based underlay connection with an OpenZiti net.Conn to create a zero trust ssh client - zssh.

The full zssh project is availalbe on GitHub at https://github.com/openziti-test-kitchen/zssh (I work on the OpenZiti project and support zssh among other things)

I poked at it a bit but there was no free trial period. I know a bunch of people are using OpenZiti and zrok for Jupyter notebooks in general... Here's a blog I saw not long back that might help but I wasn't able to prove/test/try it... (sorry)

https://www.pogs.cafe/software/tunneling-sagemaker-kaggle

I don't actually know. I'll go poke with Runpod for a few and see :)

Interesting idea. I'm not very well-versed in training models or LLMs or even Jupyter Notebooks, but the comment about port forwarding SSH caught my eye since I work on a free, open source zero-trust overlay network (OpenZiti). I tried to find some information about moonglow under the hood / how it worked but didn't succeed.

If you're interested, you might find embedding OpenZiti into Moonglow a pretty compelling alternative to port forwarding and it might open even crazier ideas once your connectivitiy is embedded into the app. You can find the cheapest compute for people and just connect them to that cheapest compute using your extension... Might be interesting? Anyway, I'd be happy to discuss some time if that sounds neat... Until then, good luck with your launch!

OpenZiti maintainer (zrok sometimes). It depends on your definitions of peer to peer. the private sharing functionality is peer-to-peer at the application level using a zero trust tunnel, but it'll ride through/over the openziti overlay network (the zero trust part).

If you use the public sharing option, it's definitely "just" a reverse proxy back to your share location without the need to open a firewall hole in your home network. Super useful for plenty of tasks and there are numerous offerings like this.

You can self-host everything yourself if you like or you can use the NaaS version provided by NetFoundry. We operate the zrok/openziti overlay for you in that case. To self-host you would need an openziti overlay network, a zrok controller and zrok front end. It's pretty easy (well, easy for me maybe) overall. People are starting to self-host more and more zrok instances. The software is all strictly opensource and a liberal apache v2 license. You can find them on github:

* https://github.com/openziti/ziti/ * https://github.com/openziti/zrok

If you (or anyone) appreciate free, open source tooling like this, don't forget to give the projects a star on github and help spread the word! :)

Very neat. Lots of similar tools listed on https://github.com/anderspitman/awesome-tunneling. Seems similar to zrok.io, ngrok, cloudflare tunnels, tailscale funnels and zrok although you're using http/3 explicitly.

Personally I work on two similar projects you might want to check out: zrok and OpenZiti. Similar projects, but zrok is closest to what you did here.

Yes it's very similar to ngrok or to tailscale funnels or to cloudflare tunnels because it's a SaaS offering that someone (my employer in this case) hosts for free for the world to use... However zrok is also self-hostable and yes you can set it up in daemon mode. Right now setting it up for more than one thing in daemon mode (referred to as zrok front door https://docs.zrok.io/docs/guides/frontdoor/) isn't quite as ergonomic as we would like (doable, just takes a wee bit more effort right now, you can read a post about it on our forum where someone did just that https://openziti.discourse.group/t/zrok-how-do-i-run-multipl...)

It won't timeout if you run it as a service in this way.

"better"? I mean that's up to you. It's quite similar that's for sure, doing largely the same sort of thing but it all depends on how you use it.

zrok is fully open source and fully self-hostable, that's probably the biggest difference? other than that I suppose it depends on your use case and what you like better. zrok has some interesting features with its caddy support, with drives, with zrok front door.

I don't have a full and complete list of similarities and differences but those are a few that come up that might differentiate it. I work on the OpenZiti project (the project zrok is built on/around) so I'm only adjacent to zrok (I use it more than develop it) and I've not done anything other than read the funnels docs for a few minutes :) If you're experienced with funnels thoguh, I'd be interested in what you thought when you tried zrok.

Play Minecraft with friends without needing to open a hole in your firewall and for free. All open source too.

It might be more similar to zrok's caddy integration where you can get "fancier" than just delivering files? Blot is trying to do different stuff than zrok is it seems. Like, it's processing markdown, zrok doesn't try to do that for example. zrok is more about sharing easily. blot doesn't appear to be open source from what i can tell and it's not self-hostable as far as I can tell. seems pretty different overall. I'm not exactly sure what blot is trying to do/be.

Go really does have a great standard library and the abstractions/interfaces/structs in place are perfect for SDKs providing zero trust connectivity like those found in OpenZiti (or zrok)

I will stay with Bitwarden too, but it does look nice. I appreciate the design look/feel.

I put a PR up for zrok... :)

https://github.com/anderspitman/awesome-tunneling/pull/82

Yes that's exactly correct. The underpinning of zrok is an OpenZiti overlay network. That network relies on a fabric of routers all meshed together. (self hosters would probably have _one_ router, but you get the point).

Both ends attach to the overlay, then the overlay mesh fabric is responsible for getting traffic from one place to the other securely in a zero trust way (you can read about OpenZiti if you want but I think you 'get it' already, but let us know if you have other questions)

I said somewhere else in the comments I was working with a fella and he shared his vault instance with me via ngrok (zrok didn't exist at the time). So ngrok/zrok are great, dev-focused tools (p2p). (zrok might grow past being a great dev/p2p-focused tool too)

For what you're describing, the OpenZiti overlay might be more your ball of wax. It's a bit more complex than just "share" this and "access" that so there's more to learn (which is why ngrok/zrok are so nice, they are *EASY* to use) but you might find value in the tech that is under zrok, that OpenZiti overlay

We keep working on actual benchmarking but it's somewhat tricky to get reliable numbers... We're working on it now. Sometimes it's 'favorable' sometimes it's not. That's kind of a non-committal answer from me, but that's the best I've got for you at this time.

I'd expect wireguard to often be faster due to its protocol/implementation. I've seen people complain about wireguard if you don't set the MTU. Maybe you'll try them both out and blog about it??? :) (that'd be pretty cool regardless of the outcome tbh).

What I usually tell people, is that I use OpenZiti/zrok all the time. As a human, I don't even notice it. Sorry we don't have better details at this time but hopefully that a reasonable answer

There's always a "root" of trust somewhere/somehow. Ideally it's a human that you trust. In the case of zrok, it uses a secure zero trust overlay provided by openziti. you "enabling" zrok in your shell is that root of trust. you get a x509 certificate which is then used to attach to the zero trust overlay. On the other side when you "zrok access" you provide a unique token that has been shared with you by someone you trust (presumably). So you, as the person doing the sharing are the real "root" of the trust. You're trusting that zrok isn't compromised and that the certificate that is returned to you from the overlay is trustworthy etc. I could go on - but that's hopefully enough of an overview