I feel like there's a fundamental shift in the user interface that's causing this. People are starting to expect an "agentic interface" - that they are able to give kinda vague inputs and nudge things to work in a way they like, over the traditional experience of having increased clarity at the cost of increased setup (drag and drop, many UI first interfaces, etc).
I was editing a google doc yesterday and found it annoying that i had to find the "link" option from the context menu instead of just saying "turn links into links" and moving on.
This imo impacts everyone, regardless of how developer-ey you are. Perhaps non-devs expect a "friendlier"/more "agentic" interface now? Don't have the right vocabulary to explain.
Yep, most modern workflow and agent builders now support editing via natural language. Mastra even has an agent that helps you build other agents. An agent-builder agent, if you will.
If you're willing to take the pain of setting up an actual authz model, I've found OpenFGA^ to be really nice. We used it to set up some pretty complex authz involving cross-agent/user/org creation and sharing of data. It's not _simple_, but it is effective.
Thank you. This is very interesting. I'm excited to see an open source project adopt a zanzibar-oriented approach to resource management. This is exciting!
Just before I hurl myself at this for several days/weeks -- where were the pain points? I'm usually wary of new projects in this space but OpenFGA looks pretty mature already
The main pain points around using a Zanzibar-like approach (typically called Relationship-based access control) are:
(1) The need to write relationships and keep them updated in the permissions database. Often, this requires writing to both the application database and the permissions database, at the same time. On the SpiceDB side, we provide a Postgres FDW [1] to make this easy IF your application data lives in Postgres
(2) Representing complex permissions in ReBAC schema can be a challenge (at first) if you're coming from an ABAC system - you need a slightly different mental model for ReBAC, where (as its name implies), permissions are reachable via the relationships between objects, rather than attributes on objects.
(3) ACL-aware searching: this is a very hard problem in authz in general and gets slightly harder with ReBAC.
The separation of the search index and the permissions database makes it harder to integrate and computing permissions, at scale, is incredibly complex. For SpiceDB, we have Materialize to help solve this problem [2].
I really want to love KeyCloak. I've had really bad experiences with weird uptime bugs and crash loops that kept me from giving it an honest retry over the last couple years.
It also really shows its age, imo. The interface is clunky, roles and groups having overlapping responsibilities is confusing, making custom UIs for it makes me feel ancient, etc.
I really can't complain though. There is simply no alternative that's as open atm. It's also not easy to make one ( I tried :( ).
Showing its age is also a pretty significant plus, for such a critical part of one's infrastructure. That means it's been beat up on and run through the ringer for a decade plus at this point and had lots of chances to fix CVEs and other bugs. Not to say there won't be more, but being older and time-proven for an IdP is a major positive.
Keycloak and Better Auth aren't as fundamentally different as you may think! Better auth supports authn/z, being an identity _source_, being an identity provider, being an OIDC/SSO provider (so others can login using better auth), rbac, SAML/SCIM, and a ton more. It's actually really powerful! Most folks found better auth as an alternative to next-auth/auth.js - but better auth does a lot more than those.
This seems to be focused on Python, but for all the TS devs out there, what you'll see will be implicit `any` errors. Quick word of warning on having LLMs fix those - they love to use explicit `any`s or perform `as any` casts. This makes the lint error disappear, but keeps the actual logic bug in the code.
Even if you ask it not to use any at all, it'll cast the type to `unknown` and "narrow" it by performing checks. The problem is that this may be syntactically correct but completely meaningless, since it'll narrow it down to a type that doesn't exist.
The biggest problem here is that all of these are valid code patterns, but LLMs tend to abuse them more than using it correctly.
Default linting in quasarsjs doesn't like unnecessary casts, or using 'any' types - AI generally then fixes it...in varying degrees of effectiveness - sometimes properly, sometimes with horrific type abominations.
There's an easy shortcut in the second level past the climb on the pink pipe and before you climb the ramp where you can jump to the semi-circle on the lower platform on the other side. Love it!
This section in particular piques my interest. I never found this confusing, since the change in HEAD is just representative of the order of operations (in rebase, you are setting the current commits "on top" of the commit you are rebasing onto, etc). This feels like what is confusing isn't really HEAD itself, it's a fundamental understanding of the git model?
I feel like folks using git without understanding the basics of what it does is what leads people astray? If so, why isn't this part of our basic training as engineers who use git?
I was editing a google doc yesterday and found it annoying that i had to find the "link" option from the context menu instead of just saying "turn links into links" and moving on.
This imo impacts everyone, regardless of how developer-ey you are. Perhaps non-devs expect a "friendlier"/more "agentic" interface now? Don't have the right vocabulary to explain.