Summary: Here we look at an overview of what we have been discussing in this module.
These different tracks have intersected, overlapped and sometimes diverted from one another, taking us along multiple roads that were looking at
These different tracks have intersected, overlapped and sometimes diverted from one another, taking us along multiple roads that were looking at:
* the potential of infrapunctures to address harms caused by digital infrastructures,
* the differences between digital infrastructures, computational infrastructures and platforms and what kind of friction that brings forward,
@ -11,15 +11,16 @@ These different tracks have intersected, overlapped and sometimes diverted from
* bots as infrastructural embodiment,
* examples of bots as possible infrapunctures,
* the proposed term *bot logic* in relation to platform logic,
* bot behaviours
* bot behaviours,
and two ways to engage with bot logic by writing a fictional scripted dialogue and diving deeper into their materiality by running a simple bot code template which toots on botsin.space.
While this short module is not a programming lesson, a tutorial, or a set of methodologies to understand the possibilities of bots as infrapunctures, we hope that it can point towards a few ways in which bots either support or challenge the relations and interaction that a digital infrastructure makes possible.
Throughout this module we have tried to trace multiple forms of bot making and thinking with as kinds of intervention within a digital infrastructure.
As they do not require to function within server-side conditions and can be run using personal resources, bots create potential for users to express agency within the infrastructure's affordances and possibly even relations between the human and nonhuman actors present.
Bots are of course not a solution to computationally generated harm, nor are they able to repair infrastructures. While there is possibility to run a bot without using the API of an infrastructure, in order to have access to different functionalities than users, most bots still engage with it. It follows that with a change in an infrastructure's internal policy, they can easily be rejected.
Bots are of course not a solution to computationally generated harm, nor are they able to repair infrastructures. Let's take for example the dependency of bots on APIs. While there is possibility to run a bot without using the API of an infrastructure, in order to have access to different functionalities than users, most bots will engage with it. It follows that with a change in an infrastructure's internal policy, the bots can easily be rejected. One example of this is the Twitter bot purge from 2018.
Nonetheless, bots enable certain possibilities to get to know and engage with an infrastructure's material, political and social aspects. Bots are prototypes as arguments, pointing towards ways in which infrastructures could be different. And perhaps this rhetorical quality may lead to a bigger impact.
Summary: Wrap up of the module. Thinking through infrastructural embodiments for times of infrastructural complexity.
We have reached the end of the module. The term *digital infrapunctures* leaves us with possibilities to critically engage with digital infrastructures, that ask for further unfolding and experimentation. Infrapunctures can be small. An intervention can trigger bigger ones. To make sure that we can rely on truly fair operating infrastructures, we need a whole range of actions that expose infrastructural stress points. Could these include activist bots marking hurt? Poetic bots proposing alternative readings? Or annoying bots asking for attention?
