tcbrah

The WordPress analogy is actually pretty apt here given Toni's background. Automattic went through exactly this - Matt stayed as the visionary/product guy while bringing in operators to handle the scaling side. And WordPress is arguably one of the most successful open source projects in terms of actual mainstream adoption.

The tricky part with Bluesky is figuring out which phase they're even in. 40M signups sounds like growth phase, but the retention numbers tell a different story. They might need a sustaining CEO before they've actually finished growing, which is an awkward spot to be in.

tens of billions of executions per day is insane. i run ffmpeg a few thousand times daily for automated video assembly and even at that scale the process startup overhead is noticeable. the single-decode multi-output trick alone saved me like 40% wall time when i switched to it. cant imagine what those savings look like multiplied by 10 billion

problem 2 is actually scarier than most people realize because it compounds. your agent reads a README in some dependency, that README has injection instructions, now the agent is acting on behalf of the attacker with whatever permissions you gave it. filesystem sandboxing doesnt help because the dangerous action might be "write a backdoor into the file i already have write access to" which is completely within the sandbox rules.

the short-lived scoped credentials approach someone mentioned upthread is probably the best practical mitigation right now. but even that breaks down when the agent legitimately needs broad access to do its job - like if its refactoring across a monorepo it kinda needs write access to everything.

i think the actual answer long term is something closer to capability-based security where each tool call gets its own token scoped to exactly what that specific action needs. but nobody has built that yet in a way that doesnt make the agent 10x slower.