This is the repository for the online module Bots as Digital Infrapuncture, commissioned by the Utrecht University
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

72 lines
5.3 KiB

Title: Materiality of Bots
Slug: 02-s6-step-2
Date: 2020-11-01 12:01
Summary: Code, API's and background processes.
Talking about the materiality of bots might sound a bit funny at first. It is crucial though to closely look at *how* and *where* a bot operates, in order to imagine in what kind of ways they can intervene in an infrastructure. To do this, we will study the digital materiality of bots.
<!-- We use the term *materiality* by following Johanna Drucker's definition of *performative materiality*[^drucker]:
> “Performative materialtiy suggests that what something is has to be understood in terms of what it does, how it works within machinic, systemic, and cultural domains.” -->
<!-- As we learned from the section *Bot Logic*: bot-making includes not only a study of technical mechanisms, it also includes studying the norms, values and communicative habits of an infrastructure. -->
The materiality of bots can be unpacked through three technical ingredients of a bot-making process:
1. **code**
2. **API's**
3. **background processes**
4 years ago
### Code
The first ingredient will not come as a surprise: **code**.
If we look at the digital materiality of a bot, we can say that a bot is a script: an executable file that sits on your computer or on a server. Code is used to describe *how* the bot makes a connection, *what* function it has and *when* it comes into action.
There are a whole range of programming languages that a bot-maker can use to make a bot. Popular programming languages are Python and Javascript. The choice for a specific language is often based on the preference of the programmer. However, the choice for a programming language can also be based on the availability of a so called *library*: a friendly wrapper that enables a programmer to interact with an API.
4 years ago
### API's {#APIs}
4 years ago
If we talk about the relationship between platform and bots, we cannot escape talking about the **API**.
The term API is an acronym for Application Programming Interface. It is an code-based interface between the programmer and a platform, such as Wikipedia, Reddit, Whatsapp, Twitter or Mastodon. Not all communication infrastructures have an API, it's a decision of the owner of the infrastructure to make one. Every API is therefor different and each one comes with different rules and constraints.
Taina Bucher[^bucher] defines an API as an infrastructural device that is shaped (and shaping) many different things:
> Among other things, web APIs encompass: a physicality in terms of the corporeal landscape of infrastructure and technology, through to the economic logics at work (i.e. business models, ownership, licencing of the APIs), functions and services (i.e. access to data), practices of users (i.e. forms of labor, play and collaboration), discursive formations (i.e. statements, knowledge, ideas), rules and norms (i.e. design principles, terms of service, technical standards), as well as social imaginaries and desires.
When looking at API's from a technical perspective, we see a set of rules that applications use to communicate with each other. This (apparently) neutral conception is in reality a very complex conglomerate of imaginaries, whether technological, economical or societal.
Essentially does the API determine how the platform developers imagine it will be used by other developers, revealing a relationship of imbalanced power. It welcomes interventions as an opportunity to expand the functionalities beyond what the original developers might have imagined. On centralized infrastructures this often results into generating more economical value in the end.
So to sum up: a bot is written in **code** and uses an **API** to interact with an infrastructure.
4 years ago
### Background processes
To run the bot, we need one more last ingredient: a so called **background process**.
A computational *process* is nothing more then a running script. In the most simple version, this can be done from your own computer. In a more complex version, you could upload your script to a server and run it from there continuously as a **background process**.
Why would you run a bot continuously?
As bots usually operate over a long period of time, you might not want to run them from your own computer, as this means that you need to keep your computer on for a long period of time (imagine you want to keep a bot running for a year!).
Instead, bot-makers often run their bots from a server as a *background process*, which allows them to continuously run them without the need to be present. Processes can be stopped, started or restarted at any time with simple commands. Their status can be checked (to see if a bot is still running for example) and logfiles can be accessed.
These three ingredients (*code*, *API's* and *background processes*) provide insight into the digital materiality of bots.
In the next page we will further unpack the material implications of code, by zooming into the features and constraints of *programming logic*.
<br>
## Footnotes
[^bucher]: Bucher, Taina. "Objects of Intense Feeling: The Case of the Twitter API" *Computational Culture 3* (2013) <http://computationalculture.net/objects-of-intense-feeling-the-case-of-the-twitter-api/>
<!-- [^drucker]: Johanna Drucker (2013) *Performative Materiality and Theoretical Approaches to Interface*, <http://digitalhumanities.org//dhq/vol/7/1/000143/000143.html> -->