Dear guest,
We traveled from home to home by bicycle, setting up homeservers. As friends and companions on this Infrastructour, we studied our routers over drinks served by our hosts. Where possible we installed our servers in our homes, in other cases we had to depend on another member of the group. While self-hosting together we questioned our understandings of networks, autonomy, online publishing and social infrastructures, where each of us departed from a different question. We would like to share our personal (yet interconnected) routes with you, tell you a story, present our web- and printed zines, and invite you to explore our homebrewed network.
Here are our accounts of this experience.
My house was the starting point of the Infrastructour, and that made me the first host of the day. I have to admit I was quite nervous, waiting for the Xpub1 group to come to my place. I thought, if the first installation fails, it will bring bad luck to the group! Luckily, the router is located in the living room, so I was confident that there was space for everyone. I had to make sure that I had access to my router because this is the first essential thing for installing a web server. Surprisingly, the password had never changed from the default “1234”, so it was about time to change it… Everyone started looking at my router’s interface. So many weird terms appeared: LAN, WAN, DHCP, Port Mapping, Port Forwarding and so on…
Most of us felt awkward trying to understand how everything worked. Looking at each other with a question mark on our faces, we started discussing internet connections, the World Wide Web, nodes and paranodes of a network. After a series of questions and answers, and with each other’s help, we finally succeeded! My Raspberry Pi took on a new life and was ready to serve. It felt quite rewarding that we could finally continue the bike tour to the other houses for this installation journey. Our collective “suffering” while installing our servers and finally creating our small network helped me understand how difficult it is to “build” alternatives. Not only conceptually, but also materially. Even at an amateur and rudimentary level, it requires quite some dedication and time - and lots of discussions to educate each other.
In the end, why did we create a self-hosted network? Does what we publish through this network have a unique value, precisely because of our suffering on the very first day of its establishment? These questions came to my mind on that day and many more followed, most of which related to broader social aspects around digital networks. A lot of questions about privacy, inclusivity, safety and knowledge of technical tools, which I asked myself during this project, were maybe too big to answer directly. As a strategy, I thought it would be useful to gather them and write small texts expressing my thoughts. Trying to shape and share some of my ideas around these issues would hopefully help me find the “safe and cosy” online corner I was looking for. I wanted a place in which I could host my personal concerns about a frightening post-digital era.
The Infrastructour recalls a time in which networks became more familiar to me. It took some time to understand what the meaning of having a server at home is. In the installation moment, I discovered new utilities of my router, my provider company, my server, etc. At this time, I felt that I started to have a better understanding of my network topology. We started the server installation process looking for the physical conditions that this small machine needed, such as direct connection with the router and power supply. Once we had solved these logistic issues we accessed the router (through the default password I had found some days before) via my laptop and we set the server configuration to make it work online. I also discovered that I was able to host another person’s server. Biyi’s server was hosted in my router for some weeks with a parallel structure to mine, so I was able to control the configuration of both our servers. I found myself in control of the conditions of the networks that others were in.
When we installed the server we configured the local and public IP (that we would identify later with a domain name) opening the proper ports to manage it. We had some problems originating in the lack of a user-friendly interface, and limited freedom provided by my Internet Service Provider. Once we managed to have a public IP for both of our servers we had created a public self-hosted node, so we were able to publish everything through the internet hosting it all ourselves.
At this moment I knew that I had the power to define my own rules and restrictions. I didn’t have any filter between me and my publication ambitions. I felt really responsible for the content that I could make public. We are used to utilizing external platforms to host our material. When we do that, we accept their rules and conditions but when we host it ourselves we are the ones establishing our own guidelines.
Our first networked activity was to build a ring between our servers. This action made me conscious of the real connection between the users of our network: Xpub1. Through this ring, we could navigate between our webpages, defining an interrelated connection among users.
In parallel, we started having a strong theoretical approach to network topology where I started to come across concepts like centralization, agency, link, virtual communities, bot, user, synergy and collaboration… As an architect, I have worked with visual concepts that I’ve always found easier to assimilate and understand. So, I started to research networks that define the connections between users through visual material.
At this point, crowd-sourced and collaborative projects became a good mirror of graphic networks (and networks in general). There, one can find these concepts of centralization, rules and community-making having a real reflection in a graphic creation. In order to have an active experience of these types of networks, I thought of developing several drawing experiments with Xpub1, where the levels of agency, synergy, and centralization would change depending on who determines the users that are going to participate. Who establishes the rules, and how do the users interact? This experiment would help us understand which consequences influence the participant’s behavior if we transform the nature of their network, which is built on a specific project, and how these changes affect the visual collaboration.
At the beginning of the Special Issue, we were asked to read an article by Brian Larkin, “The Politics and Poetics of Infrastructure”. The text approached the concept of infrastructure in a comprehensive and concrete way. Larkin described anthropological and ethnographical ways of interpreting infrastructure; amongst several anecdotes, some related to the description of goods and material provisions during Soviet and post-Soviet eras. This was particularly resonant with my daily experiences of China’s transition from a society organized in an infrastructure of planned, provisioned material flows, towards a society organized by the “invisible hand”. The introduction of this text in the beginning of the trimester expanded our interpretation of networks, in both its material and ideological aspects.
After the article paved the way for our expanded concept of infrastructure, we embarked on the Infrastructour. I was too late to subscribe to a new Internet provider upon moving into a new house, so I didn’t have a subscription until weeks later. Up to this time I was a “parasite”, hosted through Paloma’s router, as she had opened extra ports for me. Finally the router was delivered. A note in the box specified that I could only connect it after 18:00 on January 23rd to receive the earliest signal available on my street in Katendrecht. Located in the south of Rotterdam, it once was home to both the red light district and Chinatown. However, on the delivery day, there was no signal. Two KPN technicians were dispatched to fix the problem, despite my subscription being from Tele-2. They replaced the four-holed communications socket; problem solved! According to the setup menu, this particular four-holed connection is mostly found in houses built during the 1970s and 80s.
The following week I learned that, although Tele-2 was running the service, KPN covered the building and maintenance-specific parts of the infrastructure. During a brief repair, this inter-parasitic cohabitation of providers became visible to me as the customer.
The relationship between Tele-2 and KPN as two distinctive and connected ISPs triggerd my interest to explore network topology in practical reality. In my network publication, I used network as a writing strategy to recount narratives about institutions that present rigid and flexible qualities. I treat my writing content - public library, privately-held bookstores, printshops, and readers as nodes within a network, in context of a lived, social reality. The vivid narratives reveal network and nodes as entities elusive to define. Rather, it’s the inter-layering topological quality that defines their nature.
On the way to my place a few of us stopped at Eudokiaplein to buy groceries for lunch. Although I already had things to make sandwiches at home, I picked up some hummus and corn chips for the group. When the rest of Xpub1 arrived I offered food, alongside what was becoming the repeated (now ritualistic) offer of “Coffee or tea?”. With a sandwich in one hand, I got down to the business of setting up my homeserver, as I configured my router through a browser.
Crammed between Roel and Biyi on a two-seater sofa, I opened ports in the firewall and forwarded them. The final test was to see if I could access the server from a remote terminal. However, this was proving impossible. I made a hotspot on my iPhone and connected my laptop to it … success! It turned out that I couldn’t access my server while connected to the local network; I had to fake going “outside” in order to get back “in”.
My homeserver is now in a temporary sublet, only about 10 minutes walk from where it was installed that day. I had to move it, along with the rest of my meagre possessions, after my housemate (the main tenant) gave notice, and the real estate agent said we all had to move out because the landlord wanted to sell the place. About a month after this I was sitting on the sofa in my pajamas, SSH-ing into the server, when I heard unfamiliar voices in the stairwell. The landlord had decided to relet the apartment and now a real estate agent was leading a parade of strangers through my living room in an unannounced house inspection. Since then, at share-house interviews I’ve had to ask if I could configure the router for my server; not a typical question, and one that raises a few eyebrows.
My research interests started with the Infrastructour and the visualisation task Artemis and I had of mapping dependencies. Together we tried to find a novel way to visualize the network that wasn’t just simply a generic method of connecting dots with straight lines. The term dependencies incorporates not only technical factors, such as physical access to a router, but also social dependencies, such as whether or not we had to ask anyone for permission to use the network. What we came up with in the end was a series of concentric circles; here, we imagined the dependencies almost like tiers on a wedding cake, or the wifi symbol multiplied for each section of our network.
Reading texts from the 1970s media activist group Radical Software revealed a connection between what we were looking at, and the radical approaches of people who were seeking to decentralize the broadcast television network. These included visualisations of alternative network topologies such as klein worms, weird shapes that could account for hidden complexities such as black holes, parts with other parts folded into themselves, or endlessly circulating links.
I’m interested in vision; not just what the eye sees, but also how it influences the way you think about things. Abstraction is useful in rendering complex ideas, but at the same time limits the sense of autonomy. I’m trying to understand networks and our place within them, and to visualise what seems hidden or invisible to me. I’ve collected readings and republished them online, taken photographs, written texts, and made sculptures and drawings, both by hand and by walking between our homeservers while GPS tracking myself. While walking I noticed other networks, represented by lines that were never straight - contrails in the sky, tram lines, and tyre tracks on bicycle paths throughout Rotterdam. The lines made by my GPS walking seemed to form knots - or nodes - where my location was obscured to satellites, somewhere up there, far above me.
So, we were riding our bikes to my place, the last one of the Infrastructour. Pedro and Rita couldn’t self-host their servers and their house is near mine. The idea was to set them up all together, connected to my router.
Once inside, it was easy to find my router; too easy. From the ground floor, exactly on the left side of the entrance, one can find the ethernet plug; from there I installed a long cable which runs along the side of the first flight of stairs, arriving at the first floor where it enters through the door of my apartment. The ethernet cable again sneaks snakily up the second flight of stairs arriving on the second floor, passing the corridor and entering into the main room where it finishes its two-floor journey to rest in the socket of my router. We all followed this cable until its end and we started the process of installing the servers. While Rita and I were using a Raspberry Pi as hardware for our server, Pedro was using another machine labelled TIZEN SUNXI ALLWINNER A20. He didn’t have the possibility to set it up through SSH and he needed a screen to connect his hardware via an HDMI cable, plus a mouse and a keyboard. Fortunately, I had all he needed and we were positive on the success of these last server configurations because my router was the same as Simon’s, so we already knew how to set it up and manage the port forwarding process. However, after a while we noticed Rita’s machine wasn’t recognised on the home page of the router (192.168.1.1), where you can check the connected devices and their respective IPs. The physical router went from being a nice looking and clean object, with a cable for the power and the snakey Ethernet cable, to resembling a nest of connected objects with multiple lights and colors. I had a power strip because I knew there was only one plug, and we needed another three to supply the power to our machines. My idea was to hide that nest in a box but actually it is still there. To find out what was the problem with Rita’s server we entered inside the tangled object with our eyes and our hands, and after we checked the connections we realized two of the five plugs for Ethernet cables (one was already taken by the two-storey long cable which enable the connection in the web) were labeled as TV while the other two where labeled as Internet, and that meant only two of the three servers could have been set.
Rita had to give up having her server hosted at my place and decided to set it up at Artemis’ instead. Apart from this problem related to the difference between routers, the day ended well. Some went home, others continued the tour in a pub with a beer, but this experience with technical problems and new techie terms was the beginning of an ongoing process in discovering the material and the digital aspects of a network that comprises hardware, software and physical dependencies. We started to understand how difficult it is to comprehend the complexity of it all. Even if the intention is to have something independent, we understood that independence requires a knowledge which is both technical and situated. In such circumstances one needs a teacher. There is not only the knowledge of how it works, but also the practical knowledge of how things work in particular circumstances. This was the starting point for my thoughts on autonomy and contingency. The idea of having your autonomy on the web – in our case through a server which is ‘ours’ – is always related to these particular conditions and to the fact that you need to operate hardware and software that will facilitate it… one has to balance the two different worlds (autonomy vs contingency) and yet the notion of autonomy is based on both; knowing terms and physical structures, protocols and how to apply them by opening ports.
We can find a similarity between hosting a server and being hosts in our house; just as there are protocols in software there are protocols within homes, to open ports is to open doors. If one is only a client, one is homeless, or a guest in someone else’s house; on the other hand, if one has their own server, one becomes a host. Things that are normally separated come together. The distances collapse. This process is a passage from client to client-server.
I already knew we wouldn’t be going to my apartment during the Infrastructour. I guess that this might have been the main reason why I got a bit skeptical about this pursuit of online autonomy from the beginning. When I first came across this theme I had to immediately question myself. On the one hand, to what degree are we really autonomous while still relying on an internet provider? On the other hand, as I was not able to have a server hosted in my home, would the task be unaccomplishable even before it had begun?
A short contextualization on why I could not set my server up in the freshly renovated building where I live: I live in a 21-story building, where the internet is provided by one company to all the separate houses. I don’t have physical access to the main router and I only have a small access point installed in a reachable place. Even while calling the company in charge of this hardware I was not given the credentials to further explore, and neither did they have the time nor patience to explain to me how the system was put together. Long story short, I think that the community aspect of building this network was what made it possible to continue. I set my server in Tancredi’s place. His house was the last one on the tour, but from what I can recall, that didn’t even make our installation more successful or straightforward than any of the previous ones. We did not do it on the Infrastructour day with everyone there. I not only had different hardware from all the others but the software was also different. During the weekend, over beers and without time constraints, we finally did it: the server was online! I could not SSH into it directly but, in an ingenious way, we were able to create a bridge between both server and everything was sorted out. I could easily access it remotely. I think that this increased my autonomy as long as this small machine was still plugged in, and online. Practically however, I still relied on a second party.
From this point on, my main question became clear: what did it mean to be autonomous and what kind of examples were available which allowed me to see more directly how communities rely on self-hosting and how they manage it?
We were introduced to Mastodon, an online federated social network. I focused my research on this case study, where users can either be part of an instance or host their own. I researched within its universe to understand what kind of communities are present and why they moved there. Mastodon started being used by some because it provided a possible answer to issues of personal safety . We can take the example of marginalised communities (for instance LGBTQI+). Such groups used to rely on Twitter to discuss and share their points of view, but Twitter became filled with hate bots, trolls that skimmed through posts and at the first trigger word would react (in)discriminately. This made a few users leave Twitter, and Mastodon presented an alternative. When you create your own instance, you can state clear rules for what you imagine it to be. Some instances try to be open to everyone in order to provide a safe space. However, this also creates the necessity to draw clear lines between what one can and cannot do.
At the very beginning of the Special Issue #8, we had an Infrastructour, where we visited each other’s places in order to install our own server. I remember I was quite confused about what Roel and Manetta meant by installing the server, and how the procedure of installation would happen. I have to admit that I was quite clueless about networks, except for some basic knowledge on how to connect electronic devices to WIFI, or how to reboot a router.
Amongst the confusion, we had to choose a device for our own server in the meantime. There were single-board computers, such as several Raspberry Pi, a device that looked like a gameboy I had back when I was around 16 years old and a very old mini laptop. I had a lot of trouble deciding which device to choose. Although all of them seemed to work equally well, for some reason I was very serious about choosing the device that I would use for my server. Ridiculously enough, my laptop was broken at the time, and I was waiting for a new laptop to be delivered from Korea. Since we needed a screen to set up some configurations with the device immediately, I had no choice but to take the old mini laptop. Moreover, this meant that whenever I wanted to check if my device was working properly, I could do this conveniently. Because it has a screen, it’s possible to log in to the server on the mini-laptop directly. It was like killing two birds with one stone.
Even with a decent device, self-hosting my server at home proved to be difficult. The problem was that my building has a centralised network system which doesn’t give residents full access to routers in our homes. This meant that I couldn’t configure my router and I wouldn’t be able to install it at home, which made me very disappointed. Luckily, Artemis offered to let me “piggyback” on her router, which she now shares with other devices including hers, mine and Rita’s.
At this point, I began to question what dependency means within our network. Although we had planned to self-host our servers, sharing a router reduced my independence. To me, hosting your own personal server means that you should possess full control of it. However, I could already see some physical and social dependency problems. Some of these issues occurred not only from the limited accessibility of my router at home, but also from needing permission to use someone else’s router. For example, if Artemis doesn’t allow me to come over to her place to use my mini laptop with its convenient screen, then I have no physical access to it. What’s more, if she unplugs her router, or decides to move house and change the Internet service provider, technically my server will be “gone”.
Based on my experience, I started thinking about why I couldn’t do certain things, and how I managed to solve these problems. This led me to formulate research questions: What were the technical, physical and social limitations I had in installing my server? What does dependency mean in our network? How much are we dependent on our network? Who are we depending on within our network? There are different layers of dependencies in networks, so how do you define whether you’re independent, or not?
With Special Issue #8, I experienced self-hosting a network, documented dependency issues, and recorded my personal observations using an XMPP based publishing tool that I developed as a way to annotate these thoughts. The relationship between servers, XMPP, and the annotation tool are layered in interconnected dependencies, but with their own stories to tell.
Before going to everyone’s house, we had to make sure we had access to our router, with a username and password. In most cases, the service companies seemed to leave everything as it came (a very username:admin, password:1234 approach). However, that wasn’t my case. The building where I live is managed by one company, and somehow me having access to any credentials would compromise the safety of other residents. I cannot explain this argument very well, not only because I lack the IT knowledge, but also because when I contacted the company that maintains the routers they didn’t know what “host your own server” meant. It seems that being self-hosted is not an aspiration shared by most individuals.
This way, I had to rely on another person’s router (and goodwill) to host my own server. The first option was Tancredi’s place, but the lack of available network sockets was a constraint. I then became dependent on Artemis’ house. Biyi usually calls the people who rely on other people’s servers “the parasites”, which is quite a good analogy if we think how we are literally sucking resources from our host. Slowly we started to build our interdependencies inside the network.
Creating a network between ourselves, being nodes and sharing links with each other, seemed fascinating, but I wasn’t really sure what that actually meant, nor was I acquainted with the specific jargon. Exploring our routers was the first step to becoming autonomous by hosting ourselves and starting to build digital evidence of our network, but that wasn’t a linear process. All the difficulties and hardship grew on me and I started wondering if there was a future for decentralized, self-hosted networks. If we, as students of the subject, found it hard to manage all the specifications of setting up a server, how could this ever become a comfortable norm?
In this way, I also speculated on some inconveniences, such as what would happen if someone moved house, changed routers, became a dead node in the network, etc. The sustainability of our digital bond was the trigger point for my personal research.
I started to look at other networks, physical or digital, online and offline. I was searching for common paths they followed, how they dealt with some problems that we were also encountering and for how long these networks survived. Alongside this, I was prototyping some tools, small experiments to scrape links, images, sources, anything that could prove that our network had existed at some point in space and time. The documentation and anecdotes of other communities helped me understand better the focal point of my doubts: a digital network can indeed be fragile and ephemeral, but the cooperation aspect is important and I believe it can outlive the web version of a network.