rough-sea

The plan is to bring the celld model to workerd: run a fleet of workerd instances that use a bucket for coordination and storage. Building on workerd, instead of a separate runtime means our effort isn't split and that APIs are exactly the same in both CF and self-hosted. And of course the deno team will help improve the worker runtime itself.

JSR keeps running - the infrastructure is moving to CF

rusty_v8 isn't going anywhere - we'll keep maintaining it and will be working towards integrating it into workerd

It's a joint decision and I agree with it. I'm most invested in its success and have put the most work into it - and I no longer think it's where I can do the most important work. There are some good ideas in Deno and it's well engineered - but it ultimately is not solving big problems. It has been sucked into the gravity well of node compatibility, which forces it to behave exactly as Node does. Why reimplement Node? It works. Marginal performance or UX or security benefits are not enough.

I'm interested in building powerful new abstractions. celld has been working remarkably well, depending only on object storage for coordination and persistence. It is not just a slightly different API to interact with the file system or network - it's an entirely new model for server development. I wrote a bit about it here: https://x.com/rough__sea/status/2105853283617440032

We'll ship monthly releases for a year, and Deno stays MIT-licensed. If people want to carry it forward, I'd like that.

you should look at celld

workerd is missing the scheduler - the thing that allows it to operate across nodes. Durable Object storage are just local sqlite databases.

celld is the full distributed system (albeit single tenant). It distributes DOs (cells) across any number of VMs. The databases for each DO are in object storage with RPO=0 guarantee.

It's not about enforcing read-only - we want agents to do destructive things. Like rebooting a pod, rolling back a deployment, etc.

Plus a lot of these services are reached by tunneling through something else. We tunnel into k8s where it has dangerous credentials.

We also don't want to define MCPs for everything. The principle is that the agent doesn't need code changes, including skills/MCPs - it just accesses systems.

Claw Patrol lets us give agents more access because it's watching everything at the wire. `kubectl delete pod foo` waits for slack approval, SELECT on env_vars runs through an LLM judge to check if it actually returns secret data. For our setup this is security policy that is a single file, checked into git, that gates access across 14 k8s clusters, clickhouse, postgres, a dozen other HTTP APIs.

Could work - but our agents (codex/claude/openclaw) spawn subprocesses - imagine an engineer uses claude to debug an issue, it spawns psql directly, routing around MCP. Wire level interception is the only place a process tree can't escape.

Regarding reinventing permissions - scoped credentials solve this to some extent, but it's really nice to have a single place where we can define rules for all services (eg "DROP TABLE" never can occur), or you can SELECT unless it includes the env_vars.secrets column.

Yes works at the wire level, not http. Have a look at the example config file https://github.com/denoland/clawpatrol/blob/d2e531d8cb0f1a3a...

Claw Patrol holds credentials - so probably doesn't make sense to layer with AV - but it's true that AV has more sophisticated storage of creds (eg using 1p)

If the operator isn't around, then it shouldn't be approved. But yes, this is a problem, we have to ask the agent to retry after approval if its timed out. Currently the design philosophy is that the agent doesn't need to know anything about the firewall - no skill files, no code changes, completely transparent. But we're soon introducing a discovery endpoint that will allow the agent to know which services it has credentials for and tell the agent how to poll for HITL approval. This is an area of active development: https://github.com/denoland/clawpatrol/pull/666

There's a plugin API https://clawpatrol.dev/docs/plugins/

You can define different profiles that are associated with different credentials. Take a look here https://clawpatrol.dev/docs/credentials/#single-credential-t...

Thanks! Don't forget wire level protocol parsing - this is important because agents usually can spawn subprocesses and if they have postgres credentials, you're just one psql call away from disaster if you only have MCP/HTTP proxies in place.

Yes default allow and no rules by default. Some sort of default policy would be a great feature - I've been considering it. No one wants agents to DROP tables.

We have a big and detailed config file for our own internal use - but reluctant to release that exactly because it has information about our systems.

There's an example config file here that might be helpful https://github.com/denoland/clawpatrol/blob/main/examples/ga... - we use agents to write the config by pointing it at https://clawpatrol.dev/llms-full.txt

Unless you ascribe to some meta-physical soul - you believe human consciousness is encoded in matter - in the interactions between atoms. Actually at a much higher level of abstraction- neurons - but it’s all simulatable in principle. Thus, yes, it could literally be a bunch of x86 instructions.

deno added this about a year ago https://docs.deno.com/api/web/~/Temporal https://deno.com/blog/v1.40#temporal-api

JSR supports sigstore https://jsr.io/docs/trust

Love the effort but...

> We are targeting Summer 2026 for a first Alpha version on Linux and macOS. This will be aimed at developers and early adopters.

this is frighteningly far out for a prototype...

use deno!

https://docs.deno.com/runtime/manual/basics/permissions

"embeds TSC as a library" understates the integration:

https://github.com/denoland/deno/blob/75efc74931c1021fdc41c9...

https://github.com/denoland/deno/blob/75efc74931c1021fdc41c9...

Deno makes certain tradeoffs that make it feel seamless

deno does type checking. https://docs.deno.com/runtime/manual/tools/check

Don’t underestimate the difficulty of semiconductor manufacturing. It’s not that they’re trying to implement a fixed target - the technology has been exponentially advancing for the last 50 years.

excellent idea!

and use `deno compile` to ship it as a self contained binary

The authors of the original Imagen paper have gone on to create https://ideogram.ai/

https://github.com/denoland/deno is at 91.5k

Thank you for the detailed feedback. Deno 1.38.4 was just released with a partial fix for the VSCode issue you mentioned. We're fixing the twisted issue too.

https://github.com/denoland/deno/issues/21389 https://github.com/denoland/vscode_deno/issues/895

other fixes are being discussed.

Yet another misguided comment.

We cannot simply stop driving anymore than we can stop using an increasing amount energy. There are huge portions of humanity that live in places that depend on cars. It’s a non-solution to say people should just stop driving - billions cannot.

Thank you. It’s depressing to find so many people on HN expressing sympathy for the nonsense written in the manifesto.

People should read “Beginning of Infinity” for a strong counter argument.