The projects I had encountered were compelling visualisations. Being mostly exhibition pieces, their value lies in their dissemination and consumption of their message, more seldom in their active use or participation. What could be the value of my phone server? Coming from mostly technical documentation with a focus on the hard- and software created a kind of estranged, solitary mode of thinking and working. I struggled to stay in contact with the other aspects that this practice could have. What kind of infrastructures exist outside of art exhibition spaces? Who uses them and who maintains them? Setting up digital infrastructure can be quite simple, but for it to fulfill a purpose outside of itself it needs to be populated, to respond to a need. This is also the biggest shortcoming of this first research cycle and something I wanted to focus on in the second cycle. I decided I had hit a momentary dead-end and chose to close the Act. For the moment, the phone server remained a method of investigation for me, to understand certain concepts or terms by making them visible (to me/to others) with the server. My mentors Helen and Cristina introduced me to a few collectives and I started to research them, now looking further than their technical documentation and project descriptions.

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 global digital infrastructure presents a predetermined and narrow set of roles to take on within these infrastructures, roles that are usually assigned to us rather than chosen by ourselves, such as engineer, worker, user, protestor,... 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 it 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 role of server administrator.

This collective administration of the IT infrastructure is a radical approach 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 describes this alignment of means and ends, when a group sets up their infrastructure according to their ideals, as a type of prefigurative politics (De Valk 2025, 115), described as “the embodiment, within the ongoing political practice of a movement, of those forms of social relations, decision-making, culture, and human experience that are the ultimate goal” (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 different importance laid on including people who don’t have a background in IT or programming into their spaces and workshops. They often try harder to use easier language, to hear everyone in the room and to make space for different needs. At the Haecksen meetup I visited in Freiburg, having an interest in watching movies or being there because a friend dragged you 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, technological or not.

Documentation as an invitation to agency

Documenting projects and the language used in these documentations also make it really clear who is invited to participate, to reenact, to remix and to 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). Documentation that offers ways to tackle problems which might come up, that doesn’t assume fixed prior knowledge and that reads in a way that sounds empowering or motivating to people that don’t have experience with these technologies already encourage further digital literacy and agency. This is really clear in the Server Charms documentation, that offers ideas on where you could source materials or who you could turn to for additional support. “If you don’t own one yourself you might have a friend that has one or might find a community electronics workshop with one near you. The chances are good that you’ll also find someone who can quickly show you the basics of soldering at those places if you’re a complete beginner.You can also quickly watch learn the basics online. For example with this video or this article. It’s fairly easy!” (buffet and Murphy 2020, XX).

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 concept can be especially relevant in projects that include multiple people of different backgrounds and technical knowledge. Programming software or administrating infrastructure together doesn’t necessitate all members of the group to acquire the same set of (technical) knowledge.

Building for resilience

The larger a community of users grows, the more pressure there is to provide a reliable service. Wolke7 in Basel is a strong example of this. They are a volunteer-run not-for-profit organisation that run a server infrastructure in Basel and provide open-source tools and server space, writing that “The internet is not only about the sharing of ideas and information. It’s about decentralizing power. That’s why nearly every government and corporation on the planet are against net neutrality. And why we must fight for it!” (wolke7, n.d.). Because they aim to be a real alternative to commercial clouds, they have to reach for a high level of data security and redundancy. While this service-oriented approach appeals to a broad group of people, it requires a specific kind of labor and resources that not every collective can or should sustain.

Working with digital infrastructure long-term doesn’t have to mean that it has to be constantly online. For many groups, the infrastructure is not the main work, so maintenance 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 their servers and then rely on the rest from 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. point about automisation and constants etherpad management?

This shift changes how we look at projects like rosa, the traveling feminist server. Rosa is offline when traveling and mainly activated for specific events or meetings, as a site for collective thinking and documenting. Still, since the server has a physical location, the responsibility is hard to share equally in practice and Cristina tells me that the question of how often the server has to be activated to justify keeping it for that purpose is also being discussed between the groups.

For many of these projects and collectives, the actual connections and relationships formed during and around their interrogations are much more central than the infrastructures and digital networks. The resilience in the networks is often not the redundancy, the upkeep, uptime and reliability of its services but rather the quality of the relationships. 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)

Joyful experimentation

Not all of the projects and collectives are focused 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 local infrastructures.

A main driving force for many of these collectives or projects is the idea of limitation. Reclaiming and caring for old hardware instead of buying it. Making lightweight applications or software that works in old browsers or on old computers, that is readable and maintainable, so that it can be reused and cared for by different people over time. Perhaps most radical and least visible is deciding not to make something, deleting things that are not in use, using and maintaining existing systems instead of building new ones. These principles are also at 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, XX). In permacomputing, this is often addressed by designing for energy descent, designing for longevity, using waste as a resource, offline first, skill sharing and/or building alliances.

Working within these limitations, whether in hardware, uptime, or energy is an inconvenient act, much like boycotting a major platform. But these inconveniences lead to discovery. In design, this approach proposes new aesthetics rooted in things like limitations in data size, the handmade web and noob programming. These are potential entry points for developing agency. 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. The rise of vibe coding presents a strange tension towards the ideas of the handmade web. While it lowers the barrier to writing code, it also presents the possibility remaining ignorant of its functions and implications, leaving the decision-making to the bot and remaining focused on an outcome only.

Thinking of and setting up a piece of digital infrastructure that seems important or interesting is one thing, but making time and keeping up the social work surrounding digital infrastructures is often the more important task. 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.

We were often stuck between a wish for radical, 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 would this resource be shared through local networks only? How could we communicate 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 the Bleibeguide wants to stand against, we have pushed it further back, being in contact and conversation mostly with the people who actively contributed to the Bleibeguide, to make sure we understand some of its history and its intentions. Luca mentions in a reflecting letter to me that it might also have been a reluctance to burden people, perhaps the thought of asking for free labour. I also think it 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 kind of 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 to reinforce existing or even create new barriers. “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 who can afford to do free labour, we applied for funding early on in attempt to enable people to work with us on the Bleibeguide who are not in position to afford doing this without financial compensation. One of the positions we find especially important here is translating the content and, perhaps even more importantly, rewriting the content together to ensure the language and terms used feel appropriate to the different people the Bleibeguide aims to speak to. Luca writes about the potential tensions of paid and unpaid work coexisting in the project in her letter, 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 in this project a new asymmetry emerges, as the process is being led 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 Fraser (2016) in her essay Contradictions of Capital and Care, in which 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 remunerated; 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.”

Figuring out how to include more perspectives into the Bleibeguide and how to ensure agency and reduce hierarchies within this collective work will be how where we take up work again in the summer. Making people aware of the resource again is another part of the process that we will start planning for. Who needs to know about it and what are the places that the information should be available? Aside from this, we also need to further discuss and make transparent our commitment and capacities. When we started, we were already aware that, even more than needing an update (although this is the biggest chunk of work), 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 who might be aware of the infrastructure and how to restart it in case it goes offline when we are both away? This is both to ensure its availability but also to ensure there is no claim or ownership over 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?

As mentioned at the beginning of this text, Olga suggests to look from the inconvenience of making an infrastructural change to the irresistibility of the new encounters or learnings. This is a strategy for seeing the affective pulls of systems full of friction, limitation, relation making and interdependency compared to the convenience, smoothness, addictiveness and dependency of big tech systems. In my research irresistible infrastructure emerge as:

• meso-scale projects of collective relations
• aligned with and directed towards a purpose
• explicit in their materiality and locality
• role-opening with shared interdependencies and responsibilities
• rooms of shared learning and intimate encounter
• explain goals and decision-making to open for questions and critique
• centre the quality of the relations
• foster maintenance
• sustainable and, where possible, regenerative
• invite to share discomfort rather than evade it

This first definition that emerged from my process is suggested here as a way of thinking about and questioning existing or emerging practices rather than as design principles to follow. The most important learning of my process in working with these principles in mind, is to pro-actively reach out to other communities to talk about processes and thoughts on both sides, to get feedback and further perspectives. Allowing time for reflection and conversation, and being willing to reconsider and adapt, is one way to ensure that infrastructure remains accountable to the community and beyond. It is these conversations and learnings that I will take with me.