Spacetube is a communication tool that groups use to talk to other groups. A group installs it on their chat platform, and can then open tubes to other groups by sharing a code through an existing communication channel.
The first version of spacetube has been built and I am currently in the process of selecting the best place to focus my attention in the next phase of development. The aim is to get Spacetube into a position where it’s used by real groups for a real purpose, then adjusted to suit their needs over time.
At the end of 2023, I conducted a user research exercise where participants played a game using Spacetube. Their feedback was collected in a set of user interviews (interview output here).
Current status of Spacetube
Analysis of User Research
Feature Priorities
Feature Candidates
Documentation
Richer Events
Group Interaction
Refined User Testing
Grouptalk Modes
Web Interface
Security
Self-hosting Support
Tube Settings
Immediate Needs
Explanation
Simpler Spacetube Set-up
Grouptalk Affordances
Summary
Appendix
Pseudo-Users
Group Preparation
Technical Debt
Platform Integrations
Current status of Spacetube
Spacetube consists of:
* A Matrix appservice that can be self-hosted as an appservice on a group’s matrix homeserver.
* A web application that displays a visual interface of a spacetube connection.
* An API that supports the web application and basic bridges to Discord and WhatsApp.
* A website with links to the instructions on the github repository and an early introduction post.
The appservice has the ability to connect 2 or more Matrix rooms to each other and forwards messages from one Matrix room to the other room(s) on behalf of the entire group.
Analysis of User Research
This feedback came from the user interviews (interview output here) and discussions with other domain experts and stakeholders.
What came up most often was the need for more guidance on how to think about spacetube and how to use it. I’ve labeled this as the need for more effective explanation.
It also came up that spacetubes could be easier to set-up, that they were still in the domain of the “technical user”. I’ve labeled this as the need for simpler setting up of spacetubes.
Finally, the dynamics of group communication came up, and the necessity for some kind of sense of how the group was “supposed” to interact using the new tool. This could require a mixture of mimicking the existing ways of producing group statements and investigating other modes of grouptalk (the composing of messages sent from a group). I’ve labeled this as grouptalk affordances.
Feature Priorities
The first long list of feature candidates are all the possible improvements and additions that have been suggested so far, as best as I can recall and compile from my notes. After the long list, I expand three pieces of work that relate most closely to the needs identified in the user research.
Feature Candidates
These features are grouped by category, but aren’t ordered by priority in any sense.
Documentation
* Diagrams, videos, start-up guides
* Demonstration groups that users can join to experiment with the tool
Richer Events
* Images, including profile pictures for bot interactions
* Polls and proposals for many-group spacetubes.
Group Interaction
* Pseudo-users as a tool for user experience evolution
* Social techniques to ready a group for spacetube.
* Visualising masks and choruses for group personas.
Refined User Testing
* Alter the game played with the synthetic groups.
* Trial the group formation exercises.
Grouptalk Modes
* Speaking stick
* Quorum for approval
* Designated ambassadors
* Designated drafters and approvers
Web Interface
* Manage invites and tube creation
* View all spacetubes you have access to
* View the connections of the spacetube
* Visual signifiers of grouptalk mode
* Change tube settings
Security
* End to end encryption support. Currently spacetubes can only use private matrix rooms, rather than encrypted ones.
Self-hosting Support
* Docker image for those using docker for matrix hosting
* AppService installation guide
Tube Settings
* Spacetube help command
* Assigning pseudo-identities to connected groups
* Tube behaviour e.g. “Forward all”, “forward using command”
* Selecting grouptalk mode
Immediate Needs
Of the above list, I’ve identified the pieces of work that could best address the immediate needs as outlined in the user research analysis.
To recap those three needs were:
* Explanation of what spacetube is and what it does
* Simpler and clearer group setup
* Grouptalk affordances that are close to what users are familiar with.
Explanation
This involves diagrams, analogies, videos, examples and any other way to explain what the problem is that spacetube sets out to solve, and the way that spacetube accomplishes it.
I have a set of diagrams already drawn on paper that I used in the development of spacetube to keep track of where messages were and what the various appservice-controlled users were supposed to have access to. I can adapt these drawings for the documentation.
The output of this will be comprehensive instructions and user information on the spacetube website.
Simpler Spacetube Set-up
The current system of setting up a spacetube, while less involved than it used to be, could still be simpler and easier.
The web interface has the most potential to be user friendly, because it has the most latitude for customisation i.e. there can be buttons and labels for specific functionality. This piece of work is defined as enabling a user to go through the web interface to create tubes and invite other users into the rooms.
The interface can also create a link for a user in a different group to minimise the amount of set-up on their end.
The initial user can also have the option to send invites via matrix user id.
Grouptalk Affordances
From the user research a few options for how to manage the grouptalk came up.
A role system with “drafter” and “approver” roles for sending messages on behalf of a group.
“Speaking stick” method, where one user has the ability to send at any one time, and then this ability is rotated through the group.
Quorum of approval, where any user can suggest a message, but some number of other users approving the message is required before it’s sent.
These modes can be selected from when a group is first created and switched between by a group admin in the tube settings.
Summary
The user analysis and domain expert interviews were very helpful in determining the next pieces of work that spacetube should engage in. Documentation, enabling less technical set-up and developing the grouptalk system further were identified as the priority pieces of work.
Once this work has been completed, I will return to the question of what would best serve the users and potential users of Spacetube.
Appendix
Some other items that came out of the user interviews or development experience that could be expanded on.
Pseudo-Users
Necessity for single-threaded groups. Many chat groups are single-threaded for whatever reason.
Can also make it easier to understand what’s going on, if you can address the pseudo-users, or predict how they’ll act on your behalf. “Ambassador” rather than “tube-service-bot”. Or sending a message that starts with @groupname rather than !spacetube send
Group Preparation
The group formation interview was very interesting. This is a new way of communicating and people need some guidance on how to proceed, especially if they’re mindful of their status within a group.
Group formation techniques, set-up instructions for the human element of spacetube i.e. developing group voice and personas. This is mostly informed by the interview with Chris, which I can summarise as:
* Sharing individual starting point
* Building the habit of listening
* Discussing the group dynamic
* Agreeing a communication plan
A template could be provided of what to talk about as two groups, with prompts to suggest avenues the conversation could go down. Group conversation being somewhat new, I will look into existing ways groups interact, most of which are formal agreements or co-signing statements and partnerships.
Group Formation and Preparation
* What is our group? How does our group speak? Who wants to be a spokesperson? How do people feel about having a spokesperson?
* What is the happy version of our group? What is the servile version of our group? How does our group act when it’s energised? How does it act when it’s depressed?
This system is intriguing but also socially innovative as well as technically innovative, making it riskier to pursue at the same time.
Technical Debt
There’s two ways I can identify that the actual software could be improved, making the developer experience faster and less error-prone:
* Rewrite the app service and web application using TypeScript and React
* Add unit tests
Platform Integrations
There has been existing work on platform integrations, namely discord and whatsapp. With spacetube currently an experimental system, it makes more sense to focus on the core features within the matrix ecosystem. It also aids the development of open source systems more to add features to them, rather than closed systems.
The warmaster and his assistants generating the turn order
The Optimistic Nihilists Rising From The Dirt