oncensher

Yeah, I didn't mean to downplay how hard it is to apply the utilitarian calculus or even to suppose that the bare doctrine of utilitarianism resolves questions about what the ultimate good we should be trying to maximize is. I basically agree that utilitarianism is not a complete recipe for how to live. I just think that it probably gives the correct answer in cases where we can see clearly how to apply it because I'm skeptical of theories like Anscombe's. Which is to say that utilitarianism is a big tent.

Now if we look at EA, the basic tenet of EA seems obvious -- basically just utilitarianism. And from what I've seen, in practice also, EA is a pretty big tent. I don't know the specifics of SBF's case, but I think essentially no one thinks that he acted correctly. I don't know how many mosquito nets he bought, but I agree that if he bought enough, it might be that he net raised utility, and if that is so, it's something to be thankful for. But it doesn't make him some kind of utilitarian saint unless he couldn't have done even more good by some other course of action that wouldn't have hurt the ponzi scheme victims and brought opprobrium on the whole EA movement

The "global stop order" is just generally perceived as an impossible coordination problem. So instead we see a mix of labs voluntarily putting in guardrails and regulatory efforts (which are not only aimed at hypothetical super-AIs of the future). Of course labs are also in a competitive race. And I actually think that it does make sense that the richest companies in the most dominant positions would in a better position to worry about safety than a startup that is just trying to survive at all. And just in general, it seems reasonable that the fewer companies have access to dangerous tech the better. This isn't really about some highly speculative future tech either -- current models already pose lots of risks, and the pace of model improvement is something wildly unprecedented. Whether or not you call it ASI, the capabilities we will have two years from now are hard to even imagine properly. Also, I don't think the issues that you are highlighting are all ones that Anthropic would dismiss as second-tier. In particular, mass unemployment from AI is how we will deal with a massive devaluation of human labor is one of the most serious concerns. And about other issues, reasonable people may differ. I'm more worried about biorisk than environmental damage, for example, but clearly we should be keeping an eye on both. Serious risks and problems, just because they aren't already harming people today, are not just a distraction.

The original topic was Anthropic's guardrails, which were meant in part to stop China from using Anthropic's models to bootstrap their own. I take it the logic of the comment was that pulling attention to Anthropic's stance on regulation is switching to the topic. But for what it's worth, I also think that people are way to quick to assume that strong regulations would only help China and thereby hurt safety. There are many reasons why the opposite may be true: - reducing demand for Chinese models reduces the incentive for Chinese companies to make them - if US companies can't use Chinese models, they won't have an incentive to help their development - China may enact similar regulations if the US leads, either out of concern for US safety or for commercial reasons

Also, I think some similar things can be said about AI safety measures in China aside from regulation. Currently, the US leads in model safeguards, but it isn't like China has zero interest in AI safety. Even if the US and China are rivals, there are many points of common interest (biorisk and "sci-fi" scenarios like an AI takeover, to name just two).

I think depending on how much integration you want, either option 1 or treating the multiple applications as a single application that can do multiple things could be good options. Also, option 2 could still avoid having to worry about your auth service going down or rate limiting you. And you could avoid JWT headaches.

Perhaps there is also an option 4, which is option 1 plus a shared user information database for things like Stripe account, profile picture, etc. That is more complex obviously, but it would still solve the issues I had with WorkOS. In particular, I think it would mostly solve "syncing external auth provider state with your user state is a bug center." In particular, the awkwardness around sequencing of account creation and deletion would largely go away because that would be managed as in 1, and the extra shared information would be just that. (But maybe you would want to delete it if the user deletes all their accounts?) And you wouldn't be forced to use webhooks to get updates to shared user state. You could put it in a shared Convex database, for instance, or use some other solution of your choosing.

Had a similar journey recently. Started with Stack Auth, found it unusable in production due to extremely hard rate limits and bad performance even when not rate limited. Switched to WorkOS AuthKit, which works much better and supports useful enterprise features. But inclined to BetterAuth for new projects.

- Syncing external auth provider state with your user state is a bug center. It helps to keep as little state as possible in the auth provider, but there is still some. - Refreshing JWT access tokens every few minutes is another bug center and honestly there is no need to do this if you control your own auth. - WorkOS does not have a complete API. It is built on the assumption that you have one product per billing account and a fixed number of environments (staging, production, and they can give you another one if you ask support). You have to whitelist redirect and other URLs in the dashboard, and there doesn't seem to be an easy way for agents to do it.

Outsourcing auth does not make much sense IMO. The less you can split your state over multiple services the fewer problems you will have. Sometimes it is inevitable, like for payments, or if you need specialized databases for performance reasons. But for auth there is really no good reason if good libraries are available. To people who say that using a service will help you get started faster, none of the problems I hit with auth services had to do with having high scale -- most of them hit before I even launched.

I found that agents can already figure out how to do everything in CloudFlare as long as they have an API token with the right privileges. They are smart enough to figure out how to use the API. But the friction spot is that I need to make the API token by hand and basically add permission to do everything they might ever need to do. It would be nice to have a smoother way to handle the permissions so I can let them do everything they need to do frequently without asking for permission yet still make it easy to approve actions that are only needed occasionally, without having to guess in advance which permissions fall into which category