Yeah, the underlying sandbox technology between Ash and CC is fundamentally different.
Ash is built on the Endpoint Security and Network Extension APIs. Together, they cover the full gamut of potential sandbox escapes, and it's a simple process to update sandbox rules while the sandboxed process is running.
Claude Code sandbox is built mainly on sandbox-exec, an older macOS sandbox technology. It works for filesystem and IO device control, but it can only filter network requests by IP address. CC uses an application-level network proxy as a workaround, but not every network client respects the HTTP_PROXY env variable it requires. There are other workarounds in CC sandbox for complex use cases (e.g. dangerouslyDisableSandbox) that Ash does not need.
Your feedback about permissions is something I'm working on fixing now. Apple requires multiple permissions for Endpoint Security and Network Extension APIs and the current setup process doesn't walk users through that process as elegantly as I would like it to.
I'd be interested in seeing a breakdown in which ones use:
- VMs
- Containers
- sandbox-exec (macOS builtin tool)
- Endpoint Security + Network Extension (AFAIK this is just Ash but it would be good to see company here)
There is a very to-the-point diagram called the Hydrogen Ladder [0] that classifies the usefulness of hydrogen by domain. The author makes a good case that, despite its versatility, hydrogen is almost always worse than some other clean technology for any use case. It’s hard to make, store, and use in a scalable/cheap way, and even generous estimates of future progress show a cost curve that requires subsidies basically forever.
Buses are classified as a “Most Uncompetitive” category. Electricity, whether wired or battery powered, is cheaper and easier to scale for the predicable everyday energy use of a city bus.
One unmentioned feature of federation is that it lowers the cost of switching. If your provider begins to misbehave, you can jump to another one. This is especially true in email, where you can move from one host to another by updating your domain's MX records.
Without federation, switching means migrating both your host and your network of participants simultaneously. That is a much harder and more expensive coordination problem.
You are analyzing the wrong thing: email as a hosting mechanism isn't exactly federated, it is the email addressing scheme that is federated. You happen to be self-hosting your domain (which is part of a different system: DNS, which is more hierarchical than federated, though I have often put it in the latter category), which allows you to move around and even delegate to third parties your email host (which is really what you are doing: federation isn't what is allowing you to delegate your hosting provider, as your hosting provider works for you and you alone), but at the email layer that's because you did the super-rare thing of owning your own domain name and knowing how to have an MX record.
The switching cost for the average user of a federated system--one which has experienced lock-in on someone else's naming system, such as by using a gmail address or having a mastodon account on a large instance--is brutal. There is an advantage here that that is even possible, and there is then competition between these inter-compatible providers, but there are still many reasons why users tend to end up wanting to end up attached to larger namespaces (all of technical, political, and economical). Hell: even some of the smartest people I know seem to have an @gmail.com address (or worse: have let their identities become owned by a company they happen to work for) no matter how immediately "amateur" that makes them look to me :(.
(I gave a short "talk" about this at the Distributed Web Summit a few years ago, but the video they took has an over-an-hour audio sync issue and I haven't taken the time to edit my own copy yet.)
Email federation is more than just the addressing system. Even with a consistent address, your host still needs to be able to send and receive SMTP messages to participate in the ecosystem.
Address lock-in is real but doesn't fully negate the benefits of federation. Even if you don't control your address's domain, you can switch providers without losing the ability to send and receive email. There is extra cost in pointing your bank account to your new address, but it is possible. If your bank communicated to you via a non-federated protocol like WhatsApp, switching would be impossible.
This looks pretty interesting. Besides telephony and other message-passing applications, what are the hero use cases for an actor system on an embedded device?
I don't know about "hero" use cases, but I use actors (state machine responding to events in a queue) quite a bit when making hobby Arduino devices. It allows me to have a "button" device that can work with both the hardware pin interrupt controller and a clock to generate "click" and "hold" events, to pass to other actors in the system. I also will also use an actor to manage an I2C device, so that that actor can detect errors and restart the device to recover from errors. You could do either of those things without actors, but doing so has made it easier for me to compartmentalize my code and organize how data flows and states change.
The structure of your website's data is less important than its moderation process. High quality online communities tend to have strong, well-defined moderation policies – Wikipedia and Stack Overflow are good examples, as are HN and certain subreddits (eg AskHistorians).
Regardless of the technology behind a website, online communities without strong moderation tend to die over time as low quality content crowds out everything else.
Thank you for the remark. That is indeed also what I am looking at, or more precisely the interaction between structure and moderation policy. Stackoverflow is a very good example of how they interact. At such an early stage, I am mostly trying to identify structures on which policies can be built, as policies are much easier to change.
> I think that in studying economic growth, we (and especially we in the Silicon Valley) focus way too much on gadgets, and too little on the simple fact of human knowledge of how to do things.
This is a major component of software's power – it's a tool for formalizing knowledge and skills permanently and distributing it rapidly at ~0 marginal cost. If a piece of software is both correct and performant, it can last a very, very long time, possibly outliving its creators. And the best software composes, so one program can build on top of another to build up a massive skillset.
Ash is built on the Endpoint Security and Network Extension APIs. Together, they cover the full gamut of potential sandbox escapes, and it's a simple process to update sandbox rules while the sandboxed process is running.
Claude Code sandbox is built mainly on sandbox-exec, an older macOS sandbox technology. It works for filesystem and IO device control, but it can only filter network requests by IP address. CC uses an application-level network proxy as a workaround, but not every network client respects the HTTP_PROXY env variable it requires. There are other workarounds in CC sandbox for complex use cases (e.g. dangerouslyDisableSandbox) that Ash does not need.