Rich Bartlett and Nati Lombardo of Enspiral (later The Hum) introduced a 'trinity' schema, of basic text-based digital tools for collaboration.
The trinity has tools for chats, tools for handling threads, tools for handling documentation.
Trinity slide 2020
# Text chats Examples of chat tools are *Slack*,*Telegram*, *WhatsApp*, *Twitter*, *RocketChat*, *Matrix/Element*, *Mastodon*. Chat in larger chunks - like in Mastodon - can be viewed as ‘micro-blogging’.
Chat protocols differ in just how mutual or hierarchical they are, with regard to rights and permissions of different classes of actors. > Mastodon for example is fully peer-to-peer and federated across instances (running on the ActivityPub protocol) while Slack tends to be used for broadcasting across nominal ‘teams’ within corporate environments, running in closed enclosures.
Most chat tools are sandboxes with tacit, proprietary, internal protocols, that don’t federate across instances - the way, for example, that good-old email does, running on the SMTP protocol. But popular chat platforms are keen to have their feeds rebroadcast.
The basic thing about chat tools is that in principle they arrive immediately, and thus are seen as **synchronous**.
They also are transitory: posts scroll quickly off the top of the window and are hard to find again, and tooling for bookmarking or other forms of 'memory' are generally minimal.
# Issue threads Examples of threaded tools are **forum** software (*Loomio*, *Discourse*), and good old-fashioned email, in modern, threaded email browsers, perhaps generated through **listservs** or notification streams.
*Zulip* carries over some of the affordances of threaded email into something that looks and feels like a chat tool. Rocket Chat supports issue threads too.
Threaded media are broadcast to all members of a designated ‘space’. They may feel closer to micro-blogging because they permit quite large chunks of content - like the unrestricted length of email for example. However, email isn't great for clarity in the UI in the way that chats are.
An important thing about threaded media is the space they can establish for **deliberating** in a community. So, affordance for **polling** and transparently **registering** points of view is part of this. > Tools vary a lot in this regard, and very few of them are very good at this - **Loomio** stands out, it was designed to support decision making - but other kinds of ‘community standing’ or ‘trust’ are sometimes tooled-up too (specialised tools to support ‘contribution accounting’ are closer to this: see ‘specials’ below).
A second important thing about threaded media is that, being **asynchronous**, they enable participation by people whose lives fall into **different patterns of time**, whether this is timezones in global collaboration, or work regimes arising from roles in a political economy (paid wage work, seasonal work, precarious work, household work, care work, voluntary work, etc).
# Documentation, libraries, repositories People make use of *Gdocs* in this way. *Wikis* are designed to work in this way. You can use *Etherpad*, *HackMD*. Code geeks use tools grounded in *git* protocol (gitHub, gitLab). 'Favourites' (for example, in Mastodon, in the web browser, on the desktop), portals and lists of links serve similar purposes - but generally these are personal tags and are not shared across a group.
These tools can be more and less helpful, in how they facilitate filing of documents and easy, transparent access to them. But they all enable repositories of documents to be assembled and held in the Cloud and mutually accessed by people - under various classes of privilege - **in a distributed way**.
The documentation element in the trinity is important in underpinning *the political economy of curating-work* - which is a 'politics'.
In the trinity there's a gradient from left to right, across the three categories. The gradient concerns the amount of curating labour that's possible, and necessary. Labour of curating