aisrael

(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.

This is really great way of putting it. Node/Python/Go were the obvious alternatives for us.

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.

Author here - yeah, that's how I feel about it, at least for startups specifically.

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.

[0] https://www.propelauth.com

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.

[1] Disclaimer, I’m a founder of PropelAuth

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.

[0] https://news.ycombinator.com/item?id=30700770

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!

Email andrew [at] propelauth.com or apply here https://www.ycombinator.com/companies/propelauth/jobs

Congrats!

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!

Email andrew [at] propelauth.com or apply here https://www.ycombinator.com/companies/propelauth/jobs

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.

Thank you!

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.

I wrote about the differences between us and ORY Kratos here: https://news.ycombinator.com/item?id=30702430 Happy to chat anytime, if you want, my email is in my bio.

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.

What would your ideal experience there be?

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.

Thanks, appreciate it!

Our main differentiator today is a much quicker time to go live - which usually boils down to us providing more hosted UIs out of the box, guides focused on B2B use cases, and libraries that are more centered around organizations.

Anecdotally, pretty much every startup we talked to that tried to use Auth0's organizations either stopped pretty quickly or ripped it out due to API slowness.

If you've used their org support, I'd love to chat to hear more

Appreciate it! PropelAuth's authentication is powered by PropelAuth which is definitely confusing sometimes. I try and think of them as two different services (APIs/hosted pages as one service and an internal configuration service as the other) which helps me.

The plus side is everything we build for ourselves we can release to customers.

Thank you, we're excited to hear any feedback you have as we grow!

Your landing page is really clean, I like it!

It's always fun to hear the workarounds people do to avoid adding orgs/teams - my personal favorite is the single account everyone share a password case :)

Happy to chat anytime - my emails in my profile!

Thanks! Generalizing it is something that we think a lot about. There's a lot of value in providing something simple like RBAC with a few roles, until you need something more custom.

I personally think that the ability to opt into more complexity is really interesting. Starting with a basic set of roles within a single organization is appealing when you are small, and then importantly having the ability to layer in groups or layer in scopes/actions associated with those roles.

Thanks! SAML and SCIM are both on our short-term roadmap and are really important. We want to implement it such that the code you write for supporting orgs today works regardless of the type of integration - and then the differences would primarily be the experience for your end-users.

There's a one to many mapping from users to organizations. We can also support users that don't have organizations. What types of configurations would you want?