michaelquigley

This happens in the OpenZiti layer for mcp-gateway. The overlay has strong identity and end-to-end encryption. So by simply wrapping any standard MCP server with mcp-gateway, you've got all of that and more, without having to change your implementation.

I'm the lead developer of zrok. I've also had a habit of building static site generators over the years. Might be an interesting little crossover possibility.

There's a bunch of zrok stuff in the pipeline that's way more important to get to first... but maybe down the line we can support some kind of extension mechanism in zrok and static site generators could just sort of snap right in...

Stuff to think about anyway.

Excellent idea! Sounds like a great addition in an upcoming release. I'll add a backlog card to explore that concept a little...

Update:

https://github.com/openziti/zrok/issues/394

zrok is an open-source peer-to-peer sharing platform for network services, files, websites, and other resources. zrok is built on top of the OpenZiti overlay network. It's fully self-hostable and designed to be extended. No gotchas or paid-only features.

I've got a couple of big announcements that I'd like to share...

First, the service instance at zrok.io is now in public beta. We've been running a private beta since March. If you want to start working with zrok and aren't ready to self-host, you can easily and quickly get an account with zrok.io and start experimenting right away.

Second, since our last post here we've added full tunneling support to zrok. In addition to sharing HTTP-based resources, you can now share your raw TCP and UDP network endpoints using zrok.

Lots of other powerful stuff is coming in the next couple months. Check out the link for more details!

> Would this be useful for adding document sharing to applications I write, for instance, a hypothetical word processor? I mean sharing with other people working on a document. The SDKs seem to be clients, so to interchange files between two applications with an embedded SDK, does it still need a third machine running an API server?

We could certainly incorporate an "embeddable" SDK so that zrok can be incorporated into other applications.

As it currently stands, you would need access to a zrok "service instance" ("cloud"), running the zrok controller (providing API access). But we could certainly look at other kinds of use cases where that control plane is potentially enabled ephemerally or on-demand. I have some ideas for things we might be able to do.

Neither of these are on the immediate roadmap. But if people ask for them, we could certainly build them.