A lot of software today feels like it’s deaugmenting human intellect. So much so that staying neutral is now revolutionary---not to mention improving it. A, not even pessimistic, explanation might be: having users rely on you creates a very secure business model for the creators. Open is much harder to successfully monetise.
- Applications are indeed hard to make when people expect it works everywhere, loads quickly, and can be accessed through a web browser
- Teams like figma and linear figured out some of the 1000x productivity and performance unlocks to make those kinds of apps.
- In Figma’s case, gpu rendered canvases, and with linear, local-first caching. Having those kinds of things puts you in a different market category than most would be competition. Of course, you still need to make a compelling product on top of your glass chewing engineering.
- What’s interesting this year, is you no longer need to be Evan Wallace shifting bits with butterfly flaps in Emscripten to get Figma’s level of performance. And while it’s still complicated, popular libraries have reduced the need for a concentration in distributed systems to create local-first applications.
This was already a popular stack before I noticed it. Current identified players and research:
- The Web Assembly App Gap and GPU-backed User Interfaces
- Rust GUI space: Zed which recently opensourced it’s codebase and toolkit, Makepad by Rik Arends, warp.dev (closed),
- CRDTs: Yjs and various hosted services. Interesting even newer popular players above still roll their own The road is still pretty rough,
- the syncing/CRDT section
- While Rust is popular for it’s compile pipeline to Web Assembly, actual use of the language for creating user interfaces is still in open exploration Advice for the next dozen Rust GUI’s
- Accessibility needs to be redone nearly from scratch if you render directly to the GPU
- We lose a lot of the open hackability of HTML’s inspect element and view source (which Electron with all it’s warts brought to the desktop). Although some options like Gnome Toolkit have something similar
- Rust in itself is a more complicated language to learn. If there’s a critical mass of people who think it’s worth it for safety, maybe that doesn’t matter? Else we’ll get a second wave of libraries and toolkits from Zig as it matures. Only adjacently related while we remain in garbage collected javascript land. Moore’s Law is dead for memory, still going for CPU and GPU (assuming we have resources to make them). Maybe Data-driven Design ans ECS-architecture makes a jump out of gaming to general sofware? tbd There’s a widening gap between “state of the art” web frontend architecure and what you’d need for a lot of rich applications HTMX, Astro, and Qwik make a lot of sense to reduce load on the client with islands and resumability. Significantly less so when your goal is to make the client self reliant, or remove central servers all together. This doesn’t mean their bad, just suited to a particular niche.
init garden
This experiment slowed down a bit faster than I expected it to. So now let’s try something slightly different.
As usual, this shift is partially inspired by some recent reading; this time How the Blog Broke the Web by Amy Hoy. There were a few interesting ideas but what stood out was her “retrospective” of an age of online writing, not automatically sorted by time—ALSO blog = weB Log🤯!
…anyways it would seem “gardens” do seem to be catching on generally around the web. What does information look like and how do we share it when everything isn’t by default organized into a feed? Like Amy Hoy suggests, maybe this hasn’t been explored more because of the friction in trying new formats, but alas here we go.
I’m not sure what exactly this will look like on my end. If I’ll still have a useful RSS feed; or if it will matter. The first changes will likely be:
- switching to a grid by default rather than a stream (I’d planned to do this and a collapsed version for some time so will try to push it into the stream version before I change.)
- some way to visualize connections between pages
- Future created on dates will now be last changed. Dates in general will be substantially de-emphasized
- slightly unhinged: considering “publishing” to an are.na channel then pulling from their API.
The switch will ideally not be too drastic at the surface but will add in new ways to explore the content.
Super Normal Software
I stumbled across an old Robin Sloan article recently. The entire thing is worth reading, but this section stood out to me:
you are always a step removed from the object of attention. You are not the deal, you are not the Lil’ Wayne video, you are not the flirty text message. You are the facilitator, you are the mediator, you are the vessel… What’s the relationship between a toolmaker and a tool user? I wonder about this a lot.
He argues that maybe we do have too many toolmakers. And why would you want to do such a thing when you could be the artist / author / writer directly connecting to an audience on the other end? But if we make tools, better in service of some creative goal than general consumption. More Pixar, less Apple.
My first thought in reaction is somewhat defensive. Tools can be art. Entering into my current thing (still unsure) from Industrial Design, I think of the Barcelona chairs, KitchenAid Standing Mixers, and Rams’ Universal Shelving Systems which have entered into the collection of various museums and art galleries. And most importantly manifestos like “Super Normal” from Jasper Morrison and Naoto Fukasawa on the beauty of objects designed so well as to fade into the everyday. There’s something beautiful there for toolmakers in being forgotten.
Admittedly, there is something fundamentally different with software. More often the goal of toolmaker here is to “leave a stamp” on the world. To create a Hub from which to direct all traffic. And yet no one puts onboarding flows on display at MoMa—except that one time. We certainly don’t cherish apps, like they would a well used drill or cast-iron skillet. Except sometimes people do. What’s going on here?
Scrolling a bit further into the comment section led me to a similarly titled post, Bless the Toolreaders. There the author describes this “lack” in software as “walls between tech culture and, well, culture.” With this the exceptions make a bit more sense. Tech and software are generally described in opposition to culture and society. “Those pesky Silicon Valley bro, so distracted by disruption they forgot to question if they should!”
It’s difficult, perhaps impossible, to be Super Normal in a field constantly engrossed with The New. But if there is an interest in dissolving these barriers, in nurturing the cultural value of software, perhaps the solution might be to fade away more often. Rather than facilitator or mediator, to disappear altogether.
emergent order v1
I heard about Elinor Ostrom the first time last year. And a paper by Ron Eglash only a few months ago. There seems to be an very solid thread tying these two together, along with others like Jane Jacobs, Arturo Escobar, Keller Easterling (very new to me). In most cases, these people were writers and researchers, bringing light to the work of independent communities.
It’s all still quite amorphous, but Organized Chaos—or maybe Emergent Order—sounds like a decent tagline at the moment. So, what is it? Best I’ve got is a string of quotes—to be better digested in the future:
Life and Death of Great American Cities
There is a quality even meaner than outright ugliness or disorder, and this meaner quality is the dishonest mask of pretended order, achieved by ignoring or suppressing the real order that is struggling to exist and to be served - Jane Jacobs
Hope in Source #11: City as Liturgy
Pickstock : Descartes :: Jane Jacobs : Urban Planners: Replacing a “living, very sophisticated, rich and subtle order” with “visually flashy and comprehensible, but that was outside of time and therefore dead.”
Organic Order is not meant to be known all at once. It runs a system based on its output. Generating a fractal order - Timothy Patitsis
RadicalxChange Replayed #14: No Normal | Keller Easterling in Conversation with Shumi Bose
The parameters of the system are constantly changing and therefore systems don’t hold… Productive entanglements is the phrase that we’ve been throwing around. - Shumi Bose
Designers tend to find and apply a kind of over arching (top-down) order to the work they do. These seem to fly in the face of that; Elinor Ostrom’s research shows communities coordinating to maintain shared resources without a central authority. Ron Eglash documents the fractal patterns in African architecture. Recurring themes: “Everyone is a designer” but not in the IDEO Design Thinking way (and it’s rarely ever called capital-D Design). The only constant is change.
The New Urbanists are old now, so I’m not sure where this rabbit hole goes for someone making those top-down order things, but it might be useful.
Update [27-10-2023]: I came across this essay on design’s shift away from the problem-solving lens. There’s a lot of interesting history along the way and a wide range of sources for future rabbitholes. It did not have a solution to life, the universe, and everything like I’d expected, but helps address some of the dissonance I’ve felt with design.
Skimmed / Read
- Design for the Pluriverse - Arturo Escobar
- Life and Death of Great American Cities - Jane Jacobs
Want to read:
- Medium Design - Keller Easterling
- Order Without Design - Alain Bertaud
- The Self-Organizing Universe - Eric Jantsch
Rabbithole Roundup no. 6
Social Unbundling
Imagine a restaurant that only sold rice. Open 12 hours a day. 7 days a week. Brown, White, Sticky, Fried, Jollof, blended, mashed, or boiled but always rice. How long could they realistically milk the novelty of their artificially created constraint?
This weekend was a quick dive into the “unbundler” space. Why do we do this thing anyway? Maintaining a presence across 5 different networks and platforms with near identical functionality. Often to stay in touch with people, stuck with this same affliction. Kind of like, going to 3 different restaurants to get a round meal. Unbundlers aggregate feeds across multiple networks and media forms, and present them in a way that might be more useful to the human on the other end.
Fraidycat creates “a personal surveillance network” of people you want to monitor. Everything is organized by recency, although you can sort follows into tags and priority. Proudly, a “tool for you to wield.”
I found Fraidycat in the comment section of a blog post, which was linked to in an are.na channel. A channel I do not follow with very strong ties across the every single are.na channel related to having a healthy and non-obsessive relationship to technology supercluster. 
visualized with g02 graph
All quite funny because, of course, the creator of Fraidycat also has an esoteric blog with links back to are.na, quotebacks, and beaker browser. All my rabbits seem to live in the same hole.
Yakread’s initial introduction had me jumping with excitement. Though it has since been (re)introduced with a stronger focus on newsletters. Maybe he lost The Path, or there might be something slightly broken
Shared Knowledge Base
And now a very different kind of media.
Roam Research’s creator went on Metamuse and took a shot at all the clones saying no one had come close to scratching collaborative thought (paraphrased). To be fair, this is a lot harder to reach with local-first architecture. But how does one share a collection of ideas easily?
First and most obvious would be a book or a website, but interaction here is limited. Published content is sealed off in a way that this would hopefully break down. Git repos work surprisingly well, but might be too technical (Obsidian and Logseq’s funding, publishing and sync, may “affect” incentives to make this work better). Other approaches include https://reading.supply, although quite small (and a SaaS platform) it has the most fleshed out public “networked thought” network I’m aware of. Noosphere seems interesting. Mostly in specification phase? But haven’t had time to dive deeper. There might also be something brewing among Bluesky’s API Touchers, too early to say.
Finding Maxima in Protocol Constraints
Disclaimer: I’m going to borrow some language from Optimization Theory, which I only have a cursory understanding of (sorry).
Most people would agree that protocols are a good thing. They scale emergent activity by helping to coordinate base expectations. Without any kinds of protocols, laws, or standards, our society—if you could still call it that—would be chaos. Yet an over-reliance, or maybe over growth, of protocols also leads to problems. When we set too many constraints, our systems become fragile; likely to break themselves or their participants. Is there a definition for where this drop of point is, or would something so specific fall into the same trap? Maybe a better analogy would come from baking. Stir the batter ✨just right✨, so your gluten might develop, but DO NOT OVER-MIX.
And here we see the question return, what does an over-mixed cupcake look like? Its traits, the warning signals at the edge of danger? Who up adding regression tests into their flour integration?
I do not have answers to these questions—for protocols or cupcakes. Perhaps one approach might be to start with an outcome. Is the protocol sufficiently adequate to fulfill your initial goal? If so, perhaps it’s time to stop tweaking, back away slowly, and let it run. And repeat for the next target. A few small batches rather than one big failure.
Related? Concepts
- Small Pieces, Loosely Held
- Formality Considered Harmful
- Watershed Two (Tools for Conviviality)
- Easy to Learn, Hard to Master (Game Design)
Web as smalltalk
Found this article from 2013 by Zachary Voase, expressing the idea of browsers becoming the new Small Talk. The missing piece that still does not exist today is Small Talk’s image persistence. He ends with:
So if we’re moving into a world of treating the browser as a VM, the manager of a long-lived application state, we need the other parts of the Smalltalk model: live-editing and persistence. The Chrome Web Inspector is great for modifying CSS rules on-the-fly (it’s a declarative language, DOM redraws are cheap on a human timescale, go figure). Editing JS is trickier due to its functional, callback-based nature; the average JS object tree is much more nested than that of the average Smalltalk VM. But Chrome is again showing that it is possible. So the final piece of the puzzle is persistence: this bundle of HTML, JavaScript and CSS needs to be written back to the server.
I have a hunch that WebDAV combined with standard HTTP authentication could be the answer. I’m not 100% sure on it, but I can easily envision a world where you fix bugs in your website by opening it up in a browser, reading a stack trace, fixing the JS in that same browser and persisting your changes back to the server. This hasn’t happened for the most part in 2023. Live editing JavaScript is harder because websites are more frequently “compiled” from some framework code.
This is very different from the properties I believed Andy Matuschak was looking for here. It’s worth mentioning that there are specific places where something similar happens, but on the web these are still relegated to developer environments and WYSIWYG editors.Maybe the real issue isn’t html and javascipt, but that there isn’t an expectation of development environment as often when creating a language.
Hello, world 2
This is my first post intentionally created for this stream. If all goes well, there will be many more after this—ideally none so meta. Prior posts have been (selectively) copied from my existing notes or tweets, toots, scrawls, and musings scattered around the internet.
Why?
---mumbles about data sovereignty and “blogging as a revolutionary art practice”.--- I don’t want to ever need to post on more than one social media site. So why not make my own. And it’ll be on my website where no one else can take it down— except for Vercel, [redacted to avoid phishing], Amazon, Microsoft, and some motley collection of ICANN key-holders, certificate authorities, and nation states.
More practically, I read too many of Robin Sloan’s blog posts; Maggie Appleton’s budding notes format inspired me to publish earlier; and this specific format was lifted almost completely from Linus Lee (with more motivation from Grant Custer)
Nerdy details that were helpful to me when I setting up: First here’s the repo. To make sure I write here regularly (some of this might not have happened yet on April 22, 2023), the src/content/note folder is symlinked to daily notes in my obsidian vault. This then gets synced to all my devices with Syncthing (Mobious Sync on iOS). When I have notes, I simply write them down there. I’ll need to occassionally push the project to Github, but hopefully there will be a way to automate that too. Long-term maybe this will also syndicate to other parts of the web #POSSE. I’ll need to decide on an ideal method of “translating” them first.
I reserve the right to come back and change things at a later date. For my sanity this will be reserved to typo’s and fixes withing a three day window. Any edits can also be seen on Github.
Todo:
- Publish and sign externally one day
- Nicer tag formatting
- Bidirectional links for when I eventually reference a correction in a different note months later.
Rabbithole Roundup no. 5
Interdependence #89 with Primavera De Filippi on “Extitutional Theory”: Framing to contrast “institutional framework” of rules and roles, by considering identities, i.e., how people perceive themselves and each other and relationships between identities so less social problems look like nails for institutionalization coughatomcough also connects surprisingly well to Undesigning a DAO by Samantha Marin
Raph Levien, while describing the state of GUI toolkits in rust says, “At present, this tradeoff space is very sensitive, in that small differences in requirements and priorities may end up with considerably different implementation choices.” I think this might generalize very well to how fragments form across different ecosystems.
Rabbithole Roundup no. 4
Zero Knowledge #253: Anoma’s “homogeneous architecture, heterogeneous security” is an interesting idea. Could be useful in decoupling apps and innovation from security and social bubbles. Feels like a flip of eigenlayer’s approach, but addressing a similar core problem.
Feels criminal not to mention, Metamuse podcast—the app is cool too. At least half the links in RR no.3 links branched from there. Bangers on local-first, BYO client, homemade tools, playful software, longevity, and many other things.
Networks vs Empires
Notes from “Convivial design heuristics for software systems” by Stephen Kell: applications / libraries / jobs exist inside a ecosystem / language / country. To become useful requires becoming dominant. Becoming dominant leads to eventual capture of hostage users, rather than fans. 
“The Space and Motion of Communicating Agents” by Robin Milner
Loose threads
GLBs. What’s biconomy doing? Armada. Peridot
Rabbithole Roundup no. 3
wow… this was a lot. Started with wallets, and ended imagining Kusanagi’s ghost in the shire. Specifying Spring ‘83 and Clay Shirky’s Situated Software were particularly interesting. https://are.na/sameoldlab/hyperpads
Rabbithole Roundup no. 1
Product and UX don’t need to be in conflict with privacy. Gabriel Valdivia’s case study for Tonic had a thoughtful approach to tailoring recommendations without resorting to tracking and storing user data. There was a framework to go along with it too:
Sensible products are data-prudent, mindful of their users’ time and attention, transparent, and give users top-level control of the experience.
Into the Bytecode #13 with Henri Stern talk balancing protocol-product and control vs convenience. Having and maintaining transparent communication about progressing toward decentralization.
I wish I didn’t need to think about this so often, but On Weaponised Design continues being relevant to recent events, both “good” and “bad”. A slightly depressing—but necessary—look at how design assumptions impact end user security.
personal software has good vibes
Data as Layer Zero
Although protocols tend to receive a lot of attention, I see an equally compelling argument for data instead acting as “the” base layer. On blockchains, tokens standards exist independent from Uniswap or OpenSea/Seaport. In other spheres, .obj, .svg, .pdf, .jpeg, and .mp3. These are all formats for structured information, compatible with any application which implements it.
One reason, data’s value might not be as prominent is the dance between data and platforms. A large enough platform can force new standards into existence even without them being open—coughs Adobe. Otherwise several parties might need to cooperate to get meaningful adoption. The data format needs platform support to grow, until it becomes a standard. At which point, a lack of support will hurt the platform’s business.
When it works? Fun, fun, fun (Maxim Leyzerovich has an inspiring thread of the forms this could take.). But at it’s worst, we get monopolies. Most of my earlier examples already have improved versions. The open process is too slow and adoption shifts to one entities imporved (but, closed) version. They decide the standard for everyone else and dictate it use (see early pfs, or current h265 and fbx). So how do we keep standards open and innovative without falling to the control of a single party? One way I can see is making the improvement so good it outweighs pain of transition (easier said than done).
No pain would be nicer though. Maybe this is where protocols are important? 🤷 They can lower the switching cost for products built on top, allowing us to migrate between open standards as they evolve and grow. Platforms might also realize its in their best interest to work together, in a similar process to Market-Protocol Fit
Most things do eventually become irrelevant or break down so the goal should rarely be to make the perfect standard or protocol. The interesting part is the dance; the spread and growth of new standards, dominance, , and eventually ossification. Maybe a better model for replacement.