← Dark Star world index

There Is No Spoon

How software tools become assumptions, assumptions become architecture, and architecture begins deciding which ideas look possible.

John Rigler · Dark Star paper · October 2026

Abstract. Software is built in layers. We use programming languages, libraries, servers, databases, frameworks, package managers, cloud services, and development tools because each solves real problems. Over time, however, a useful layer can stop looking like a choice and start looking like part of reality. New projects are then designed to fit the inherited stack rather than beginning with the problem itself. This paper calls that process stack capture. It begins with ordinary web software, follows the growth of JavaScript and Node.js into a large development ecosystem, and then shows the same pattern appearing in blockchain development around Ethereum and the EVM. The point is not that these tools are bad. The point is that tools become dangerous to thought when we forget that they are tools.

1. Software begins as instructions

At the most basic level, software is a set of instructions for a computer.

A person wants the machine to do something: display text, calculate a number, save a file, play a sound, communicate with another computer, verify a signature, or respond when somebody presses a button. A programming language gives the person a way to express those instructions.

Very little useful software is written directly from the bottom up. Programmers reuse work. They use operating systems instead of writing their own hardware drivers. They use libraries instead of rewriting common functions. They use databases instead of inventing a new storage format for every project. They use web servers instead of writing the entire network protocol by hand.

This is sensible. Civilization would get nowhere if every bridge builder had to rediscover metallurgy.

The problem begins later, when the collection of reused solutions becomes difficult to distinguish from the problem itself.

2. What a software stack is

A software stack is simply the collection of layers used to make a program work.

A web application might contain:

Each layer may be justified. But a stack has a social life as well as a technical one. People learn it. Companies hire for it. Training programs teach it. Investors recognize it. Job titles form around it. Tools are created to manage the tools already in the stack.

Eventually a particular arrangement can become the normal way to imagine software.

problem → useful tool → common tool → standard practice → expected architecture → “the way software works”

3. There is no spoon

The phrase “There Is No Spoon” comes from The Matrix. Here it describes a much less mystical realization.

The spoon is the thing that looks like part of reality but is actually part of the model.

In software, the spoon might be a server, an account system, a database, a framework, a build process, a mobile app, a cloud provider, a smart contract, or a token. Any one of those may be useful. The mistake is assuming that because the layer is normal, the layer is necessary.

Stack capture begins when an implementation choice becomes difficult to perceive as a choice.

This matters because software is unusually good at hiding its history. Once a tool becomes standard, a new programmer often encounters the standard before encountering the original problem that caused the standard to exist.

The programmer learns the solution first.

Then the solution becomes the shape of future problems.

4. The simple web

The early web provides a useful place to see the process.

A basic web page can be remarkably small. The browser requests a file from a web server. That file contains HTML, a simple language that describes the structure of a document: headings, paragraphs, links, images, forms, and other elements.

CSS can describe how those elements should look: their fonts, spacing, size, position, borders, and colors.

Those two pieces are enough to publish a large amount of useful information.

The browser itself already contains substantial machinery. It knows how to display documents, follow links, draw graphics, play media, store some local data, make network requests, handle input devices, and enforce security boundaries.

That detail matters. The browser is not merely a television screen waiting for a remote server to tell it everything. It is a programmable computer environment running on the user's own machine.

5. What JavaScript is

JavaScript was created as a programming language for web pages.

HTML describes the page. CSS describes its presentation. JavaScript gives the page behavior.

JavaScript can respond when a person clicks a button. It can change what appears on screen. It can calculate values. It can validate a form before anything is sent across the network. It can read files the user explicitly selects. It can create graphics, use cameras with permission, store local information, perform cryptographic operations, and communicate with remote services.

For many years, one of the important conceptual boundaries of web programming was easy to understand:

browser JavaScript runs on the user's computer · server software runs on somebody else's computer

That boundary was never absolute, but it was visible.

Then JavaScript escaped the browser.

6. Node.js changes the shape

Node.js is software that allows JavaScript programs to run outside a web browser.

This was a major and useful development. A programmer who already knew JavaScript could now use the same language to write server programs, command-line tools, automation scripts, development utilities, and network services.

That removed a practical barrier. A team no longer had to use JavaScript in the browser and then switch to an entirely different language for the server.

Node.js also became associated with npm, a package manager and enormous public repository of reusable JavaScript software. A package manager lets programmers declare that their project depends on other packages and then automatically downloads the required code.

The result was explosive productivity. Instead of writing everything themselves, programmers could assemble software from thousands of available parts.

This was a real advance.

It also changed what JavaScript development looked like.

7. Node.js capture

Once Node.js became common, it stopped being only a way to run JavaScript on a server. It increasingly became the environment through which web projects were created, assembled, tested, and deployed.

A developer might begin with a page that ultimately runs in a browser, yet still need Node.js on the development computer in order to build it.

This happens because the project may use Node-based tools to:

None of those jobs is imaginary. The tools often save enormous amounts of time.

But notice the shift.

A language that began as code running directly inside a web page can now arrive wrapped in a development environment where Node.js is assumed before the first line of application code runs.

At that point a strange question becomes reasonable:

Does this application actually require Node.js, or did the development culture require Node.js?

Those are not the same question.

8. Packages and dependency gravity

The package ecosystem creates another form of capture.

Suppose a programmer wants to solve a small problem. A package already exists, so the programmer installs it. That package depends on five other packages. Those packages depend on twenty more. Soon a project containing a modest amount of original code may depend on hundreds of pieces of software maintained by other people.

This does not automatically make the project bad. Reuse is one of the foundations of programming.

But dependencies create gravity.

Once a project uses a package ecosystem, it becomes easier to solve the next problem by adding another package from the same ecosystem. Documentation assumes the package manager. Tutorials assume the same directory structure. Security tools scan the same dependency files. Hosting companies recognize the same build process.

The ecosystem becomes self-reinforcing.

A useful convenience becomes a path of least resistance, and the path of least resistance eventually becomes the path developers are expected to take.

9. Framework capture

A framework is a larger set of conventions and tools for organizing software.

Frameworks exist because large applications are genuinely difficult to manage. When hundreds of interactive elements change on a page, programmers need reliable ways to organize state, update the screen, divide the program into reusable pieces, navigate between views, load data, handle errors, and coordinate many developers working at once.

React, for example, became a widely used way to construct interactive web interfaces from reusable components. Other tools grew around it. Next.js added conventions for routing, rendering pages, server-side behavior, data loading, and deployment.

Again, these tools solve real problems.

The capture occurs when the framework becomes the first answer rather than a response to a demonstrated need.

A small browser application may then inherit:

The resulting application may be excellent. But the stack itself now has enough weight to influence what programmers consider normal.

A plain HTML page with ordinary JavaScript can begin to look primitive even when it performs the required job completely.

10. The server becomes assumed

The next capture is architectural.

Modern software often assumes that an application has a permanent server behind it.

The pattern is familiar:

browser or app → API → application server → database → cloud provider

The browser becomes the visible surface. The important state lives elsewhere.

User identity is often stored in an account database. Application history lives in the database. Business rules execute on the server. Search depends on the server. Permissions depend on the server. If the server disappears, much of the application disappears with it.

This arrangement is often correct. A bank, multiplayer game, airline reservation system, or collaborative business application may genuinely require shared authoritative services.

But because the pattern is so common, developers can stop asking which parts actually require a central service.

The existence of the server becomes evidence that the software is serious.

The absence of the server can look like something has not been built yet.

This is stack capture in mature form. The architecture is no longer merely helping solve the problem. The architecture is helping define what counts as a complete solution.

The trap is not complexity by itself

Some problems are complex. Some systems should have many layers. The trap is not “more software is bad.” The trap is losing the ability to tell the difference between complexity required by the problem and complexity required by the culture surrounding the problem.

11. Then blockchain arrives

Blockchain technology enters this history with a very different starting idea.

A blockchain is a shared record maintained by many computers according to agreed rules. Instead of one organization keeping the only authoritative database, many participants can independently verify the ordered history.

Cryptocurrency is the most famous use. A blockchain can record that control of some digital value moved from one cryptographic key to another.

A cryptographic key is a piece of secret information used to create a digital signature. The signature allows other computers to verify that a particular action was authorized by the holder of the key without learning the secret key itself.

A wallet is software that manages those keys and helps construct or sign transactions.

A transaction is a signed request to change the shared ledger according to the network's rules.

Those ideas alone are already unusual. They allow people who do not share a database administrator to agree on an ordered history of signed events.

But blockchain development did not remain at that level.

12. Ethereum and the EVM

Ethereum introduced a particularly influential model.

Ethereum is not only a ledger for transferring its native currency. It also contains the Ethereum Virtual Machine, usually called the EVM.

A virtual machine is a software-defined computer. Instead of being one physical laptop sitting on a desk, the EVM is an agreed computational environment whose operations are reproduced and verified by the Ethereum network.

Programs stored for that environment are called smart contracts.

A smart contract is not “smart” in the human sense and is not automatically a legal contract. It is a program stored at an address on the blockchain. When a valid transaction calls the program, every participating system can determine the same resulting state according to the EVM rules.

Developers commonly write these programs in Solidity, a programming language designed for Ethereum-style smart contracts.

This opened a large design space. Developers could build exchanges, lending systems, games, collectible systems, voting mechanisms, financial instruments, ownership registries, and many other shared applications without one company maintaining the only authoritative program state.

The EVM was a powerful abstraction.

Its success also created a new stack.

13. The EVM stack hardens

An Ethereum-style application often needs more than a smart contract.

The developer may use:

To someone outside this world, that is a lot of machinery. To someone trained inside it, the pieces can feel natural because each solves a familiar problem.

The stack may now look roughly like this:

web framework → wallet → JavaScript blockchain library → RPC service → EVM → smart contract → blockchain

And the development environment around it may add:

Node.js → npm packages → compiler → contract framework → tests → deployment scripts → cloud services

Again, none of these components is inherently wrong.

The capture happens when a project is evaluated by whether it contains the familiar pieces.

“Where is the smart contract?” can become a more natural question than “Why does this require a smart contract?”

“Where is the wallet connection?” can come before “What authority does the user actually need to exercise?”

“Where is the backend?” can come before “What data cannot safely or practically live with the user?”

The inherited stack begins writing the design brief.

14. Tokens become the visible object

The EVM also made it relatively easy to create new digital assets.

In this context, a token is a balance or asset defined by a smart contract. The contract specifies rules for who owns how many units and how those units can be transferred or otherwise used.

Some tokens are designed to behave somewhat like currencies. Others represent voting rights, claims, access, game objects, financial positions, or unique items.

A token standard is a shared set of technical rules that lets wallets, exchanges, applications, and other contracts interact with many independently created tokens in a predictable way.

This interoperability was extremely productive. Once the standard existed, a new token could immediately fit into a large ecosystem of existing software.

But successful standards change attention.

Projects began to be understood through questions about their tokens: How many exist? Who receives them? What are they for? How are they distributed? Can they be traded? Does holding them provide access or voting power? Will more be created later?

The word tokenomics emerged as shorthand for this economic design around a token.

For some projects, those are exactly the right questions.

For others, the questions can distort the object before anyone has established that a new token is necessary at all.

This is where a technical stack becomes a cultural filter.

A project using blockchain infrastructure may be treated as incomplete because it does not issue its own token. A project using signed transactions but no elaborate smart contract may look less sophisticated. A system that treats the blockchain as a durable public record rather than primarily as a financial machine can be difficult to classify.

The success of one use begins hiding other properties of the medium.

15. Message capture

At this stage, stack capture becomes message capture.

An idea enters an established technical community. To be understood, the idea is translated into the community's normal architecture and vocabulary.

The translation might proceed like this:

new idea → “what is the app?” → “where is the backend?” → “where is the smart contract?” → “what token does it use?” → “what are the token economics?”

The questions are individually reasonable because they describe many successful systems.

But together they can force an unfamiliar idea to become familiar before it can be evaluated.

A project may add a server because applications are expected to have servers. It may add a framework because professional web applications are expected to use frameworks. It may add a smart contract because blockchain projects are expected to have smart contracts. It may create a token because blockchain ventures are expected to have an economic object that can be measured and traded.

At the end, the project is legible.

It may also no longer be the same project.

The technology has not merely implemented the message. The technology has edited the message into a form the existing ecosystem already knows how to read.

16. The technology trap

The trap can now be stated without reference to any particular programming language or blockchain.

A technology solves a real problem.

The technology becomes popular.

Training, jobs, libraries, companies, funding, and infrastructure grow around it.

New problems are increasingly described in the language of that technology.

Eventually, removing the technology looks stranger than adding it.

tool → standard → ecosystem → profession → expectation → worldview

Funding becomes architectural gravity

This loop is not driven only by technical fashion. It is also selected economically.

A project that can be described as a company, platform, proprietary service, token ecosystem, subscription, or defensible control point is easy for an existing funding system to recognize. It presents something that can be owned, financed, measured, and scaled.

A system whose strongest claim is that the original builder can disappear is harder to make legible in those terms.

That does not require a conspiracy. Each participant can make a rational local decision. Developers learn the tools employers hire for. Conferences feature projects with budgets. Funded teams can afford polish, travel, marketing, audits, integrations, and developer relations. Investors see the architectures that already look investable. The resulting visibility then teaches the next generation what a serious project is supposed to look like.

funding incentives → visible projects → tooling norms → expert consensus → more funding

The result is rigidity. The stack does not merely solve problems. It becomes the cleanest route to institutional recognition.

That is why subtraction can look implausible from inside the ecosystem. A project with fewer layers may also have fewer familiar signals of seriousness.

The trap is strongest when the simplest architecture is also the hardest architecture to finance, explain, and recognize.

This is why “There Is No Spoon” is useful as a cultural phrase.

The revelation is not that the software is fake. The software is quite real. The servers consume electricity. The frameworks contain millions of lines of code. The contracts execute. The tokens trade. The companies employ people.

The thing that is not real in the same way is their necessity.

The necessity has to be demonstrated again for each problem.

A technically mature person is not someone who knows the largest number of tools. Technical maturity also includes the ability to look at a familiar layer and ask what would remain if that layer were removed.

Sometimes the answer is: the system would fail, because the layer is doing indispensable work.

Sometimes the answer is: very little would change.

And sometimes the answer reveals that the project was organized around the stack rather than the problem.

The point is not to reject Node.js, React, servers, databases, Ethereum, the EVM, smart contracts, tokens, or development frameworks.

The point is to recover the ability to see them.

17. When the clues are wrong

Stack capture becomes most important when someone does not merely criticize the normal architecture, but actually sees another way to build.

At that point the problem stops being theoretical.

A person can arrive with a working system that deliberately omits familiar layers. There may be no permanent application server. There may be no account database. There may be no project token. There may be no large smart contract. There may be no framework-heavy front end. The system may use a blockchain, but not in the way people have learned to recognize a “blockchain project.”

To the builder, these absences may be the point.

To an observer trained inside the captured stack, the same absences can look like missing work.

The observer starts looking for clues:

If those clues are not present, the project can become difficult to classify. It may be described as incomplete, eccentric, too simple, insufficiently scalable, insufficiently “Web3,” or merely as an odd use of existing technology.

This is a particularly strong form of capture because the misunderstanding can survive direct demonstration. The observer sees that something works, but still searches for the conventional machinery that would explain why it works.

The problem is no longer that the new idea is hard to explain. The problem is that the audience has been trained to look for evidence that belongs to a different architecture.

That matters to anyone working outside a mature technical grammar. A genuinely different design can be stifled before its core idea is evaluated, not because it fails technically, but because it lacks the expected markers of seriousness.

The builder then faces a choice. Add the familiar layers so the project becomes legible, or keep the architecture intact and accept a much higher explanation cost.

This is where stack capture becomes message capture.

18. Web 2.8

There is a particularly important consequence in the history of Web3.

Web3 is often described as a break from the architecture of Web2: less dependence on platform accounts, less dependence on one company's database, more user-controlled keys, more public verification, and more durable state that does not disappear when a single service shuts down.

But a captured development culture can take those new primitives and immediately rebuild the old architecture around them.

A project begins with a blockchain, then adds:

The blockchain is still present. The wallet is still present. The token may be present. The project can therefore look unmistakably Web3 from the surface.

But much of the actual dependency structure has reverted to Web2.

Dark Star calls this Web 2.8: Web3 primitives embedded inside an architecture that still behaves like Web2 where it matters.

This helps explain a recurring frustration around Web3. The promised shift can seem perpetually close while the practical result remains strangely familiar. Users still depend on hosted interfaces. Projects still depend on companies. Identity still collapses back into accounts. Data still becomes inaccessible when an API or service disappears. A “decentralized application” may still be unusable when its centralized front end goes offline.

The failure is not necessarily in the blockchain primitive itself. It can occur in the layers reintroduced around it.

This is also why very large technology companies can perceive parts of a new medium correctly while still pulling it back toward the platform model they already know. The failure mode is not stupidity. It is institutional momentum: identity, discovery, storage, monetization, and rule-making keep returning to a central operator because that is the architecture the organization knows how to own.

The more useful test is therefore not whether a project uses fashionable decentralized primitives. It is whether the artifact, identity, and useful history survive the disappearance of the preferred operator.

And those layers are often reintroduced for exactly the reasons described in this chapter: they are familiar, fundable, teachable, hireable, measurable, and recognizable as professional software.

This is why adding the expected clues merely to satisfy the captured worldview can destroy the thing being attempted.

If the architectural experiment is specifically trying to remove permanent servers, platform-owned identity, mandatory application databases, unnecessary contracts, or proprietary custody, adding those layers back for legibility does not merely make the project larger. It reverses the experiment.

Web3 primitive → familiar Web2 stack → restored dependencies → Web 2.8

Stack capture therefore offers one explanation for why Web3 so often appears to reproduce the structures it claimed to replace. It should not be treated as the only cause of every Web3 disappointment; economics, governance, security, regulation, fraud, usability, and speculative incentives matter too. But stack capture can explain a specific and important failure mode: the new substrate arrives, while the old architecture survives almost intact above it.

From this perspective, the decisive question is not whether a project uses a blockchain.

It is whether the use of that blockchain actually removes an old dependency, or merely decorates it.

19. A note about AI

Even a reader who has no interest in blockchain should probably stop here for a moment.

Large language models and other AI systems are changing the cost of moving between technical domains. A person no longer has to remain inside one narrow specialty in order to ask useful questions about another one. Someone working in a more associative way can move from software architecture to cryptography, publishing, databases, law, design, networking, or documentation and use an AI system as a translation layer between them.

That does not eliminate expertise. It changes the cost of crossing the boundaries around expertise.

This matters because many captured stacks are reinforced by organizational structure. One team owns the front end. Another owns the backend. Another owns infrastructure. Another owns security. Another owns data. Another owns deployment. The technical stack and the corporate chart begin to mirror one another.

AI puts pressure on that arrangement because one person can increasingly inspect, question, prototype, and connect work that previously required a chain of specialist handoffs. The person does not become every specialist. But the boundaries become more permeable.

AI may be important not only because it makes existing work faster, but because it makes some inherited divisions of work easier to see as optional.

This is one reason stack capture matters beyond Web3. The same question can now be asked inside almost any project:

If I were starting from the problem today, with these tools available, would I still build all of these layers?

That question can be uncomfortable for organizations whose processes, job boundaries, procurement, and authority were built around the existing stack. But it is becoming easier for individuals and small groups to ask it seriously and test the answer.

So even if the reader goes no further into Dark Star, the practical argument of this chapter still applies: do not confuse the structure you inherited with the structure the problem requires.

20. The next chapter

The next chapter is not another abstract argument about software culture.

It is a concrete example of what happens when someone begins from a different set of assumptions about blockchain.

The familiar blockchain story starts with money, wallets, smart contracts, tokens, exchanges, and applications built around them.

The next chapter starts earlier.

It starts with Bitcoin itself, including the human-readable newspaper headline embedded in the genesis block. From there it looks at transaction fields, public addresses, deliberately constructed carrier addresses, provably unspendable outputs, and the possibility that parts of a cryptocurrency transaction can function as durable public language rather than only as payment machinery.

That path eventually becomes Chisel.

The point of the next chapter is not that everyone should build this way. It is to show why a person working from these lower-level properties can arrive at a system that looks strange when judged by the clues described in this chapter.

Once the stack is no longer treated as reality, the same underlying technology begins to reveal different affordances.

Next: The Address Is the Index

The question changes from “Where are the expected pieces?” to “What can the underlying medium actually do?”