This is going to be a long post, so I took the liberty of adding a Table of Contents.
Table of Contents
- Overview of the idea
- Technical details
- If you don't care about the technical bits, skip this section and click the next one!
- Setting up your Space
- How to play
- How to pick a system
Overview
Back in the day, I was introduced to ttrpgs by a friend of a friend. He invited me to an IRC Channel, sent me a PDF character sheet for a D&D 3.5e character. He said “Don’t worry, you’ll have fun and figure it out”.
I didn’t have fun and I didn’t figure it out. It was a bad intro to TTRPGs. It turned me off of D&D and the whole world of TTRPGs for years.
However. . .
Thinking back on it, it seemed great. It was basically a VTT, but entirely theater of the mind. The DM described where each player was and asked the player what they wanted to do. The version that they played was live, like people sitting around a table and playing. However, while digging at the time, I found groups that play full on TTRPGs completely asynchronously. The players just said what they wanted to do, and then waited for a response. It was akin to play by mail. The conversation around it was usually ongoing in other channels, but the main thread of play was “stopped” while every one waited for the next action.
This sounds ideal for a modern game group, especially with some of the lighter-weight systems that have gotten popular. So I set out to make one.
Technical Section
Look, I know not everyone is as technical as I am. I write emulators for 50-year-old CPUs on Twitch. However, when I tell you that it is dead easy to run your own Matrix server, I mean it. I think anyone with a reasonable amount of knowledge about computers could do it. Whether you should is another story.
Now, it is trivial to get a hosted Matrix server, and most people, even the technical ones, should just do that. You don't even need your own instance, really, you could set up a Space on an existing instance. You do you! If you choose to do that, you can skip forward to this section
For the rest of you nutjobs, here's a very brief crash course. To be very clear here, this is more meant to be a reminder to me about how I set it up. It should work for you, too, but know that you're probably not the primary audience for this bit. Unless you're me. Hi me!
Getting the Server Running
The only requirement for this section is that you have to know how to open a terminal. On Windows, you need PowerShell, not Command Prompt.
The easiest way to run a Matrix server is to have Python installed already. If you don't have Python installed (I dunno, maybe you're on Windows. Don't run servers on Windows), go install Python. The best way to do that in 2025 is with a program called uv. Fortunately, installing uv is simple on every platform. Once uv is installed, it shouldn't matter what OS you're on, every command will be the same. I think.
Next you need to install your python version using uv. You shouldn't need to use a specific version.
Once you have your Python installed, you're gonna follow the instructions straight from the horse's mouth. We'll be using a Matrix server implementation called Synapse. This was originally created by the creators of the Matrix protocol itself, but is now maintained by another company.
We're going to use the “Pip Install” instructions, because they're better for our purposes, but we're going to do it slightly differently. We need to use uv instead of using the commands they use.
So, type:
mkdir -p ~/synapse
uv venv
source ~/synapse/env/bin/activate
uv pip install --upgrade setuptools
uv pip install matrix-synapse
After that, you'll need to run the bootstrapping script inside Synapse.
cd ~/synapse
uv python -m synapse.app.homeserver \
--server-name YOUR.DOMAIN.NAME\
--config-path homeserver.yaml \
--generate-config \
--report-stats=no
That last command will create a configuration file called homeserver.yaml. You're going to have to edit that in a text editor. Don't use Microsoft Word, and don't use Macos' Pages. Use Notepad if you're on Windows, Text Wrangler if on Macos.
Once you've installed the server, it's time to CONFIGURE IT! This part is the tricky part, so pay attention.
They have a section on configuring Synapse further down the same page. Note that they say some very hurtful words about SQLite, but the fact of the matter is that, unless you plan to run this for hundreds of people, you don't need Postgres. Also, I don't want to write a section on installing and configuring Postgres. If you wanna use Postgres, you're on your own. (I actually use Postgres, because I am a monster and I maintain my own production Postgres instance. Don't be me, your spouse will despise you.)
I'm going to give you a shortcut, and we're going to walk through it. So, fire up that text editor and open the file homeserver.yaml.
Most of this should be good to go already. Take a second to verify that the server_name you want to use is correct. Fixing an incorrect server name later is hard enough that it's better to just start over with a new server name than to try to fix it! Trust me. For example, the server_name for my instance is chat.bauxite.tech.
One thing you need to add is a single line which sets up the .well-known file for allowing you to sign into your instance with a client. This line needs to be at the “root level” of the configuration file. All that means is that it should have no spaces before the key (the thing before the colon). A good place to put it is directly below your server_name line.
public_baseurl: https://YOUR.SERVER.NAME
Note that this must match the server_name configuration, and it needs to include the https://, which is the URL scheme.
That's all you need to do to configure your Synapse server. In theory, you could just get started. However, there are lots of ways to customize the server, including adding third-party authentication (So you can log in with Google or Facebook or any of the other companies that give you a free service at the expense of your personal data). If you are going to allow other people to sign up directly on your instance for Matrix accounts, then you should do that. The nice thing about Matrix is that you don't need to have an account on the server in order to use rooms hosted on the server.
Cool, huh?
In a follow up post “eventually”, I'll give some tips on making this more “production-like”. Like I said earlier, if you're hosting this for a few friends, you do not need to do any of that. Just start the server with the synctl start command and follow the directions to make yourself an account.
Congratulations, if all went well, you have a server! Go find yourself a client (I like Element, it's “Good enough”), log in and read the next section.
Setting Up a Space
Fundamentally, what we're trying to accomplish here is akin to play-by-mail (PbM) (or play-by-post, PbP). Startplaying.games has a great little explainer on what that entails. The only difference between PbM and our little chat-based solution is that the gameplay loop is a little tighter. We have the capacity to have multiple little side stories going on that can't happen in PbM, since it is a more “ordered” experience.
So, let's look at how I set up my Space. The rest of this article is going to be more descriptive than prescriptive.
What is a Space?
If you are familiar with Discord, you know what a server is. A server, in Discord-land, is a specific community. The equivalent in Matrix is not a Matrix server. Don't mix those up! The equivalent is a Matrix Space. I have a Space called b4ux1t3 Has Entered the Dungeon which represents my game world. It's divided up into (for now) four Rooms:
We'll get to those in a second.
The Space is representative of a single “Game Session”. This is one group of players playing in the same canonical world. That doesn't mean that this is a “specific plane of existence” in the sense of D&D's planescape. It's more akin to a play group. The Multiverse is even vaster than players realize, since each game group technically exists in its own separate multiverse. A multiverse of multiverses. How's your brain? Mine hurts.
The Rooms
Adding a new Room to a Space is trivial, but it will be different for each client. Check out the manual for your chosen client for how to do it. Element's User Guide (in PDF form) is here.
Each room is a logical division that has semantic meaning.
Roughly:
The Tavern is basically the hub. New players join there, get their characters, and get access to the other rooms by joining existing quests (or starting new ones).
Out of Universe is your basic OOC chat. Technically I don’t have any rules against talking out of character in the other rooms, but it’s probably a good idea to keep chatter to a minimum so other players don’t lose track of what’s going on.
The Wilderness is, roughly, adventures that take place out doors.
The Dungeon is the same, but roughly things that take place “at places”.
Note that these are not discrete locations unto themselves (except maybe The Tavern). They are merely “themed discussions”, which roughly group players by the kinds of locations they're going to.
As an aside, I'm toying with the idea of adding a fifth room that acts as the actual staging area before players are shoved into The Tavern. It would act as an orientation room, where new players can learn and ask question about the mechanics of the game, get their characters made, things like that. It'd be a somewhat more focused version of the Out of Universe room.
Rooms are easy to add to spaces, so if you find yourself needing to add more rooms to be “specific places”, that's fine! It may also be worthwhile taking the old RP forum route and just actually map out your world with rooms. One room is the capital city of a continent, another is a player's home town.
I have the suspicion that that may get kind of overwhelming, though. For now, I'm going to stick with just these rooms.
Once you've set up your room structure, you're ready to play!
Okay, But How in the Hells Do I Play?
This is the part that I'm going to probably come back and edit as I find more gotchas and more “rules” to follow.
Generally, though, my plan is to find a few adventure modules that make sense for my given setting (We'll talk about settings and systems in a future section). These have the benefit of already being laid out, so I don't need to do any specific prep work. As a GM, you're probably already great at railroading your players, so just do that. 😉
The actual play is pretty straightforward. Players can explore the world, typing what their characters do in the section they are in. If they are setting off on a quest, for example, they'll put a thread or just a few messages describing the beginning of their journey in The Wilderness. Then they walk away from the computer, phone, device, whatever.
Yep, you read that right. This method of play is not meant to be instant or fast-paced. It's meant for busy people who have stuff to do. I think this specific bit is going to be the hardest thing for some players to come to terms with.
You, as the GM, make your rounds every few hours (or just once a day, whatever, you have stuff going on, no biggie), checking the active threads and rooms, giving rulings, and describing new scenes. Then you walk away. You don't sit there and babysit it. Let people talk about things, let them make their actions, then realize that their action was a stupid one and retract it and do something else.
Note that I don't think it's bad if you and some players get into a little live session. The point is that that's not the default.
I'm considering building a bot for Matrix that allows someone to catch up on all of the new messages since they were last active with the Room specifically to support this style of play. That said, if the group is small enough, it shouldn't be that hard to catch up. That's also why I'm keeping the number of rooms fairly low. It's only a few places to check.
This format is going to require a few soft rules to keep it working. For example, you may or may not want to outright “ban” OOC discussion in the adventure rooms. There's the case to be made that it's more immersion breaking to be told you can't talk in-situ about what's going on, but there's also the case to be made that someone accidentally talking about the wart they had removed in the middle of combat could be worse.
As far as I know, most Matrix clients support Markdown syntax for styling text, so it may be worthwhile to encourage players to make in-situ OOC talk demonstrably different with italics or even some character string indicator (Like double parentheses: ((LOL, ridiculous!))), or some combination of those.
This is also why I think it's important to have a specific, dedicated space for OOC discussion. That space should be focused on the game, but it doesn't need to be in character and it doesn't need to be beholden to the “physical layout” of the world like the other rooms are.
In some situations, it may make sense to add time-boxes to the situation at hand. Maybe certain locations have time-based traps (a rising sea of lava, e.g.) that really requires the players there to work together to survive. Don't respond in two hours, half a day, whatever? Your character get's lava'd! Alternatively you may just have to take over a PC sometimes to move the action along. Do not do this unless everyone is aware that it can happen, and only do it if you absolutely have to. Probably.
On that note, though, it may also be worthwhile to adjust how you use your system's death mechanics. Again, I haven't done this yet, so we'll see how this plays out!
Wait, That's It?!
That's it. That's all I have for you, at least so far. Watch this space (or at least this blog) for more about what I discover as I explore this concept myself!
One last final thought is that this concept might work well with multiple GMs running it. As long as everyone agrees on some ground rules, this can help speed up the gameplay loop pretty significantly. Maybe.
How to Pick a System
I think most modern systems would work well in this format. For very mechanic-heavy and statistic-oriented games, it has the benefit of allowing players to really think through their actions, and play min-max meta games to their hearts' content. (Not to mention that the GM has all the time in the world to “Hold on, let me look that up”.)
For more rules-lite games, it has the benefit that players can be drivers of the story. There are game systems out there where the GM is basically a referee for the players. Blades in the Dark comes to mind. It's conceivable that you could have a server running Blades in the Dark with no GMs, just a bot or something that utilizes an oracle system. I want to try this.
In the end, the point of this kind of gameplay is to explore a story, to build a world together. It's up to you as the GM to provide the sandbox, to flesh it out, but it is your players who will be making the story. This is not something where railroading actually works, despite my joke earlier.
Conclusion
I think this has the opportunity to enable some very fun play for a lot of people that may not have the time (or energy) to play TTRPGs, whether in person or online. The time investments required by players are minimal, and even the GM can lean heavily on the asynchronous nature to get things ready for their players while the players are doing other things.
I have said more than once that this is a new thing to me. I haven't done any of this, and I have specifically avoided looking up how this has been done before. So, if you've read all this, I really, really appreciate it. I'd also really appreciate feedback! You can hit me up on Mastodon, or on PhD20's awesome TTRPG forum, where I have a thread going about this concept.
When I go live, a link to the Space will appear here. 😁
In my next post, I'll share how I plan to inboard new players.