Decentralization and Architecture
Over the last month, I've been working on a decentralized blogging tool called mumblr (remember tumblr?). It uses Fission's WebNative library to store blog posts as markdown files in IPFS. Boy, do I have some thoughts.
But first, why do I call this blogging tool decentralized? It's due to a bizarre shift in architecture; the notion of "application", "my files", and "servers" is completely different than the client-server, centralized world that runs much of the web today.
I've spent a few hours drunkenly stumbling around in Excalidraw trying to capture that new architecture for you, and the results are mixed. Suffice to say everything changes. All of our familiar terms that we've been relying on as stable for the last few decades change.
b
In a traditional client-server architecture, the server topology largely consists of three broad categories:
A "client", usually the user's browser or perhaps a mobile device.
A "server", which, at least conceptually, can be thought of as a single entity. The truth might be far more complex, including specialized servers for different purposes, from handling API requests to databases.
And "third party services", which are just other things on the internet that we interact with.
Most often, requests move from the client to the server and finally to third-party services, and then back. Of course, clients sometimes call out to third-party services directly, when convenient.
The "application" can be thought of as a conceptual unit encompassing the client, the server, and the database. "My files" can be thought of as living "inside the application." Technically, the user's data reside on a database controlled by the application, which the user has no ability to interact with directly, so this characterization makes sense.
Here's a simple diagram of a client-server version of mumblr:
In a decentralized application architecture, things are different. For starters, the notion of a split in the application between "client" and "server" largely disappears. Instead, the server topology can be thought of as:
The "client", or rather "clients", which runs inside the user's browser or on their device.
And "third-party services", which become a strange blend of out there on the internet and also running locally on the client.
In this new world, the "application" can be thought of as being simply the client. "My files" are genuinely mine, often living on my local machine, and the application merely has permission to access them.
Here's a simple diagram of the decentralized mumblr architecture: 
Note the server still exists in order to fetch the application code (the HTML, CSS, and JavaScript) that's needed to bootstrap the client locally:
So, when you squint, you might just summarize decentralized architectures in a completely unsurprising way: "no servers."
I don't claim that the above is a fantastic explanation, or anything of the sort. You'll have to wait for Jess's Definitive Guide to Decentralized Applications. Rather, I'm trying to "describe in my own words", and my own pictures, what decentralization means. So thanks for entertaining my meandering explanation.
Now, the implications of "no servers" are the really interesting stuff. In practice, decentralized systems fulfill many of the design goals of local-first software. (In fact, if you want a well-crafted explanation, just read that article). I've been getting to live those implications while building and using mumblr, and I'm aiming to get that knowledge deep into my bones.
https://twitter.com/jessmartin/status/1532686977442660352
I've been live-streaming my work sessions on mumblr. If watching someone talk out loud while they code and draw on a whiteboard is your thing, I created a playlist on YouTube where you can follow along as I build and learn.
Glimpses of the Future
Tools for Thought Meeting in NYC, in the flesh!
If you're in the NYC area, or even if you're not, you should consider coming to New York on Sunday, June 26th for an in-person Tools for Thought meetup. Why? Because I'll be there and I'd love to hang out with you! In person, no less! The Tools for Thought Rocks group has a lot of overlap with the "make computers better" and "future of coding" groups. I promise we'll keep things interesting with lots of time for conversation and collaboration, not just someone talking at you for an hour.
Fund Better Computers
Speaking of better computers, Parker Henderson and some friends put together a quirky little microgrant program for people who want to make computers better. I love the vibe and the spark. I'll be attending the Funding the Commons event in NYC June 24-25 to think about that how we can enable more things like this while also providing long-term, sustainable funding mechanisms for projects that actually get off the ground.
"web3 is at a 1970 level of development"
I've finally found my favorite framing for where we are with web3: the web3 world computer is at a 1970 level of development. Matt Webb beautifully sums up the reality and the promise in his excellent post. He closes with this:
If the web3 world computer has only just reached 1970 then, first, don’t expect too much. There’s real utility to be found but in very prescribed use cases. But also, second, there are wild and unrecognisable transformations to come. There is room for imagination and invention.
I couldn't agree more. So, go forth! Imagine! And invent!