wakamoleguy

Looks like a game archive exists here: https://ataraxosai.github.io/

Maybe we’re in violent agreement? In the example of a staging database config, I understand the problem that CI faced, the fix in the PR, and a rough upper limit on the tech debt impact of the connection strings diverging. I have an assumption (not an understanding) about how long it might take to learn about PgBouncer in Neon, and the worst case if it is wrong (CI breaks). Does that qualify as understanding the PR? I couldn’t have authored it by myself with this understanding, because to do so would require me to have learned about PgBouncer to find the fix.

This leans heavily on what "doing your job properly" means. Code quality, understanding, and doing your job properly are not so black-and-white. Your job is probably not to push out flawless code; it's more likely to push out valuable code, that minimizes risk, and appropriately trades off speed and quality (for some appropriate definition of "appropriate").

If parents can't take babies on planes, they'll tend to drive instead, which is much more dangerous overall.

Looks like most of the images are concepts. I wonder if the looks will change before launch? And they do say the cost is only a few k above the gas models. Something to wait and see, I guess.

Speaking of autonomously acquiring resources in the real world, how is proofofcorn.com going? Looking now, it seems like it stalled out several times, and the corn likely never made it to market. Not a great data point for this type of project.

Unfortunately, your behavior is identical to what a reseller would do.

These statistics don't necessarily imply that the programs don't improve the situation, only that mental health outcomes are worsening faster than programs are improving them. The existence of support programs could also encourage more measurement of mental health issues, which says nothing about the ground truth.

On the extreme side, things like blackmail and fraud are generally illegal, even if they can make you money. Most of these dark patterns that "work" tend to follow a similar pattern: by taking advantage of the target, one can extract more money from them.

I would possibly be a terrible salesperson, because these all give me the ick. Your product should provide an offer of genuine value.

In a typical office environment, the correct response to “I don’t have access to this Google Doc” is to ask for access from the person who sent you the link. In another context, it could be fair to think “Hmm, this is some sort of capture the flag challenge, and obtaining access is the point of the assignment.” That assessment separates what we’d consider reasonable from way out of line.

I do wonder what this means for AI agents longer term. In a world where we humans already struggle with truth and misinformation, what happens when you can easily (intentionally or accidentally) spin up a cohort of fanatical believers to pursue any given conspiracy theory?

That's a really good question. This may also end up depending on the level of trust within the team. One thing I didn't call out is that an "optional gate" can still just be checked by sending a DM, like "Hey, do you think I need this check on this project?" So in high trust teams the differences are small.

On lower trust teams, I could see the cycle you mention crop up more. I'm not sure of the answer, but I don't think it is to force everybody through the onerous process out of perceived fairness. Any ideas on how to bring visibility to that failure mode?

There is only zero incentive if the filter detects AI music reliably. It's still a race between effective detection and cost to generate content, isn't it?

> A person reading a suspicious email might notice that the sender’s domain has an extra character, or that something about the request feels off. An AI assistant scanning your inbox for items that need action may not slow down to check those things.

I don't quite buy this in either direction (although they are both couched as possibilities, which makes it a pretty safe statement). Humans might notice, but years of annual mandated phishing trainings has led me to believe that humans as a whole are generally not great at noticing.

AI agents OTOH mostly do as they are prompted. If the human prompting them tells them to check these things, they will likely check much more consistently than any human. If the prompt doesn't say to check, the agent won't. But that again falls back to what the human might or might not think about.

What a strange take. LLMs produce plausibly correct output, which is exactly where plain JavaScript and DOM manipulation will result in a spaghetti mess.

Frameworks like React that add structure to the data flow, component encapsulation, and a huge repertoire of patterns to train on, plus Typescript for immediate compile-time feedback loops… those are what LLMs thrive on.

I disagree. Especially with AI, it’s far too easy to generate and insert an image with no time, energy, or eye for detail.

Authors do it because it supposedly leads to better engagement, shows up bigger on social media, and breaks up the text. But generally, unless the visual content meaningfully adds to the text content, users will largely ignore it.

Thanks! I have been learning about FedCM recently, but I need to read more. My understanding is that it requires the relying party to allowlist which IdPs it trusts, is that correct? That always seemed like it would make it gravitate towards social sign-ins, and harder for self-hosted email domains to participate.

I haven't come across the Email Verification Protocol yet, will take a look! At a glance, the flow seems almost identical to BrowserID. I'm curious how the UX looks.

That’s real, yeah. I also remember a couple concerns around that privacy as well. One being that if your IdP controls your email, they could probably figure out what sites your communicating with anyways. And perhaps a timing issue with when relying parties fetch the public key to verify assertions?

For bespoke projects, a lot of the privacy concerns go away once I’m using my own authentication in the first place (I control the full stack). So then the value would come more from federation (which is hard to bootstrap) or developer experience. I do still think BrowserID has something going for it there, potentially.

I do wonder if I’ll miss the centralized session management, though. I’m building this IdP to be modular, so I could try a different protocol on top of the user management core down the road.

Thanks for sharing!

That’s how this project started, with trying to take the Persona repo and bringing it up to date. There were two challenges… first, don’t underestimate how hard it is to take a decade old Node repo and run it today. There are no types, many dependencies don’t work on modern Node versions, and upgrading them all together is a nightmare. BrowserID is not a very complex protocol, so rebuilding it gave me an opportunity to use new tools (TypeScript, Bun, Jose for crypto).

And the second reason is that I don’t want to try to be Mozilla Persona. The fallback IdP is a great idea, but y’all have no reason to trust me to be the one to run it. I can sidestep that issue for my own needs today, avoid the complexity of sending emails, and if for some reason this project does pick up any steam we can figure out whether/how to add that functionality down the road.

I’ve tried it in the past. This was a few years ago, so it’s possible it’s changed since then. But the reason I’m not choosing it for myself today is that it relies on either Sign in with Google (fine) or magic links to verify the user. I really don’t want to manage email delivery for this project, which is admittedly a stubborn personal choice. It just adds a lot of complexity that I don’t care to spend time on for hobby projects.

The biggest one I’ve come across is the ability to manage and revoke sessions from a centralized location. With BrowserID, you can’t just sign out of your IdP and expect all relying parties’ sessions to invalidate. Instead, BrowserID asserts that you controlled the email at a point in time, and then it’s up to the site to decide how to manage the session afterwards.

3rd party cookie blocking makes this worse, since it’s difficult to silently refresh your session by checking with the IdP behind the scenes. I believe Auth0 uses a hidden iframe for this, which uses 3rd party cookies and looks a lot like a tracking pixel. Without that refresh mechanism, though, relying parties are pushed to have longer lived sessions, which makes the lack of a global revocation worse.

And yet the data shows that they did decline. I'm sure they could be much better, and the response will vary from state to state.

The data ownership is really interesting, as many threads here are going into. I wonder if it's possible to sidestep that entirely, though! Under the CCPA, "personal information" is defined as information that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked — directly or indirectly — with a particular consumer or household. That says nothing about ownership.

To the extent that Flock is only storing the data on behalf of their customers, I'd understand they wouldn't be required to delete it. But to the extent that they are indexing it, deriving from it, aggregating it across customers, and sharing it via their platform, it seems they should be required to remove that data from those services.

But then again, I am not a lawyer!

Is there a technical limitation why these never seem to be grouped into a thread? I generally appreciate the updates on my package, but I also value a tidy inbox.

These are all risks. Not all risks need to be mitigated, but some can be. Others can be accepted. Saying “Python is too slow for production scale, but our goal is a small proof of concept,” is a valid answer even if it doesn’t “solve” the complaint. And if you don’t even have that answer, then the burden is not your problem. The lack of due diligence is.

I mean, that LLM idea _sounds_ ridiculous, but similar ideas have worked really well in machine learning for games like Chess and AI.

It was some attempt at reductio ad absurdum. If you are concerned about letting Alexa into your home, you must be as irrational as Chris Hemsworth. Edit: I'm misusing reductio ad absurdum, but somebody will please tell me what the fallacy here is called.

It’s also possible that I start my next task without remembering to create a new diff first. That might explain the conflict when the original commit becomes immutable?

I build a few diffs off of my local main, create and push a bookmark, and then create a PR back to main from that bookmark.

Maybe it’s based on whether the GitHub merge is a squash, rebase, or plain merge? Or do folks usually manually perform the merge with jj?

I have been trying to use jj for a couple months now, but hitting some friction with my company’s GitHub PR workflow. Specifically, after the PR is merged, the next time I fetch I always end up with a ton of conflicts. It gets hard to clean them up, so I often end up abandoning all mutable commits to start fresh.

I feel like I’m doing something wrong, as I haven’t seen this mentioned in any tutorials, but I don’t know what! :-/