Chapter 3: Praxis Doubling

<unicode>⟀⋒⌘</unicode>

Praxis Doubling

Contributors: In-grid

(theory*practice)*2

Praxis doubling is itself a plural. The _ing on doubling is a process ongoing, a verb and an action that is multiplied through different orientations and approaches. By doubling praxis we aim to coalesce together, seduce and mutually shape feminist network praxises with critical access praxises. In this dance aiming to feel out how both of these approaches to bringing theory into collective action can not only make room for more accessible technical praxis, but also for their matters to become more frictious and disputed. Praxis itself being the combination of practice and theory, of code and conduct, and of docs and protocols. Praxis doubling we offer how bringing together different praxis makes room for them to permeate one anothers, to diviate actions and can animate relations otherwise.

To make-sense of these technical network relations together In-grid has built up a debugging practice around technical docs. Technical documentation is a resource that explains processes and practices of technical infrastructures.This collective debugging praxis came about when we came in touch with Serpub's table of feminist network praxis, and brought with us our own background of collective access praxis. By disobediently making room at this collective table for these methods we aimed not only to make room to make-sense of our misffiting with the inherited figures and imaginaires of network infrastructures and their technical docs, but so that this room for misfitting can disorient dialogues towards forming our own collective counter imaginaries and figures that can reshape their limits, and what is backgrounded within their praxis.

methods section?

I am wondering if we have a quick methods para to talk about disobedient action research or maybe this misfts/cripping text <- this basically says making sense of frictions and misfitting in determined relations is a way to subjectivley situate and deviate actions from their plans . . .

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 as a collective works. Specifically, the processes that facilitate that/our work. The number of in-grid members hovers around 13-15 active members at any given time. Of that group, smaller groups form around specific projects and streams of work, usually around 4-6 members focusing on a project at a time [^1]. Most of us are fractional and/or precarious workers, so even when a project garners the interest of enough people to make it feasible, we still face the material obstacle of meeting everyones capacity. This includes allowing for last minute drop-outs from meetings to make space for shifts in work or other commitments, as well as caring for those that turn up after months out and want to join back in.

We are also quite promiscous as a collective and enjoy collaborating with a range of individuals beyond In-grid's already intersectional members. For us this doesn't dilute who we are but brings in a wide rage of expertise and perspectives that we feels outweighs an experienced or expert individual. So while everyone has the opportunity to contribute to our ways of collaborating, we agreed early on to aim to not silo off our different skills into roles, determined expertise 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 oriente our collective practices towards skill and knowedge sharing in practice, but it also made room for projects to be more accesible to collaborators, where otherwise there might be social, technical or capacitiy based barriers. We have found that even though caring for this wide range of perspectices, practices and politics take a lot more labor, it offers room for these approaches to multiply, for them to more than double, and for us to unfold situated praxis from specific projects and relations, such as the docs and workshops we share here.

Abundent 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 and informal educational resources and relatable diagrams to inform everyone as much as possible about the contextual and technical details within each project. These practices stem for In-grid from the copious notes we make every meeting we have, even back to when we began working together in 2020. Many of our earlier materials are misplaced, mislabled or duplicated as we have been trying over these years to feel out a way of keeping records outside of big tech, and in a way that is accessible to our members however entangled they are. For the Servpub project, and before we had the wiki installed, we made notes together on etherpads hosted by a scattering of other collectives and organisations. These pads held our notes from submeetings, workshops, conversations, and saved chat logs. Slowly ufolding 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 desired to shape them.

These notes overflowed from the working sessions we had with other feminist server collectives such as Systerserver, Varia, and CC, where they shared with In-grid their practices and politics around setting up and maintaining these types of network infrastructures. Several interested in-grid members did not have the capacity to attend these initial training moments, and so to keep them updated we began this project's infinite-scroll-like pages of notes, code blocks and annotations. These notes included references to documentation from other collaborating groups, and to "official" documentation provided by the makers of the softwares we used. We felt it necessary to record the practical steps of the process, alongside more affective notes and asides to eachother. This allowed us to be ourselves, and express moments of connection to and around documentation that could otherwise be isolated and dispassionate.

Over time it became apparent that our unweildly scattering of notes and Servpub's particular setup, needed it's own technical docs to make room for these technical practices to takes shape from the backgrounds, relations and politics around this infrastructure. We go on to share how through these critical access informed docs 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 these technical praxis of documentation with critical access praxis we made room to access the relations, figures and politics iherited from their configurations, and make-sense for ourselves of how these normalizing relations misfitt our devious collective bodies. In making room for frictious misfitting, feeling the pressure and inflexibilty of configurations as to imagine how we desire to be collectivley (dis)oriented otherwise.

Sedimented Norms

Technical documentation is a form of knowledge exchange that has been standardised and sedimented within institutionalised computing contexts like computer engineering and before that from electrical, mechanical and more specifically industrial engineering and design. In these contexts, the promise of technial 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 specific imaginaries of the system it is embeded within. The expertise of this artefact however, also means that the docs become a compendium of standardised, abstracted and streamlined process of infrastructuring . Jeniffer Gabrys might call this a "flat-pack cosmology" or one where technologies and their practices are configured into determined infrastructures, which hold in place specific worlds and politics. With Miriyam Aouragh and Paula Chakravartty's Infrastructures of empire (2016), we can understood how these promises of technological freedoms through specific determinate infrastructures, can bring with them their background and often the dominant militiaristic 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 product/tool in a specific order or relation. The selection here orients them to give just enough information to make the tool knowable and practiced in the way it was intended to be, but also encoded so that only the specific role or category of person can access them. With Aimi Hamraie's tracing of the figure of the Flexible User (2017) it can also be understood that these inflexible flat-pack configurations actually aim to shape users and the human factor they make up into normate and generalized figures that fit within their plans.

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 normalizing configuration. If we take up Tinc's official technical docs for example, there is no room made to offer any of the politics of the softwares makers, or for how they felt about these software, just what seems to be enthusiasm for the technical capactities of the VPN. Outside of this affective and political critique there is also no effort made within these docs for them to be accessible to no experts, both in the language they use and the way they structure and offer up their matters. By design, docs do not usually reveal beyond a certain level of utility of a system. Open source platforms will make more parts accessible but 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 configurations of how technical docs share practices and their 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 is where we make room for theses sedimented technical tables, discourse and knowledge to be tested, debugged and troubled through our multiples of Praxis. These disorienting trans*praxis crossing between critical access and feminist netwroks to offer how these approaches in action have shaped our network infrastructurs. In this section highlighting how this crossing of bounds, merging of methods and breaking down of technicalities can open up the plurality of contigent possibilities for how these infrastructures can be manifested by collectives and improvised through their situated politics and practices.

To help discuss a few of these multiplications we are working snippets from our docs to share how this disciplines of theory and practice have shaped one another. This excert below is a key example of our trans-praxis, and where on the front page of our docs we make room for critical access praxis to multiply our technical praxis. In this section offering 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. In this approach making room for the documentation of technical practices to be more accessible to different backgrounds, but also for their knwoledges 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 collectivley manifested Servpub through semi-public and public workshops, as well as closed working sessions and independent working, these practice of copious, if atomised note taking, moved towards a pastiche of devious technical docs. These docs giving shape to how we had accessed these technical matters and made sense of them collectivley.

In this process of coalescing the servpubs techincal documentation through our trams*praxis they started to become politically implicated and entangled in the backgrounds we brough with us. The docs that we eventually arrived at are somewhere between internal notes, technical docs and DIY instructions; a simply-written, narrative-moderate, set of instructions on building a autonmiomus self-hosted server with a VPN. These deviating docs making room not only for them to be accesible in form, but also to our social relations and politics which hold this collective infrastructure together through its embrace.

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 wikimedia instances. This diversity of docs is someways an impressive thing as we can feel the backgrounds of these different groups come through, What do they care about? How are they practicing and approaching these technologies and infrastructures together? And how do they contextually share and shape the abstract socail relations that make up these technical practises? In other ways this can make these knowledges very inaccessible to different groups and communities. This can of course be done on purspose so that their has to be a certain level of intimacy given to the infrastructure, its politics, practices and technologies to manifest them. This is highlighted in en-crip-ing time (Simms and Marangoni 2025) where the work is purposfully obfuscated and en-cripped to put the labor and care on the person approaching the work. Here though In-grid in praxis with technical docs wanted to form a practises of knowledge sharing that could both orient towards being legible and accessible, but also towards holding our collective background that ServPub has emerged from.

In this process of docs in praxis we met many times and of course made many notes.

These docs detail how to setup the different sections of the servpub autonomous publishing server (wiki4print.servpub.net), and where we co-authored and designed this book. This somewhat menacing setup is a reflection of how we attempted to respond to the form/conventions of technical docs. [expand on the progression of going from internal docs, to collectively hosted docs with Systerserver, to hosting them on w4p to then to including them as a reference to this chapter].

We took part in the workshops prepared by Systerserver and ourselves towards the more public events of the ServPub project, and

Expand: Articulate our response to that. How can we offer a response, why? What is the percieved gap we are trying to fill with these proposed docs?

But the process of creating something as seemingly neutral as techincal documentation, became more politically implicated as work, efficiency, transparent methods, etc became entangled in the choices we made. The docs that we eventually arrived at are somewhere between internal notes, technical docs and DIY instructions; a simply-written, narrative-moderate, set of instructions on building a self-hosted server with a VPN, set up for collective management/sysadministration.

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 improvise-able by those manifesting them. In this section, In-grid reflects deeper on how we have inquired into 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 expertise. To do this, we formed a set of workshopsfrom these docs that we called Practicing Protocols. The name of 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 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 make 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, 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, metaphor 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.

These workshops came about as we reflected on making these docs, and how much of the sense-making we had made of them came from being in contact with them that made room for us to question and critique their norms. During the Servpub project where there was an abundance of feminist network praxis, there was also ample room made to question the figures, relations and norms of these infrastructures as we actioned them. Through the collaborations there had been times where In-grid members were questioned by others about our sedimented metaphor and relations, and making us reconsider if our collaborations are oriented through the "driver - director" hierarchies we inherited from institutions of computing, or if we wanted to reorient these relations into "conductor-finger dancer" or similar. When taking this critique away from our own sedimented norms of practice we also found depth in questioning how we could critique the other misfitting and friction 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 itself 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 and 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 for two iterations, one as part of a combined panel In-grid members hosted at 4S/EASST in Amsterdam, and the other internally with In-grid members to make-sense of and orient our serve as we set it up. The workshop at 4S/Easst, which is an international Science and Technology Studies (STS) conference, was run as part of a combined panel, where we presented work alongside TITiPI, NEoN digital, Júlia Nueno, as well as members of SHAPE. The panel presented a spectrum of community organised infrastructure, and this itteration of Practicing Protocols alongside aimed to offer up space for people to make-sense of these collective netowrk infrastructures together. The second workshop was run internally for In-grid members who were not specifically involved within 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 instead set up a Virtual Private Server and foundational digital infrastructure for In-grid to start to experiment with and care for. In setting up this foundational infrastructure through our misfit debugging practices, we aimed to have set it up 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 excerts aim to give a snapshot into how these different groups, contexts and expertise felt and made friction that aimed to improvise and deviate these network norms towards the collective bodyminds we are in dialogue with.

Misfitting Contracts . . .

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

During the first itteration of these workshops at 4S/EASST, we had a group of 5-6 people mostly from accademia and from a variety of backgrounds, both disciplinarily 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. For the workshop we oriented to aimed for it to be qute accessible technically, as to make it as barier free as possible. This being the case we were fine with people just taking part in the dialogue and not the practice, but did encourage them where possible, with one of use even lending someone a laptop to join in. Saying this the set of protocols we frictiously went through together aimed at logging onto the ervers via SSH and editing a text together that was being served there.

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

In this section here, 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 of people we started to unravel not only how it is abelistly figured, but also how the relations it configures and holds in place are shape by a specific kind of body and background. Within the workshop at 4S/EASST this misfitting was brought up by the group when we shared the figures and metaphors of SSH, how it repressents a handshake between bodies and one that forms safe and secure communication between devices within sedimented network configurations.

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 definitley able bodied, but also when we take in the backgrounds and histories of these network infrastructures, they are also predominently male and white. This con-figuration of the handshake then 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 had around this.

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

Snippet from the full workshop notes

In dialogue around this configurational misfitting the group started to orient towards what we would rather be connecting and building trust trhough. How we as a group wanted to imagine and practice 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 in conversation but the collective notes of the workshop quoted above shared the "server hugs" that we desired together, for 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.

This iteration of the Practicing Protocols workshops was held by 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 set up our first server together. In this setup making room for us to make sense of these configurations together and how we might want to orient and improvise them otherwise together through collective praxis. This workshop was held just after a nice lunch we cooked for each other, and as we sat their quite full, and very comfy, we started to manifest our collective infrastructure together. The steps we took to do this were to log in to the server, to make user accounts for our members and to host website of our workshop notes there.

A diagram describing how the users are configured within network infrastructures.

In this section here we highlight one of the main misfittings In-grid members felt during this workshop. The misfitting that was unavoidable here was that of the determined user of these servers, which is the individualised account and role that permit them specific limiting relations within the determinate heirachies of the system. 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 no existent 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 thechnical 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>

Not users but:

• maintainers?
• carers?
• Member?
• Players?
• Collaborators and caretakers
• it is nice to be individuals in a collective
• characters
• Conversationalists
• persona
• Infra as another collaborator not users/using
• Fistulas

Leaving Entangled

In-grid, and more largely the group involved with servpub as a whole, is made up of many individuals with still more multiple practices/praxises. It is shaped by our approaches and attitudes towards collective work, accreditation, labour and funding. These attitudes have have had material influence on the configuration of the tools and platforms we have used, and the form of sites like wiki4print. 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 include elements of our personhood. Traditional documentation ommits affective detail intentionally. On a practical level this is a useful way of keeping work succint, searchable and quick to parse and implement (ideally, anyway). What this can do however, is exclude none experts by glossing over information about why you might take a particular action in lieu of another, making steps appear arbitrary or opaque. If we are not able to understand the reasoning behind why a step has been taken in a set of documentation, it makes it difficult to deviate from that precribed path. If we are understand a process enough to make a decision about whether we want to follow that path or not, we are able to make more creative choices and cobble together different methods and approaches. Ommitting the personal and affective also obscures the experiences and perspectives of the people who made the work, and the situatedness of that work. The docs which exist on wiki4print are an intentioned to remain unmaintained at the time of publishing it more widely, 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 acts as a form of record keeping, but 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 indefinately. All this, being said, our leaving in of these more personal notes and asides do make the the docs 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.

References

Acton, Kelsie. 2023. ‘Plain Language for Disability Culture’. In Crip Authorship, edited by Mara Mills and Rebecca Sanchez. New York University Press. https://doi.org/10.18574/nyu/9781479819386.003.0008.

Aouragh, Miriyam, and Paula Chakravartty. 2016. ‘Infrastructures of Empire: Towards a Critical Geopolitics of Media and Information Studies’. Media, Culture & Society 38 (4): 4. https://doi.org/10.1177/0163443716643007.

Hamraie, Aimi. 2017. ‘Flexible Users: From the Average Body to a Range of Users’. In Building Access. Universal Design and the Politics of Disability. University of Minnesota Press. https://doi.org/10.5749/j.ctt1pwt79d.6.

Pad up to date: https://pad.riseup.net/p/PraxisDoublingChapterNotes-keep

index.php?title=Category:ServPub