Chapter 3: Praxis Doubling

Praxis Doubling: Misfitting Infrastructures

(theory*practice)*2

Praxis is the combination of practice and theory, code and conduct, docs and protocols. We posit Praxis Doubling as a term for bringing together different kinds of praxis, making room for them to permeate one another, to deviate actions, and animate relations in different ways. Praxis doubling is itself plural. The "-ing" in doubling signals a process that is ongoing – a verb and an action that is multiplied through different orientations and approaches. By doubling praxis we aim to coalesce, seduce, and mutually shape feminist network praxes with critical access praxes. We aim to see how both of these approaches bring theory into collective action and not only make room for more accessible technical praxis, but also allow their matters to become more frictious and disputed.

To make-sense of these technical network relations, In-grid has built up a debugging practice around technical docs.Technical documentation is a resource that explains the processes and practices that make up technical infrastructures. This collective debugging praxis came about when we came into contact with ServPub's table of feminist network praxis, bringing with us our own background in collective access praxis. By disobediently making room at this collective table, we aimed to make-sense of our misffiting with the inherited figures and imaginaries of network infrastructures and their technical docs. Through accepting these misfittings we can disorient dialogues towards forming our own collective counter-imaginaries and figures – ones which can reshape their limits and what is backgrounded within a single praxis. In this chapter, we outline how we have come to practise Praxis Doubling, and the methods we have used to facilitate this mingling of praxes.

Methods

The practices we describe here are ones that have emerged through an entanglement between disciplinary conventions and our own dis-abilities to fit within them. We engage with time scarcity, technical language hegemony, and the expectations of productivity from the situatedness of our accessibility needs and political ethics. This chapter expands on the ways in which we put these needs and ethics into practice, going through the process of working as a computational artist collective and how we approached creating critical documentation for the technical infrastructure of ServPub. We will stop to reflect on the points where the tools we work with created frictions that halted the alleged smoothness of technological processes, and will expand on the ways in which we worked around, through, and within these tools to make room for ourselves and each other (Rice et al., 2024). Some of these ways include approaches to time management and note-taking, deliberately unpacking or abandoning technical terminology, incorporating anecdotal situations rather than writing for a universal user, and critically examining the political implications of names and logos of different tools. The technical documentation that is the outcome of this nebulous process is presented here as one offering of what a doubling of praxis may look like. We have transcluded excerpts from the technical documentation to exemplify this. We also acknowledge that the duality held within the double is not capacious enough to contain the multitude of difference and misfittings that the tools and conventions we confronted try to erase. This chapter contains the doubling(s) of theory and practice that emerged from our particular confrontation with building this infrastructure as artists, technologists and crip, neurodivergent, and queer peers. We will go through some of our work modalities, confronting specific tools and their frictions, and some methods for making room for misfitting within them.

Background to In-grids Docs Praxis

To describe why the ServPub docs look and work the way they do, we must first (briefly) explain how In-grid works as a collective – specifically, the processes that make it accessible for us to work together. The number of In-grid members hovers around thirteen to fifteen active members at any given time. Of that group, smaller clusters form around specific projects and streams of work, where approximately four to six members focus on a project at a time. When a proposed project garners the interest of enough members to make it feasible, we then confront the material conditions around everyone's time and capacity – specifically, the conditions that result from fractional and/or precarious work commitments. We work around that by allowing for some inefficiencies, such as last minute drop-outs and confirmations for joining meetings and working sessions, as well as caring for those returning after a several-month break to rejoin a stream of work. We are also quite promiscuous as a collective and enjoy collaborating with a range of individuals beyond In-grid's already intersectional members. For us, this does not dilute who we are but brings in a wide rage of expertise and perspectives that we feel outweighs the contribution of an experienced or expert individual. While everyone has the opportunity to contribute to our ways of collaborating, we agreed early on not to silo off our different skills into roles, determined specialisms, and isolated/ing processes, but to make room for them to be shaped by bodies inside and outside of our collective. Not only did this orient our collective towards skill and knowledge sharing in and through practice, but it also made room for projects to be more accessible to collaborators, where otherwise there might be social, technical or capacity-based barriers. We have found that even though caring for this wide range of perspectives, practices and politics takes a lot more labour, it offers room for these approaches to multiply – for them to more than double, and for us to unfold situated praxes from specific projects and relations, such as the docs and workshops we share here

Abundant Notes, Better Make Some Room for Them

During the ServPub project, we adopted an exhaustive note-taking process – not only to document meetings, but to create how-to guides, informal educational resources, and relatable diagrams to inform everyone as much as possible about the contextual and technical details about each step of the project. These practices stem from In-grid's copious notes taken every time we meet, since we began working together in 2020. Many of our earlier materials are misplaced, mislabelled or duplicated as we have been trying over these years to feel out a way of keeping records outside big-tech tools, and in a way that is accessible to our members, however entangled they are. These notes started on a series of pads – not all of which have been tagged sensibly or have now been lost. The pads that we managed to wrangle were consolidated into an index pad, which we named the pad-of-pads – in reference to the bag-of-bags that we all have our homes. We then moved to a shared Git repository, which some us have integrated with local text-editing software Obsidian to keep a record of projects and events. Our current admin setup is on a Servus-hosted suite where we have a shared calendar, notes, polls, and storage space. This, however, is a more recent administrative development that we arrived at to balance the need for logistics with the need for friction, improvisation, and pause.

For the ServPub project, we had notes together on Etherpads hosted by a scattering of other collectives and organisations which we try to gesture to in the colophon of this book and wiki. These pads held our notes from sub-meetings, workshops, conversations, and saved chat logs. These notes overflowed from the working sessions we had with other feminist server collectives such as Systerserver and Creative Crowds, where they shared with In-grid their practices and politics around setting up and maintaining these types of network infrastructures. These initial training moments were an important resource and we began this project's infinite-scroll-like pages of notes, code blocks, and annotations to try and contain it. Not many rules were put in place for this process of record-keeping, so they emerged as a chronology. The notes included references to documentation from other collaborating groups, and to "official" documentation provided by the makers of the software. Due to how fluid the process was at the time, we also recorded more affective notes and asides to each other in the same pads, reflecting the context of the information recorded. Often this context only made sense to us as collaborators and friends. However, even if not necessary to understand the technicalities of the work, these side notes allowed us to be ourselves, to centre our subjectivities and express moments of connection to and around the work being done through documentation that could otherwise be isolated and dispassionate. Slowly unfolding from this scattering of pads and notes, we started to makes sense of what these infrastructures, technical practices and their knowledges were to us and how we wanted to shape them.

Over time it became apparent that our unwieldy scattering of notes and ServPub's particular setup needed it's own technical docs to make room for these technical practices to take shape from the backgrounds, relations, and politics around this infrastructure. We go on to share how, through these critical-access-informed docs, we made room to question how their inherited formats for sharing technical knowledges were sedimented within configurations to dictate bodies, practices, and matters into determinate infrastructures, roles, and relations. By doubling the technical praxis of documentation with critical access praxis, we made room to access the relations, figures, and politics inherited from their configurations, and to make sense for ourselves of how these normalising relations misfit our devious collective bodies. In making room for frictious misfitting, we felt the pressure and inflexibility of configurations as a way to imagine how we desire to be collectively (dis)oriented otherwise.

Sedimented Norms

Technical documentation is a form of knowledge exchange that has been standardised and sedimented within institutionalised computing contexts such as computer engineering – and before that from electrical, mechanical and more specifically industrial engineering and design. In these contexts, the promise of technical documentation is to provide a legible understanding of how something was built and from there be able to maintain it within specific regimes and to develop it further within the particular imaginaries of the system it is embedded within. The expertise of this artefact, however, also means that the docs become a compendium of standardised, abstracted, and streamlined processes of infrastructuring. Jeniffer Gabrys might call this "flat-pack cosmology" – one where technologies and their practices are configured into determined infrastructures, which hold in place specific worlds and politics. Miriyam Aouragh and Paula Chakravartty's Infrastructures of Empire (2016) offers an understanding of how the promises of technological freedoms through specific determinate infrastructures can bring with them their background – and often the dominant militaristic protocols and politics they are produced through. Technical docs, through this efficient orientation, offer selective points of access to their practices that dictate the reader/user to use the tool/product in a specific order or within a specific relation. The selection orients them to give just enough information to make the tool knowable and practised in the way it was intended to be, but also encoded so that only a specific role or category of person can access them. Aimi Hamraie's tracing of the figure of the Flexible User (2017) describes how these inflexible flat-pack configurations actually aim to shape users – and the human factor they make up – into normate and generalised figures that fit within their plans. This figure of the user is often whom such technical docs are made for, and we will revisit the user further on in the chapter when we talk about improvised roles.

Through their encoding, encrypting, and isolation of specific practices and their knowledges, technical docs configure the erasure of not only the affective and human presence from the systems, but also their backgrounds and politics. By prioritising "efficiency", these docs do not question the ways they demand bodies, communities, their infrastructures, and their practices to bend to their normalising configuration. For example, if we take Tinc's official technical docs, there is no room made to offer any of the politics of the software's makers, or for how they felt about this software – just what seems to be enthusiasm for its technical capacities. Outside of this affective and political critique there is also no effort made within these docs for them to be accessible to non-experts, both in the language they use and the way they structure and offer up their matters. By design, docs do not usually reveal anything beyond a certain level of utility of a system. While open-source platforms will make more parts accessible, they are still not annotated, documented or legible to a wide range of capacities. This orients these technical practices and infrastructures to only be accessible to anyone who already knows how to navigate technical files or code.

This sedimented configuration of how technical docs share practices and knowledges not only limits the capacities of what these network infrastructures can do, but also who can manifest them. The isolated technical knowledges held in docs highlights how these practices are held apart from their theory, how their sociality and background are hidden from view, and how this beckons for us to seduce them into devious praxis.

ServPub Docs In-Praxis

This section will dive deeper into the specifics of how In-grid puts in practice the ideas and theories with which we open this chapter. To mark this transition we are mobilising our "in-" prefix which, following in the footsteps of Trans-feminisms' use of "trans-" as a prefix, we use "in-" to indicate that we will be mutually shaping and shaped by the word that follows. For us this is a way of making sense of the materiality and relations we work through as Queer Feminist, and a way to process all of the trouble we get or find ourselves "in-".

Here, we explore how we navigated working with the conventions of technical docs within a practice that applies the theories of critical access, and the friction between them in the context of technical legibility – bringing the docs in-praxis. This is where we make room for these sedimented technical tables, figures, discourse and knowledges to be accessed, debugged, and troubled through our multiples contexts of praxis. This disorienting trans*praxis – crossing between critical access and feminist networks – describes how these approaches have shaped our network infrastructures in action. In this section, we highlight how this crossing of bounds, merging of methods, and breaking down of technicalities can open up the plurality of contingent possibilities for how infrastructures can be manifested by collectives, and improvised through their situated politics and practices.

To help discuss a few of these multiplications we are including snippets and transclusions from the Servpub docs to share how these disciplines of theory and practice have shaped one another. We have made these in-trans-clusions clear with dotted bounds that both shows the separation but room for them to touch. The excerpt below is a key example of our trans-praxis, where within the front page of the docs we make room for critical access praxis to multiply our technical praxis. In this section, we offer up how we have worked with Kelsie Acton's notion of semi-plain language (2023) to try to challenge these inaccessible and sedimented norms of technical docs. This approach makes room for the documentation of technical practices to be more accessible to different backgrounds, but also for their knowledges and expertise to be disputable and shaped by those taking it into praxis.

Access (〜￣▽￣)〜

Acton states this as:

Note on writing: This chapter is written in what I call a semi- plain language style. This means I do the following:

• Use an active voice
• Mostly use the 6000 most common words in the English language
• Use short sentences
• Use 14 point font
• Use “I” and “you”

Following Acton In-grid understands this as not trying to assimilate dialogues into dominant technical talking points. Instead, In-grid approaches this practice through critical access as to distribute where the expertise of systems are located, making them disputable from many experiences, backgrounds and knowledges.

As we collectively manifested ServPub through semi-public and public workshops, closed working sessions and independent working, this practice of copious – if atomised – note taking moved towards a pastiche of devious technical docs. In this process of coalescing ServPub's technical documentation in-trans-praxis, the docs became politically implicated and entangled in the backgrounds we brought with us. The docs that we eventually arrived at are somewhere between internal notes and personal asides, technical docs and DIY instructions: a simply-written, narrative-moderate set of instructions on building an ambulant self-hosted server with a VPN. These deviating docs make room not only for them to be accessible in form, but also for the social and political relations which hold our collective infrastructure together to also be accessible, known and figured out.

Why Tinc?

We are using Tinc because it is inherited from the history of projects that we are working with. This setup pulls from the original work of XPub and their HUB project, which used it to form experimental server space for their students which could get passed institutional firewalls securely and let devices roam. This led to the development into other projects like Rosa and the ATNOFS project, as well as Constant's Circulations. Similarly, we used the setup to form an experimental network of servers to form this Servpub collective publishing infrastructure.

You can read more on this history at the bottom of Constant's Circulations about page under the heading Radical Referencing.

Below is a list of other resources and docs on how to set up tinc that we have worked from/with:

• XPub docs - Tinc VPN install
• Lurk docs - Tinc VPN install
• Psaroskala zines - Making a private server ambulant

In the background of ServPub there are also pre-existing separate docs for the Tinc setup by XPUB, Run Your Own, and the many versions and docs of Wiki4print hosted on their MediaWiki instances. This diversity of docs is impressive, as we feel the background and priorities of these different groups come through. What do they care about? How are they practising and approaching these technologies and infrastructures together? And how do they contextually share and shape the abstract social relations that make up these technical practices? However, this same abundance and specificity can make these knowledges inaccessible to different groups and communities. This can of course be done intentionally, so that there has to be a certain level of intimacy given to the infrastructure, its politics, practices, and technologies to manifest them. This is highlighted in Simms and Marangoni's En-crip-ing Time (2025) where the work is purposefully obfuscated and en-cripped so it is only known through radical practices of intimacy and care. Here though, In-grid –In-praxis with technical docs – wanted to form a practice of knowledge sharing that could both orient towards being accessible and disputable, but also towards holding the collective backgrounds that ServPub has unfolded from.

Activating the Docs

Throughout our practice of technical docs we have been questioning how we can make room for them to not only be accessible from a plurality of capacities and backgrounds, but also open up the technical practices they document to be disputable and improvisable by those manifesting them. In this section, we reflect more deeply on how we have explored this later step, and how we approached making the docs and the practices they offer to be re-interpretable and disoriented from a plurality of embodied and situated expertise. To do this, we formed a set of workshops from these docs that we called Practicing Protocols. The name, Practicing Protocols, itself emerges from both its feminist STS roots, but also through a crip understanding of protocols as a place to dispute expert knowledge of systems through counter-protocols. Through this framing, these workshops aimed to make room for people to accessibly be in touch with technical practices, and along the way, make sense of the misfitting we as a group felt from the normalised and sedimented figures and relations these network configurations hold in place. We developed this workshop as a way to not only make accessible the often obfuscated and encrypted practices of digital infrastructure, but to also bring them into dialogue with the operational concepts and metaphors they operate through. In doing this, our workshop aimed to create a space where people can bring the knowledges they have gained in practice together with the embodied knowledges and expertise they brought with them from their backgrounds. To dispute, improvise, and disorient these protocols in action we also turned to the methods of TITiPI's Disobedient Action Research (Pritchard et al. 2021), to inform us of how to collectively dispute what these systems are, how we make-sense of them, and how we would want to imagine, shape, and practice them otherwise.

The Logo for Tinc. It has a black and white image of an Apache attack helicopter with the work "Tinc" written across it.

During the ServPub project – where there was an abundance of feminist network praxis – there was also ample room to question the figures, relations, and norms of these infrastructures as we actioned them. Throughout our collaborations with other collectives involved with ServPub, there had been times where In-grid members were questioned by others about our sedimented metaphors and relations. This prompted us to reconsider whether our collaborations were oriented through the "driver–navigator" programming hierarchies we inherited from institutions of computing, or whether we wanted to reorient these relations into "conductor–finger dancer" or similar. When taking this critique away from our sedimented norms of practice, we also found depth in questioning the other misfittings and frictions we felt within the protocols, figures, and inherited relations of the infrastructures we were manifesting. This is where we started to find and make friction around things such as Tinc's logo (pictured above), which for us seemed to be one of the few political gestures of the VPN. The logo pictures an Apache attack helicopter as a signifier of security and privacy, and which for us seems to situate this software as embedded within security politics. These politics are ones where safety and privacy of networks are conflated with security and militarism. This sense-making of misfitting made room for us to collectively orient and improvise how we wanted to imagine and enact these relations of safety and privacy from our own backgrounds and politics. Here, by making both the theory and practice accessible and disputable, we offer up how this praxis has more than doubled.

So far we have run the Practicing Protocols workshops in two iterations: one as part of a combined panel hosted by In-grid members at 4S/EASST in Amsterdam, and the other internally with In-grid members. The workshop at 4S/EASST, an international Science and Technology Studies (STS) conference, was run as part of a combined panel, where we presented work alongside TITiPI, NEoN Digital, researcher Júlia Nueno, as well as members of SHAPE. The panel presented a spectrum of community-organised infrastructure, and this iteration of Practicing Protocols aimed to offer up space for people to make-sense of these collective network infrastructures together. The second workshop was run internally for In-grid members who were not specifically involved in ServPub and may have missed out on learning these skills or understanding these practices and their knowledges. This second workshop within In-grid also importantly moved from being an accessible representational process, like we did at 4S/EASST, to part of a working session were we set up a Virtual Private Server (VPS) and foundational digital infrastructure for In-grid itself. Setting up this foundational infrastructure through our misfit debugging practices, allowed us to more intimately establish the structure through our own collective intentions and desires <3.

Bellow we highlight two points of praxis where we emphasise the sense-making of misfitting within configurations that unfolded from the Practicing Protocols workshops. The excerpts aim to provide a snapshot of how these different groups, contexts, and expertise felt and made friction that aimed to improvise and deviate these network norms towards the collective body-minds we are in dialogue with.

Misfitting Contracts...

Projection showing workshop slides from Practicing Protocols alongside the collective working pad we used for debugging at 4S/EASST.

During the first iteration of these workshops at 4S/EASST, we had a group of five-six people – from academia and a variety of backgrounds – with both disciplinarian and lived experience. This workshop was at 8:30 am the day after the main conference celebration, and so everyone there was a bit hazy, and gently waking up. The workshop was designed to be quite accessible technically, to make it as barrier-free as possible. This being the case, we were fine with people just taking part in the dialogue and not actively practising the techniques described, but did encourage them where possible, with one In-grid member even lending a participant their laptop so they could join. The set of protocols we frictiously went through together aimed at logging onto the servers via SSH and editing a text together that was being served online from there.

A diagram made by In-grid to represent how SSH communicates to the server from a device.

In this section, we raise one of the key misfittings that was made sense of during this workshop to offer up how this process made room for us to question and disorient the sedimented configurations of network infrastructures. To do this we bring focus to Secure Shell (SSH), and how – when making-sense of this protocol with this group –we started to unravel not only how it is abelistly figured, but also how the relations it configures and holds in place are shaped by a specific kind of body and social relation. It was through the metaphor of the "handshake" through which SSH mobilises that this misfitting was brought into question – particularly how the "handshake" between bodies is meant to represent an act which forms safe and secure communication between devices within sedimented network configurations.

The following in-trans-clusion from our docs illustrates how this metaphor can be used.

Security via SSH Keys

SSH Keys are user specific and are used in addition to a shared login password to make it more secure than traditional usernames and passwords. To make this method of access truly secure we will need to eventually disable password-only login.

SSH is often metaphored as a handshake between devices, but you can also think of the shared public file as the key, and the private file as the lock. Locks are non-transferrable and have to be generated per user.

To generate a key each user must execute this command on their laptop:

ssh-keygen -t rsa

This will generate a pair of public and private keys. You will then need to fill in the information requested (most of it is optional so you can leave it blank) and set a password (Also optional).

You’ll receive something like this:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/me/.ssh/id_rsa):`
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/me/.ssh/id_rsa.
Your public key has been saved in /home/dave/.ssh/id_rsa.pub.
The key fingerprint is:
ef:69:3b:9e:3b:2d:99:0d:ac:57:4e:b2:92:82:bd:9f me@hostname
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|                 |
|        S.       |
|         .+ o    |
|     o   o.%     |
|    . o +oXo+    |
|      .+E=B*     
+-----------------+` 

The shared key is the:

id_rsa.pub

The private Key is the:

id_rsa

When accessing the servers through SSH together, we reflected on how our devices were interfacing through these sedimented metaphors and figures. As a group here we started to question what a handshake represented within this configuration. The person shaking the hand is firstly assumed able-bodied, or assimilating to that norm, but also – when we take in the backgrounds and histories of these network infrastructures – they are also predominantly male and white. Therefore, this figuration of the handshake is a place where many of us felt we misfit, where we did not want to be "pulled in by the hand" and into determined and limiting forms of contract-making as trust, and the frictions we felt around this. The following notes emerged from the workshops and our collective reflection and writing on SSH.

2. SSH

• authenticity of host can't be established. - trust issue
• hospitality; being a respectful guest & welcoming host (simultaneously)
• server playing hard to get but finally got a seat at the table
• the terminal visually looks the same whether its your local machine terminal or a different shared machine, so it feels like the same. Because you are bringing somewhere else to you instead of you going.
• there is an obscurity to the virtual
• How could an SSH feel more material, closer
• Anonymity
• temperature feels very material - what else could be included i.e. location to the server
• physically caring for it's wellbeing (plugged in)
• is the handshake appropriate? i.e. banking, trumpy handshakes, getting pulled in by the hand, whats the origin of the expression?
• is it about a manifestation of trust - and so what else could signify this
• server hugs

In dialogue around this configurational misfitting the group started to orient towards what we would rather be connecting and building trust through – how we, as a group, wanted to imagine and practise these networks through intimacy and care. From this sense-making of how these infrastructures have been normalised to specific bodies, we started to question how we wanted to shape and improvise them to our relations and desires. There was more to the conversation but the collective notes of the workshop quoted above shared the "server hugs" that we desired together – the soft, comforting embrace of networks we wanted to shape and be held by.

Improvised Roles...

An image from the workshop day and in one of the members' kitchens ready to get coding.

The second iteration of the Practicing Protocols workshops was held internally by a group of seven In-grid members. It aimed not only to share the practices and knowledges we had built up from being a part of ServPub, but also to set up our first In-grid server together. This workshop was intended to leave room alongside the practicalities of implementing the server, for making sense of these configurations, and how we might want to orient and improvise them otherwise and together through collective praxis. This workshop was held just after a nice lunch we cooked for each other, and as we sat there, quite full and very comfy, we started to manifest our collective infrastructure together. The steps we took to do this were: logging in to the server, setting up user accounts for our members, and hosting a website of our workshop notes there.

A diagram describing how users are configured within network infrastructures.

In this section we highlight one of the main misfittings felt by In-grid members during this workshop. The misfitting that was unavoidable here was that of the determined user of these servers. The user is the individualised account and role that permits specific limiting relations within the determinate hierarchies of the system. An example of this is the demarkation of a user to a user within the SUDO group. SUDO group users are members of a user group called "Superusers", who have more access to perform sensitive commands. It is often figured as a way of elevating users' privileges, which in turn allows them to do things like update or install packages, restart or disable tasks. The term SUDO is a truncation of the phrase "Superuser do."

We read the figure of the user here as one who is isolated within a closed system, not only through technical protocols but also through the nonexistent capacity for and resulting invalidation of any social backgrounds. By finding friction with the configuration of the user within network infrastructures, we question who these technical relations are imagined for, but also what the limits of their relations and capacities for intimacy are.

Adding Users

To make a new user, use the command below.

adduser <nameofuser>

[!note] You will be prompted to input a password and it is always better to give different users different passwords for security.`

If you want to give this user sudo access, then they have to be added to the “sudo” group. You don’t need to create this group, it exists by default and you can just add or remove users from it. The sudo group is stored in this directory: /etc/sudoers.d/

To add a user to the sudo group run the following command:

usermod -aG sudo <nameofuser>

When setting up our user accounts together on the server one by one, we questioned how these roles misfit our collective relations. The user role as stated above only holds the capacity for a determinate relation – one where a person interfacing with the server has to flex to specific relations and norms. When we brought this in touch with how we make room for our members to "perform" in our space, the role of the user had very defined and hard limits – ones that could not hold the diversity of bodyminds, capacities, and perspectives we wanted to embrace as a collective. In this space of misfitting we amplified this friction by starting to imagine what roles and relations we wanted to manifest within our network infrastructures.

User Protocols

Not users but:

• maintainers?
• carers?
• members?
• players?
• collaborators and caretakers
• it is nice to be individuals in a collective
• characters
• conversationalists
• persona
• infra as another collaborator not users/using
• fistulas

When making this room to disorient the sedimented role of the user within network infrastructures, we began to question how we wanted to be together on this server. From this point of collective deviation we started to shape and perform the user through our own metaphors and figures. These ranged from maintainers and carers, but also to characters and personas. These figures brought a blend of In-grid's background of performances, parties, and arts with those of infrastructural practices and labours. From this point of misfitting and friction-making – alongside many others in the workshop – In-grid started to shape and practise the social and technical relations we desired to be together.

Praxis*∞

In-grid – and more broadly the group involved with ServPub as a whole – is made up of many individuals with still more multiple practices/praxes. For us, this means that this publishing infrastructure is shaped by our many approaches and politics towards collective practice. As we have worked to build an infrastructure which tries to reflect the desires and concerns of those who have built and will use it, we have also created a way of recording that work which includes elements of our personhood. Traditional documentation intentionally omits affective details. On a practical level this is a useful way of keeping work succinct, searchable, and quick to parse and implement (ideally, anyway). What this can do however, is exclude non-experts by glossing over information about why you might take a particular action instead of another, making steps appear arbitrary or opaque.

Through learning and making this infrastructure, we recognised that not being able to understand the reasoning behind why a step has been taken in a set of documentation makes it difficult to deviate from a prescribed path or a set tool-kit. One of our aims for creating critical-access-informed docs is to create enough room around these technical processes to allow others to make these decisions – for example, whether they want to follow a certain path or not – and to build the capacity to make more creative choices and cobble together their own improvised methods.

Reflecting back on the plurality of praxis we have shared in this chapter – from the ServPub infrastructure, to our resulting access-informed docs, and the Practicing Protocols workshops we made with them – these entangled and overflowing layers of praxis demonstrate how we have brought together disciplines and methods in action that unfold the predetermined configurations of network infrastructures into other performances and relations. Here we highlight how the critical access praxis that In-grid is engaging has mutually shaped and transformed the background and history of feminist network praxis from which this project builds. Through this mutual shaping we show one way in which critical access can make room for prescribed configurations, infrastructures, and their politics to be made more accessible to a range of capacities, and also to be disputed by validating the diverse forms of expertise and knowing that we bring to meet them.

The docs which exist on Wiki4print are meant to remain unmaintained at the time of publishing, as a record of the place and position we were at when the platform was made. A version will be hosted in a way where others can contribute to maintaining it, but the choice to create a static version both provides a record for memory-keeping, and also reflects the fact that they were written by a group of precarious and fractional workers who can't commit to keeping them up to date indefinitely. Leaving them in this frozen stage with personal notes and asides included does make them more vulnerable, and more deeply entangled with our own partialities and politics. However, we welcome this complication, as we are happy to leave our practice entangled with our theory, and our code knotted in our conduct.