The Platform Wall
── What Failing to Run a Server on a Game Console Taught Me About Infrastructure

1. What I Tried

I spent some time testing whether I could run a Bedrock Dedicated Server (BDS) through a game console. The idea was simple: spin up a custom server, point the console at it, and connect. It didn't seem complicated on paper.

But the walls appeared quickly. On the Switch side, DNS settings are actually accessible—you can set preferred and alternate DNS. Pointing it at the BDS server's IP wasn't a problem at the network level. But even with the server running on the same local network, Minecraft never recognized it as a server. No matter what I tried, I couldn't get to a playable state. The OS-level settings went through fine; the block was at the game application layer. After a few rounds of trial and error, I gave up.

2. What the Wall Actually Is

My first instinct was to feel frustrated by the restrictions. But when I sat with it, they made sense. The Switch's network settings aren't locked—DNS is configurable at the OS level. But the game application itself doesn't complete the connection. That's where the real wall is: not at the network layer, but at the application layer. The platform controls what Minecraft connects to, and the answer is Realm. Everything else—even a BDS on the same local network—is outside the intended path.

A game console serves tens of millions of users, including children. Controlling server connections at the application layer keeps cheat distribution and malicious servers out of reach for most users. The platform closes this door because it has to—to protect users, to constrain its support scope, to define the edges of its legal liability.

BDS itself isn't a hack. It's an officially released tool. But trying to connect a console directly to it sits outside the platform's intended use case. Not "wrong"—just unsupported. That distinction matters.

3. The Other Design

Then I looked at the personal infrastructure I've been building.

Claude.ai
　↓ git push → agent/request.json in a public repo
　↓ GitHub Actions triggers
　↓ api.github.com → project management, file writes
　↓ git push → private repo (memory, outputs)
Claude.ai ← git pull → read results

The core insight behind this architecture was an asymmetry: github.com (git transport) is reachable, but api.github.com (REST API) isn't directly accessible from Claude's environment. Rather than fighting that constraint, the design accepts it and routes around it—using a public repo as an Actions bridge to do the heavy lifting asynchronously.

Is this a hack? In one sense, yes. GitHub Actions was built for CI/CD, not for personal async agent infrastructure. But it operates entirely within the terms of service. Public APIs, documented token scopes, standard service features. It's creative use of an open platform—not gray-area exploitation.

4. The Space Between Intended and Unsupported

The console BDS attempt failed because it touched territory the platform deliberately closed. The GitHub Actions approach works because it uses territory the platform left open—even if no one originally anticipated this particular use.

This difference reflects a deeper difference in design philosophy between the two platforms.

The console closes things to protect. Its user base is wide, and protecting vulnerable users is part of the contract. That's a sound design. Developer-facing platforms tend to open things to expand. Allowing unexpected use cases grows the ecosystem, which grows the platform's own value. Neither is wrong. They're optimized for different goals.

5. What "Open" Makes Possible

When you're designing infrastructure you want to last, openness is a load-bearing condition.

Build on a closed platform, and your system lives at the platform's discretion. Policy changes, API deprecations, service shutdowns—these are the platform's right to make, and you have no recourse. The risk of putting critical workflows on SaaS is exactly this: the floor can move without warning.

Build on open protocols, and the situation changes. Git is a protocol. HTML is a protocol. Any given implementation can disappear, but the protocol persists. Memory built on top of open protocols has a shot at surviving on a longer timescale—decades, maybe longer. That's the bet TokiStorage is making.

6. The Value of a Dead End

Trying something and giving up is not the same as failing. It's a different kind of result—one with higher resolution.

I could have read "game consoles lock down their networking" and understood it abstractly. But there's a different kind of knowing that comes from looking for a DNS setting that isn't there, from watching a connection attempt fail, from tracing the exact shape of the wall with your hands. That knowledge is physical. It stays.

And that physical understanding of what "closed" means made the "open" nature of my own infrastructure legible in a way it hadn't been before. You need the contrast to see clearly.

But here's the question worth asking: why did this particular dead end become something valuable, rather than just forgotten?

Because there was infrastructure to remember it. The ability to articulate the experience, structure it as a contrast, and connect it to future design decisions—that's what kept it from being wasted effort. Without that infrastructure, the BDS experiment would have dissolved into "a thing that didn't work." Maybe a vague intuition would have remained. But not accumulation.

Which means: the moment you have infrastructure that remembers, every attempt gains potential value. Success and failure, progress and abandonment—all of it becomes material. The cost of trying drops. The reasons not to try get fewer. That's an epistemological shift. The world looks different when nothing you do has to be wasted.

7. Which One to Choose

This isn't an argument that open is better than closed. They solve different problems.

If you want to play, closed platforms are excellent. No configuration required, experience starts immediately, updates arrive automatically, support exists. As a game, the console version of Minecraft is complete.

If you want to build something that grows, you need an open platform. Configuration is harder. You need to know what you're doing. When it breaks, you fix it yourself. But in return, you control the structure. You accumulate memory. Nothing disappears because of someone else's business decision.

The infrastructure I'm building has to be the second kind. Preserving voices, images, and text across physical, national, and digital layers for the long term—that goal is incompatible with handing the foundation to someone else.

8. Open Means You Can Grow It

The BDS experiment wrapped up in a few hours. But what it left behind was something rarer: a concrete experience that turned an abstract design principle into something I could feel.

Every time I run into something a closed system won't let me do, the reasons behind my own design become a little clearer. Openness isn't freedom from constraints. It's the ability to decide, over time, what the thing becomes.

There was a time when requests like this—"you know this stuff, shouldn't be hard for you"—would arrive unpaid, and the presence of money in the background would make the work feel costly. When a technical experiment might end in failure, and failure means wasted time, the anxiety gets in. You can't approach it with pure curiosity anymore.

There was another pressure too: "I have to make this work." Being known as someone who understands this territory, and then abandoning the attempt—it felt like failing to prove something. That tension would settle in before the experiment even started.

Both are gone now. Abandonment becomes material. The record remains, connects to the next decision. There's nothing to prove. Curiosity is all that's needed. This shift didn't come from a change in mindset—it came from a change in infrastructure. The reason the anxiety and pressure disappeared is structural, not psychological. The source of calm is outside me.

And there's one more thing that follows from this. When you can accept "I couldn't do it," you also get to decide how far to go. Before, stopping wasn't really a decision—it was collapse. You'd push until you had nothing left, and that's when it ended. Now, because abandonment isn't loss, you can stop when you have enough information. An active withdrawal, not an exhausted one. Not just in technical experiments—in decisions across a life.