adding a big chunk of section 6 + a change in section 4
This commit is contained in:
parent
51be9544cd
commit
3186c218c4
@ -49,8 +49,10 @@ As opposed to Twitter, Mastodon is a free and open source self-hosted networking
|
||||
|
||||
Mastodon is part of a bigger network, which is also known as *the Fediverse*, which has grown into a social media space that is currently used by more then 5 million people. In contrast to social media platforms as Twitter, Instagram or Facebook, it consists of a whole range of different *kind of* social media: blogs, micro-blogging, photo-sharing, video-sharing, link-sharing, etc., that can exchange posts and content with each other. Each instance does this, however, under their own terms. In contrast with the top-down organisation of centralized networks, the Fediverse and its federated network typology allow different groups to configure their network differently.
|
||||
|
||||
Each network is being shaped by its stakeholders. Which is sometimes a single individual, sometimes a group of peers that share the same interest and other times by an organisation. Often it is the system administrator(s) of a network who decides what the rules are: who can publish? What kind of material can be published? What communication features are available?
|
||||
|
||||
|
||||
|
||||
<!--  -->
|
||||
|
||||
Interestingly enough, with a different infrastructural system comes a different type of ruleset. The federated network structure of the Fediverse also has concequences for bots. On platforms like Mastodon, bots need to both comply to the terms of services of the API and to community agreements, such as the formentioned Code of Conduct or Community Guidelines.
|
||||
|
||||
|
||||
@ -5,12 +5,13 @@ Summary: Start of the bot-making excercise.
|
||||
|
||||
In this last section of the module we will make a bot. 🤖
|
||||
|
||||
We will use the dialog script we wrote in the previous section and translate it into a bot ([in case you haven't done it yet, it is recommended to go through this section first](/category/section-5-infrapunctural-imaginaries-exercise.html)).
|
||||
We will use the script we wrote in the previous section and translate it into a bot ([in case you haven't done it yet, it is recommended to go through this section first](/category/section-5-infrapunctural-imaginaries-exercise.html)).
|
||||
|
||||
Before we dive into bot-making, we will first look into the **materiality of bots**: How do they operate? What code is needed to make a bot? And how does a bot connect to an infrastructure, both in a technical and dialogical way?
|
||||
Before we dive into bot making, we will first look into the **materiality of bots**: How do they operate? What code is needed to make a bot? And how does a bot connect to an infrastructure, both in a technical and dialogical way?
|
||||
|
||||
Then we will go through a couple of basic features of **programming logic** to explore the computational nature of bots, such as loops, if/else statements and variables. It will help us to get a better understanding of the mechanisms behind these automated agents.
|
||||
Then we will go through a couple of basic features of **programming logic** to explore the computational structure of bots, such as loops, if/else statements and variables. It will help us get a better understanding of the mechanisms behind these automated agents.
|
||||
|
||||
After that, we will look at the code of an **example bot**, to study how other bot-makers write and operate them.
|
||||
After that, we will look at the code of an **example bot**, to study how other bot makers write and operate them.
|
||||
|
||||
And lastly, we will finish this module by **making a bot** ourselves.
|
||||
|
||||
|
||||
@ -1,61 +1,55 @@
|
||||
Title: Materiality of Bots
|
||||
Slug: 02-s6-step-2
|
||||
Date: 2020-11-01 12:01
|
||||
Summary: Code, API's and background processes.
|
||||
Summary: Code, APIs 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.
|
||||
In order to imagine in what kind of ways bots can intervene in an infrastructure, we will study the 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:
|
||||
Their materiality can be unpacked through three technical ingredients of a bot making process:
|
||||
|
||||
1. **code**
|
||||
2. **API's**
|
||||
2. **APIs**
|
||||
3. **background processes**
|
||||
|
||||
### 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.
|
||||
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* functions 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.
|
||||
There are a whole range of programming languages that a bot maker can use to make a bot. 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.
|
||||
|
||||
### API's {#APIs}
|
||||
### APIs {#APIs}
|
||||
|
||||
If we talk about the relationship between platform and bots, we cannot escape talking about the **API**.
|
||||
If we talk about the relationship between communication infrastructures 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.
|
||||
The term API is an acronym for Application Programming Interface. It is an code-based interface either between multiple applications or between the programmer and a platform, such as Wikipedia, Reddit, Whatsapp, Twitter or Mastodon. Not all communication infrastructures have an API, it is a decision of the owner of the infrastructure to make one. Having access to an infrastructure through a programming interface is not a default. Also, every API is different and each one comes with its own rules and constraints.
|
||||
|
||||
Taina Bucher[^bucher] defines an API as an infrastructural device that is shaped (and shaping) many different things:
|
||||
Taina Bucher[^bucher] defines an API as an infrastructural device that is shaped (and shaping) many different elements:
|
||||
|
||||
> 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.
|
||||
When looking at APIs 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.
|
||||
Essentially the API determines 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.
|
||||
To sum up: a bot is written in **code** and uses an **API** to interact with an infrastructure.
|
||||
|
||||
### Background processes
|
||||
|
||||
To run the bot, we need one more last ingredient: a so called **background process**.
|
||||
To run the bot, we need one 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**.
|
||||
A computational *process* is nothing more then a running script. In the simplest 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!).
|
||||
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 all this 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.
|
||||
Instead, bot makers often run their bots from a server as a *background process*, which allows them to be continuously active without any further intervention from the programmer.
|
||||
|
||||
These three ingredients (*code*, *API's* and *background processes*) provide insight into the digital materiality of bots.
|
||||
These three ingredients—*code*, *APIs* and *background processes*—provide insight into the technical 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*.
|
||||
In the next page we will zoom into the features and constraints of *programming logic*.
|
||||
|
||||
<br>
|
||||
|
||||
@ -63,9 +57,3 @@ In the next page we will further unpack the material implications of code, by zo
|
||||
|
||||
[^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> -->
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,51 +1,82 @@
|
||||
Title: Programming Logic
|
||||
Title: Logics of Programming
|
||||
Slug: 03-s6-step-3
|
||||
Date: 2020-11-01 12:02
|
||||
Summary: Loops, if/else statements, variables and more.
|
||||
Summary: Variables, data objects, loops and if/else statements.
|
||||
|
||||
<!-- > People, things, events are "programmed", one speaks of "inputs" and "outputs", of feedback loops, variables, parameters, processes, and so on, until eventually all contact with concrete situations is abstracted away.[^weizenbaum] -->
|
||||
<!-- [^weizenbaum]: Weizenbaum, Joseph "Computer Power and Human Reason, From Judgement to Calculation" (1976) -->
|
||||
|
||||
As bots are written in code, they are based on the features and constraints of *programming logic*.
|
||||
As bots are written in code, they are based on the features and constraints of certain logics of programming.
|
||||
|
||||
To unpack this term, we will look at how the following elements are operating, specifically in the programming language Python:
|
||||
At the end of this section, we will be working on a bot example written in the Python programming language. Even though we will not be able to provide a programming primer here, we would like to introduce some general elements that are used in programming practices. We will look at how the following elements are operating in Python:
|
||||
|
||||
* variables
|
||||
* data objects
|
||||
* loops
|
||||
* if/else statements
|
||||
* variables
|
||||
|
||||
### Variables
|
||||
|
||||
When writing code, information can be temporary stored in the memory of the computer under a specific label, called a *variable*. These can store text (as *strings*) or numbers (for example as *integers*) and function as useful containers to reuse an element multiple times.
|
||||
|
||||
```
|
||||
a = 3 # This is an integer
|
||||
b = '3' # This is a string (note the quotation marks)
|
||||
```
|
||||
|
||||
Variables can be used in mathematical operations, such as the following:
|
||||
|
||||
```
|
||||
a = 3
|
||||
b = '3'
|
||||
|
||||
a + b
|
||||
> 6.0
|
||||
|
||||
a + b
|
||||
> Error
|
||||
|
||||
a * a
|
||||
> 9
|
||||
|
||||
a * b
|
||||
> '333'
|
||||
```
|
||||
|
||||
### Data Objects
|
||||
|
||||
How to store data?
|
||||
There are multiple ways to store data, two of them being lists and dictionaries.
|
||||
|
||||
Lists
|
||||
**Lists**
|
||||
|
||||
```
|
||||
agents = ['bot', programmer', 'user', 'moderator', 'server', 'regulator']
|
||||
colors = ['red', 'magenta', 'yellow', 'blue', 'purple', 'green']
|
||||
objects = ['apple', 'book', 'cable']
|
||||
some_numbers = [2, 3, 5, 7, 11]
|
||||
```
|
||||
|
||||
Dictionaries
|
||||
**Dictionaries**
|
||||
|
||||
```
|
||||
vocabulary = {
|
||||
'welcome' : 'Hello, how are you doing?',
|
||||
'disagreement' : 'That makes no sense to me.',
|
||||
'greeting' : 'Thanks for this, bye!'
|
||||
}
|
||||
|
||||
'welcome' : 'Hello, how are you doing?',
|
||||
'disagreement' : 'That makes no sense to me.',
|
||||
'greeting' : 'Thanks for this, bye!'
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
### Loops
|
||||
|
||||
A loop is an element in programming that allows you to execute a single line of code multiple times. It is a central figure in automatising a task that is repetitive.
|
||||
A loop is an element in programming that allows you to execute a single line of code for a certain number of times or until a condition is fulfilled.
|
||||
|
||||
By using for example a `range()` loop, you can ask the program to execute a command `x` many times. In the following example, the `print()` command is asked to return the word `bot` as many times as the loop is iterating.
|
||||
|
||||
```
|
||||
for x in range(5):
|
||||
print('bot' * x)
|
||||
print('bot' * x)
|
||||
|
||||
> bot
|
||||
> botbot
|
||||
@ -54,26 +85,32 @@ for x in range(5):
|
||||
> botbotbotbotbot
|
||||
```
|
||||
|
||||
Another type of loop is the `while` loop, which allows to repeat a command for an infinite number of times. This type of loop can be stopped by a manual interruption of the programmer, usually by typing a specific key-combination, such as `CTRL+D`.
|
||||
Another type of loop is the `while` loop, which allows to repeat a command for as long as a condition is or isn't fulfilled. This type of loop can be stopped by a manual interruption of the programmer, usually by typing a specific key-combination, such as `CTRL+D`.
|
||||
|
||||
```
|
||||
while True:
|
||||
print('bot')
|
||||
print('bot')
|
||||
|
||||
> bot
|
||||
> bot
|
||||
> bot
|
||||
> bot
|
||||
> bot
|
||||
> ...
|
||||
```
|
||||
|
||||
Other loops, such as the `for` loop, are useful to iterate over a specific set of items. If you would like to write a bot that would, for example, post a message of each sentence of a book, you could loop over all the sentences and `print()` them one by one.
|
||||
|
||||
```
|
||||
sentences = open('book.txt').readlines()
|
||||
sentences = [
|
||||
|
||||
'This is the first sentence.',
|
||||
'This is the second sentence.',
|
||||
'This is the third sentence.'
|
||||
|
||||
]
|
||||
|
||||
for sentence in sentences:
|
||||
print('sentence')
|
||||
print('sentence')
|
||||
|
||||
> This is the first sentence.
|
||||
> This is the second sentence.
|
||||
@ -86,20 +123,19 @@ A next element in writing your bot could include the description of specific beh
|
||||
|
||||
```
|
||||
for x in range(5):
|
||||
if x < 3:
|
||||
print('Counting ... ' + str( x ))
|
||||
else:
|
||||
print('Nearing to the end ... ' + str( x ))
|
||||
|
||||
> Counting ... 0
|
||||
> Counting ... 1
|
||||
> Counting ... 2
|
||||
> Nearing to the end ... 3
|
||||
> Nearing to the end ... 4
|
||||
if x == 2:
|
||||
print('This is the middle!')
|
||||
|
||||
else:
|
||||
print('Counting ...')
|
||||
|
||||
> Counting ...
|
||||
> Counting ...
|
||||
> This is the middle!
|
||||
> Counting ...
|
||||
> Counting ...
|
||||
```
|
||||
|
||||
### Variables
|
||||
|
||||
|
||||
## Footnotes
|
||||
These are just a few examples of how the automated tasks of a bot could be written in a programmatic way. Of course there are many more which we will not exhaust in this module, but by describing the basics of how these blocks combine, we can start to comprehend the logical operations and operators that together can be turned into more complex bots. At the same time, this extremely brief introduction in programming features also provides us with some hints at the limitations of such formal languages. For example, try to imagine how you could capture the word *bank* as a variable, both for its understanding as a financial institute and the side of a river. Contextual information is very hard to grasp for computers, computational purists would even argue that it is impossible.
|
||||
|
||||
|
||||
@ -1,17 +1,21 @@
|
||||
Title: Make a bot
|
||||
Slug: 04-s6-step-4
|
||||
Date: 2020-11-01 12:03
|
||||
Slug: 05-s6-step-5
|
||||
Date: 2020-11-01 12:04
|
||||
Summary: How to make a bot?
|
||||
|
||||
For this exercise we will make use of the digital infrastructure of the *Fediverse*. We briefly unpacked what the Fediverse is in section 4: Bot Logic ([*Read this section again by clicking here*](02-s4-bot-logic.html)).
|
||||
For this exercise we will make use of Mastodon instances in the Fediverse. We briefly unpacked what the Fediverse is in section 4: Bot Logic ([*Read this section again by clicking here*](02-s4-bot-logic.html)).
|
||||
|
||||
The federated structure of the Fediverse is an interesting infrastructure to work with in this exercise, in two ways.
|
||||
To dive into bot making, we will go through a simple bot template that is specially prepared for this module. It is written in the programming language *Python* and is saved as a *Jupyter Notebook*. The latter makes it possible to run this code from the web! These Jupyter Notebooks furthermore allow the combination of text and executable code into one document.
|
||||
|
||||
The Fediverse is designed for all sorts of different kinds of *formats* of publishing. This choice for multiplicity is furthermore reflected in the way the Fediverse is governed: instead of being a top-down governed platform, it is a federated network of networks. Each network is being shaped by an owner. Which is sometimes an individual, sometimes a group of peers that share the same interest and other times by an organisation. The owner of a network decides about the rules: who can publish? What kind of material can be published?
|
||||
We registered an account on botsin.space that can be used in this example script. botsin.space is a Mastodon instance "for bots and bot allies"[^botsinspace] administered by Colin Mitchell (@muffinista@botsin.space)[^muffinista]. The instance is introduced as follows:
|
||||
|
||||
To dive into bot making, we will that is specially prepared for this module. It is written in the programming language *Python* and is saved as a *Jupyter Notebooks*, which makes it possible to run this code from the web![^botexample]
|
||||
> This instance exists for people who want to run Mastodon bots, but you are welcome to join if you are a human. Both bots and humans are expected to follow this Code of Conduct. You can learn more about ways to support the costs of this instance.
|
||||
|
||||
Let's make a bot!
|
||||
With this exercise the module will end. We would like to use this opportunity to send you off to another infrastructure, a community-led, public hosting service called *MyBinder*, where you are invited to work with the example script of a Mastodon bot.
|
||||
|
||||
In a time of infrastructural complexity, do you put your effort into destabilizing an existing system where the hurt is already beyond reparation or do you use your energy to punctuate another space that at least attempts to do things ethically and has the potential to provide agency over their tranformations to a broader group of people.
|
||||
|
||||
---------------------------
|
||||
|
||||
Please follow the link to proceed:
|
||||
|
||||
@ -21,6 +25,10 @@ Please follow the link to proceed:
|
||||
<br>
|
||||
<br>
|
||||
|
||||
`EOL`
|
||||
|
||||
# Footnotes
|
||||
|
||||
[^botexample]: The bot-example is kindly hosted by *MyBinder* (<https://mybinder.org>). [EXPAND]
|
||||
[^botsinspace]: <https://botsin.space/about>. Accessed on 30th October 2020.
|
||||
[^muffinista]: Colin Mitchell's profile on botsin.space: <https://botsin.space/@muffinista>. Accessed on 30th October 2020.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user