Links - 27^th November 2022

Federation isn’t about giving users freedom, it’s about giving nerds a sense of control.

Which is funny, because when you use a federation protocol, that dictates how your software works and functions. You don’t get to control how your social network functions, the people writing the software do, and even then they don’t always have that much control either. If a big instance changes the way things work, the rest of the network has to fall in line or risk isolation.

A federated model loves to assume that everyone’s on a level playing field. That you can just fork the software, run your own service, and do what you like, casually brushing over the reality that the biggest players dictate policy, and that if you don’t play along, you won’t be part of the network.

This is why so many federated die hards are terrified that Google, Meta, or another giant of industry will join in.

They fear that things will turn out like email, where there’s a cartel that controls spam blacklists and smaller email servers routinely get null-routed. They fear things will turn out like XMPP, where a large player captures most of the users, only to turn around and drop compatibility. They fear that a large firm adopts ActivityPub, builds incompatible features atop to lock users in, and shut competitors out.

You can release new features but you might end up breaking old clients. On the other hand, when you control the server, the client, and the protocol, it’s a lot easier to build out your product and release new features. Twitter discovered the same thing with third party clients. Images in tweets? Polls? Video? Bad news if a huge chunk of your userbase are on an third party client.

In other words: The problem about using a protocol is that you cede control to it.

Galloway’s book “protocol” is a dry and terse academic treatise that covers this in detail, but the lazy among us can just look at cryptocurrencies, with forks and mining cartels, to see this in practice. With a protocol, you can’t release new features, you can’t change how things work without getting buy-in from the rest of the network.

When a large player breaks away from a federated network, they’re labeled as a bad actor. Sometimes people point to capitalism as being the root cause, but i’m more inclined to believe that fragmentation is a natural consequence of the federated model.

Software is a temporary garden whose fate is inextricably intertwined with its gardeners. Beyond that, software is a theory. It’s a theory about a particular solution to a problem. Like the proverbial garden, it is composed of a microscopic ecosystem of artefacts, each of whom has to be treated like a living thing. The gardener develops a sense of how the parts connect and affect each other, what makes them thrive, what kills them off, and how you prompt them to grow. The software project and its programmers are an indivisible and organic entity that our industry treats like a toy model made of easily replaceable lego blocks. They believe a software project and its developers can be broken apart and reassembled without dying.

What keeps the software alive are the programmers who have an accurate mental model (theory) of how it is built and works. That mental model can only be learned by having worked on the project while it grew or by working alongside somebody who did, who can help you absorb the theory. Replace enough of the programmers, and their mental models become disconnected from the reality of the code, and the code dies. That dead code can only be replaced by new code that has been “grown” by the current programmers.

A successful software project is grown from a small living thing to a larger living thing. Building the project large from the start and will never come to life. Replacing the gardeners that brought it to life will lead it to whither.

The present discussion is a contribution to the understanding of what programming is. It suggests that programming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts.

Second, the expectation of the possibility of low cost program modifications conceivably finds support in the fact that a program is a text held in a medium allowing for easy editing. For this support to be valid it must clearly be assumed that the dominating cost is one of text manipulation. This would agree with a notion of programming as text production. On the Theory Building View this whole argument is false. This view gives no support to an expectation that program modifications at low cost are generally possible.

On the basis of the Theory Building View the decay of a program text as a result of modifications made by programmers without a proper grasp of the underlying theory becomes understandable. As a matter of fact, if viewed merely as a change of the program text and of the external behaviour of the execution, a given desired modification may usually be realized in many different ways, all correct. At the same time, if viewed in relation to the theory of the program these ways may look very different, some of them perhaps conforming to that theory or extending it in a natural way, while others may be wholly inconsistent with that theory, perhaps having the character of unintegrated patches on the main part of the program. This difference of character of various changes is one that can only make sense to the programmer who possesses the theory of the program. At the same time the character of changes made in a program text is vital to the longer term viability of the program. For a program to retain its quality it is mandatory that each modification is firmly grounded in the theory of it. Indeed, the very notion of qualities such as simplicity and good structure can only be understood in terms of the theory of the program, since they characterize the actual program text in relation to such program texts that might have been written to achieve the same execution behaviour, but which exist only as possibilities in the programmer’s understanding.

Diagrams are often relegated to the realms of quantification, formalized data, or strict research processes. When considered more expansively — with appreciation for the plurality of knowledge — we can view them as cogent tools for connection, creation, and sensation.

Defined simply, a diagram is a delineation of interacting lines — of gesture, connection, understanding, and more. Through these threads and their conversations, diagrams reveal stagnancies and flows in systems of every scale, posing new ways to connect and move through them. They invite us to create knowledge and to understand ourselves as always already embedded within orders and dis/orders. Diagrams are everywhere: knitted on looms, traced in a snail’s slime trail, held up by tendrils, scribbled in notebooks, and more, and more, and more.

There’s a sprawling web of artists, thinkers, organizers, friends, and writers who are in the practice of using diagrams to world, weave, and open up our lines of flight and sensing. Below are a few texts, diagrams, and practices that can help us think through the potentiality of the diagram as a tool for actualizing our thoughts and imaginings as we envision new worlds.

The resources below are all starting places. I invite you to absorb their dense meshworks and make your own by tracing, twisting, linking up, connecting, drawing, dancing, commoning, feeling, unthreading, etc, etc, etc. Embrace and walk with uncertainty, let it guide you as a generative force towards tangled creation. Grab an open line and run with it!

What follows is my vast, unpublished 1979 “Mother of All Multics Emacs papers” from which all of my lesser and greater Emacs papers, published, internal, and unpublished, were ultimately excerpted, including Prose and CONS: A Commercial Text-Processing System in Lisp in the 1980 Lisp Conference proceedings and the 1980 Honeywell conference paper. It’s about time to expose it, and the WWW/HTML is now the ideal vehicle.

Multics is no longer produced or offered for sale; Honeywell no longer even makes computers. People edit on computers on their desktop so cheap and fast that not only do redisplay algorithms no longer matter, but the whole idea of autonomous redisplay in a display editor is no longer a given (although autonomous redisplay’s illustrious child, WYSIWYG, is now the standard paradigm of the industry.). There is now no other kind of editor besides what we then called the “video editor”. Thus, all of the battles, acrimony, and invidious or arrogant comparisons in what follows are finished and done with, and to be viewed in the context of 1979 — this is a historical document about Multics and the evolution of an editor. It is part of the histories of Multics, of Emacs, and of Lisp.

Many of the deficiencies of Multics described here were thereafter remedied, not only by Emacs, but by a managed-video system inspired by Emacs. Although it started out as rebellious “hack”, Multics Emacs became an integral part of the Multics product.

The idea is that as you start to find patterns in your application, you can encode them in a little language — this language would then allow you to express these patterns in a more compact manner than would be possible by other means of abstraction. Not only could this buck the trend of ever-growing applications, it would actually allow the code base to shrink during the course of development!

One result from the STEPS program that I find particularly impressive was Nile, a little language for describing graphics rendering and compositing. The goal was to use Nile to reach feature parity with Cairo — an open-source renderer used in various free software projects — which weighs in at about 44 000 lines of code. The Nile equivalent ended up being about 300 lines.

“Hey, wait a minute” you might say “why can’t we just invent a higher-level, general-purpose language?” Personally, I believe we have reached diminishing returns for the expressiveness of general-purpose languages. If there is a higher level, what would it even look like? Take Python, for example — it’s so high-level it pretty much looks like pseudocode already.

The problem with general-purpose languages is that you still have to translate your problem to an algorithm, and then express the algorithm in your target language. Now, high-level languages are great at describing algorithms, but unless the goal was to implement the algorithm then it’s just accidental complexity.