(author here) That's a good question, I should've explained it better.
Technically, the other property of a puzzle is that there's exactly one good move. If you have one move that can mate in 3 and another move that can mate in 4, it's actually not a puzzle by the strict definition of the term. So, the reason I set the depth to 10 was because I'm actually looking for the second best move to be bad/losing.
For real positions, 10 might honestly be too low to confidentially state that every other move is bad, but for mate in 3 it was a good enough and still performed well.
To me, the language agnostic answer to reducing tech debt is having a good test suite so refactoring is easier. We're pretty good on that front.
We have definitely done large refactors before, and I'm sure we'll have more in the future, but I don't think we need a major rewrite or anything like that.
That's fair, I was definitely being a bit too general. There's another comment in this thread that summarizes it better which is asking "what would I use if Rust didn't exist?" and I think that's a more clear line. All of my embedded work was in C/asm so Rust is actually a great choice there.
This is actually something we’re working on at PropelAuth[0]. Our general philosophy is that most SP’s don’t want to deal SAML and would prefer to just have their users manage their own org membership - whether that’s via SAML, invitations, etc.
We haven’t built an API for it though, instead opting for a UI that walks the end-user through the steps of integrating with their IDP. That’s partially because every IDP is so different that we felt you really need a UI to show exactly what to do.
The SAML world is definitely a fun mess. We’re[1] building out SAML support and are beta testing it with a few customers and it is funny how different even the large IDPs are. Add in things like needing to test the integration, making sure attribute and role mappings are correct, and it’s unfortunate but understandable that companies not specializing in auth wouldn’t want to deal with it except for customers that pay a lot.
Thanks! I’m the founder of PropelAuth - our focus is providing user authentication for b2b businesses. We did a launch HN[0] a while back if you want to read more about us.
PropelAuth | Founding engineers | Remote (US) | https://www.propelauth.com
We are a dev tools company that provides useful APIs/tooling for B2B startups, starting with easy to use abstractions on top of complex authentication + authorization.
Our tech stack includes: Rust, Typescript, React, Postgres, Python, and Pulumi. We also build client libraries that support additional languages.
We just finished YC (W22), raised a seed round, and are looking to make our first few hires. It's a great time to have a really big impact!
We are a dev tools company that provides useful APIs/tooling for B2B startups, starting with easy to use abstractions on top of complex authentication + authorization.
Our tech stack includes: Rust, Typescript, React, Postgres, Python, and Pulumi. We also build client libraries that support additional languages.
We just finished YC (W22), raised a seed round, and are looking to make our first few hires. It's a great time to have a really big impact!
That makes sense - and is definitely something we'll need to more clearly support. The distinction between the two cases is also pretty clear, thanks for you all your thoughts here!
We had similar feelings about Auth0's org implementation, it doesn't really match the way most companies think about orgs, especially at an early stage.
Not yet, but we have started to get more requests for SMS support. If you'd be interested in an early version of our SMS support, definitely reach out and we can set you up with it.
Appreciate the feedback! We've had people use organizations in both ways, honestly. The implementation is definitely more like a Gmail group of users than a company.
In your example, some people have implemented it as Acme is the organization, and some people have implemented it as specific teams within Acme are an organization.
I suspect we'll need to add a second tier (e.g. a team or a group) underneath a more rigid definition of a company. Would that have made things more clear?
That makes sense, it definitely simplifies things. I like the idea of choosing between "everyone is signing up with their work accounts" and "users can join potentially multiple organizations, work related or otherwise". Thanks for the feedback!
For offboarding, we provide full data dumps of all user + org information - password hashes included. I want people to use us because they want to not because their data is stuck with us.
Ah, sorry about that. The issue is if you try and accept an invite for a different email address than what you are signed in for, it stops you. But, it's definitely a confusing experience when testing since it's really common to create a few test accounts - thankfully it doesn't happen much in prod.
Yup, the short lived tokens are JWTs - wasn't sure how much detail to go into in the description.
For comparing to something like Kratos, probably the best way of putting it is, the first line of the quickstart guide for Kratos is "Ory Kratos has several moving parts and getting everything right from the beginning can be challenging" - and we want to provide the opposite initial experience.
We want there to be an understandable UI for login + team management that you can interact with immediately and quickly configure.
Kratos and Oathkeeper are really cool though, especially when you want to go significantly deeper in tuning things. As we add on more complexity, we want to make sure that that initial experience is still really walk up usable.
I'm glad you find it approachable :) Definitely, WorkOS has more of an enterprise focus which is also important - we are more focused on early stage startups today.
Technically, the other property of a puzzle is that there's exactly one good move. If you have one move that can mate in 3 and another move that can mate in 4, it's actually not a puzzle by the strict definition of the term. So, the reason I set the depth to 10 was because I'm actually looking for the second best move to be bad/losing.
For real positions, 10 might honestly be too low to confidentially state that every other move is bad, but for mate in 3 it was a good enough and still performed well.