Taking my cue from Andrew Shell (of rssCloud Server fame, about which you will be hearing more soon ;-), i have added a little feature to the footer of this site, which expresses my appreciation to Dave Winer, Andrew and the wonderful RSS community, which makes syndication of all sites great and small Really Simple!
I just learned that it’s possible to join this WordPress blog to the Fediverse, by simply activating the ActivityPub plugin that is already installed… So let’s see if this works!
In “What Is the Terminal?” Jon Udell frames the problem that his new product Bram aims to mitigate -and does surprisingly well, considering how new it is. The terminal has become far more approachable and powerful in this age of AI agents for everyone; you can now ask, in plain language, for the software you want, and watch an agent go build it. And yet, for exactly that reason, comprehensibility of all that it is doing has become more of an issue than ever, for users of every stripe, however technical they may or may not be.
The easy reading of Jon’s title is that Bram makes the terminal optional for people who fear it: “The terminal is a foreign and hostile environment. Now it’s optional,” he writes, and that much is true. But the sharper point is the one that lands for experts too. In the age of AI agents the terminal has become a firehose: agent messages, your messages, tool calls, file reads, diffs and command output… All streaming past faster than anyone can absorb. Nobody- not the rawest beginner, nor the most seasoned engineer -takes in all of it in real time. That loss of comprehensibility is now a well-worn complaint in developer circles, and it’s the problem Bram is really built against.
So this isn’t “the terminal for dummies.” Jon is explicit that the payoff reaches the pros: “if you are a terminal jockey,” he writes, “you may enjoy the more legible display of agent messages, your messages, pasted screenshots, diffs, tool calls and results.” That’s the tell. Bram isn’t hiding the work and dumbing it down for the beginner; it’s making the same work legible- for the newcomer who never wants to see a shell, and just as much for the veteran who lives in one and still can’t take in the torrent an AI agent throws off.
And legibility here is a set of concrete mechanisms, not a mood. Instead of one linear stream rushing past, Bram decomposes the work into surfaces you can actually inspect: a worklist of discrete tasks, a transcript of the exchange, readable diffs, an issues panel and a commits panel; those are the tabs running down the screenshot above. And between the agent proposing a change and that change touching your files, it interposes explicit gates: you approve what gets applied, then separately approve what gets committed. That is where comprehension is recovered- not by slowing the agent down, but by turning the firehose into discrete things a human can see, review and sign off on, one at a time. It is exactly what a developer needs in order to stay responsible for code they did not personally type.
Here’s why that matters to me beyond the code. The teams I care about are hybrid in two directions at once. They mix technical and non-technical people: a farmer, an editor, a designer, a programmer. And, increasingly, they mix humans and AI agents working the same tasks. For twenty years, GitHub gave software teams a shared substrate for exactly this kind of collaboration: issues to name the work, commits to record it, review to bless it. What it never did was welcome the people who would never open a terminal, or the agents now working alongside them.
That’s the missing link I think Bram might be. Not “GitHub for programmers,” but GitHub for today’s hybrid teams: the same legible, reviewable, version-controlled way of working, extended to everyone at the table, human and machine, coder and not. The agent proposes; a person understands enough to approve; the record is public and portable.
And notice the shape of this very post. I’m not replying to Jon inside some platform’s walled garden. He wrote on his blog; I’m answering on mine; a pingback will quietly connect the two, and RSS will carry both to whoever’s subscribed. Read in, written out, via the same interface, the way Dave Winer has always said the social web should work. It’s the same instinct as Bram: keep the substrate open, keep the work legible, and let people- and their agents -meet on ground nobody owns. This ground is sacred; let us work to protect it.
Still more white than pink, in fact, but becoming more pink by the day (something to do with their diet, i gather), the wife & i have been seeing these birds in the early hours of each day, heading out on our morning walk… Then gone, an hour later on our return home, to who-knows where, though i suspect the Ria de Alvor estuary. They don’t “Murmurate” like the starlings, as i know from the one time i caught them departing, but stream off like a flock of arrows, heading East into the sun, now well over the horizon. Can’t count on their always coming back, as this pond is bound to dry up before we get much deeper into summer… So these mornings that we are graced with their visit are a blessing: a gift of our beloved landscape.
A murmuration -that vast, shape-shifting flock of starlings wheeling over a winter field at dusk- has no lead bird, no server, no committee. Each starling simply reads its nearest neighbors and adjusts. Out of that purely local, permissionless reading comes coordination of breathtaking complexity, with no one in charge.
That is the protocol I want for organizations, regardless of size, budget and technological capacity.
The aim is small and stubborn. Let an organization publish the handful of things that actually define it- who it is, where located, what it offers and needs, who it’s tied to- once, at a URL it controls, in a shape any other entity (human or machine) can read. Publish it the way you’d publish a blog post: out in the open, owned by you, syndicated by anyone, captured by no one. Not a platform everyone has to log into, but a way for organizations to read each other directly, so that the coherence is emergent rather than administered.
The good news is that none of this needs inventing. The parts already exist, and have for twenty years. I’m not building a new platform; I’m assembling standing ones:
My own daily reading already runs on this stack, with Dave Winer’s FeedLand at the head of it. I’m building on the standard because the standard is the thing that has outlasted everything stacked on top of it. This is what Really Simple buys you: nothing to depend on but the web itself.
A word on the name, since it invites the question. There is a project called Murmurations : a small, volunteer-run index for exactly this kind of profile, and a good one. I use it. But I want to be precise about its role, because the whole sovereignty of the thing turns on it: Murmurations is an optional discovery layer: a place your profile can be found, not a place it has to live. The canonical copy stays at your URL. Register with that index, with three indexes, or with none and just hand out the link; the data and the feed don’t care. If every index went quiet tomorrow, every profile would still resolve and every feed would still flow. I’m leaning on the metaphor more than the product. The flock is the point; an index is just one pair of binoculars.
There’s a posture underneath all this worth naming, because it’s why I’d rather build on bare standards than on anyone’s platform. The organizations are the Masters here; the software, including the AI agents I work with, are the Emissaries (hat-tip to Iain McGilchrist here). The agent drafts, fetches, refactors, tirelessly doing the analytical labor; the human sets the intent and keeps the meaning. Sovereignty isn’t a feature you bolt on at the end. It’s the consequence of keeping the data and the tooling under your own hand from the first line. A standard you can read in an afternoon is a standard you can stay master of. A platform is not.
I owe a second debt here, to Jon Udell, who has spent decades arguing for structured, syndicatable data that doesn’t rot inside a silo. This post, and the code behind it, were built the way he describes in Vibe Coding as a Team Sport: a human and a coding agent working through a shared, checkable record rather than a pile of hidden chat logs. His tool Bram is the harness: just enough ceremony to keep the agent honest. I mention it because the how is part of the claim: if the history of building the tool is as open as the tool itself, the whole thing stays inspectable, forkable, and yours. Gardens, not platforms, all the way down.
So here’s where it stands. It’s early: there’s nobody in this flock yet but me and Claude (my trusty emissary :-), and it’s my entry into a hackathon running through July. But it’s up, it’s in the open, and it speaks RSS in and out. This post answers a standing invitation from Dave Winer, who’s been rebuilding interop for the social web on exactly these foundations and asked anyone working in the same direction to put up an app and see who works with it. So that’s the test I’m after: if this can interop cleanly with rss.chat, it can interop with the rest, because that is what building to the standard means.
If you’re reading this and you build, fix, or fly with any of it, come find me. It’s all in the open so it’s useful to whoever lands here next and wants to join the flock.
Repo: github.com/ludwa6/sovereign-org-profiles
Live profiles: https://ludwa6.github.io/sovereign-org-profiles/
/ Walt Ludwick
Good interview with Jimmy Wales, in which he tells how Wikipedia strives to maintain its utility as a trusted source of truth, even as it has become deeply embroiled in the Culture Wars swirling about it. One of the key antagonists in this war is Elon Musk, wielding the recently launched Grokipedia as his primary weapon. In the following interview, Elon shares his own perspective on the differences between these two utilities and why his is simply superior; whether this proves true or not, i can only think, in this emergent age of ChatBot mediation of all queries, that this may spell real trouble for Wikipedia.
Per this open issue posted to the Scripting-News repo, it sounds like it should be possible soon to have Markdown support in the RSS feed for this site -a feature i would very much like to leverage here, once it is truly available.
ReFarmer.blog 
.jpg){kind=link}