Local // Onchain

Late night musings / early thoughts / not fully thought through

The Challenge of Building Lightweight and Independent Systems

Two years ago, we were deep into developing an unreleased BTC DeFi product at we3.co, and one of the most interesting challenges we explored was this: how could we make it not just super lightweight but also as independent as possible from outside libraries and servers? We wanted to take "don’t trust, verify" to its absolute limit—build something so simple, there wasn’t even anything to trust because there wasn’t anything there to doubt.

One of the things we experimented with was creating a customizable portfolio dashboard that didn’t require an account, didn’t need to connect to anything, and didn’t rely on any external service.

This is where my obsession with URLs and local storage kicked in. Each position ahad a unique identifier, so we could remember "your" position using just that. Every decision you made on the frontend could be encoded right with that into the URL. Bookmark it, and boom—you’ve got a personalized view that’s yours alone. You could share it if you wanted to, but there was no way for even the page itself to remember you.

This approach got me hooked. I started building a bunch of small apps to test the limits of what URLs could do (it was fun!), and in the process, I stumbled upon the local-first community led by the masterminds at Ink & Switch.

At its core, local-first is about rethinking how we handle data ownership and collaboration. Collaboration is the essence of the internet. No matter what version of the internet we’re talking about, it’s always been about making stored data accessible, interoperable, and collaborative.

Today, most of our data lives on someone else’s server. We like to think we have ownership and agency, but the truth is, if Figma, Google, or any other big player has a bad day, good luck accessing your files. We don’t fully control our data; we just access it.

So, every time a new tool promises better collaboration, you’ve got to ask yourself: should I invest time in this? What happens if the startup behind it runs out of money? What if Google buys it and makes it worse? How long before it goes the way of all enshittified services?

Local-first wants to keep the superpower of collaboration but shift the data primarily back to you, locally. Just like the good old days. Local data is faster. It doesn’t need to ping a server on another continent every time you hit a key. Local-first means your data has real longevity—it stays with you, even if the service shuts down, temporarily or permanently.

Initially, everything was local-first. But we can all agree that not being alone in our files anymore has a lot of upsides. As a designer, not having to worry about whether we’re all looking at the latest version or the same file was and still is a game changer. Collaboration is here to stay, and tools like Partykit are making what was once a hard engineering problem, accessible only to the massively venture-backed or the controlling tech giants, much more accessible and approachable. It’s a step in the right direction, for sure.

But I still love ownership and agency. And I love data longevity.

Local-first tries to bridge the gap—collaborative software with local data. But that brings its own set of engineering challenges. I highly recommend diving into the work of Ink & Switch to understand this more deeply. Technology, as always, evolves, and maybe not today but tomorrow, collaboration and local-first will become more feasible, more viable, and more desirable. But for now, real-time collaboration is more of a goal than a reality. It needs new approaches to conflict resolution and consensus, or something along those lines. For now, it is closer to pull requests and merges, as far as I understand. But things are moving gradually, and then, as always, all at once.

It’s still early days, and as always, early things grab my attention. I probably misunderstand a fair bit of it—I’m still a designer by craft and an artist at heart, not a scientist.

So, I’ve talked a lot about "Local." But what about "Onchain"? Web3, blockchains, distributed ledgers—they’re the other side of the same coin for me.

Data will either be best stored locally, with access to networks (whether that’s the internet or some other form for synchronous collaboration), or it will be decentralized onchain.

Both approaches give you more agency, control, and ownership. Sure, I might think the safest place to stash your wallet keys is on Apple’s server (because if they go down, we’ve got bigger problems anyway), but we all know the saying: not your keys, not your coins. That’s why I keep mine locked up tight in a titanium cylinder—locally. And then it hit me: we’re accessing onchain through a local file, aren’t we?

So, what’s onchain good for? To me, blockchains are at their core about social interaction graphs and state machines. Maybe they’re part of the solution to the synchronization puzzle that local-first needs to solve.

But they also solve for data longevity. Anyone can run a node, and it’s getting harder and harder to take the network down. It can’t really go offline. And they are massive multiplayer by default.

The future isn’t going to be about being offline or online. It’s going to be about being local or onchain. Two movements, potentially in a weird yin and yang, but both pushing us towards a world where we have more control, more ownership, and more agency over our data. We already access onchain through a local file, so what’s the intersection, the relationship—the point where onchain becomes the yin to local’s yang?

Again, these are very early musings—I’m not fully clear myself yet... Thanks for sticking with me this far, though. Any feedback? Please DM me."

// Special thanks to Shuya for the framework inspiration and late-night conversations.

Local First Blog Post by Ink&Switch

https://www.inkandswitch.com/local-first/