The trinity has tools for chats, tools for handling threads, tools for handling documentation.

The trinity - Chats, threads, repositories

**Text chats** Examples of chat tools are *Slack*,* Telegram*, *WhatsApp*, *Twitter*, *RocketChat*, *Matrix/Element*, *Mastodon*. Chat in larger chunks 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**.

**Issue threads** Examples of threaded tools are **forum** software (*Loomio*, *Discourse*), and good old-fashioned email, in modern, threaded email browsers, 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.

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.

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 - 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.

These 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'.

There's a gradient from left to right, across the three classes of tools in the trinity. It concerns the amount of curating labour that's possible, and necessary. Labour of curating

--- >The logic of the trinity continues to be valid, but tools and expectations have evolved since this model was first proposed. Today, an Extended trinity needs to be mobilised. It includes trios that have been promoted from the original Stack and Specials. > See also: > - Stack > - Specials