now out: “Anarchive as technique in the Media Archaeology Lab | building a one Laptop Per Child mesh network”

I am thrilled to have had the opportunity to co-author a paper, titled “Anarchive as technique in the Media Archaeology Lab | building a one Laptop Per Child mesh network,” with a remarkable PhD student I work with, libi striegl. It is now out as open access in the inaugural issue of The International Journal of Digital Humanities (edited by Thorsten Ries) and discusses how the Media Archaeology Lab acts as both an archive and a site for what the authors describe as ‘anarchival’ practice-based research and research creation. ‘Anarchival’ indicates research and creative activity enacted as a complement to an existing, stable archive. In researching the One Laptop Per Child Initiative, by way of a donation of XO laptops, the MAL has devised a modular process which could be used by other research groups to investigate the gap between the intended use and the affordances of any given piece of technology. Please read and enjoy!


What and Where is the Interface in Virtual Reality? An Interview with Illya Szilak on Queerskins

It’s been four years since the publication of Reading Writing Interfaces (University of Minnesota Press 2014) and admittedly, to my ears and eyes, the first chapter on gestural and multitouch interfaces already seems outdated – at least outdated in terms of specific tech if not in terms of the general principles. If I were going to write about interfaces that are dominating or seeking to dominate the consumer and creative markets in 2018, instead of gestural or multitouch devices I would surely have to write about Voice User Interfaces (VUIs) such as Amazon Echo, Google Home or Apple HomePod – those seemingly interface-less, inert boxes of computing power (for some reason, always coded as women – harkening back to a mid-20th century notion of the female secretary as self-effacing, perpetually amiable, always helpful, always eager to please) embedded throughout homes that just sit there waiting to respond to any voice command and appearing less as a computer and more as an artificially intelligent in-house butler.

But I would also have to write about the growing inevitability of Virtual Reality systems such as Occulus Rift, Sony PlayStation VR, HTC Vive, Google Daydream View, Samsung Gear VR, and I’m sure many more. For me, the problem with accounting for the interface of VR is more difficult to understand than VUI devices, partly because VR poses two problems: for one, the interface that dominates most of the waking hours of the creator is entirely different from that of the user (god help the VR designer who has to design a VR environment in Unity with a headset on); the second problem is that, on the user side, it’s as if the interface has been displaced, moved to the side, outside of your vision and your touch, at the same time as you’re now meant to believe you’re inside the interface – as if your head is not in front of the screen but rather inside it. There is still a screen (even though it’s now inside your headset) and there is still a keyboard and mouse (you have to have a PC to use a device such as Occulus Rift so both the keyboard and mouse are presumably somewhere in the room with you as you play) but all these key components of the Keyboard-Screen-Mouse interface have been physically separated and then added on to with hand-controllers. The way in which the interface for VR users has been physically removed to the peripheries of the room in which the user is stationed is, I think, quite significant. If an interface is the threshold between human and computer, any change in either side of the threshold or the threshold itself (whether it’s a change in functionality or in physical location) is bound to have a profound effect on the human. In the case of VR, the physical changes in the location of the interfaces alone are enough to fundamentally change the human user’s experience as they are now standing up and mobile to an unprecedented degree at the same time as this mobility has nothing to do with exploring the affordances of the interfaces themselves or their affordances – the mobility is entirely in the service of exploring a pre-determined, usually carefully controlled virtual environment.

One of the recurring issues I raise in Reading Writing Interfaces is that of invisibility – especially the danger in interfaces designed to either disappear from view or distract us from the fact that we have no understanding and no access to how the interface is shaping and determining what and how we know, what and how we create. As I wrote in the introduction, “Despite our best efforts to literally and figuratively bring these invisible interfaces back into view, either because we are so enmeshed in these media or because the very definition of ideology is that which we are not aware of, at best we may only partly see the shape of contemporary computing devices.” However, as I argued in my book and as I still believe, literature and the arts are built to take on the work of demystifying these devices and these interfaces and making both visible once again. Thus, while I think the fundamental problem with VR as I describe it above is that users are becoming even more estranged, even more alienated from whatever lies behind the glossy digital interface (in fact, now the estrangement is both literal and figurative as the computer producing the VR experience is potentially as much as twelve feet away), I have already noticed that writers and artists are taking this challenge on. This is precisely why I wanted to interview Illya Szilak so much on the work of interactive cinema, “Queerskins,” she’s creating with Cyril Tsiboulski for the Occulus Rift. Szilak is a long-time active participant in the digital literature community as both a writer/creator and a critic (writing for the Huffington Post). Her transmedia novel Reconstructing Mayakovsky was included in the second volume of the Electronic Literature Collection. Her latest piece, Queerskins, is described on the Kickstarter page for the project as “a groundbreaking interactive LGBTQ centered drama that combines cutting-edge tech with intimate, lyrical storytelling.” Below are my questions and her answers – enjoy!


In the process of writing and creating Queerskins with Cyril Tsiboulski, where do you locate the interface in virtual reality systems such as the Occulus Rift? Is the interface different for you as writer/creator than it is for the reader/user?
The interface for us is between reality and virtuality. The hardware of VR is what allows us to navigate that. Of course, books, too, do that, but, without going into a scientific or philosophical discussion of “presence,” suffice it to say, that the experience of being in another world is a primordial mechanism for organismal survival that relies on a motor map of interactivity. Reading may create a conceptual version of this, but your body does not experience it in the same way. For me it relates theoretically to Marinetti’s total theater especially his manifesto on Tactilism in which he says: “The identification of five senses is arbitrary, and the identification of five senses is arbitrary, and one day we will certainly discover and catalogue numerous other senses. Tactilism will contribute to this discovery.”

I think machine extended bodies have the potential to learn new forms of sensing “reading” the world and VR will certainly be used for this transcendence. We are also interested in producing a kind of Brechtian estrangement, so that this transcendence is always in dialogue with the realities of embodiment; even VR hardware requires a body to perceive.

In Queerskins, we are using a variety of techniques to manufacture an aesthetic and narrative sweet spot between reality and artifice. And, we use a variety of technologies and techniques to do this. It was important not to make this into a seamless whole but to leave spaces between so that the user is able to attain some amount of critical distance; so we are combining a 3D modeled car interior created from photogrammetry, 360 video landscapes, 3D scanned and CGI objects and animations and 3D volumetric video live action.

As with all our narratives, we want to explore the tension between material, historical, embodied realities and virtual realities which includes, in the case of VR, not just 3D immersive environments but also, as with our online narratives, harnessing user imagination and memory. For me, ethics are linked to the material and historical. The lived realities (this time–this place) of LGBTQ people can’t be wished away. So, it was really important to use historically accurate objects. Almost every object in the box and many of the sounds are archival – bought off  eBay and 3D scanned or, in the case of sound, recorded by others in different environments or found on the Internet Archive.

At the same time, we recognize the perhaps quintessentially human desire for transcendence: through love, technology, sex, religion, writing, art, imagination, memory and storytelling itself. So, we love the incredible possibilities that VR generates in that respect (we have a plan for three more episodes for queerskins: a love story and transcendence becomes a more and more complicated and innovative part of this though always connected back to material/ historical realities). In this episode, we are more interested in the gravity of the experience. A young man has died of AIDS, essentially abandoned by his parents. So, no, you don’t get to fly or move mountains. You will be allowed two transcendent moments which we are calling memory spaces. In them, there is a change of place and time. In the first, you can get up and walk through a cathedral, but all you will find are just the sounds and images of Sebastian’s everyday life – in other words, memories.

These moments of transcendence are differentiated from the emotionally wrenching reality of the car ride both aesthetically and through the user’s sense of space and  agency. These latter elements are, of course, key narrative devices in VR. VR is a spatial medium, I think that in this medium is more so than film; it was important for us to create a situation that could be read “body to body” because we wanted to hook into the old brain of motor neurons to create emotional responses to the environment. For the most part, the visitor (that’s what they call user or reader now) is stuck in the car with no way to move (in fact, we will seat belt them into the chair which we had created for filming the actors in front of green screen) behind the two actors. So, we actually worked with theater director, choreographer and Butoh dancer, Dawn Saito, to choreograph the two actors’ gestures in a kind of missed call and response.

Again, staying with gravity and materiality and mortality, and to maintain immersion – because we need the user to be absolutely present for the emotional bloodletting happening in close proximity in the front seat, it was important that users not be distracted by having to learn new actions and that their interactions be of the everyday variety; so you can pick up things, you can turn the pages of a diary, you can walk.  (In later episodes you will be able to play music on a virtual lover’s body or walk on the ceiling and have kaleidoscopic housefly-vision, and make the statues of a church come to life…) But for this one, well, hey, you are walking and moving and doing and alive and, that, at least, is better than dead. Limiting user agency here is purposeful. We want you to feel the loss: you can not speak, nor write, nor communicate in any way, just as Mary-Helen can not tell her son that she is sorry or that she loved him.

We are really interested in sound because not only is it spatial, it is can be used to harness the user’s imagination – very old school transcendence and also very much associated with older technologies like radio and text. So, Queerskins starts out with credits and sound. (Skywalker Studio is doing sound post-production and audio design for us.) You begin by imagining the story. This cues users subtly to their role. You are the co-creator. You get pieces of information and have to put together the story and most importantly you come up with an  idea of who the man who died was and the life he lead. When you finally hear his voice speaking his own intimate diary entries, he may or may not be what you thought he would be. The diary is in a sense the missing body. You will find it on one side of you on a pew in the cathedral memory space. On the other side is Sebastian’s empty funeral suit. (Which is the queerskin? )

Can you describe a few creative possibilities opened up by the software/hardware you’re using?
Depthkit was used for filming the actors – it’s basically software that processes data from a high end DSLR video camera to create a texture map and a Kinect which creates a volume map and fuses these to create live action 3D volumetric video. It allows us to have actors in a CGI environment which gives the user a sense of “being there” much more than 360 video does. The 360 video outside the car has a flatness, a nostalgic aesthetic that we actively sought (we flew to Missouri and drove around rural areas ten hours a day with a stranger I met on FB) after we did initial experiments. It looks like old rear screen projection or like you are traveling through a home movie. It’s “real” in the sense that documentary video is “real” but you don’t feel like you are really in the space with your body.

Can you describe a few limitations you’ve faced by the same software/hardware? How has it shaped or determined what you’re able to create?
We spent a lot of time and money making sure we could actually get the actor footage into the CGI car in a way that looked realistic. That being said, it is not perfect– there is flare around the edges and the kinect reads everything in the same plane so we had to make sure that actors didn’t cross over into each other. As iI said–we were already choreographing the actors, so this just became part of the choreography. The 360 video shakes because we shot from a car –we are removing that but will also be using haptics–a motor in the seat the visitor sits on, to make the user’s body feel like it is shaking. In VR, a lot of this comes down to $. There are alternatives which would cost a lot more. But, then, for us, part of this is working aesthetically around the limitations. Also, optimization in the game engine is an issue, we have had problems with frame rate drops that puts our audio out of sink with video. These projects are so complicated that sometimes you don’t know what exactly is doing this. However, frame rate drops are not an opportunity for experimentation like some other hardware limitations. THat is a failure. These are limits of aesthetic expectations and our hardwired senses–we can’t really play with that in this piece. So, Cyril has had to play with the script a lot to decrease frame rate drops.

How, if at all, do you want your reader/user to be aware of the VR interface?
We had to wrestle with whether to let the user get up and walk because this would certainly disrupt the cohesiveness of the experience (the user might need some prompting and direction and will need to be led back physically to the seat) but, in the end, we decided the agency and sense of freedom this afforded (a refuge of sorts) was worth it. Moreover, this episode like all planned episodes is part of an interactive physical installation. They can act separately, but together provide an richer experience. The installation for this episode is a performance art “game” that we will install with the VR piece. One other thing of interest: we are hoping to use Leap Motion for the haptics, not Oculus Touch. Leap Motion is controller-less – Cyril saw it in a Laurie Anderson piece at Mass MOCA and we are working with the developers. It is incredibly natural feeling as your hands appear virtually. Leap Motion recognizes gestures, so the interface in this case really disappears but for non-gamers it means there is no learning of controllers; for us this is optimal especially given a film audience at first.

selling the future at the MIT Media Lab

The following is the text of a talk I gave at Transmediale on February 5, 2016 as part of a panel with Jussi Parikka, Ryan Bishop, and John Beck on “The Persistence of the Lab.” The text of the talk will eventually find its way into THE LAB BOOK.


What follows are some of my initial findings as I’ve been researching the past and present of the MIT Media Lab – a lab founded in 1985 by former MIT President Jerome Wiesner and Nicholas Negroponte of OLPC fame and then directed by Negroponte for the first twenty years of its existence so far. The Media Lab has become synonymous with “inventing the future,” partly because of a dogged thirty year long marketing campaign whose success we can measure by the fact that almost any discussion of “the future” of technology is a discussion about some project at the Media Lab.

And of course the lab has also become synonymous with “inventing the future” because of the central role it’s historically played in the fields of wireless networks, field sensing, web browsers, the WWW, and the central role the lab is now playing in neurobiology, biologically inspired fabrication, socially adaptive robots, emotive computing, and the list goes on and on. Given this list, you’d be right to think that the lab has long been driven by an insatiable thirst for profit operating under the guise of an innocent desire to just keep performing computerized feats of near impossibility, decade after decade.

But I’ve also come to see this performance is partly a product of a post-Sputnik Cold War race to out-do the Soviets no matter what the reality, the project or the cost. In Stewart Brand’s The Media Lab, the only book written so far exclusively on the media lab, written in 1986, the year after the lab opened, he writes with an astuteness I don’t usually associate with him:

If you wanted to push world-scale technology at a fever pace, what would you need to set it in motion and maintain it indefinitely? Not a hot war, because of the industrial destruction and the possibility of an outcome. You’d prefer a cold war, ideally between two empires that had won a hot war. You wouldn’t mind if one were fabulously paranoid from being traumatized by the most massive surprise attack in history (as the USSR was by Hitler’s Barbarossa) or if the other was fabulously wealthy, accelerated by the war but undamaged by it (as the US was by victory in Europe and the Pacific). Set them an ocean apart. Stand back and marvel. (161-162)

Brand then goes on to explain how American computer science owes so much to the Soviet space program – one which resulted in the creation of Eisenhower’s Advanced Research Projects Agency which, by the 1970s, had an annual budget of $238 million and funded many labs at MIT. And even when ARPA changed to DARPA to show that all agency projects had direct defense applicability, it still continued to fund labs such as the predecessor to the Media Lab, Nicholas Negroponte’s Architecture Machine Group. Still to this day, even though the Media Lab is famous for its corporate sponsorship, the U.S. Army is listed as one of its sponsors and many of the lab’s projects still do have direct applicability in a defense context.

But the lab is also the product of MIT’s long history of pushing the boundaries of what’s acceptable in higher education in terms of its deep ties with the military industrial complex and corporate sponsorship that goes back even to the 1920s. However, we now know that even though MIT tried to work with corporate partners in the post World War I years as it tried to pay for research programs in chemical and electrical engineering, the depression put an end to corporate partnerships until late in the second world war. The WWII in fact became a decisive turning point in the history of university science/tech labs, likely because of the enormous amount of funds that were suddenly available to sponsor research and development contracts.

Historian Stuart Leslie reports that during the war years MIT alone received $117 million in R&D contracts. So, again, naturally, once the “hot war” was over in 1945, it was almost as if MIT needed a Cold War as much as the state did so that it would continue to receive hundreds of millions of dollars’ worth of contracts. As a result, by the 1960s, physicist Alan Weinberg famously said that it was getting increasingly hard “to tell whether MIT is a university with many government research laboratories appended to it or a cluster of government research laboratories with a very good educational institution attached to it.” (quoted in Leslie 14)

Also in the 1960s, the Research Lab of Electronics (or RLE) in particular was getting the lion’s share of the funding. RLE was a lab created in 1946 as a continuation of the world war II era Radiation Lab which was responsible for designing almost half of the radar deployed during the war. The RLE also became the template for many MIT labs that followed – particularly the Arch Mach Group which, again, turned into the Media Lab in the mid 80s. RLE was one of the first labs to be thoroughly interdisciplinary, to train grad students who went on to write the books that future grad students read and then responded to by writing other books or who went on to fund tech companies, and it also groomed future leaders either of the lab itself, the university, or for government/industry. Given this beautifully efficient system of using labs to both create and replicate knowledge, it makes perfect sense that researchers Vannevar Bush and Norbert Weiner – famous in part for their roles in advancing war-time technology – were teachers at MIT of Julius Stratton, the founding Director of RLE, and Jerome Wiesner who, again, you remember later co-founded the Media Lab.

Wiesner’s life in corporate and government sponsored labs began in 1940 as he was appointed chief engineer for the Acoustical and Record Laboratory of the Library of Congress. His job at the time mostly involved traveling to the South/Southwest under a Carnegie Corporation grant, with folklorist Alan Lomax, recording the folk music of these areas. Two years later, in 1942, Wiesner joined the RadLab at MIT and soon moved to the lab’s advisory committee; during his time there he was largely responsible for Project Cadillac which worked on the predecessor to the airborne early warning and control system. After World War II, the RadLab was dismantled in 1946 and in its place the RLE was created with Wiesner as the assistant and then associate director and then director from 1947 to to 1961. 1961 was the same year President John F. Kennedy named Wiesner to chair the President’s Science Advisory Committee; Weisner served Kennedy until Kennedy’s death in 1963 and then served President Johnson for one more year and most of his work involved advising the presidents on the space race and on nuclear disarmament. In 1966 Wiesner moved back to MIT as university provost and then President from ’71-’80. With Nicholas Negroponte at his side, he started fundraising for the lab in 1977 while he was president and, again, became co-founder of the lab in 1985 once he had stepped down as president and returned to life as a professor.

The foregoing is my brief history of one side of the Media Lab’s lineage that extends quite far back into the military-industrial complex, and especially the years of the Cold war, by way of Jerome Wiesner. Now I will move on to discuss the corporate, anti-intellectual lineage operating under the guise of “humanism” that runs through Nicholas Negroponte. The son of a Greek shipping magnate, Negroponte was educated in a series of private schools in New York, Switzerland and Connecticut and he completed his education with a MA in Architecture at MIT in the 1960s. You might also be interested to know that his older brother John Negroponte was a deputy secretary of state and the first ever Director of National Intelligence. In 1966, the year Wiesner returned to MIT to become provost, Nicholas became a faculty member there and a year later founded the Architecture Machine Group – a group which took a systems theory approach to studying the relationship between humans and machines. While the Media Lab’s lineage on Wiesner’s side runs through the Research Lab in Electronics and, earlier, the Radiation Lab, on Negroponte’s side the lineage runs through the Architecture Machine Group – a lab which combined the notion of a government sponsored lab with a 1960s-1970s-appropriate espoused dedication to humanism meshed with futurism.

But of course, especially as this particular brand of humanism is always tied to an imaginary future, it’s a particular kind of inhuman humanism that’s began in the Arch Mach group and went on to flourish in the Media lab – it’s one that constantly invokes an imagined future human that doesn’t really exist partly because it’s part of an ever-receding future but also because this imagined future human is only ever a privileged, highly individualized, boundary-policing, disembodied, white, western male human. I think you can see the essence of the Negroponte side of the Media Lab in three projects I want to touch on for the rest of my talk today. The first, from the early years of the Arch Mac group, was unglamorously called the “Hessdorfer Experiment” and is glowingly described by Negroponte in a section titled “Humanism Through Intelligent Machines” in The Architecture Machine, written in 1969 and published in 1970.

In the opening pages of the book, Negroponte mostly lays out the need for “humanistic” machines that respond to users’ environments, analyze user behavior, and even anticipate possible future problems and solutions – what he calls a machine that does not so much “problem solve” as it “problem worries.” (7) His example of what such an adaptive, responsive machine could look like is drawn from an experiment that undergraduate Richard Hessdorfer undertook in the lab the year the book was writen. Writes Negroponte, “Richard Hessdorfer is…constructing a machine conversationalist… The machine tries to build a model of the user’s English and through this model build another model, one of his needs and desires. It is a consumer item…that might someday be able to talk to citizens via touch-tone picture phone, or interactive cable television.” (56)

To help him build this machine conversationalist, Hessdorfer thought it would be useful to bring teletypewriting devices into a neighborhood in the south side of Boston – what Negroponte calls “Boston’s ghetto area.”


Negroponte writes:


I barely know where to begin with this passage except to say that the entire racist, deceptive undertaking is, for me, about as far away from a humanism that acknowledges the lives of these particular humans as you can get. It also clearly demonstrates what can happen when we believe so completely in the neutrality of the machine as its assumed neutrality – or its assumed capacity to give us pure, unmediated access to reality – can be called on as a magical mechanical solution to any human problems. Got a race problem? Get a computer!

The second project from about a year later, also run through the Architecture Machine Group, is just as disturbing. This time the subjects in the experiment are not African Americans but, rather, gerbils.


The experiment, called “SEEK,” was exhibited as part of the 1970 show at the New York Jewish Museum called SOFTWARE. It consisted of a computer-controlled environment, contained by Plexiglass and full of small blocks and gerbils who were there to change the position of the blocks following an automatic arrangement of the blocks by a robotic arm. The machine was supposed to analyze the gerbils’ actions and then try to successfully complete the rearrangement according to what the machine thought the gerbils were trying to do. Unfortunately, the experiment was a disaster.


As Orit Halpern puts it, “The exhibition’s computers rarely functioned…the museum almost went bankrupt; and in what might be seen as an omen, the experiment’s gerbils confused the computer, wrought havoc on the blocks, turned on each other in aggression, and wound up sick. No one thought to ask, or could ask, whether gerbils wish to live in a block built micro-world.” Again, this brand of humanism that’s in the name of the future is one that has very little to do with situatedness (or what’s now called posthumanism) – instead it has everything to do with abstraction and transcendence in the name of producing consumer products or R&D for the military-industrial complex.

The last example I’d like to touch on today is the One Laptop Per Child Project which Negroponte took up as an explicitly Media Lab project in the early 2000s and which, again, continues these same themes of humanism meshed with futurism combined with an espoused belief in the neutrality of the machine.


The difference now is that even just the guise of academic rigor and a scientific care for method that you could see in the Architecture Machine Group has been transformed, probably because of the lab’s responsibility toward its 80+ corporate sponsors, into the gleeful, continuous production of tech demonstrations, driven by the lab’s other, more ominous motto “DEMO OR DIE.”

OLPC was launched by Negroponte in 2005 and was effectively shut down in 2014. After traveling the world since at least the early 1980s to effectively sell personal computers to developing nations, Negroponte announced he had created a non-profit organization to produce a $100 laptop “at scale” – in other words, the cost of the laptop could only be this low in the early 2000s if, according to Negroponte, they could amass orders for 7-10 million laptops. Essentially, despite his often repeated statement that OLPC is not a laptop project but rather an education project, the essence of the project was still the same as the Hessdorfer experiment or “SEEK”: got a poveryty problem? get a computer! Worse yet, don’t do a study of whether what the community or nation needs are – JUST GET A COMPUTER.

Here’s what Negroponte said in a Ted Talk from 2006, suggesting that even if families didn’t use the laptops, they could use them as light sources:


Not surprisingly, as with the lack of forethought in the experiment with the poor gerbils, by 2012 studies were coming out clearly indicating that the laptops – whether they were used in Peru, Nepal or Australia, made no measurable difference in reading and math test scores. In fact, one starts to get the sense that Negroponte’s truly remarkable skill which he began honing in the late 60s in the Architecture Machine Group is not design, not architecture, not tech per se, but rather dazzling salesmanship built on a lifetime pitching humanism and futurism via technological marvels. Even Stewart Brand saw this in Negroponte. Quoting Nat Rochester, a senior computer scientist and negotiator for IBM, “[If Nicholas] were an IBM salesman, he’d be a member of the Golden Circle…if you know what good salesmanship is, you can’t miss it when you get to know him.” (6)

And with this, the pitch perfect ending to this strange story is that in 2013, after selling millions of laptops to developing nations around the world, laptops that again made no measurable improvement in anyone’s lives, Negroponte left OLPC and went on to chair the Global Literacy X Prize as part of the XPRIZE Foundation. However, the prize itself no longer seems to exist and there’s no record of him being with the organization just a year later in 2014 – it seems he’s finally, quietly living out his salesman years back at MIT where he began.

XPRIZE, however, does exist and appears to be the ultimate nonprofit based on nothing more than air and yet more humanist slogans:


In many ways, XPRIZE is the ultimate Media Lab project spanning the world and whose board includes every major corporate executive you can think of – all to produce not even things anymore but rather just “incentives.” And in terms of the lab itself, while Negroponte seems to be practically retired and Wiesner passed away a number of years ago, the media lab continues to merrily churn out demos and products for consumers and the military under the leadership of Joi Ito – a venture capitalist with no completed degrees, a godson of Timothy Leary and a self-proclaimed “activist,” MIT couldn’t have found a better successor for the world-class salesman Nicholas Negroponte.

Works Cited

Brand, Stewart. The Media Lab: Inventing the Future at MIT. New York: Viking Penguin, 1987.

Halpern, Orit. “Inhuman Vision.” Media-N: Journal of the New Media Caucus, 10:3 (Fall 2014).

Leslie, Stuart. The Cold War and American Science: The Military-industrial-academic Complex at MIT and Stanford. New York: Columbia UP, 1993.

Negroponte, Nicholas. The Architecture Machine: Toward a More Human Environment. Cambridge, MA: MIT University Press, 1970.

—. Soft Architecture Machines. Cambridge, MA: MIT University Press, 1975.

What’s Wrong With the Internet and How We Can Fix It: Interview With Internet Pioneer John Day

I appreciate very much the willingness of the editors at Ctrl-Z: New Media Philosophy to publish an updated, revised version of an interview I conducted with the computer scientist and Internet pioneer John Day via email. The published version is available at the link above and the original version is below.

The interview came about as a result of a chapter I’ve been working on for my “Other Networks” project, called “The Net Has Never Been Neutral.” In this piece, I try to expand the materialist bent of media archaeology, with its investment in hardware and software, to networks. Specifically, I’m working through the importance of understanding the technical specs of the Internet to figure out how we are unwittingly living out the legacy of the power/knowledge structures that produced TCP/IP. I also think through how the Internet could have been and may still be utterly different. In the course of researching that piece, I ran across fascinating work by Day in which he argues that “the Internet is an unfinished demo” and that we have become blind not only to its flaws but also to how and why it works the way it works. Below you’ll see Day expand specifically on five flaws of the TCP /IP model that are still entrenched in our contemporary Internet architecture and, even more fascinating, the ways in which a more sensible structure (like the one proposed by the French CYCLADES group) to handle network congestion would have made the issue of net neutrality beside the point. I hope you enjoy and many, many thanks to John for taking the time to correspond with me.


Emerson: You’ve written quite vigorously about the flaws of the TCP/IP model that go all the way back to the 1970s and about how our contemporary Internet is living out the legacy of those flaws. Particularly, you’ve pointed out repeatedly over the years how the problems with TCP were carried over not from the American ARPANET but from an attempt to create a transport protocol that was different from the one proposed by the French Cyclades group. First, could you explain to readers what Cyclades did that TCP should have done?

Day: There were several fundamental properties of networks the CYCLADES crew understood that the Internet group missed:

  • The Nature of Layers,
  • Why the Layers they had were there,
  • A complete naming and addressing model,
  • The fundamental conditions for synchronization,
  • That congestion could occur in networks, and
  • A raft of other missteps most of which follow from the previous 5, but some are unique.

First and probably foremost was the concept of layers. Computer Scientists use “layers” to structure and organize complex pieces of software. Think of a layer as a black box that does something, but the internal mechanism is hidden from the user of the box. One example is a black box that calculates the 24 hour weather forecast. We put in a bunch of data about temperature, pressure and wind speed and out pops a 24 hour weather forecast. We don’t have to understand how the blackbox did it. We don’t have to interact with all the different aspects it went through to do that. The black box hides the complexity so we can concentrate on other complicated problems for which the output of the black box is input. The operating system of your laptop is a black box. It does incredibly complex things but you don’t see what it is doing. Similarly, the layers of a network are organized that way. For the ARPANET group, BBN [Bolt, Barenek, and Newman] built the network and everyone else was responsible for the hosts. To the people responsible for the hosts, the network of IMPs was a blackbox that delivered packets. Consequently, for the problems they needed to solve, their concept of layers focused on the black boxes in the hosts. So the Internet’s concept of layers was focused on the layer in the Hosts where its primary purpose was modularity. The layers in the ARPANET hosts were the Physical Layer, the wire; IMP-HOST Protocol; the NCP; and the applications, such as Telnet, and maybe FTP.[1] For the Internet, they were Ethernet, IP, TCP, Telnet or HTTP, etc. as application. It is important to remember that the ARPANET was built to be a production network to lower the cost of doing research on a variety of scientific and engineering problems.

The CYCLADES group, on the other hand, was building a network to do research on the nature of networks. They were looking at the whole system to understand how it was supposed to work. They saw that layers were more than just local modularity but a set of cooperating processes in different systems, and most importantly different layers had different scope, i.e. number of elements in them. This concept of the scope of a layer is the most important property of layers. The Internet never understood its importance.

The layers that the CYCLADES group came up with in 1972 were the following: 1) the Physical Layer – the wires that go between boxes. 2) The Data Link Layer – that operates over one physical media and detects errors on the wire and in some cases keeps the sender from overrunning the receiver. But most physical media have limitations on how far they can be used. The further data is transmitted on them the more likely there are errors. So these may be short. To go longer distances, a higher layer with greater scope exists over the Data Link Layer to relay the data. This is traditionally called the 3) Network Layer.

But of course, the transmission of data is not just done in straight lines, but as a network so that there are alternate paths. We can show from queuing theory that regardless of how lightly loaded a network is it can have congestion, where there are too many packets trying to get through the same router at the same time. If the congestion lasts too long, it will get worse and worse and eventually the network will collapse. It can be shown that no amount of memory in the router is enough, so when congestion happens packets must be discarded. To recover from this, we need a 4) Transport Layer protocol, mostly to recover lost packets due to congestion. The CYCLADES group realized this which is why there is a Transport Layer in their model. They started doing research on congestion around 1972. By 1979, there had been enough research that a conference was held near Paris. DEC and others in the US were doing research on it too. Those working on the Internet didn’t understand that such a collapse from congest could happen until 1986 when it happened to the Internet. So much for seeing problems before they occur.

Emerson: Before we go on, can you expand more on how and why the Internet collapsed in 1986?

Day: There are situations where too many packets arrive at a router and a queue forms, like everyone showing up at the cash register at the same time, even though the store isn’t crowded. The network (or store) isn’t really overloaded but it is experiencing congestion. However in the Transport Layer of the network, the TCP sender is waiting to get an acknowledgement (known as an “ack”) from the destination that indicates the destination got the packet(s) it sent.  If the sender does not get an ack in a certain amount of time, the sender assumes that packet and possibly others were lost or damaged re-transmits everything it has sent since it sent the packet that timed out.  If the reason the ack didn’t arrive is that it was delayed too long at an intervening router and the router has not been able to clear its queue of packets to forward before this happens, the retransmissions will just make the queue at that router even longer.  Now remember, this isn’t the only TCP connection whose packets are going through this router.  Many others are too. And as the day progresses, there is more and more load on the network with more connections doing the same thing.  They are all seeing the same thing contributing to the length of the queue.  So while the router is sending packets as fast as it can, its queue is getting longer and longer.  In fact, it can get so long and delay packets so much, that the TCP sender’s timers will expire again and it will re-transmit again, making the problem even worse. Eventually, the throughput drops to a trickle.

As you can see, this is not a problem of not enough memory in the router; it is a problem of not being able to get through the queue. (Once there are more packets in the queue than the router can send before retransmissions are triggered, collapse is assured.)  Of course delays like that at one router will cause similar delays at other routers.  The only thing to do is discard packets.

What you see in terms of the throughput of the network vs load is that throughput will climb very nicely, increasing, then it begins to flatten out as the capacity of the network is reached, then as congestion takes hold and the queues get longer, throughput starts to go down until it is just a trickle.  The network has collapsed.  The Internet did not see this coming. Nagel warned them in 1984 but they ignored it.  They were the Internet – what did someone from Ford Motor Company know?  It was a bit like the Frank Zappa song, “It can’t happen here.”  They will say (and have said) that because the ARPANET handled congestion control, they never noticed it could be a problem.  As more and more IP routers were added to the Internet, the ARPANET became a smaller and smaller part of the Internet as a whole and it no longer had sufficient influence to hold the congestion problem at bay.

This is an amazing admission. They shouldn’t have needed to see it happen to know that it could. Everyone else knew about it and had for well over a decade. CYCLADES had been doing research on the problem since the early 1970s.  The Internet’s inability to see problems before they occur is not unusual.  So far we have been lucky and Moore’s Law has bailed us out each time.

Emerson: Thank you – please, continue on about what Cyclades did that TCP should have done.

Day: The other thing that CYCLADES noticed about layers in networks was that they weren’t just modules and they realized this because they were looking at the whole network. They realized that layers in networks were more general because they used protocols to coordinate their actions in different computers. Layers were distributed share states with different scopes. Scope? Think of it as building with bricks. At the bottom, we use short bricks to set a foundation, protocols that go a short distance. On top of that are longer bricks, and on top of that longer yet. So what we have is the Physical and Data Link Layer have one scope; the Network and Transport Layers have a larger scope over multiple Data Link Layers. Quite soon, circa 1972, researchers started to think about networks of networks. The CYCLADES group realized that the Internet Transport Layer was a layer of greater scope yet it also operated over multiple networks. So by the mid-1970s, they were looking at a model that consisted of Physical and Data Link Layers of one small scope that is used to create networks with a Network Layer of greater scope, and an Internet Layer over multiple networks of greater scope yet. The Internet today has the model I described above for a network architecture of two scopes, not an internet of 3 scopes.

Why is this a problem? Because congestion control goes in that middle scope. Without that scope, the Internet group put congestion control in TCP, which is about the worse place to put it and thwarts any attempt to provide Quality of Service for voice and video, which must be done in the Network Layer and ultimately precipitated a completely unnecessary debate over net neutrality.

Emerson: Do you mean that a more sensible structure to handle network congestion would have made the issue of net neutrality beside the point? Can you say anything more about this? I’m assuming others besides you have pointed this out before?

Day: Yes, this is my point and I am not sure that anyone else has pointed it out, at least not clearly.  It is a little hard to see clearly when you’re “inside the Internet.”  There are several points of confusion in the net neutrality issue. One is that most non-technical people think that bandwidth is a measure of speed when it is more a measure of capacity.  Bits move at the speed of light (or close to it) and they don’t go any faster or slower. So bandwidth really isn’t a measure of speed. The only aspect of speed in bandwidth is how long it takes to move a fixed number of bits and whatever that is consumes capacity of a link. If a link has a capacity of 100Mb/sec and I send a movie at 50Mb/sec, I only have another 50Mb/sec I can use for other traffic. So to some extent, talk of a “fast lane” doesn’t make any sense. Again, bandwidth is a matter of capacity.

For example, you have probably heard the argument that Internet providers like Comcast and Verizon want “poor little” Netflix to pay for a higher speed, to pay for a faster lane. In fact, Comcast and Verizon are asking Netflix to pay for more capacity! Netflix uses the rhetoric of speed to wrap themselves in the flag of net neutrality for their own profit and to bank on the fact that most people don’t understand that bandwidth is capacity. Netflix is playing on people’s ignorance.

From the earliest days of the Net, providers have had an agreement that as long as the amount of traffic going between them is about the same in both directions they don’t charge each other. In a sense it would “all come out in the wash.” But if the traffic became lop-sided, if one was sending much more traffic into one than the other was sending the other way, then they would charge each other. This is just fair.  Suddenly, because movies consume a lot of capacity, Netflix is generating considerable load that wasn’t there before. This isn’t about blocking a single Verizon customer from getting his movie; this is about the 1000s of Verizon Customers all downloading movies at the same time and all of that capacity is being consumed at a point between Netflix’s network provider and Verizon.  It is even likely they didn’t have lines with that much capacity, so new ones had to be installed.  That is very expensive.  Verizon wants to charge Netflix or Netflix’s provider because the capacity moving from them to Verizon is now lop-sided by a lot.  This request is perfectly reasonable and it has nothing to do with the Internet being neutral. Here’s an analogy: imagine your neighbor suddenly installed an aluminum smelter in his home and was going to use 10,000 times more electricity than he use to.  He then tells the electric company that they have to install much higher capacity power lines to his house and provide all of that electricity and his monthly electric bill should not go up. I doubt the electric company would be convinced.

Net neutrality basically confuses two things: traffic engineering vs discriminating against certain sources of traffic. The confusion is created because of the flaws introduced fairly early and then what that forced the makers of Internet equipment to do to try to work around those flaws.  Internet applications don’t tell the network what kind of service they need from the Net.  So when customers demanded better quality for voice and video traffic, the providers had two basic choices: over provision their networks to run at about 20% efficiency (you can imagine how well that went over) or push the manufacturers of routers to provide better traffic engineering. Because of the problems in the Internet, about the only option open to manufacturers was for them to look deeper into the packet than just making sure they routed the packet to its destination.  However, looking deeper into a packet also means being able to tell who sent it. (If applications start encrypting everything, this will no longer work.)  This of course not only makes it possible to know which traffic needs special handling, but makes it tempting to slow down a competitor’s traffic.  Had the Net been properly structured to begin with (and in ways we knew about at the time), then these two things would be completely distinct: one would have been able to determine what kind of packet was being relayed without also learning who was sending it and net neutrality would only be about discriminating between different sources of data so that traffic engineering would not be part of the problem at all.

Of course, Comcast shouldn’t be allowed to slow down Skype traffic because it is in competition with Comcast’s phone service.  Or Netflix traffic that is in competition with its on-demand video service. But if Skype and Netflix are using more than ordinary amounts of capacity, then of course they should have to pay for it.

Emerson: That takes care of three of the five flaws in TCP. What about the next two?

Day: The next two are somewhat hard to explain to a lay audience but let me try. A Transport Protocol like TCP has two major functions: 1) make sure that all of the messages are received and put in order, and 2) don’t let the sender send so fast that the receiver has no place to put the data. Both of these require the sender and receiver to coordinate their behavior. This is often called feedback, where the receiver is feeding back information to the sender about what it should be doing. We could do this by having the sender send a message and the receiver send back a special message that indicates it was received (the “ack” we mentioned earlier) and to send another. However, this process is not very efficient. Instead, we like to have as many messages as possible ‘in flight’ between them, so they must be loosely synchronized. However, if an ack is lost, then the sender may conclude the messages were lost and re-transmit data unnecessarily. Or worse, the message telling the sender how much it can send might get lost. The sender is waiting to be told it can send more, while the receiver thinks it told the sender it could send more. This is called deadlock. In the early days of protocol development a lot of work was done to figure out what sequence of messages was necessary to achieve synchronization. Engineers working on TCP decided that a 3-way exchange of messages (3-way handshake) could be used at the beginning of a connection. This is what is currently taught in all of the textbooks. However, in 1978 Richard Watson made a startling discovery: the message exchange was not what achieved the synchronization. It was explicitly bounding three timers. The messages are basically irrelevant to the problem. I can’t tell you what an astounding result this is. It is an amazingly deep, fundamental result – Nobel Prize level! It not only yields a simpler protocol, but one that is more robust and more secure than TCP. Other protocols, notably the OSI Transport Protocol, incorporate Watson’s result but TCP only partially does and not the parts that improves security. We have also found this implies the bounds of what is networking. If an exchange of messages requires the bounding of these timers to work correctly, it is networking or interprocess communication. If they aren’t bounded, then it is merely a remote file transfer. Needless to say, simplicity, working well under harsh conditions (or robustness), and security are all hard to get too much of.

Addressing is even more subtle and its ramifications even greater. The simple view is that if we are to deliver a message in a network, we need to say where the message is going. It needs an address, just like when you mail a letter. While that is the basic problem to be solved, it gets a bit more complicated with computers. In the early days of telephones and even data communications, addressing was not a big deal. The telephones or terminals were merely assigned the names of the wire that connected them to the network. (This is sometimes referred to as “naming the interface.”) Until fairly recently, the last 4 digits of your phone number were the name of the wire between your phone and the telephone office (or exchange) where the wire came from. In data networks, this often was simply assigning numbers in the order the terminals were installed.

But addressing for a computer network is more like the problem in a computer operating system than in a telephone network. We first saw this difference in 1972. The ARPANET did addressing just like other early networks. IMP addresses were simply numbered in the order they were installed. A host address was an IMP port number, or the wire from the IMP to the host. (Had BBN give a lot of thought to addressing? Not really. After all this was an experimental network. The big question was, would it work at all!!?? Let alone could it do fancy things! Believe me, just getting a computer that had never been intended to talk to another computer to do that was a big job. Everyone knew that addressing issues were important, difficult to get right, so a little experience first would be good before we tackled them.) Heck, the maximum number of hosts was only 64 in those days.)

In 1972, Tinker AFB joined the ‘Net and wanted two connections to the ARPANET for redundancy! My boss told me this one morning, and I first said, ‘Great! Good ide . . . ‘ I didn’t finish it and instead, I said, O, cr*p! That won’t work! (It was a head slap moment!) 😉 And a half second after that said, ‘O, not a big deal, we are operating system guys, we have seen this before. We need to name the node.’

Why wouldn’t it work? If Tinker had two connections to the network, each one would have a different address because they connected to different IMPs. The host knows it can send on either interface, but the network doesn’t know it can deliver on either one. To the network, it looks like two different hosts. The network couldn’t know those two interfaces went to the same place. But as I said, the solution is simple: the address should name the node, not the interface.[2]

Just getting to the node is not enough. We need to get to an application on the node. So we need to name the applications we want to talk to as well. Moreover, we don’t want the name of the application to be tied to the computer it is on. We want to be able to move the application and still use the same name. In 1976, John Shoch put this into words as: application names indicate what you want to talk to; network addresses indicate where it is; and routes tell you how to get there.

The Internet still only has interface addresses. They have tried various work-arounds to solve not having two-thirds of what is necessary. But like many kludges, they only kind of work, as long as there aren’t too many hosts that need it. They don’t really scale. But worse, none of them achieve the huge simplification that naming the node does. These problems are as big a threat to the future of the Internet as the congestion control and security problems. And before you ask, no, IPv6 that you have heard so much about does nothing to solve them. Actually from our work, the problem IPv6 solves is a non-problem, if you have a well-formed architecture to begin with.

The biggest problem is router table size. Each router has to know where next to send a packet. For that it uses the address. However for years, the Internet continued to assign addresses in order. So unlike a letter where your local post office can look at the State or Country and know which direction to send it, the Internet addresses didn’t have that property. Hence, routers in the core of the ‘Net needed to know where every address went. As the Internet boom took off that table was growing exponentially and was exceeding 100K routes. (This table has to be searched on every packet.) Finally in the early 90s, they took steps to make IP addresses more like postal addresses. However, since they were interface addresses, they were structured to reflect what provider’s network they were associated with, i.e. the ISP becomes the State part of the address. If one has two interfaces on different providers, the problem above is not fixed. Actually, it needs a provider-independent address, which also has to be in the router table. Since even modest sized businesses want multiple connections to the ‘Net, there are a lot of places with this problem and router table size keeps getting bigger and bigger, now around 500K and 512K is an upper bound that we can go beyond, but it impairs adoption of IPv6 to do so. In the early 90s, there was a proposal[3] to name the node rather than the interface. But the IETF threw a temper tantrum refused to consider breaking with tradition. Had they done that it would have reduced router table size by a factor of between 3 and 4, so router table size would be closer to 150K. In addition, naming the interface only makes doing mobility a complex mess.

Emerson: I see – so, every new “fix” to make the Internet work more quickly and efficiently is only masking the fundamental underlying problems with the architecture itself. What is the last flaw in TCP you’d like to touch on before we wrap up?

Day: Well, I wouldn’t say ‘more quickly and efficiently.’ We have been throwing Moore’s Law at these problems: processors and memories have been getting faster and cheaper faster than the Internet problems have been growing, but that solution is becoming less effective. Actually, the Internet is becoming more complex and inefficient.

But as to your last question, another flaw with TCP is that it has a single message type rather than separating control and data. This not only leads to a more complex protocol but greater overhead. They will argue that being able to send acknowledgements with the data in return messages saved a lot of bandwidth. And they are right. It save about 35% bandwidth when using the most prevalent machine on the ’Net in the 1970s, but that behavior hasn’t been prevalent for 25 years. Today the savings are miniscule. Splitting IP from TCP required putting packet fragmentation in IP, which doesn’t work. But if they had merely separated control and data it would still work. TCP delivers an undifferentiated stream of bytes which means that applications have to figure out what is meaningful rather than delivering to a destination the same amount the sender asked TCP to send. This turns out to be what most Applications want. Also, TCP sequence numbers (to put the packets in order) are in units of bytes not messages. Not only does this mean they “roll-over” quickly, either putting an upper bound on TCP speed or forcing the use of an extended sequence number option which is more overhead. This also greatly complicates reassembling messages, since there is no requirement to re-transmit lost packets starting with the same sequence number.

Of the 4 protocols we could have chosen in the late 70s, TCP was (and remains) the worse choice, but they were spending many times more money than everyone else combined. As you know, he with the most money to spend wins. And the best part was that it wasn’t even their money.

Emerson: Finally, I wondered if you could briefly talk about RINA and how it could or should fix some of the flaws of TCP you discuss above? Pragmatically speaking, is it fairly unlikely that we’ll adopt RINA, even though it’s a more elegant and more efficient protocol than TCP/IP?

Day: Basically RINA picks up where we left off in the mid-70s and extends what we were seeing then but hadn’t quite recognized. What RINA has found is that all layers of the same functions they just are focused on different ranges of the problem space. So in our model there is one layer that repeats over different scopes. This by itself solves many of the existing problem of the current Internet, including those described here. But in addition, it is more secure as multihoming and mobility falls out for free. It solves the router table problem because the repeating structure allows the architecture to scale, etc.

I wish I had a dollar for every time someone has said (in effect), “gosh, you can’t replace the whole Internet.” There must be something in the water these days. They told us that we would never replace the phone company, but it didn’t stop us and we did.

I was at a high-powered meeting a few weeks ago in London that was concerned about the future direction of architecture. The IETF [Internet Engineering Task Force] representative was not optimistic. He said that within 5-10 years, the number of Internet devices in the London area would exceed the number of devices on the ‘Net today, and they had no idea how to do the routing so the routing tables would converge fast enough.

My message was somewhat more positive. I said, I have good news and bad news. The bad news is: the Internet has been fundamentally flawed from the start. The flaws are deep enough that either they can’t be fixed or the socio-political will is not there to fix them. (They are still convinced that not naming the node when they had the chance was the right decision.) The good news is: we know the answer and how to build it, and these routing problems are easily solved.

[1] An IMP was an ARPANET switch or today router. (It stood for Interface Message Processor, but is one of those acronyms where the definition is more important than what it stood for.) NCP was the Network Control Program, that managed the flows between applications such as Telnet, a terminal device driver protocol; and FTP, a File Transfer Protocol.

[2] It would be tempting to say “host” here rather than “node,” but one might have more than one node on a host. This is especially true today with Virtual Machines so popular, each one is a node. Actually, by the early 80s we had realized that naming the host was irrelevant to the problem.

[3] Actually, it wasn’t a proposal, it was already deployed in the routers and being widely used.

Glitch Aesthetics

Below is the entry on “Glitch Aesthetics” I wrote for the Johns Hopkins Guide to Digital Media. As always, so much more could have been and should be written…


Glitch Aesthetics

‘Glitch’ was first used in the early 1960s to describe either a change in voltage in an electrical circuit or any kind of interference in a television picture. By the 1990s, ‘glitch’ broadly described brief bursts of unexpected behavior in electrical circuits but it also more specifically was used to describe a style of electronic music that was created from already-malfunctioning audio technology (or from causing technology to malfunction) as a way to explore the life of the digital machine and as a reaction against the push in the computing industry to create a ever-more clean, noise-free sound. The term has since been appropriated by musicians, gamers, artists, and designers as a name for what Olga Goriumnova and Alexei Shulgin call a “genuine software aesthetics” (111). (Ssee NET.ART, GAMEPLAY) Glitch aesthetics, then, involves experimentation with the visible results of provoked or unprovoked computer error. (Such glitches could include aestheticizing the visible results of a virus or even provoking the computer to take on a virus in order to explore its underlying workings.) (see VIRAL AESTHETICS)

Its relation, then, to an aesthetics of failure and to the embrace of chance means that glitch aesthetics clearly finds its roots in early twentieth century avant-garde experiments in art, writing, theater, and music. These experiments on the one hand sought to disrupt the status quo which was supposedly maintained by tranquil, harmonius art and on the other hand they reflected a search for a new realism – one that represented the noise and chaos of a rapidly industrializing world. Luigi Russolo, for example, wrote the Futurist manifesto “The Art of Noises” in 1913 in which he declares that “Today music, as it becomes continually more complicated, strives to amalgamate the most dissonant, strange and harsh sounds…This musical evolution is paralleled by the multiplication of machines, which collaborate with man on every front. Not only in the roaring atmosphere of major cities, but in the country too, which until yesterday was totally silent, the machine today has created such a variety and rivalry of noises that pure sound…no longer arouses any feeling.” Russolo believed, then, that noise – random, dissonant, machine-based sounds as opposed to what he called “pure sound” – was fast becoming the only way to experience the world anew.

Glitch aesthetics also finds its roots in early twentieth century Dada experiments to escape the out-dated notion of the romantic, individual geniuis whose art and writing was seen to be driven by a singular, self-reliant author with a clear intent. Instead, Dadaists such as Tristan Tzara attempted to open writing and art to the chaos and unpredictability of everyday life by, for example, advocating in “To Make a Dadaist Poem” that we cut up words from a newspaper article, randomly draw these words from a hat, and copy them “conscientiously in the order in which they left the bag.” It was an attempt to redefine the role of the artist/writer by taking away authorial control and seeking to move away from the egotism of the individual romantic geniuis. More, it was also an attempt to redefine the nature of an aesthetic object. If a poem could consist of randomly chosen words and if, as Marcel Duchamp demonstrated with his ready-mades, a sculpture could consist of a urinal turned upside down or a bicycle-wheel affixed to a stool, then a whole range of traditionally unbeautiful, everyday objects and sounds are available as art.

Glitch, then, takes this radical shift in what counts as an aesthetic object or aesthetic experience and asserts that its disruptiveness (in that a glitch constitutes a moment of dysfunctionality in the computer system) defamiliarizes the slick surface of the hardware/software of the computer and so ideally transforms us into critically minded observers of the underlying workings of the computer. As Goriumnova and Shulgin put it, “A glitch is a mess that is a moment, a possibility to glance at software’s inner structure…Although a glitch does not reveal the true functionality of the computer, it shows the ghostly conventionality of the forms by which digital spaces are organized” (114). One of the best-known creators of glitch art and games is the Dutch-Belgian collective Jodi (whose members are Joan Heemskerk and Dirk Paesmans). Jodi has, for example, modified old videogames such as Quake – reassembling the original game so that its architecture no longer functions according to the conventions of *gameplay. For example, Jodi is well known for exploiting a glitch in Quake that causes the player to be entrapped in a cube; the glitch is provoked every time the Quake software attempts to visualize the cube’s black-and-white checked wallpaper. (“jodi,” “untitled game”)

It is worth emphasizing that glitches may be provoked or unprovoked. In addition to Jodi’s provoked glitch described above, glitch artist Jeff Donaldson writes that one might also provoke a glitch by sending “an audio signal through video input” or by “opening image files in word processing applications. JPGs become text, which can then be randomly edited and saved again as images to be displayed through the filter of codecs.” An unprovoked glitch, then, captures a moment in which an error in the computer system is made visible; it therefore exploits randomness and chance as a way to disrupt the digital ideal of a clean, frictionless, error-free environment in which the computer supposedly fades into the background while we, as creators or workers, effortlessly produce without any attention to the ways in which the computer (or software) determines what and how we produce. As Donaldson puts it, “[i]t is chance made manifest and a spontaneous reordering of data, like the wave function collapse of quantum theory. In its pure, wild sense, a glitch is the ghost in the machine, the other side of intention, a form that is hidden until it manifests itself of its own accord.”

SEE ALSO: hacking, interface, randomness

References and further reading

  • Donaldson, Jeffrey. “Glossing over Thoughts on Glitch. A Poetry of Error.” Artpulse Magazine.
    Glitch.” Wikipedia.
  • Goriunova, Olga and Alexei Shulgin. 2008. “Glitch.” In Software Studies: A Lexicon, ed. Matthew Fuller (Boston, MA: MIT Press), 110-119.
  • jodi.”
  • Krapp, Peter. 2011. Noise Channels: Glitch and Error in Digital Culture. Minneapolis, MN: U of Minnesota P.
  • eds. Moradi, Iman and Ant Scott, Joe Gilmore, Christopher Murphy. 2009. Glitch: Designing Imperfection. New York: Mark Batty Publisher.
  • Russolo, Luigi. “The Art of Noises.”
  • Tzara, Tristan. “To Make a Dadaist Poem
  • untitled game.”

how bibliographic description & interface creates users and objects

I’m very pleased I have the opportunity to visit the University of Cincinnati’s English Department on Saturday, April 5th to give a workshop on some of my work in critical work on interface and archives as well as the Media Archaeology Lab as a way to help them think about their growing audio archive of poetry recordings from the Elliston Poetry Room. The outline of the workshop is as follows:

  1. Overview of the history and philosophy of the Media Archaeology Lab (MAL). Discussion about media archaeology as a field and/or methodology appropriate for thinking through the Elliston collection.
  2. Challenges of cataloguing and description in the MAL; drawing on reading by Svenonius and Dublin Core, discussion of how description creates objects and users.
    • Small group activity: listen to the first track of C.K. Williams reading in the Elliston collection from February 2014; with 2-3 people, take 10-15 minutes to come up with an alternative bibliographic description for this event, possibly including fields for information you may not have access to (original medium? who recorded it and how? size of audience? etc.), and making sure you discuss how your description frames the reader’s experience and interpretation of the event; share your results with the larger group.
  3. Discussion of how interface creates objects and users; discussion of the affordances of the interface at Pennsound and Ubu.
    • Small group activity: with 2-3 people, look again at the page for the C.K. Williams reading and discuss the strengths and weaknesses of the current interface – what sorts of scholarly and creative interactions does it encourage and discourage? What sort of listening experience does it encourage and discourage? And finally, the harder question: what do you imagine could be the ideal interface either for the collection or for this particular page? Share your results with the larger group.
  4. If there’s time, discussion of the affordances of out-of-the-box digital tools for experimentation/interpretation of audio files.
    • Small group activity 1: download  Paperphone, “an interactive audio application that processes voice and sound materials live and in-context,” along with the recommended Runtime app; try to either load the same first track of the C.K. Williams reading with the app or just explore the limits and possibilities of this tool, paying particular attention to the tool’s interface. In what ways would a tool like Paperphone be useful for the Elliston collection? Report back to the group with your findings on its usefulness.
    • Small group activity 2: now look at Trevor Owen’s blog post “Glitching Files for Understanding” in which he demonstrates different ways to view MP3 files. After reading his instructions, try reading the MP3 file of the first track of the C.K. Williams reading in a text editor; discuss your observations, including what’s gained and what’s lost from this sort of analysis versus the analysis that Paperphone makes possible and report back to the larger group.