Interesting take, the article describes ENV variables and their inherent untyped danger when you depend on them, but doesn't really describe an alternative solution for them.<p>A good solution I've just seen is to validate the environment variables using a schema like [1] zod. Which will guarantee that the ENV variables are the exact type that you expect when the program starts, or it will throw an error.<p>[1] Example -> <a href="https://github.com/t3-oss/create-t3-app/blob/bc57d02789209f116662c7ebe365673027e1a1c1/cli/template/base/src/env/schema.mjs#L8-L10" rel="nofollow">https://github.com/t3-oss/create-t3-app/blob/bc57d02789209f1...</a>
I have a hard time understanding what the article is trying to tell me.<p>As soon as you have components talk to each other over IPC, you pass strings of bytes. It does not matter whether you create a nice abstraction class around a string. Over the wire it is still a string.<p>What is he proposing we do to prevent confusion between strings?<p>Adding namespaces does not appear to be a useful idea because it boils down to "do input validation", which you are hopefully already doing.
This article seems to be recommending the use of capabilities, but a question is how you represent a capability, if not as a string or a number like a file descriptor. And how do you send it over a network, if not as a byte sequence?
this is a an important article. It's a bit hard to grok and requires some experience to understand but after you end up with a messy system doing too much ghosty stuff you yearn for stability
The parts about accidentally leaking secrets reminded me of an idea I had a while back that builds on the idea of capabilities / unforgeable handles, and making a distinction between different kinds of trust.<p>An outer component, in this example a web service, might be provided with a handle to a secret that it needs for connecting to some other system — let's take Consul, for example. The web service is trusted to basically _intend_ to do the right thing, but it is not trusted to be vigilant enough to avoid leaking the secret, so it is not allowed to ever actually resolve that secret itself.<p>What it _can_ do is provide the secret-handle to another component whose job is to establish the connection to Consul for it. That second component has to be given a handle to a secret (it can't just look them up by itself) but once it has one, it can resolve it to the actual secret string. This second component does as little as possible, and is trusted to not accidentally leak the actual secret string — not even to the outer component that is using it.<p>The Wasm component model makes this sort of scheme really easy to implement because capabilities / unforgeable handles are a first-class concept and they are available for all components to create and communicate between each other.<p>I guess this might already be a well-established pattern elsewhere, but I don't remember seeing it anywhere.
So they want either:<p>- "fully qualified names" ... to some arbitrary obvious-after-the-fact degree, because fully FULL qualification becomes one of the heavyweight barriers he doesn't like: a central name validator/registry, reduced ability to reuse data because of the funny wrapping/name<p>- universal data typing, but that doesn't exist, and would be a barrier if it was<p>- universal data formats: oh god, that means standards bodies, doesn't it.<p>I totally agree about the make services interact --> they interact, but there's security holes --> impose security loop.
<i>"By “ghost” here, I mean any situation where resources are referenced by plain data."</i><p>OK, whatever.<p>What he's railing against is canned strings which identify things. URLs, names in key/value stores, etc.<p>Attempts to get rid of that include the Windows Registry. That may not be a good example.
Another attempt is identifying everything with an arbitrary GUID or UUID. Pixar moved away from that in their USD format for animation data.