I have an immediate complete distrust to anything that throws around so many buzzwords. This is the github page and I still don't understand what it even does, specifically.
replies(2):
Literally every single word of it
Buzzwords can still be technically accurate and you seem to be ignoring that when it keeps being confronted. “But it is” doesn’t matter when it comes to “but it sounds like”.
Let me give you an example; if I was walk into a store, do you think I want to talk to the person who talks about the “bidirectional optoelectromechanical document transcription and reproduction apparatus implementing discrete photonic acquisition and microdeposition techniques for bidimensional substrate encoding”, or do I want to talk to the person who will sell me a “photocopier”?
"This software let's you set up peer to peer networking between your devices, expose them to the internet, run applications on them, view useful runtime information, and integrate easily with cloud providers and infrastructure you're familiar with."
Thus, those people coming across your project may quickly overlook it instead of giving it a chance which is disappointing.
By contrast, here is Tailscales tagline: "Fast, seamless device connectivity — no hardware, no firewall rules, no wasted time."
That kind of tells even a non-technical user what it is for even if it dumbs down all it can do. That user then doesn't need to know any technical jargon or how it works under the hood or even what wireguard is at all. The tagline is what prompts them to install and try it out and from there the UX is the deciding factor in whether they keep using it or not.
I understand it may not be easy to narrow down the explanation, especially if you invested a lot of time and don't want to do a disservice to yourself by underselling it. Looking at the Tailscale tagline I quoted, it is small and ambiguous enough that it works marketing wise, regardless of all the features and solutions they offer. But it was just an example, I should maybe have used a totally different example of a product that is not in the same realm as yours.
The explanation you gave to me here is good but only because I vaguely know what all this jargon means. Try to think of a short simple sentence that a non-expert could understand.
I don't trust this.
“Octelium is a full-featured access control platform, which provides API gateways and/or VPN tunnels to your HTTP services, paired with an intuitive user, policy, and auditing backplane and policy-as-code.”
Something like the above would be much more enticing to potential users including myself. I can get a rough idea of what I can actually use it for and how it can be integrated into my existing stack—and if there are more features I’ll be pleasantly surprised when I read the docs!
- "remote access" : https://www.pomerium.com/docs/capabilities/kubernetes-access
- "access control" https://www.pomerium.com/docs/capabilities/authorization
- "visibility and auditing" : https://www.pomerium.com/docs/capabilities/audit-logs
- "user and identtiy management" https://www.pomerium.com/docs/capabilities/authentication to which I'd add device identity as well.
- "centralized policy management": https://www.pomerium.com/docs/capabilities/authorization & https://www.pomerium.com/docs/internals/ppl
- deployments using Ingress Controller or GatewayAPI https://www.pomerium.com/docs/deploy/k8s/ingress, https://www.pomerium.com/docs/deploy/k8s/gateway-api
- "for an arbitrary number of resources" not sure what to link to but there's no limit here
Congrats on the release. I saw your thread on MCP and completely agree with the approach. Happy to trade notes :)
For example, many organizations use a mix of gated HTTP over public internet AND VPN, each one will have its own vendor auth product(s), user whitelisting, it's difficult to control or regularly audit. Octelium centralizes this management and gives admins the flexibility to control how services are exposed and to whom, presumably via simple policy change git commits. SOC2, etc. then becomes a breeze to export the state of the world, onboard/offboard employees, etc.
Defining the product in terms of use cases/problems/solutions rather that competing alternatives (Tailscale, Okta, ORY Hydra, etc.) will go a long way to increase clarity.
> Funnily enough, Octelium started as a sidecar ext_authz svc for Envoy instances to operate as an IaP but I ended up creating my own Golang-based IaP, Vigil, from scratch because Envoy was just nothing but pain outside HTTP-based resources.
That's really funny... we went the opposite direction as the original versions were based on a custom Go proxy. Of course there are tradeoffs either way. Envoy is blazing fast, and does great with HTTP naturally, but has a giant configuration surface area (both pro and con), but we are now having to write some pretty low level filters /protocol capabilities in envoy for the other protocols we support (SSH, MCP, and so on) in C++ which does not spark joy. So I totally feel what you are saying.
Thanks for the kind words, though I am one of the contributors my colleague did the heavy lifting on the WebAuthN side.
Genuinely happy to see the release and where you are headed on the AI/MCP side. If you (or others) are interested, I am trying to bring more light to this model in the spec if you (or others) would like to weigh in: https://github.com/modelcontextprotocol/modelcontextprotocol...
I like where you are going with the graphics in the readme; I'd spend some effort on creating "intended usecase" scenarios, scenarios that highlight situations where the project is the perfect fit. Using a few of these to highlight very different applications give people a good mental map of where this project would fit well for them.
"John is looking for a way to provide access to an internal tool to work-from-home colleagues. This isn't simple to do because [...]. Octelium is a good fit because [...]. Here is how John would set it up: [...]"
The problem isn't that you need to “make it easier to understand for business people” (which many here would take as an offense), the problem is that you're name dropping technologies and concepts without articulating exactly what problem your product solves, and what your exact value proposition is.
Something that does everything usually does nothing well, or at least doesn't provide a coherent dev experience with a sane mental model.
I share some (very little) from some of the criticism regarding the clarity, but I disagree you need a tagine like Tailscale while your solution does several times more things.
Great product, im chewing through the docs already :)
API gateway, MCP, Oauth, VPN --> not buzzwords
The defining characteristics of buzzword are that is very broad, promises "pie-in-the-sky", and almost universally under-delivered by every vendor while incurring very steep costs. In other words, the reason "zero-trust" scares people is because they have probably been burned N times but Oracle, Okta, etc. etc. incurring large costs to achieve underwhelming/non-functioning results, often times paying $$$ to solve imagined infinity-scale problems that don't even apply to the current org size, or even 10x the size.
API gateways, MCP, VPNs are tangible things that fill fairly mundane roles, it is not hard to envision how they can be used to solve real-world properties. I can easily envision dropping an "API gateway" in front of "MCP" in my stack. ZTNA however I cannot just sprinkle on my stack as if it were magic pixie dust...
It doesn't mean that ZTNA should be outright banned everywhere, but when you do use it, you need very careful to define an exact meaning expressed in terms of non-buzzword components.
Rather one could argue they are technical jargon? But then if the technical jargon is over someone's head, maybe they are not the target audience.
I understood most of it, but it is quite dense for the first paragraph.