3.1 Planning - What else is a server

Visiting the Tools for Change exhibition ² at HEK in the summer before I started this research, I encountered the work Solar Protocol, as well as the Low-Tech Magazine. Solar Protocol is a global-spanning network of solar servers, with its website being hosted by the server that has the most sun. Low-Tech Magazine is a web magazine for low-tech practices hosted on a small solar server, which has been running since 2018. I had also started reading about permacomputing, and through the forum found the compost.party server. It is a phone connected to a small solar panel without an additional battery, so, especially in winter, it experiences longer periods of disconnection. All of these websites show the status of the server, the battery level and a picture of the server. They also all have extensive documentation of the setup and, in some cases, a maintenance log, which logs the ongoing work that goes into maintaining its online status. These projects all make their server infrastructure, its construction and maintenance visible and tie its upkeep and energy supply to the local conditions, prioritising these conditions (people’s capacity and time, weather, existing hardware) over constant connectivity. This dismantles the narrative of the cloud and shows alternative modes of hosting. They also convey another image of what a server can be and what server administration looks like, which stands in contrast to images of large server centres and their workers.

3.2 Acting - How to build a server

Planning to make a server was inspired by the manuals I saw in Low-Tech Magazine and the TiTIPI wiki. The process of starting with electronic waste and finding ways to repurpose it seemed the only viable starting point when acknowledging the conditions reinforced by hardware production. This approach is visible in works like the disposable vape web server, a web page hosted on the chip of a vape by Bogdan Ionescu, Chaline Bang’s seedling, a collaborative server running on an old macbook, or Francesco Scheffczyk’s sys/net/visible, an installation running on old office PC’s found in the trash. They all show and document strategies to repair and hack e-waste instead of buying new computers to match the ones specified in one of the manuals.

After asking around, I got hold of an old smartphone that was no longer needed or in use by anyone in my social circle. As it was still in good condition, I used termux to gain terminal access. I implemented a file sharing system (sftp) and hosted a web page with a tinyfilemanager and a git versioning tool (forgejo), both to understand the limitations and possibilities that such a small computer imposes and to understand what makes something a (web) server. The idea at that point was to store everything for my thesis on the server and to serve the output (website/publication/..) from there to the internet. I also borrowed a small solar panel that supplied the energy. The server is connected to a hotspot and the website is served into the network, only occasionally available to the internet through a cloudflare tunnel. This means that no Wi-Fi router is necessary, and the server could be used anywhere that has cell reception and enough sun. Using a tunnel is convenient, but it also means that a cloudflare server, often in the US, is involved. This contrasts with the perceived locality of the infrastructure, which is why I chose to use a wifi router going forward. While its size limits its storage capacity, a phone as a server gives the possibility of physical proximity and mobility. This then also removes the need for it to be perpetually online (and on), it can be turned on when needed. Being close to the server also means that it rarely needs to be accessible to the wider internet, most things can be done through the network. While making the server, I started jotting down the commands, which turned into a server manual containing explanations of some technical terms and instructions, available here.

The server was active only when I was working on it. As a moment of social activation of the server, I retroprojected a live video of the phone on a wall and held a demo within the MA group. In the session, I hosted a website on the university network and on the wider internet through a cloudflare tunnel. During the session, the people in the room could submit messages to the website. Using traceroute, a terminal command that sends data packets to a web address and sends back information on the internet nodes it passes through, we traced the path of the data on its way to the website through various university and corporate nodes around Basel and Zurich, all the way to the cloudflare server in San Francisco.

3.3 Reflecting - Why (not) to build a server

The projects I had encountered were compelling visualisations, yet their value largely resided in exhibition spaces, rarely inviting active, long-term participation. This left me with a central question: What does digital infrastructure look like when it exists to be inhabited and co-created rather than just observed? I had been in conversation with Chaline and Francesco, whose projects had both been made in collaboration with others and I was questioning how to involve more people in my process.

This first cycle was focused on materiality and technical setup, and it gave me a first set of defining features for irresistible infrastructure, both through what I achieved with the phone server (agency, literacy, locality) and what I didn’t (purpose, connection, relation). While locality and materiality are important factors for irresistible infrastructure, I realised that it is not something that can be worked on alone, but rather requires a meso-scale of collective relations. Irresistible infrastructure is more than a technical artefact, it is a system of humans and technology that has a purpose it aims to be aligned with and support. I decided I had hit a momentary dead-end and chose to close the action. For the moment, the phone server remained a method of investigation to understand certain concepts, such as dependence, maintenance, and scale, by making them materially present and visible. My mentors Helen and Cristina introduced me to more projects and collectives, and I began to research them, now looking past their technical documentation to understand the social labour that keeps them alive.

4.1 Planning - Sending texts

“We see local serving as an act of empowerment. To oppose big tech and to be independent. For local communities and the people around us. No need for the big complicated internet. Just you and me! Something intimate and personal.” (buffet and Murphy 2020, 1) The intimacy referred to in the Server Charms documentation is something I experienced on many of the small community servers and spaces I visited online. These spaces often felt personal. One of the reasons I felt I needed to visit at least some of the collectives was to establish a personal connection to the people behind and in these spaces before using their services or writing about them. I wanted to learn more about their processes. What is the work they do, and how do they share and sustain it long-term? What is the purpose of the infrastructure they are building? I started reaching out and asked if I could come by.

4.2 Acting - Establishing connections

I visited different collectives, meetups and events that had come up in my research. I had started my project with visiting the Transform Conference in Trier and Hack the Promise in Basel. At the end of 2025, I went on a trip to visit the Berlin Permacomputing Meetup, compost.party, varia and the poetic computation research group in Rotterdam and the assembly of the re:coding everyday technology publication and meeting some of my old colleagues in Mainz. At the beginning of 2026, I attended a literate programming workshop led by Ana Meisel at unsorted.love in Zürich, met Chaline online, visited the Haecksen in Freiburg, and met Wolke7 in Basel. I started with the threads or projects I had encountered often or knew someone in, and then followed their recommendations to the next group or person. While they have different practices, either in their general work, at the events I visited, or within their collective, I was interested mostly in server practices and limitation. The conversations I had were in very different contexts and lengths and were held informally. After the encounters, I held onto my direct thoughts by recording a voice note or writing down some notes and wrote another page of reflections the next day. Looking for a way to share some of the inspiration from my encounters outward again, I decided to make a glossary. Rather than attempting to establish authority over technical terms, the glossary aims to compile a collection of definitions, quotes, anecdotes, images and memes related to my evolving understanding of various technical terms I encountered. To support a multiplicity of meanings, each term can have any number of entries. There is no fixed version of this collection, it is only a snapshot. Aside from my conversations, the glossary and the following reflection also contain quotes and thoughts from accompanying reading.

4.3 Reflecting - Thinking back

4.3.1 Challenging roles

Digital infrastructure is much more than its cables, nodes and computational processes, much more than the sum of its materials. Global systems pass through and are determined by many bodies. Interacting with them presents a predetermined and narrow set of roles to take on within the infrastructure, roles that are usually assigned to us rather than chosen by ourselves, such as engineer, user, protester,... When we make our own systems, these roles can remain open, the borders can be blurred, or we can switch back and forth between them. The project A Traversal Network of Feminist Servers ³ does this by creating rooms to sit and learn together. They describe it as being “[...] not only about the work itself, but also about creating a culture around doing the work. To create habits and language around it, and moments of being together.” (2023, 44). One method for this are tmux sessions, where everyone with a connection to the server can see the same terminal window, so all the commands and their execution is visible to everyone at the same time. This enables a sharing of the roles of server administrator or system engineer.

I share the tmux command with Arne as we are sitting around a kitchen table drinking tea. He started compost.party, who supply a tiny hosting service on their solar smartphone web server. Anyone can write them and ask to get access to their webspace. They will be encouraged to be part of the hosting and maintenance process, either around this table, in a park or online. Aside from the space limitation of the phone, that means that only as many people can participate as is manageable for the compost.party team. One of Arne’s motivations for maintaining compost.party is his corporate job as a server administrator and the discomfort he feels there with the unilateral control over other people’s data and access rights. At compost.party, they want to share that power and responsibility.

This collective maintenance of the IT infrastructure is a fundamental shift and often means learning the necessary skills first. It takes time and effort from the group, but can also ensure that data privacy, independence from big tech or other ideals of the group are translated into their infrastructure setups. As Mara from the feminist hack meetings in Athens states:

It is common in Greece that the technical tasks of a collective, and of a project, are managed by male programmers who are not part of the group and its principles. Under this condition the tools developed are dissociated from feminist approaches and are seen as technological artefacts that give solutions, they are separated from the context they are about to become part of. (ATNOFS 2023, 143).

Marloes de Valk refers to the alignment between a group’s methods and its goals (when infrastructure is organised according to shared values) as a form of prefigurative politics (De Valk 2025, 115). In this sense, movements try to put their ideals into practice in the present, shaping their social relations, decision-making, and culture to reflect the kind of world they want to create (Boggs 1977, quoted in De Valk 2025, 113).

Visiting different feminist or FLINTA* hack spaces, or speaking to people who are part of these spaces, there is often a distinct importance placed on including people who don’t have a background in IT or programming into their spaces and workshops. They tend to use easier, less technical language and aim to create environments that are attentive to different needs. Rather than positioning expertise as something defined by complex technical knowledge, these spaces try to value the diverse perspectives each person brings, regardless of formal training or academic background. At the Haecksen ⁴ meetup I visited in Freiburg, having an interest in watching movies or being there to accompany a friend resulted in the same curious questions and conversations as coming in with years of experience in coding and IT. More than anything, it was about eating together, occupying the space and connecting over shared interests.

Irresistible infrastructure remake our relations to technology (and each other) by opening roles that anyone can inhabit, enabling a movement between different roles and encouraging non-expert participation. This is part of what can make spaces like compost.party and ATNOFs irresistible, they host shared learning and mutual dependence, remaking their infrastructure into a site of care instead of expert service. This shared administration isn't seamless or scalable. It's intimate, limited, hands-on, and it leaves behind the user-maker binary to explore many roles of active participation.

4.3.2 Documentation as an invitation to agency

The language used in the documentation of these projects makes it really clear who is invited to participate, reenact, remix and engage. This is reflected in the ATNOFS text in a conversation transcript from their meetup in Varia “in the documentation there are phrases that say things like ‘please break things, we will fix it all together later’, or there are messages that say ‘don’t be afraid’, and I really like that“ (ATNOFS 2023, 44). Out of the six project meet-ups, the last was reserved for reflection and documentation, also inviting people from outside the project to bring in methods and questions.

Documentation that offers ways to tackle problems that might come up, doesn’t assume prior knowledge, and reads in a way that sounds empowering or motivating to people who don’t have experience with these technologies already encourages further digital literacy and agency. This is really clear in the Server Charms documentation. I meet Paula in Berlin, and she shares the link to the documentation with me after attending a Server Charms workshop at the FLITNA hack space Heart of Code. It offers ideas on where you could source materials or who you could turn to for additional support, favouring offline solutions that bring you into contact with people in your area. Instead of linking to a kit to buy online and a video tutorial, they suggest asking friends or finding a community electronics workshop to borrow materials and get tips on how to use it. (buffet and Murphy 2020, 3).

This can be extended further into the code itself. At a literate programming workshop in Zürich, Ana Meisel from the permacomputing club in London talks about the concept of literate programming and invites us to use it in one of our existing projects. Literate programming is a concept from the 80’s. A quote from Donald Knuth on Ana’s slides reads “Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do”. This method asks us to think about the systems we are building before we start making, to slow down and consider functionalities and external entanglements. It can also be especially relevant in projects that include multiple people of different backgrounds and technical knowledge. Programming software or maintaining infrastructure together doesn’t necessitate all members of the group to acquire the same set of (technical) knowledge.

When documentation prioritises the reasoning behind decisions and offers solutions for different contexts and levels of understanding, non-coders can become active participants with real agency. By focusing on the why over the how and on literate documentation, irresistible infrastructure can enable three things: active participation and distributed maintenance, critical questioning of the system itself and interaction beyond real-life encounters.

4.3.3 Building for resilience

The pressure to deliver reliable services often increases as a community of users expands, a challenge described by Wolke7, a local cloud provider in Basel that provides server space for hundreds of active users. They can appear like a professional company, while they are actually a volunteer-led, non-profit collective. Their infrastructure is maintained by a handful of individuals using donated or second-hand hardware, relying entirely on contributions of time, space, and materials. Not being able to see behind the scenes, their subscribers sometimes expect the kind of conditions and service they are used to from big tech cloud providers. As we sit in a bar, Milan shows a photo of their first server, an old desktop PC running in an atelier attic. Together they recount the numerous times they transported servers across Basel by bicycle, searching for years for a location that offered the right conditions (internet, free rent, heat regulation and energy supply) and where the server noise isn’t a nuisance.

Working with digital infrastructure long-term doesn’t mean it has to be constantly online. For many groups, making and maintaining infrastructure is not their main work, so this has to be scaled to what is actually sustainable for the people involved. The TITiPI interdependent infrastructure map shows a way, in which each collective from the TITiPI network provides one or two services on its servers and then relies on the rest of the other collectives within the network. This also leaves space for projects that don’t have the capacity to self-host to get access to services that align with their ideals.

This shift changes the way we view projects such as rosa, the travelling feminist server. Rosa is offline when travelling and is mainly activated for specific events or meetings as a space for collective thinking and documentation. However, since the server has a physical location, it is difficult to share the responsibility equally in practice. Rosa is resting on a shelf when I meet Cristina, and she tells me that, towards the end of the project rosa started from, the groups had already been discussing how often the server needs to be activated to justify keeping it for this purpose.

For many of these projects and collectives, the connections and relationships formed during and around their work are much more central than the servers or tools they worked on together. The resilience of irresistible infrastructure is not redundancy, uptime and reliability of its services, but rather the quality of its relationships, which outlive its technical failures. As adrienne maree brown mentions, “emergence shows us that adaptation and evolution depend more upon critical, deep and authentic connections, a thread that can be tugged for support and resilience. The quality of connection between the nodes in the patterns.” (2017, 14)

4.3.4 Joyful experimentation

Not all the projects and collectives focus on long-term server practices or hosting alternatives to cloud services. As written in the Trans*feminist Counter Cloud Action FAQ by TITiPI “self-hosted projects or local service providers do not have the capacity, training or resources to measure and deliver the required analytics with equal authority. But we think they do have the capacity to develop more intelligent modes of dealing with computing within limits, rather than banking on the promises of Net Zero.” (2023, 15). Some projects that are more short-term and experimental can still make suggestions for computing otherwise that can flow into longer-term infrastructure.

A main driving force for many of these collectives or projects is the idea of limitation. In practice, this means reclaiming and caring for old hardware instead of buying new. It can also be writing lightweight software that works in old browsers, or clear documentation so projects can be reused and maintained over time. Perhaps the most radical and least visible approach is deciding not to make something, deleting things that are not in use, and maintaining existing systems instead of building new ones. These principles are the core of permacomputing.

This is why a radical reduction of that wastefulness is a major concern to us: maximize the hardware lifespans, minimize the energy use. And this is not just about a set of technical problems to be fixed – the attitudes also need a radical turn. Small is beautiful, understandability is beautiful, ‘virtual’ is not immaterial, online time should be used wisely, not everything needs to be constantly available, doing things with less is not ‘returning to the past.’ (De Valk and Heikkilä 2021, 1-2).

Projects like Windternet ⁵ propose going beyond the idea of limiting harm and towards building regenerative community infrastructure that actively improves the conditions in their environment (Snodgrass et al. 2024).

Working within these limitations, whether in hardware, uptime, or energy, is an inconvenient act. Berlant asks us to “[...] think differently about the encounter with the inconvenience of other people: that we might desire not only them or any objects but also the inconvenience” (Berlant 2022, 170 quoted from Poppe 2023). Rather than being avoided, these limitations are actively desired because they shape the outcome and lead to discovery. In design, this approach fosters new aesthetics rooted in data size limitation, the handmade web ⁶, and amateur programming. These become entry points for developing agency in shaping digital systems. When we stop trying to mimic the seamless perfection of corporate platforms, we can begin to expose the seams of our infrastructure. This transparency makes the system understandable and, therefore, maintainable by a community rather than just a specialist.

I talk to Paula about this, and she shows me wwwobble, a project she is co-developing that aims to lower the barrier to coding websites. However, the rise of 'vibe coding' (generating code with chatbots) introduces a strange tension with idea of the handmade web. While it also lowers the barrier to writing code, it allows creators to remain ignorant of its functions and implications, outsourcing the decision-making to a LLM and focusing strictly on the outcome. Ultimately, we tend to care for and maintain the projects we feel connected to, the ones we understand and have actively shaped. That kind of attachment is much harder to build with auto-generated content. Tools like wwwobble suggest a mixture of coding and direct object manipulation in the browser page, as a means of getting closer to the actual code without having to learn coding before, and remaining in control of the creative output.

Adding to an ever-growing pile of unused, unkept and unwanted hard- or software only adds to the amount of data and materials used and kept. The importance of maintenance, care and upkeep of existing collective digital infrastructure is what directed my thought process for the third cycle.

5.1 Planning - A proposition

I wanted to use the rest of the thesis time frame to begin supporting an existing project in Basel. The Bleibeguide had come up a few times during the first year of the MA, and it felt like an important digital resource that I knew was in need of maintenance work. I proposed that this become an intersection of Luca’s and my thesis projects, Lucas focus being on solidarity. We also decided for this to be the beginning of a shared longer-term commitment, exceeding the time-frame of this research project.

The Bleibeguide is a collection of projects and resources in seven languages that aim to facilitate access to the city of Basel and the right to stay regardless of legal status, language or income. It started over a decade ago, with a first version published as a PDF by the Bleiberechtkollektiv in Basel in 2013. It was made into a website by the captns, a design collective in Bern, and revised in parts in 2015/16 by the Bleiberechtkollektiv. This collective no longer exists, and thus, the website has not been updated for many years. The website was made with wordpress and contains a google maps plugin that no longer functions. It is hosted by the captns on a plesk server from metanet, with the Anlaufstelle für Sans-Papier ⁷ covering the running costs. What we know of its history is pieced together from the website, other sites that refer to it and the people we were in contact with directly, who had been part of the project at different intervals.

Hmm, I can’t say exactly when the Bleiberecht Collective in Basel was founded. I only joined much later. Probably around the mid-2000s (when the slogan ‘Kein Mensch ist Illegal’ emerged). The Bleibeguide was inspired by the urban citizenship debate and similar, existing projects in Zurich (which emerged in the context of the Autonomous School) and Vienna. The first edition came out in 2013 (we raised the money through a crowdfunding campaign), the second in the winter of 2015/16. At that time, a grant application was submitted to print the second edition and create the website. The website went live in the summer of 2016 (I believe it was only updated sporadically after that). There was no third edition of the book. (Text message from Moritz, translated by me)

A lot of work had gone into this collection of resources over the years, into its preparation, production and dissemination. Before Luca and I started, we met Johanna and Finn, who, together with a third person, had taken on the task of reviewing and updating the information currently contained in the Bleibeguide. Contacting projects, deleting information that is outdated and editing addresses, links or descriptions where information has changed. In our conversation with them, but also with the others we were in contact with, the idea of ownership or authorship was rejected. Nobody claimed authority over the processes or results of the Bleibeguide. This is reminiscent of adrienne maree brown’s framing of being a “joyful conduit” (brown 2017, 7). Having something pass through you, shaping parts of it and then passing it on with the openness of it being reshaped. The Bleibeguide as a resource will undoubtedly become more valuable and more accessible, the more people are part of shaping it. As Marloes de Valk writes, “Setting up any kind of technological infrastructure cannot fall on the shoulders of one person and requires a gradual process of consolidation in a heterogeneous group bringing together different backgrounds and types of knowledge. It’s an ongoing process of learning from each other. It can only converge in a local and specific way.” (De Valk 2025, 143).

5.2 Acting - A start

Similar to what I had read and discussed with the collectives and projects that had inspired me, I wanted to align the technologies and design of the Bleibeguide to its principles. From a technical side, to me this meant situating it in Basel, ensuring transparent soft- and hardware, removing it from its big tech entanglements, keeping it small and lightweight, easy to update and well documented. For the design, Luca and I wanted to highlight the multiple languages and ensure clear structure, transparency and equal representation of the content. We had decided in advance to work on it intensively for a month and then to pause, reflect and make a plan to continue after the MA. After that month, we had established communication through texts, emails, voice notes, phone calls or in-person meetings with various layers of participants of the last decades of the Bleibeguide and sorted through the current and edited content by Johanna and Finn. We started setting up a new code and content base available here, which contains the new code I wrote for the website and the revised content in an unfinished state.

This new, in progess version is backed up and available through codeberg ⁸ and keeps all its data in the repository in a simple json format. The site is hosted on the phone server from Action 1, at the moment residing in Luca’s shared flat and currently available under http://92.104.182.86:80. This is a test run to see what kind of environment the phone server needs. Ideally, it will later move to a collective space in Basel that has opening times, stands in solidarity with the Bleibeguide and can make it a visible infrastructure in the city. Instead of waiting to finish a version of the site, we want to connect it to its domain soon, so people who still engage with it can see what is happening and get in contact with us directly, to be involved, in conversation or to contest or question the decisions we have made so far.

5.3 Reflecting - A stumble

We were often stuck between a wish for radical or experimental approaches, for deeper connections into the communities and a need for simplicity, availability, maintainability and the urge to get a new version of the ground quickly. How will this resource be shared? Who needs to know about it, and where is it available? Who is it for? Who does it belong to, and how can we make sure it doesn’t belong to us? What is the language and content of it? Who writes and decides this? How can we involve more people in this process, especially people affected directly by the barriers of legal status, language and income?

Pausing the work after a month has brought these questions closer to us. While knowing and speaking about how important it is to include more people in the process, especially people affected by the conditions that the Bleibeguide wants to stand against, we have pushed it further back. So far, we have been in contact and conversation mostly with the people who actively contributed to the Bleibeguide, to make sure we understand as much of its history and its intentions as possible. Luca writes in her thesis that it might also have been a reluctance to burden people, perhaps the thought of asking for free labour. I think it also came from us wanting to add to a collective effort from our skill-set, from the things we had spent years learning and rehearsing, so design and programming. Applying these skills to the project led us, to an extent, to fall back into the roles and processes we rehearsed them in (such as client and designer, brief, sketch and product). Thus, by redesigning and setting up the Bleibeguide alone, even though in conversation, we risk reinforcing existing barriers or even creating new ones. “Technology is, if not always already of the dominant culture, always laden with a legacy of division. Technical cultures are world-making: they sort people and present barriers to entry by design.” (Dunbar-Hester 2020, 242 quoted from De Valk 2025, 123).

Thinking on the problem of free labour, we applied for funding early on in an attempt to enable people to work with us on the Bleibeguide who cannot afford to do this without financial compensation. Something we find especially important is rewriting the content together to ensure the language and terms used feel appropriate to the different people the Bleibeguide aims to speak to, and translating the content. Luca writes about the potential tensions of paid and unpaid work coexisting in the project, stating that:

At the same time, the coexistence of paid and unpaid work within the same structure may impact solidarity itself. This dynamic is always complex, and a new asymmetry emerges in this project, as the process is facilitated by those (us) who work without remuneration. The decision to voluntarily forgo financial compensation is not neutral: it presupposes a position of relative economic security and is therefore not equally available to all. The hierarchies that emerge in this context deviate from the classical logic described by the critical social theorist and political philosopher Nancy Fraser (2016) in her essay Contradictions of Capital and Care, in which she argues that unpaid labour is structurally subordinated to paid work. Rather, the inverse risks producing its own asymmetries: those who receive financial compensation may feel less entitled to question decisions precisely because their participation is compensated; unpaid contributors may accumulate a form of moral capital that exerts an unintentional effect; and paid participation may be perceived as transactional or temporary, while unpaid involvement may signal a deeper commitment to solidarity. This produces new distinctions between those who ‘truly belong’ and those who do not. (Weiss 2026, chap. 5.2.2)

Figuring out how to include more perspectives in the Bleibeguide and how to ensure agency and reduce hierarchies within this collective work will be where we take up work again in the summer. We also want to further discuss and make transparent our commitment and capacities. When we started, we were already aware that, even more than needing an update, the Bleibeguide needs a longer-term care commitment. Is this a time frame of 3, 4 or 5 years that we commit to? How would we deal with one or both of us moving away from Basel? Who else can we include in this commitment? One possibility for this is finding a new home for it in a collectively led space in Basel, both to improve availability and to ensure there is a possibility for different people to access the infrastructure. How do we prepare the Bleibeguide for other people to take after those years are over? How often do we add or update the information?

Many questions remain open as we set out to reshape our process going forward. The process feels very different to what we are usually offered as services online and the way designer-client relations are often pre-defined. Instead of promising that all our burdens can be removed, our tasks and thinking automated, working with irresistible infrastructure, we are asked to stick with these troubles and share them amongst us and to continuously stay open for critique and reflection.