Until now we have been referring to digital infrastructures. However, bots they are mostly contextualised as being active on a platform. In many ways digital infrastructures and platforms overlap in their invisibility, broad public usage, or extensibility. According to Platin et al (2016), both ways of framing offer helpful elements to each other. We are witnessing a platformisation of infrastructure in tandem with an infrastructuralisation of platforms through information technologies, where on the one hand, infrastructures start to splinter into services taken over by private enterprises, and on the other hand, platforms start taking on more responsibilities which were previously managed by the government. [^platin]. For the purposes of this online module, we are interested in the programmability (the capacity to go beyond the original designers' intention) and affordances (what is allowed ) of platforms combined with the public interest and responsibility of infrastructures. However, in order to highlight the importance of tools made solely for the purpose of optimising for a public, and not for corporate profit, we will from now on refer to platforms as digital communication infrastructures. Doing so avoids the ambiguity of describing the continual reparation of systems and their ecology as health. We are interested in the potential of bots to repair in the benefit of one or multiple publics.
Having just unfolded what infrastructural harms could be, we now move to exploring bots. When we say bots, we refer to software agents which automatise certain actions and can run autonomously or semi-autonomously. Some of the most mentioned examples are voice assistants such as Alexa or Siri, but they can also be web crawlers indexing the web or bots maintaining Wikipedia.
The particular bots we are interested in for this online module are those that act as an interface between the digital platform and human users, or what Andreas Hepp calls communicative robots[^hepp], robots that "are defined as autonomously operating systems designed for the purpose of quasi-communication with human beings to enable further algorithmic-based functionalities – often but not always on the basis of artificial intelligence" [page numbers].
@ -11,3 +13,7 @@ In this section, we will introduce Andreas Hepp, professor of media and communic
[^hepp]: Hepp, Andreas. "Artificial companions, social bots and work bots: communicative robots as research objects of media and communication studies"
*Infrapuncture* is a helpful term at a time when there is a lot of discussion around the political roles [perhaps be more specific, e.g. their undue influence in elections] of automated agents [maybe just call it bots?] in communication platforms. Making a bot can be a way to probe and understand potential forms of interventions, create new imaginaries or deflate existing hegemonic structures.
*Infrapuncture* is a helpful term at a time when there is a lot of discussion around the political roles [perhaps be more specific, e.g. their undue influence in elections] of automated agents [maybe just call it bots?] in communication platforms. Making a bot can be a way to probe and understand potential forms of interventions, create new imaginaries or deflate existing hegemonic structures.
However, a bot always relies on the technical restrictions and possibilities of interaction defined by the infrastructure. In order to run a bot, a technical understanding of this infrastructure is therefore required. The API (Application Programming Inferface) is an important entry point here. This technical framework provides a programming interface to communicate with a system. The API can be understood as a *door protocol* that is designed by the owner of an infrastructure, which eventually defines the technical imaginary of a platform. (*We dive a bit deeper into API's in Section 6, [click here](/02-s6-step-2.html#APIs) to go their directly.*)
However, a bot always relies on the technical restrictions and possibilities of interaction defined by the infrastructure. In order to run a bot, a technical understanding of this infrastructure is therefore required. The API (Application Programming Interface) is an important entry point here. This technical framework provides a programming interface to communicate with a system. The API can be understood as a *door protocol* that is designed by the owner of an infrastructure, which eventually defines the technical imaginary of a platform. (*We dive a bit deeper into API's in Section 6, [click here](/02-s6-step-2.html#APIs) to go there directly.*)
Before launching a bot into a digital environment, the bot maker does not only need to find a technical entry point, but also a social one. Writing a bot does not only imply technical knowledge about an API of a platform, [<-thispartoftehsentencecanbedeltedbecauserepetivive]italsoimpliesathoroughunderstandingofwhatdeterminesthepossibilitiesofinteractionandthesocialnormsestablishedwithinasocialenvironment.
