bmann.ca
+4
-1
.gitignore
+4
-1
.gitignore
······
+6
.obsidian/canvas.json
+6
.obsidian/canvas.json
+3
-3
.obsidian/core-plugins.json
+3
-3
.obsidian/core-plugins.json
···
+22
.obsidian/graph.json
+22
.obsidian/graph.json
···
+1
-1
.obsidian/templates.json
+1
-1
.obsidian/templates.json
+13
_journals/2025-06-03_0724.md
+13
_journals/2025-06-03_0724.md
···+[[Steve Klabnik]] is [disappointed in the AI discourse](https://steveklabnik.com/writing/i-am-disappointed-in-the-ai-discourse/) "all of the discussion online around AI is so incredibly polarized…both the pro-AI and anti-AI sides are loudly proclaiming things that are pretty trivially verifiable as not true"+He recommends two good reads: [The Software Engineering Identity Crisis](https://annievella.com/posts/the-software-engineering-identity-crisis/) and [Algorithmic Underground](https://jmsdnns.com/tech/algo-underground/)
+13
_journals/2025-06-12_1420.md
+13
_journals/2025-06-12_1420.md
···+[Justin Searls explains why to be excited](https://justin.searls.co/posts/these-4-code-snippets-won-wwdc/) about what Apple announced about LLMs at WWDC. One is that developers can do "free, unlimited invocation of Apple's on-device language models", so zero cost LLM features by using a user's own device. The rest is about native support in Swift for working with LLMs.
+10
_journals/2025-06-13_1222.md
+10
_journals/2025-06-13_1222.md
···+As part of walking the startup showcase at Web Summit Vancouver, I saw [Forestwalk Labs](https://forestwalk.ai/) [demo'ing Timberline](https://www.youtube.com/watch?v=0ptXBlsZwC0), their agentic Mac app - building task management in an agent-first way.
+13
_journals/2025-06-13_1236.md
+13
_journals/2025-06-13_1236.md
···+[[Tonk]] [released an explainer](https://tonk.substack.com/p/tonk-the-explainer) about their new release - "a CLI that helps you vibe code your second brain", "designed to simplify the process of building custom dashboards, tools, and AI agents using your own data."
+10
_journals/2025-06-13_1249.md
+10
_journals/2025-06-13_1249.md
+26
_notes/Against the Dark Forest.md
+26
_notes/Against the Dark Forest.md
···+Kissane argues for not ceding the public social Internet predators and having only the privileged exist in Cozy Web space.+> The complex of ideas I’m going to call the Dark Internet Forest emerges from mostly insidery tech thinking, but from multiple directions—initially in Kickstarter co-founder Yancey Strickler’s [freeform noticings](https://www.ystrickler.com/the-dark-forest-theory-of-the-internet/) that apply science fiction writer Liu Cixin's dark forest theory of the universe to social media, then in humanist all-arounder Maggie Appleton’s [illustrated tech notes](https://maggieappleton.com/cozy-web) [[Dark Forest and Cozy Web]]. It names an experience of paranoia and anxiety that by the end of the 2010s was widespread among people with meaningful connections between their online personas and their ability to maintain their standard of living. It hit a nerve, especially within some corners of tech-and-society thinking that influence internet makers. It even shows up in a [_New York Review of Books_ piece](https://www.nybooks.com/online/2024/05/04/more-real-than-life-i-saw-the-tv-glow/): a coup for something so initially modest.+One of the confusing points for me is that [[Dark Forest]] has ended up being explained in two opposite directions: what is listed below as "beneficial dark forests" is in fact the [[Cozy Web]] of permissioned spaces.+> For Strickler, the internet was becoming just such a perilous dark forest, stalked by shadowy forces. Or, one sentence later, it was becoming a series of beneficial dark forests that provide refuge for the imperiled. These protective forests included newsletters and podcasts, but also, “Slack channels, private Instagrams, invite-only message boards, text groups, Snapchat, WeChat, and on and on.”+> here’s the idea that “dark forest” internet spaces serve as refuges because they’re “non-indexed, non-optimized, and non-gamified.” And further, that dark forest spaces grow “because they provide psychological and reputational cover. They allow us to be ourselves because we know who else is there.”+So, Kissane's post here would be called "Against the Cozy Web", where the intent here is to push back against [[Brazilianization of the Internet]]+> In a framework for thinking about our networks, to leave out the majority of people sustaining real damage is a failure of _perception_ and of _proportion_. It matters because the remedies available to people like me—a white, tech-ish worker in the US—are not necessarily going to do much for the people bearing the brunt of the mega-platforms’ worst actions.+As a call to privileged folks who can build their own Cozy Web, Kissane says that we need to not retreat and leave the long tail of the public open to predation:+> The public social internet is worth designing and governing in a way that demonstrates less than total amnesia about the history of human civilizations and the ways we’ve learned to be together without killing each other. For people with the ability and willingness to work on network problems, the real choice isn't between staying on the wasteland surfaces of the internet and going underground, but between making safer and better places for human sociability and not doing that.
+13
_notes/Anselm Eickhoff.md
+13
_notes/Anselm Eickhoff.md
···
+2
-2
_notes/Brazilianization of the Internet.md
+2
-2
_notes/Brazilianization of the Internet.md
···> Talking to no one is the near future of social media, the digital equivalent of warming your hands over an oil drum bonfire in an abandoned city-> As we retreat from the toxic, cluttered social media clearnet to the newsletter-and-messaging [[cozyweb]], this is closer to the real future of the internet: Each of us armoring our digital selves with a carefully constructed array of filters to let in the good and keep out the bad+> As we retreat from the toxic, cluttered social media clearnet to the newsletter-and-messaging [[Cozy Web]], this is closer to the real future of the internet: Each of us armoring our digital selves with a carefully constructed array of filters to let in the good and keep out the bad-Clearnet here is actually [[dark forest]] theory, where the open or “clear” internet bombards us with things we don’t want. Whether that’s spam, irrelevance, ads, or active toxic responses from other humans.+Clearnet here is actually [[Dark Forest]] theory, where the open or “clear” internet bombards us with things we don’t want. Whether that’s spam, irrelevance, ads, or active toxic responses from other humans.> <mark>humans themselves will have a harder time competing for attention and access</mark>. In a landscape that feels increasingly noisy and polluted, this challenge is heightened even further, as the stabilizing elements steadily retreat from it, creating a vicious cycle where the spam and fury become ever more concentrated.
+46
-14
_notes/Community Search Engine.md
+46
-14
_notes/Community Search Engine.md
···+**Community Search Engines** are an approach to build highly relevant search indexes and collaborative content spaces for communities.+The interface is similar to agent chat interfaces -- chatting and refining to get what you're looking for -- as well as personal notes / bookmark collections[^tft] -- browsing and interacting with "your stuff" to find what you've stored before.+[^tft]: I'm not using tools for thought or second brain labels here. For those that have adopted such a system, its content would be a major input to such a system.+I'm using the label search engine as a term that I think will resonate with the mass market: you go there to find stuff.-These are often communities of interest, but can also considered to be trust relationships: if you are connected to a group of people you may extend trust to other recommendations they make.+Google has broke the social contract of search. Even without [[AI slop]] being placed as the first "result", the results returned lead to top ranking pages that themselves are low quality SEO garbage.+OK, I'll ask my friends for what they think! But, on corporate social platforms such as Twitter, Instagram, or Threads, the algorithm is centrally controlled and can't be scoped to your friends.+You're not sure that your request will be seen by your connections, and your connections won't necessarily see your post.+* discovery -- browsing and finding what you're looking for, ideally with a tune-able, transparent algorithm+* distribution -- being able to share "your stuff" in a way that it's possible for others to in turn see it and discover it+For both, we think that [[Open Social Protocols]] offer a way forward. We also think distribution is up stream of discovery aka [[DREAM]].+If your information isn't seen because it isn't indexed or shared, or is algorithmically black holed or suppressed, it can't be discovered.+[[DXOS]] has their [[DXOS Composer]] suite. Local first content, LLM models, and composition of a number of different tools, from Discord API connections for indexing, to audio / video transcription.+The [[Patchwork]] system by [[Ink & Switch]] stores data local-first, cached in your browser. It relies on [[Automerge]] for sync. It doesn't have much in the way of a search index at all, and until [[Keyhive]] is integrated, doesn't have a permissions system. It can do multiplayer collaboration by sharing links to content.+[[Groundmist]] is a proof of concept that uses [[Ink & Switch]]'s tiny essay editor with local-first, private data (a precursor to Patchwork, it also uses [[Automerge]]) and combines it with [[ATProtocol]] for public publishing as well as structured data via the AT Protocol Lexicon system.+[[Tonk]] has just released the [Tonk CLI and TonkbookLM](https://tonk.substack.com/p/tonk-the-explainer). Uses [[Automerge]]. Specifically mentions [[Obsidian]] as a source of local data.+I envision a [[Personal Notes & Publishing Stack]] that enables people and communities to collaborate, pool information, and add context and relevance.[[Dark Forest and Cozy Web]]: communities are moving to cozy web spaces, and/or have need for members only content. The open internet has degraded search incentivized by click throughs to show ads, and commercial social platforms-[[Brazilianization of the Internet]]: forming communities, which can be considered a kind of commons, do exclude or make [[cozyweb]] spaces. Does this cause a kind of elitism, and/or further deteriorate public spaces?+[[Brazilianization of the Internet]]: forming communities, which can be considered a kind of commons, trending towards [[Cozy Web]] spaces. Does this cause a kind of elitism, and/or further deteriorate public spaces?+[[Erin Kissane]]'s [[Against the Dark Forest]] specifically argues that we need to protect the publis social internet and not all retreat into [[Cozy Web]] corners. The entire article is dense and amazing and I could quote every paragraph.[[How Algolia uses Electron to improve internal productivity]]: I’m still inspired by this description of Algolia implementing company wide search across internal tools, with desktop integration. This should be a tool for organizations of all kinds.-I applied to [[SoP 2024 Application]] with some ideas around this that has some longer writing.-Part of community is "flow" ([[Stock and Flow]]) and [[Proto Apps]] is how I think social graphs / communities / flows of information form.+I applied to [[SoP 2024 Application]] with some ideas around the original formulation of using events and digital communities as a way to bootstrap the search engine, without tackling the [[Personal Notes & Publishing Stack]].+Part of community is "flow" ([[Stock and Flow]]) and [[Proto Apps]] is how I think social graphs / communities / flows of information form.
+20
_notes/Cozy Web.md
+20
_notes/Cozy Web.md
···+> We create tiny underground burrows of Slack channels, Whatsapp groups, Discord chats, and Telegram streams that offer shelter and respite from the aggressively public nature of Facebook, Twitter, and every recruiter looking to connect on LinkedIn.+> It's the digital realm of [Domestic Cozy](https://www.ribbonfarm.com/series/domestic-cozy/) Gen-Z vibes. Casual, comfy, and not trying to kick up a fuss.+[[Against the Dark Forest]] is [[Erin Kissane]]'s article that uses the alternative formulation, and in my formulation would be called _Against the Cozy Web_.
+8
_notes/DXOS Composer.md
+8
_notes/DXOS Composer.md
+17
_notes/DXOS.md
+17
_notes/DXOS.md
···+DXOS is an open source framework for building real-time, collaborative web applications that run entirely on the client and communicate peer-to-peer, without the need for centralized servers.+* [Echo](https://docs.dxos.org/guide/echo/) - **E**ventually **C**onsistent **H**ierarchical **O**bject store is a peer-to-peer graph database written in TypeScript.+* [Halo](https://docs.dxos.org/guide/halo/) - The HALO **protocol** supports the verification, transport, and exchange of identity information between networked peers.
+6
-4
_notes/Dark Forest and Cozy Web.md
+6
-4
_notes/Dark Forest and Cozy Web.md
···+Maggie Appleton’s illustration of Dark Forest vs Cozy Web is amazing - visit her article to check it out.> The cozy web is [[Venkatesh Rao]]’s term for the private, gatekeeper-bounded spaces of the internet we have all retreated to over the last few years.> Venkat first proposed the term in one of his *Breaking Smart* emails on [The Extended Internet Universe](https://studio.ribbonfarm.com/p/the-extended-internet-universe). He builds off Yancey Strickler's companion idea of [the Dark Forest](https://onezero.medium.com/the-dark-forest-theory-of-the-internet-7dc3e68a7cb1) theory of the web. The “dark forest” is a place that *seems* eerily quiet and devoid of life. All the living creatures within it are hiding. Because “night is when the predators come out. To survive, the animals stay silent.”> The predators here are the advertisers, tracking bots, clickbait creators, attention-hungry influencers, reply guys, and trolls. It's unsafe to reveal yourself to them in any authentic way. So we retreat into private spaces. We hide in the cozy web.+Private / members only areas that mostly look like chats or private forums are the [[Cozy Web]]> We create tiny underground burrows of Slack channels, Whatsapp groups, Discord chats, and Telegram streams that offer shelter and respite from the aggressively public nature of Facebook, Twitter, and every recruiter looking to connect on LinkedIn.
+20
_notes/Dark Forest.md
+20
_notes/Dark Forest.md
···+Description of the current state of the "open web", where ads, tracking, pop-ups, scams, mis-information are at every turn of a user's journey, which is causing many to retreat to [[Cozy Web]] spaces that are smaller group and permissioned.+> The predators here are the advertisers, tracking bots, clickbait creators, attention-hungry influencers, reply guys, and trolls. It's unsafe to reveal yourself to them in any authentic way. So we retreat into private spaces. We hide in the cozy web.+Confusingly, Dark Forest by itself can be argued in both directions -- that Dark Forest is both a space where one can be attacked when moving in the open, but that "protective forests" are where people can hide. In my formulation, these protective forests are the [[Cozy Web]].+The concept was recently popularized by the sci-fi book, [Dark forest hypothesis (Wikipedia)](https://en.wikipedia.org/wiki/Dark_forest_hypothesis):+> The **dark forest hypothesis** is the conjecture that many alien civilizations exist throughout the universe, but they are both silent and hostile, maintaining their undetectability for fear of being destroyed by another hostile and undetected civilization. It is one of many possible explanations of the [Fermi paradox](https://en.wikipedia.org/wiki/Fermi_paradox "Fermi paradox"), which contrasts the lack of contact with alien life with the potential for such contact. The hypothesis derives its name from [Liu Cixin](https://en.wikipedia.org/wiki/Liu_Cixin "Liu Cixin")'s 2008 novel _[The Dark Forest](https://en.wikipedia.org/wiki/The_Dark_Forest "The Dark Forest")_, although the concept predates the novel.
+30
-1
_notes/Familiar.md
+30
-1
_notes/Familiar.md
···> Dialog is designed for the user-origin web. A Dialog database is content addressed, forkable, mergeable and efficiently syncable. It is local-first, runs in a web browser tab, and works just fine when the user's device is completely offline. It assumes a user-centered authority model; no external authority is required to enable any of its features. It is even agnostic to the transport used when syncing across forks and replicas ([sneakernets](https://en.wikipedia.org/wiki/Sneakernet) welcome).-> Dialog will sound familiar to those of you who followed along when I was building Noosphere. Noosphere was remarkably effective for what it was. But, Noosphere made different trade-offs. I am hopeful that the trade-offs we have chosen for Dialog will make it a worthy successor and more generalized to boot.+> Dialog will sound familiar to those of you who followed along when I was building Noosphere. Noosphere was remarkably effective for what it was. But, Noosphere made different trade-offs. I am hopeful that the trade-offs we have chosen for Dialog will make it a worthy successor and more generalized to boot.+> I'm three months into the effort to bootstrap Familiar. The jet lag is waning after my travel to and from the second annual Local-First Conference in Berlin. The premise of "LoFi" is in the name: developers increasingly value the end-user experience of network software that is able to run on their users' device with or without network availability. The talks were interesting across the board if you care about this topic (and you can stream them [here on YouTube](https://www.youtube.com/playlist?list=PL4isNRKAwz2MabH6AMhUz1yS3j1DqGdtT)). My high-level takeaways are:+> - **Sync is a major topic of concern for local-first software:** many (if not most) of the talks either focused on state synchronization, or included it as a major element of the presentation; there were several talks by folks building developer tools focused on enabling a combination local caching + some form of real-time synchronization of the local cache.+> - **Most local-first stacks still assume server authority:** from the OG local-first duo [PouchDB](https://pouchdb.com/)/[CouchDB](https://couchdb.apache.org/), to more recent projects like [[Jazz]]) and [Zero](http://zero.rocicorp.dev), many of our tools still assume that there is a centralized canonical data source that is (probably) not controlled by the "local" user, which is another way of saying that they are built for a [Same-origin Policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy) web.+> **We still haven't cracked the local-first authority model:** we have a lot of tools that enable local-first data, but scant options for local-first authority; I was excited to learn about the progress being made on [Keyhive and Beelay](https://www.inkandswitch.com/keyhive/notebook/), a promising initiative being driven by some of the most talented people who are working on these problems. Much work remains ahead of us.+> The passion and ingenuity on display at the conference was exhilarating. But, I remain preoccupied with ruminations about power and how it manifests in the network. Most of the tools that we are building assume an authoritarian web. [An excellent talk by Robin Berjon](https://www.youtube.com/watch?v=BbqZvp7D_nY) hit YouTube recently that explores the implications of this assumption. The Single-origin Policy web begets a digital feudal system, and this power structure in the network is increasingly shaping the power structures of our society. We need to make new assumptions, new kinds of tools and new institutions as we seek to subvert the powers that be.+>Dialog DB is nascent and highly experimental, but if it interests you then I invite you to [follow its ongoing development on Github](https://github.com/dialog-db/dialog-db).+Dialog is being designed for a local-first, User-origin Policy web. Users of the single-origin web give up authority over their identity and their data to the hegemon of a digital fief. The user-origin web places the root of authority in the hands of each user. So, in Dialog:+- The canonical replica of a user's data is the local copy - the one on their device - even when the database lives in a web browser tab+- Authority is encoded in the data itself so it access control is self-evident and moves with data as it replicates across the network+- The server's role is to facilitate the transfer of data between replicas; it can be "dumb" storage (e.g., Amazon S3)+Dialog makes a new assumption about the shape of the web: that there may not be a server (and even when there is a server, it is not the canonical authority over a user's data). I gave a vertical slice demo of Dialog's query and "serverless" replication properties in Berlin; [here is a hastily recorded screencast of the demo](https://youtu.be/0a_Nb2CAoJc).
+17
_notes/Forestwalk Labs.md
+17
_notes/Forestwalk Labs.md
···+Building products that help teams do their best work. Forestwalk is building delightful LLM-powered tools that solve teams' problems.+<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/0ptXBlsZwC0?si=pwKfEjKroSBpWhRu" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
+5
-1
_notes/Goal Workspaces.md
+5
-1
_notes/Goal Workspaces.md
···As AI-based [[agentic computing]] evolves, these goal workspaces share data, feedback, interfaces, visualizations, and outputs that lead towards some goal.+This concept, of goal seeking within a shared space with multiple people and agents collaborating, is likely premature.
+51
_notes/How To Scale a Development Team.md
+51
_notes/How To Scale a Development Team.md
···+> As hackers, we’re familiar with the need to scale web servers, databases, and other software systems. An equally important challenge in a growing business is scaling your development team.+> Most technology companies hit a wall with dev team scalability somewhere around ten developers. Having navigated this process fairly successfully over the last few years at Heroku, this post will present what I see as the stages of life in a development team, and the problems and potential solutions at each stage.+> Grow to 10 - 15 developers, and you’re on the verge of a major team structure change. I’ve been told that many promising startups have been killed by failing to weather the transition between these stages.+> With this many developers, iteration planning, standups, or any other kind of development-team meeting has become so big that the attendees spend most of their time bored. Any individual developer will find it difficult to find a sense of purpose or shared direction in the midst of trudging through laundry lists of details on other people’s work.+> In programming, when a class or sourcefile gets to big, the solution is to break it down into smaller pieces. The same principle holds for scaling a development organization. You need to break into targeted teams.+> In the earlier stages, you should avoid attacking on multiple battlefronts, and instead keep all developers focused around a single goal for the company. With creation of fiefdoms for each team, this has changed. Now you can and should attack on multiple battlefronts. Each team should be executing independently against its own goals, and not worrying too much about what other teams are doing.+> But now you have a new problem: lack of cohesion. Your decentralized teams are setting their own roadmaps and deciding on features independently. But to avoid fragmentation in your product, someone needs to decide an overall direction and set of product values. More succinctly: you need a strategy.
+15
_notes/Infer.md
+15
_notes/Infer.md
···+Infer is Vancouver's meetup for tactics, techniques, and lessons learned in LLM and AI engineering.
+14
_notes/Jazz.md
+14
_notes/Jazz.md
···+Jazz gives you data without needing a database — plus auth, permissions, files and multiplayer without needing a backend.+<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/E7UNbIf6oA4?si=kaA_Enb82U7q0yyy" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
+1
-1
_notes/Local First.md
+1
-1
_notes/Local First.md
_notes/Local-first Software.md
_notes/Local-first Software Essay.md
_notes/Local-first Software.md
_notes/Local-first Software Essay.md
+135
_notes/Malleable Software Essay.md
+135
_notes/Malleable Software Essay.md
···+> tools that users can reshape with minimal friction to suit their unique needs. Modification becomes routine, not exceptional. Adaptation happens at the point of use, not through engineering teams at distant corporations.+> [[Geoffrey Litt]], Josh Horowitz, Peter van Hardenberg, and Todd Matthews. 2025. **Malleable Software: Restoring User Agency in a World of Locked-Down Apps**. Ink & Switch. https://www.inkandswitch.com/essay/malleable-software/.+#### [We want to adapt our environments](https://www.inkandswitch.com/essay/malleable-software/#we-want-to-adapt-our-environments)+#### [Mass-produced software is too rigid](https://www.inkandswitch.com/essay/malleable-software/#mass-produced-software-is-too-rigid)+> Before, new ideas took minutes to try; now they could take hours of wrangling configurations, if they were possible at all. **Computerizing work led to a loss of agency.**+> It may seem inevitable that our specific requirements aren’t served by our software—but that’s only because we’ve taken for granted that software is controlled by centralized development teams. What if we were to shift more control into the hands of users who know their own needs?+> App stores are designed for companies distributing software to consumers, not amateurs sharing tools with their friends. This is a system of industrial mass production, not small-scale craft.+This is interesting, but it also leads me to think about what the civilizational substrate of software needs to be, in order to serve the needs of the many, and how that is in opposition to "small scale craft". The equivalent of aqueducts and sewers. Sync engines, accounts, user owned data, and encryption.+#### [Our goal: malleable software](https://www.inkandswitch.com/essay/malleable-software/#our-goal-malleable-software)+#### [Existing approaches](https://www.inkandswitch.com/essay/malleable-software/#existing-approaches)+> <mark>Going from installing plugins to _making_ one is a chasm that’s hard to cross.</mark> And each app has its own distinct plugin system, making it typically impossible to share plugins across different apps.+> The open source software movement promotes the idea of distributing source code so that users of software can own their software, contribute back to it, and if needed create their own version that better meets their own needs. <mark>This has been a positive force for the world, and represents an important ingredient for malleability.</mark>+> But having access to edit the code doesn’t mean minimal friction. **Modifying a serious open source codebase usually requires significant expertise and effort**. This applies even for making a tiny change, like changing the color of a button . Even for a skilled programmer, setting up a development environment and getting acquainted with a codebase represents enough of a hurdle that it’s not casually pursued in the moment.+I am less positive on open source, or rather the mere existence of a certain kind of license. [[Proto Apps]], with user owned data means that as a user, I can move between apps or switch between clients regardless of their license.+> There is now momentum towards a world where anyone can generate a web application from a chat, without needing any programming experience.+> How can users tweak the _existing_ tools they’ve installed, rather than just making new siloed applications? How can AI-generated tools compose with one another to build up larger workflows over shared data? And how can we let users take more direct, precise control over tweaking their software, without needing to resort to AI coding for even the tiniest change? None of these questions are addressed by products that generate a cloud-hosted application from a prompt.+> **Bringing AI coding tools into today’s software ecosystem is like bringing a talented sous chef to a food court.** If you’re used purchasing meals from a menu, a skilled chef can’t do much to help you. Similarly, if you’re using closed-source software from an app store, an AI coding assistant can’t do very much to help you as a user. <mark>To fully take advantage of the capabilities of AI, we need to move past the food court to something more like a kitchen—a site of open-ended creation</mark>.+> This essay isn’t an exhaustive survey of all work on malleability. For a longer reading list, we recommend the [Malleable Systems Collective catalog](https://malleable.systems/catalog/).+### [A gentle slope from user to creator](https://www.inkandswitch.com/essay/malleable-software/#a-gentle-slope-from-user-to-creator)+> So far we’ve focused on the rigidity of individual applications. But there’s another reason that it’s hard to adapt software to meet our needs: the very idea of “applications”. Because we’re so accustomed to this idea, it can be hard to see the nature of the problem—so let’s consider an analogy from the kitchen.+#### [Apps are avocado slicers](https://www.inkandswitch.com/essay/malleable-software/#apps-are-avocado-slicers)+> …because the avocado slicer is narrowly focused on one task, it’s useless at anything else. If you used a specialized gadget for every single task, you’d end up with a mountain of plastic.+> How does this analogy apply to software? **Many applications are avocado slicers.** They’re a bundle of functionality targeted at some specific use case: planning a trip, tracking workouts, organizing recipes. Because an app needs to handle many tasks associated with a use case, it sometimes doesn’t handle any of them particularly well. You may have come across situations where an app is missing some functionality that’s important to you, while simultaneously including extra bits you don’t need.+> On top of that, solving a larger task using multiple applications often requires manual coordination. We can put windows next to each other and copy-paste data, but not much more. If we want more knife-like software tools, we’ll need better ways for smaller software tools to work together.+> **How might we reorient software around more general, composable tools**—that feels more like a knife and less like an avocado slicer? There are two sub-problems to address: sharing data between tools, and combining tools within the user interface.+> A key inspiration in this area is Michel Beaudouin-Lafon’s work on [Instrumental Interaction](https://dl.acm.org/doi/10.1145/332040.332473) described in his talk [A World Without Apps](https://www.youtube.com/watch?v=ntaudUum06E).+#### [Sharing data between tools](https://www.inkandswitch.com/essay/malleable-software/#sharing-data-between-tools)+#### [Composing the user interface](https://www.inkandswitch.com/essay/malleable-software/#composing-the-user-interface)+### [Communal creation](https://www.inkandswitch.com/essay/malleable-software/#communal-creation)+> And there’s an even more fundamental reason to think of malleability through a communal lens: we use computers together! A product team needs a single system for tracking projects. A department at a hospital needs a single system for patient intake forms. These communities are certainly not well-served by one-size-fits-all applications they have no control over. But the solution can’t be every-user-for-themselves either. We should help communities build and maintain _shared_ solutions to their problems.+> See [The inequities of our remote gathering tools](https://medium.com/@paulate/the-inequities-of-our-remote-gathering-tools-185f0446b0f6) for more on how one-size-fits-all apps like Zoom can disrupt democratic social dynamics.+> **With the right infrastructure, we can work together to craft our software.** People with similar needs around the world can exchange work and build collaboratively, as we have seen happen in free-software communities. And local communities, from companies to families to civic organizations, can build and maintain software suited to their local needs. When local needs get higher up the “slope” and call for special levels of skill and enthusiasm, you don’t need everyone in a community to attain these levels – just enough people to play that role and get the job done.+> **Building software for “local” contexts is sometimes _easier_ than building software for world-wide use.** You don’t need to build airtight, industrial-grade software if you are in direct contact with your users and can be responsive to the situations they run into. You don’t need to anticipate everyone’s needs in your design, just your community’s.+> On an even more intimate level, Robin Sloan memorably described how an app built for his family could be a [“home-cooked meal”](https://www.robinsloan.com/notes/home-cooked-app/).+### [Ink & Switch prototypes](https://www.inkandswitch.com/essay/malleable-software/#ink-switch-prototypes)+> **we have been prototyping an infrastructure stack for building, running, and sharing software that prioritizes malleability.** Our approach builds on another area of our research: local-first software [[Local-first Software Essay]], which is a philosophy that prioritizes giving users ownership and control over their data, while maintaining the ability to collaborate with others. As part of that work, we developed a collaboration library called [[Automerge]], which persists and synchronizes JSON documents among users.+> Another thing we’ve found while customizing Patchwork is that **AI is a useful complement to a malleable environment.** We argued earlier that AI-assisted coding alone does not guarantee malleability. But _when combined with a malleable environment_, AI-assisted development can make it much faster to edit your tools.+> We’ve used AI assistance to rapidly build many tools in Patchwork. The Section Word Counter tool mentioned above was coded with AI assistance in just a few minutes—in the middle of a writing session, without needing to set aside dedicated time.+> A malleable environment can also provide platform capabilities that make AI-generated software more useful. For example: we have an interface for making small software tools from an AI chat. While this UI superficially resembles existing products like [Claude Artifacts](https://support.anthropic.com/en/articles/9487310-what-are-artifacts-and-how-do-i-use-them), the generated tools gain capabilities from existing inside of Patchwork. They automatically support persistence and multi-user collaboration, and can compose with existing tools for editing existing data.+> A related challenge is managing expectations of quality. Most of the tools we’ve built aren’t anywhere close to the polish level of commercial products; they’re scrappy personal tools. When someone shares a tool, how can they communicate its level of quality? There’s a difference between sharing a tool “as-is” and committing to ongoing maintenance.+#### [Infrastructure for malleability](https://www.inkandswitch.com/essay/malleable-software/#infrastructure-for-malleability)+#### [Dynamic documents](https://www.inkandswitch.com/essay/malleable-software/#dynamic-documents)+### [Towards a better future](https://www.inkandswitch.com/essay/malleable-software/#towards-a-better-future)+> **Privacy and security**: How do we reconcile the desire for extensible software and interoperability with the reality of bad actors? When untrusted strangers are sharing modifications to existing software that can access sensitive data, dangerous things can happen.+> **Business models**: How would developers make money from their software if they were shipping composable tools, not monolithic applications? How is support and maintenance paid for?+> **Culture**: How do we cultivate a movement towards personal agency where people _want_ to modify their environments, both digital and otherwise?+> These are daunting challenges. <mark>Technical capabilities can’t be a full solution; economic and cultural shifts will also be required.</mark> But change is possible—computing is still young, it has changed a lot in the past decades, and surely many structural shifts still lie ahead.+> Everyone deserves the right to evolve their digital environments. It’s an important way to fulfill our creative potential and maintain a sense of agency in a world that is increasingly defined in code.
+1
-1
_notes/Malleable Software.md
+1
-1
_notes/Malleable Software.md
···> Designing software environments where people can customize tools in the moment to meet their unique needs.-The "Malleable Software Essay" has not yet been published. It aims to set a foundation much as their April 2019 [[Local-first Software]] essay did.+The [[Malleable Software Essay]] essay was published in June 2025. It aims to set a foundation much as their April 2019 [[Local-first Software Essay]] essay did.
+57
_notes/Malleable Systems Collective.md
+57
_notes/Malleable Systems Collective.md
···+> This catalog highlights projects, people, groups, research, discussions, and other initiatives in the malleable software community. It is our hope that bringing more awareness to these efforts will lead to greater collaboration and better systems for us all that support the [essential principles](https://malleable.systems/mission/) of malleability.+The Malleable Systems Collective is a community space that [catalogs](https://malleable.systems/catalog/) and experiments with **malleable software and systems** that reset the balance of power via several essential principles detailed below.+For all of these principles, it is not yet clear how to best achieve them, and there are sure to be many possible solutions with different tradeoffs. We’ll need to experiment as community with various approaches. The collective’s primary goal is to report on such efforts and raise awareness of work in these directions.+_All layers, from the user interface through functionality to the data within, must support arbitrary recombination and reuse in new environments._+_Tools should strive to be easy to begin working with but still have lots of open-ended potential._+_Modifying a system should happen in the context of use, rather than through some separate development toolchain and skill set.[^3]+Modern computing is a jungle of arcane, inscrutable tools that throw up walls of difficult to parse errors that slowly chip away at your enjoyment of the creative work of building something new. While today much of this is only seen by software developers, it does sometimes leak through, such as when raw error messages are displayed.+If we are to have any hope of giving all people the same power over computers currently accessible only to experts, we must get rid of these obstacles by refining our tools so that we can focus more on the actual goal, which should make computing more fun and accessible to all.+Most contemporary applications fail to meet all of these principles, leaving us with no pathway towards improvement. The only option is to plead with the app developer and hope they will deign to grant your request. As the importance of computing in everyday life grows with each passing year, we must fight for these values to ensure the power of computing is evenly distributed.+[^1]: This paraphrases [User-tailorable systems: pressing the issues with buttons](https://dl.acm.org/citation.cfm?doid=97243.97271) (MacLean et al., 1990): “it should be as easy to change the environment as it is to use it”.+[^2]: This is adapted from [What Lies in the Path of the Revolution](https://malleable.systems/catalog/#revolution) (Basman and Tchernavskij, 2018) who argue that “all authors should have the ability to freely contribute their expressions to the work of others, and freely ‘buy into’ and ‘buy out of’ the expressions of others”.+[^3]: This draws on similar themes from the [in-place toolchain](https://www.inkandswitch.com/end-user-programming.html#in-place-toolchain) section of [End-user programming](https://malleable.systems/catalog/#enduser) (Ink & Switch, 2019).
+51
-11
_notes/Personal Notes & Publishing Stack.md
+51
-11
_notes/Personal Notes & Publishing Stack.md
···-The base line tool that I am looking for to anchor [[Community Search Engine]] is a multi-player personal notes & publishing stack.+The base line tool that I am looking for to anchor [[Community Search Engine]] is a multi-player personal notes & publishing stack. I have cataloged many emergent tools and tech stacks on the Community Search Engine that are now very close to what I have envisioned.You should feel comfortable putting meeting notes, quick scratch notes, pages on their way to be published, links and a few comments, research from multiple web pages, and other material in here. It is your companion for research, progress, and evolution.···It wants to be the digital place where your family group, project team, or entire small business go to find, document, and extend a growing model of useful information.It's where you store the results from searching, browsing, or collaborative agent-based research sessions.···* backlinks, where linking to a note also showcases a "backlink" when viewing the note. This creates a graph of linked notesThere are some other features like tags, aliases or transclusion that needs some more thinking.Increasingly, the concept of author / creating / updating over time is an extremely useful anchor.Opening notes and having date / time stamps as a default entry is good. Simple mode is one "day" note per day. A more excellent mode that also fits with shorter content publishing and sharing is block-based unique notes.-Visually, collecting notes into day / week / month chunks is one way to display aka a "log" or "work log". So a day becomes a view, but can contain multiple+Visually, collecting notes into day / week / month chunks is one way to display aka a "log" or "work log". So a day becomes a view, but can contain multiple blocks or sub notes.+Ultimately, date & time data is metadata and can be used to create a view of any kinds of content.-Export and import of Markdown notes should be supported, but strict representation of one note == one file at all times is not necessary.+Links are a primary way to remember or have quick access to "remote" content. Bookmark style for when you want to easily access the link (e.g. BC Ferries schedule), or informative / normative, like keeping a link to the restaurant in your neighbourhood that you recommend, even though you don't really visit the page.+On the other hand, there is the Clipping use case -- you want to quote, annotate, or comment on remote content and keep it locally, which adds relevance for you and other readers.+Including the full content of remote links makes for a richer local index when you're querying and working with your own content. When contributed to a [[Community Search Engine]], one gets both a community relevance graph (people who have bookmarked / clipped a link) and a sense graph, where different people have quoted / annotated / commented on the link.Multi-player does not necessarily mean real time collaborative editing. It starts with a single person having multiple devices where things are kept in sync, and goes from there to groups of people.-The hardest part of multi player notes is permission management. "Open" collaborative notes like [[HedgeDoc]] are easy, but can suffer from spam. Security through security by sharing links to hashes can work pretty well.+Zooming out from Personal Notes, a multi-player space can be one note that is being collaborated on, to group collections of content, which in turn forms context.+The [[Community Search Engine]] is formed by collections of multi-player notes, context, and relevance.+The hardest part of multi player notes is permission management. "Open" collaborative notes like [[HedgeDoc]] are easy, but can suffer from spam. Security through obscurity by sharing links to hashes can work pretty well.The "folder" model seems conceptually simplest. Make a folder, add access at that level, and then everything inside inherits that.Sharing the same info with multiple different groups outside of a strict hierarchy is a challenge. This might mean using something like tagging to grant access. This is both a UX (what do you do in practice to share) and UI issue (how do you display shared docs or approximate GDocs permission listing).-Google Drive has ended up with this concept of "aliases", in order to have a document in multiple folders. Google Drive also complicates the folder model by allowing for different permissions inside a single folder. This means that everyone has a different view. Related: having variable "views" might be needed along with "baked" views where everyone has the same picture. Views might in fact be something that you collect or curate and then publish to a group.+Google Drive has ended up with this concept of "aliases", in order to have a document in multiple folders. Google Drive also complicates the folder model by allowing for different permissions inside a single folder. This means that everyone has a different view.+Related: having variable "views" might be needed along with "baked" views where everyone has the same picture. Views might in fact be something that you collect or curate and then publish to a group.+The [[Keyhive]] model, with encrypted content and capabilities delegated to individuals and groups, is the front runner of something that can work [[Local First]] and be sufficiently private, but doesn't itself have an opinionated UX, which is likely to be implemented in [[Patchwork]].+As soon as you have multi-player, you will want concepts like comments and notifications/mentions as people collaborate.+I see the majority of public / social affordances here being anchored in [[ATProtocol]] identities, although the scope here is all private / permissioned data. A publishing work flow in such a way that you can privately comment or favourite rather than only in public.+If we envision multi-player collaboration as including agents as well as human actors, a group might contain one or more [[Goal Workspaces]].+As well as personal, private usage, you want multi-player sharing with groups, and finally publishing.+Permissioned access at world scale (e.g. larger than the multi-player groups who collaborate with edit / comment access) is left for a future evolution of [[AT Protocol Private Data]].-How does one collect multiple people and agents into [[Goal Workspaces]]? A shared space with some goal, where different views, visualizations, interfaces, and data sources can be pooled to meet that goal.
+2
-2
_notes/Seeds.md
+2
-2
_notes/Seeds.md
···- I think a lot about [[commons funding]]. I haven't done enough original writing about it. [[Open Collective]] is a great platform I recommend for managing funding and disbursement, without needing a foundation or organization of any kind.···> Unlike the main public internet, which runs on the (human) protocol of “users” clicking on links on public pages/apps maintained by “publishers”, the cozyweb works on the (human) protocol of everybody cutting-and-pasting bits of text, images, URLs, and screenshots across live streams. Much of this content is poorly addressable, poorly searchable, and very vulnerable to bitrot.> Software companies founded today are competing less with pen and paper than with other Internet-first incumbents. Put another way, as happens in every maturing industry before it, Internet company revenue will become zero-sum. As a corollary, the time between founding years of software startups and their competitive incumbents is shrinking:
+14
_notes/Steve Klabnik.md
+14
_notes/Steve Klabnik.md
···+<script type="module" src="https://cdn.jsdelivr.net/npm/bsky-embed/dist/bsky-embed.es.js" async></script>
+16
-13
_notes/Tonk.md
+16
-13
_notes/Tonk.md
···-Tonk is a copilot-friendly framework that helps developers build grassroots apps on **decentralised, interoperable, private** data stores.-If you're building personal apps for you and your friends, and want to keep them **independent**, **flexible** & **discreet**, then Tonk is for you.-Tonk is an opinionated state management framework for coding with AI. It's analogous to Ruby on Rails, but for AI, and optimised for putting users in control of their data (rather than platforms).+Tonk's mission is to create a world in which people are free to build their own software and collaborate over their own networks.+AI is fuelling a surge of creative technologists crafting personal tools bespoke to local contexts - where working with data feels as intuitive as molding putty.+But for symbiotic software to evolve at the speed of thought, we need better data infrastructure that's lightweight, flexible and interoperable.+As the web fragments into unique digital worlds, we envisage a cryptographic, maximally-interoperable data-sharing network that connects us without losing our organic diversity.-1. Any app from any ecosystem should be able to call any data from any user (if the user permits),+Keepsync is our local-first sync engine that provides real-time collaboration and local-first data management for Tonk applications. It uses [[Automerge]] CRDTs under the hood to enable automatic conflict resolution when multiple users edit the same data, and when working offline.
+10
_notes/Vancouver.md
+10
_notes/Vancouver.md