gemanor

Gabriel from Permit.io here

Actually, Permit does support OPA. In fact, about 15% of our large customers came from StyraDAS and use Permit as their enterprise OPA solution.

On top of that, we offer OPAL+, which is already adopted by Fortune 100 companies as a production-grade OPA framework.

You answer is just about a discussion we had yesterday about the race between 'let build a standard that will allow the LLM to get programmatic decisions' and 'let build something that works'

Most of the standard and implementation is focused in the vision of models and clients that automatically handle the tool overhead, while in reality everything that is related to MCP requires tons of boilerplate/middleware/garbage code.

AI will not replace developers, it will just push them to use Python..

Gabriel, the post writer here.

First, thanks for sharing it mooreds :)

A lively discussion was created about the topic on Reddit, and I'll be happy to get the HN thought too about:

1. Security consideration when choosing BEaaS stack.

2. Does RBAC/ReBAC more error prone and hard to implement than RLS?

3. Where devs should put their authz enforcement

Good point indeed

During our work in the Policy as Code open source project OPAL, we discovered that AdTech is one of the most complex industries to implement fine-grained authorization. In this article, we will be sharing how Reddit developed their own authorization system for Ads using OSS and advanced policy engines.

In the debate between policy as code and policy as graph, Reddit chose a unique approach. They used OPA (code) as a model and a centralized (Zanzibar) service.

Writing JS/TS for browsers and backend applications is an entirely different skill. The only similarities are syntax. From the organization's perspective, the developer's primary expertise is a platform/framework, not a language syntax.

The point of the article is right for the indie developer who wants to stick with one language as a "mother language" and be able to produce any kind of software in no time. For scale, it is not the case.

I'm a big fan of JS/TS, but there are absolutely significantly better choices for many backend applications.

1.. 2.. 3.. Balenciaga

Is it in-house project of anthropic or more like partnership?

In 2021, when Permit.io launched, we anchored our authorization framework on Policy as Code with a specific focus on OPA/Rego. We believed, and still do, that Policy as Code approach is key to scalable authorization.

While policy engines solve the challenge of decoupling policy and code, the challenge of scaling them and loading them with the right policy and data remains strong - especially for event driven systems.

We reviewed how Netlfix used OPA with a a replication pattern; and decided to create a similar yet more extensible and event-driven solution - and so OPAL (Open Policy Administration Layer) was born - creating a scalable, zero-trust way to manage policy engines and their policy/data at scale.

Fast forward two years, and the landscape has evolved. New policies as code languages and standards have emerged (Cedar, OpenFGA, etc.), and in this evolving market, OPAL has positioned itself as a leading solution for synchronizing policy as code with policy data, particularly for self-hosted environments.

What truly differentiates OPAL from other solutions like Topaz and Permify is its flexibility. OPAL is not limited to a single policy engine; it supports a variety, making it a versatile tool for authorization applications. Using a single Helm chart or Dockerfile, one can deploy a full-fledged authorization system, customized to specific policy models, languages, and engines.

As we look to the future, we're keen to gather insights from the HackerNews community. What features would you like to see in OPAL? How can we make it more robust and efficient for your authorization needs?

We value your feedback and are excited to see how your suggestions can shape OPAL's roadmap.

P.S. As with any open-source project, your support on GitHub, especially stars, helps us a lot. Thanks in advance for your backing!

Can't agree more with your statement. Yet, the way this guy sells his company by playing an unfair game did not convince me and actually do the opposite..

Recent research conducted by Styra¹ (creators of OPA² and the Rego policy language) has revealed that policy as code (PaC) has become a critical component of the cloud-native development landscape. Nowadays, developers are utilizing PaC for every authorization vector, including developers, infrastructure, admissions, services, and applications. Moreover, new policy languages have emerged that are specific to vectors, such as Cedar³ for applications, or to particular use cases, like OpenFGA⁴ for Google Zanzibar style authorization.

OPAL is a tool that enables developers to deploy a comprehensive authorization infrastructure that automatically synchronizes configuration and data. With OPAL, developers can roll out scalable PaC-based architectures in seconds⁵.

As one of the maintainers, I would be grateful for your open-source support (stars, issues, and comments) and am eager to hear your opinions on the state of policy as code.

¹ - https://www.styra.com/press/policy-as-code-now-vital-to-clou... ² - https://openpolicyagent.org ³ - https://www.cedarpolicy.com/ ⁴ - https://openfga.dev/ ⁵ - https://www.permit.io/blog/scaling-authorization-with-cedar-...

Well, coding-wise, it's the same skill. There are components, UI logic, business logic, etc. For these practices, I would start with Swift/React native as the easiest overhead on top of standard web development.

The time-consuming tasks for newcomers are the platform-related tasks. Bugs and issues unique to iOS, find the proper IDE (incl. build-tools, etc.), everything related to assets (pictures, video, splash screens, etc.), submit to the store, build the CI/CD that fits native apps, etc.

The most important mindset, IMO, is to remember these facts and never investigate/stuck too much with these new fields, even paying some $$ for automation that could help you with the time it is consuming. Also, managing your time for the balancing between tedious new tasks and new enjoyable learning can help with getting things done.

That was precisely my thoughts before the launch, but I was surprised by the results. It is not a real thing to launch a startup, but super cool as another marketing tool.

He is talking about the after success phase, so maybe worth to listen to adjust the success willings

Correct

> I'm not clear on how you actually do that with OPA The sharding is managed from the OPAL control plane, when you configure the data sources you also configure the way the sharding works.

> ensure consistency in your application since hydrating the cache is asynchronous. OPAL use eventual consistency for cache reliability, you can know that data has changed, even before you know what changed.

> And then you start to think about caching, data consistency, and so on

If you are looking at OPA or Cedar as a standalone engine, this is the correct assumption. To avoid this hassle, there is an open-source tool called OPAL[1] that will let you run the policy engines with all the sync work without any investment in custom solutions. OPAL has a ready mechanism for data fetching and synchronization, so you can plug it into your application's data and not worry about the data.

Disclaimer: I'm one of the OPA maintainers.

[1] https://github.com/permitio/opal

Data filtering implementation has different approaches among the mentioned policy engine. For OPA, custom Rego code could return the allowed data, and the caching mechanism will ensure its consistency and reliability. For Zanzibar, since the policy derived from the data relations, data filtering is using is an internal part of the paper. I recommend the following article for more information about policy as code and policy as data to understand the context better - https://www.permit.io/blog/zanzibar-vs-opa

Sure, if you need 10ms rate, just spin up another instances. I personally prefer cloud product with lies here and there than pay so much.

IMO the main problem is the ecosystem around Salesforce. If you are the end user it is (not) ok to have latency lies, but you'll be the only one who feel it. If you aim to other developers build services on top of your product, your latency issues has exponential effect for them.

Thanks, these are good points. I think we even could "fetch" the positive facts of their writing and combine it with the real features/facts of our product for this response blog post.

Their post isn't such dirty. They just compared all the competitors in the market and consistently ranked all in 6-9 and us in 1-2. All that, by saying we have lower quality UI (not correct, objectively by our customers) and many missing features (not missing and listed explicitly on our website). We also (as all the players) do a x vs y posts, but we never thought to lie regarding others. Do you think we should actively distribute those response posts?

With the more and more sales automations and LLMs this sequence going cheaper to build. Luckily more and more organizations are moving to bottom-up and PLG models that make it less noisy to the customer.

Seems like this is the correct link https://docs.permit.io/foaz/overview

As usual, the real owner of the internet is Google :)

In authentication, we usually look for the following factors to verify the user identity `something I know, something I have, something I am.` In passkey, theoretically, you verify all the factors at once. This user has the phone, and the biometrics said, `something I have.` The `something I know` was verified once to create a continuous of the other factors. If you lose your phone, you need to find an alternative way to verify the other factors, which can be done by various methods that each authentication provider has.

I haven't had such downtime for the last couple of years (working on early-stage startups) but I'd really like them back in the corporate for personal growth as a developer in three ways:

1. Create a new side project unrelated to work, such as a tool or library I always wanted to create.

2. Learning a new stack/domain by creating a product with it. This way, I got proficient in Go language back then.

3. Look around in the corporate and see what I can hack myself for personal growth, AKA intrapreneurship. For example, I went to a CTO office of a sibling organization and asked them if they wanted to do a PoC together with our organization on something new.

If I had such time now, I would look around for a problem in my product/life that I can solve with LLM and try to create a PoC of an LLM product (maybe with a creative UI) that will teach me a lot and maybe get some users.

On the other hand, if you want as a goal to get a position in a FAANG-style company, this is a great time to do a leetcode learning path and get ready for interviews for such jobs.

1... 2... 3... a new startup founded to memorialize the last IP of beloved ones who passed away.

People are in the middle of a series, so they subscribe after the crackdown and promise themselves to cancel after they finish. If I were Netflix, I would create a "but in the crackdown" every couple of month so people will share password and then get another spike again :)