Although once little more than an academic endeavor, the RISC-V architecture is slowly supplanting applications that would have normally gone to ARM. Even a few microcontrollers have chips running this open-source instruction set now, and we expect it to grow in the future since it doesn’t require the licensing of an ARM or x86 chip. [M_Jagadeesh97] is getting ahead of the curve with this retro gaming system built on a custom-designed RISC-V system.

Most of us, presumably including [M_Jagadeesh97], don’t have access to chip fabrication tools, but what we can get is any of various FPGAs. This RISC-V CPU is built on a Terasic DE0-Nano board with 32 MB of RAM available to it, and boots to a launcher with 32 games available. There are a few limitations with this low-power system which was largely solved by limiting the display to 64×32, which lets it maintain the same aspect ratio as the original DOOM as well as the same aspect ratio for many of the older games, while still maintaining 45 FPS.

The project writeup goes deep into the design of a system like this, from the bare metal, the CPU design, the timing of the video signals, and how to implement a Wolfenstein-like raycaster. After adding a small display it looks to be fairly portable as well and is an excellent demonstration of how powerful inexpensive boards like this  FPGA can be with the proper amount of effort.

Although not technically the first virtual pet, the Tamagotchi handhelds certainly popularized the idea and made it a worldwide phenomenon. In the late 90s it was hard to go out in public and not see them dangling from backpacks and belt loops. They turned out to be more than a passing fad, too. There have been Tamagotchis in various forms since then, and one of the latest, the Tamagotchi Paradise, is uniquely hackable thanks to this custom UART interface.

The build starts with a simple and inexpensive CH340G UART adapter with a built-in USB interface. A custom 3D printed enclosure is used to house the adapter and also help to expose the interface to the Tamagotchi. This is done by wiring three pins to nickel strips, which are threaded through slits in the case and looped back around to create a pogo-style adapter for the Tamagotchi’s custom dock. Normally this would be used to link to other Tamagotchis, but in this case the USB-to-UART adapter mimics it, allowing for all kinds of in-game shenanigans. The project’s creator [Squalius] shows it off by connecting it directly to a browser tool in Google Chrome.

Not only that, but this can also be used to modify the software running on the handheld entirely, with the video showing demos playing not only Super Mario but also DOOM (of course). This isn’t too surprising given that these games are built with modern 32-bit ARM microcontrollers. For the 90s purists, though, it probably won’t surprise anyone to know that these devices have been the subject of various hacks almost since they came out.

A few years ago, [Smashcat] ported a ZX Spectrum game called Manic Miner to the Arduino Uno. The Arduino has less memory than the original Spectrum did, so doing all this on an 8-bit microcontroller was no easy lift. Since then, parts of this original port have been adapted to produce a game engine, allowing [Smashcat] to port several other games to the Arduino Uno as well.

The engine is able to host a 2D map with the ability to scroll, at a resolution of 256×256, as well as up to nine sprites at the same time. The graphics are locked to 50 FPS, but only with a real Arduino Uno that has a crystal oscillator. Some replica boards do not have a timekeeping chip accurate enough to replicate the video signal, which is done without a framebuffer. That signal, as well as two PWM audio channels, are still generated directly as well, with only a few resistors needed to hook everything up to a monitor and a controller, including the option of using an NES controller.

With all of that running on the Arduino and it hooked up to the daughterboard that provides the controller interface as well as the resistors for the video signal to function and a driver for a speaker, the system now runs the original Manic Miner as well as three other games: Scramble, Space Invaders, and Pac Man.

The engine and the rest of the code are available on a GitHub page as well, and there’s even a WebAssembly version available to run various pieces of the software without the specific hardware. The original ZX Spectrum was an interesting machine too that still inspires builds like this, despite it being well over 40 years old now.

The Kernel-based Virtual Machine (KVM) allows Linux systems to function as hypervisors without needing any extra software, but VMs created with it don’t behave exactly like real hardware does. Sometimes that’s important, though, so [sandwich] built a tool called vfio-native that obscures the fact that software might be running in a virtual machine.

There are plenty of the ways that virtual hardware differs from bare metal. The VM may behave slightly differently for obscure instructions in ways that are measurable, it may take slightly longer to perform some tasks, or the hypervisor may simply announce itself directly. vfio-native includes some kernel patches that solve some bugs which address the different behaviors, changes the way that the kernel identifies itself, and attempts to force the CPUs to behave in ways that real hardware would behave. With all of this applied to the virtual machine, it scores a 1/85 against a VM detection tool, with a standard KVM virtual machine scoring 10/85.

For anyone looking to test this out, it’s available in the AUR for Arch Linux. Also, it’s probably worth mentioning that there are more reasons to use this than cheating at Counter-Strike. For example, security researchers testing malware need to know how that software behaves when it thinks its on real hardware, and some may behave in benign ways when confined to virtual machines. Some licensed software also may disable itself when it detects its running in a VM, which can be a nuisance for things like software controlling industrial tools which only run on operating systems that are no longer maintained or hardware that can’t be found anymore. Some other tools we’ve seen before perform similar tasks as well.

Some of the first remote controls available to consumers used sound, visible light, or even just wires to communicate with their parent device. It was many years between these first rudimentary remotes before they standardized around infrared or RF signaling. Even then it was a while before remote controls were reliable enough to not have to think about anymore. They’ve gotten so good now that there are small modules available that let us quickly build these devices to perform all manner of tasks.

[Igor Brichkov] is demonstrating this project because his garage door remote control suddenly stopped working. The RF receiver and transmitter circuits are readily available and inexpensive, but they need some support circuitry to work properly. The transmitter is paired with an encoder which is provided a binary code by wiring various pins to power and ground. This “code” is sent to the receiver which has a decoder and listens for that specific code. When the codes match it changes the state of one of its pins, which is used in this case to short the garage door’s remote terminals and signal it to open the door.

Although the resulting handheld remote with its single button looks a bit like something from 1950s science-fiction, it’s an effective solution. Especially when compared to possibly trying to reprogram a proprietary remote, find one from a company that doesn’t exist anymore, or rebuild one that operates on a bizarre frequency. With access to the physical hardware, it turns out a lot of things are controlled by just shorting pins together, and anything can do that from wires to RF transmitters.

These days we take high-speed networking for granted, but it can be difficult to get vintage computers talking to modern machines. To help solve this problem [jaime] came up with Meatloaf which can provide files to a Commodore regardless of their location or medium of storage.

Meatloaf is an ESP32 device at its core, which plugs in to any of several Commodore computers through their IEC serial port. Many similar systems exist to bridge the gap between the modern world and the now-retro one, but this one connects to a dedicated service which points towards files no matter where they’re stored. There is some local storage, but it can also retrieve files from any active URL, and Meatloaf retrieves the files and then sends them to the Commodore over that serial link.

Part of what makes this unique is that the user doesn’t need to configure Meatloaf in any particular way, everything is done from the Commodore as long as the URL is known to the user. The system can even parse nested files like archive file types and send them along to the computer just like it would if they were on a period-correct floppy drive. There’s a GitHub project page as well for anyone looking to get into the weeds of this serial data interface.

The style and sound of older video games is unique enough that they’re still copied in relatively modern games like Undertale, Celeste, or Shovel Knight. There’s also a vibrant chiptune community making music on the older hardware directly. Often this involves hardware modding or otherwise finding chips from older gaming systems to replicate that unique retro gaming sound authentically. But disassembling older systems is not always necessary. Take a look at this Game Boy Advance synthesizer which uses the GBA hardware with no modifications at all.

The key to making this work is the GBA’s multiboot feature, which allowed these systems to send executable code over a link cable to other consoles which didn’t have cartridges. This meant that friends could play multiplayer games without each one needing their own cartridge, but it also means that nowadays people can send their own custom software directly to the console’s RAM without much extra effort. To run the synthesizer software, the GBA is connected to a computer, the software is started, and then when the GBA is powered on the snythesizer is automatically loaded into its RAM. The audio output is played over the headphone jack, and various controls are available on the computer and on the console.

In the video linked below, [Andy] is using the GBA with some other musical hardware and the sounds he’s getting from the unmodified console are impressive. It could certainly be a go-to for anyone interested in getting started in this style of music or who doesn’t want to do something like take apart an original Sega Genesis for the audio circuitry.

One of the major limits of mass-produced batteries is the electrolyte. From lead-acid to lithium ion, there’s some temperature where the electrolyte will freeze and cause all sorts of problems, from cracked casings to various non-favorable chemical changes in the battery itself. But if there’ a solid electrolyte available, many of the downsides of charging and discharging batteries in extreme cold disappear. These batteries developed by NASA, for example, can survive some wild temperature swings.

The electrolytes used for these batteries are either a ceramic or polymer electrolyte, both of which are solid. In testing, the batteries could meaningfully operate at temperatures of -60° C and up to 80° C on the high end. Further, the solid electrolyte helps protect them even outside of these temperature ranges. Bringing the battery temperature down to -170° C was not enough to damage the battery at all, and using a small heater to bring the temperature back up to its operating range showed no capacity losses or other issues.

These batteries are eventually intended for use in some of the coldest places outside of Earth still accessible to humans (in theory) such as the south pole of the Moon where the temperatures regularly get that cold and stay cold for long periods, especially in permanently-shadowed craters or places on the Moon we might want to put some telescopes eventually. There are other terrestrial situations where these batteries might be useful as well, since they don’t need as much thermal management as other battery types.

For as many sensors, cameras, and computers as there are on modern cars, they ought to be a dream to poke around in and customize to one’s liking. Unfortunately they’re generally plagued by the same locked-down, proprietary software that most consumer electronics ship with, making it very difficult to interact with these systems in ways the manufacturer doesn’t approve of. There are a few exceptions to this rule, though, and [Sasha] built this system which backs up the footage from their electric car’s on-board cameras automatically to a NAS.

The system is built around a Raspberry Pi Zero 2 W which plugs directly into a USB port in the car’s glovebox. To set it up, the software only needs to be flashed onto the Pi and then it can be controlled from a smartphone. It can connect to any NAS over a variety of protocols and keeps track of what footage has been backed up, and can even automatically restart a backup if the car drives away before it has completed. It also automatically frees up space on the car’s internal drives by deleting any files that have already been synced to the NAS. All of the data is kept in the user’s control as well, and nothing leaves the LAN unless the user sets up backups to a cloud service on their own.

If you have the correct electric car and a Pi other than a Zero 2 W, [Sasha] also has a package for other Raspberry Pis that should work. Unfortunately this was designed for a specific electric car; other makes and models won’t work with this out of the box, but we hope that won’t stop others from checking out the GitHub page anyway trying to figure out what’s going on under the hoods of their car’s electrical and computer systems. Sometimes this leads to things you might not expect, like using the car itself as a video game controller.

When most radio enthusiasts start trying to pick up signals from satellites, they might put together a quick-and-dirty Yagi antenna and try to catch a repeater as is passes overhead, or they might grab a small unused dish from a satellite TV service and point it up at a weather satellite by hand to try to decode some of the data coming down. But [Cranktown City] had a different approach. He found an eight-foot dish online and built a massive articulating base station out of it as his first exploration into the world of satellites.

The first problem that needs to be solved with a dish of this size is its mounting location. This installation uses a large post and concrete foundation with a custom-fabricated metal base at the bottom. The metal base houses all of the electronics not just for receiving signals from the dish, but also for orienting it properly. That includes a large metal gear driven by a wheelchair motor to control its azimuth and a linear actuator to take care of its elevation. Getting the large dish onto the frame was its own ordeal, complicated by the fact that it’s not uniform in its shape and has to be mounted in a specific orientation.

With everything assembled, the circularly-polarized antenna installed, and the computers up and running, the dish is able to track satellites across the sky and download data from things like GOES weather satellites. [Cranktown City] also built in a system that detects wind and points the dish vertically when it goes above a certain speed. This level of effort is impressive, and absolutely not required to listen in on plenty of sattelite activity out in the sky, but this installation will certainly give [Cranktown City] a lot of mileage and possibly even work for some radio astronomy.

Bicycles are the ultimate form of transportation freedom. They’re easy to repair, parts are cheap, and they will travel almost anywhere for free, as long as the rider has enough calories. Their only real downside is dealing with car-dependent societies, but once a year there’s a place in the American desert that eschews all of this and [Attoparsec] decided to take this custom cargo bike modified into an RV out to Burning Man, a place and time that would be perfect for a build like this.

The build started out as a cargo bike, but not many of them have cargo areas long enough to support a sleeping human. To increase this storage capacity, the bed was extended towards the rear. Without moving the axle further back, though, this created a problem with tail-heaviness so two trailer jacks with wheels were added to the back to keep it from occasionally tipping up too far. The sleeping enclosure was built with rigid foam insulation and taped together, in a modified style common to the Burning Man event which helps keep out sun and playa dust. The bicycle recived one last upgrade to the chain to support the extra weight, and a solar-powered refrigerator, and then it was off to the desert.

The bike RV worked well in the end, and even handled a rain storm without the roof leaking. There were some problems with the customized drive train which were solved in the short term by pounding on one of the wheels occasionally with a hammer. [Attoparsec] left the event early for other reasons, though, and might not be back for a while. But vehicles like these are gaining in popularity, presuming there are safe places to ride them. [Paul Elkins] is often making ones like this gas-powered bicycle and trailer camper.

Meshtastic has gained a lot of popularity over the last few years thanks to its low barrier of entry. No licenses are needed and the hardware is dirt cheap, at least when compared to a lot of ham radio gear. But while that physical barrier is low, there is a bit of a learning curve. Part of that comes from the fact that there are a lot of channels and modes that people could be communicating on, and unless the user knows that information up front it can be hard to find where the conversations are happening. [cemaxecuter] noticed this problem and built a Meshtastic sniffer into his radio-forward Linux distribution, DragonOS.

The sniffing software is built in C and comes as a complete standalone binary and does not rely on GNU Radio. With DragonOS up and running and the software loaded, it can look at the entire bandwidth that Meshtastic operates on and detect any traffic and decode it (as long as the key is known). [cemaxecuter] is using a HackRF as a software-defined radio for this project, which he notes doesn’t quite have enough bandwidth to cover every Meshtastic operating frequency, but it can get most of them. After firing up his own node, the software quickly detects it and shows its details in the terminal.

Software like this opens up a lot of opportunities for things that would be tedious, difficult, or impossible to do with with a standard Meshtastic node. Besides finding places where conversations are happening more easily, [cemaxecuter] also suggests that it could be used for wardriving and for locating or finding other networks much more easily. For those who still haven’t tried it out, take a look at this 2023 treatise on the protocol and hardware and then dive right in.

Refrigeration has been a challenge for humanity since the start. Ancient civilizations in dry climates like Persia and Egypt could use evaporative cooling on a large scale with specialized architecture, and with easy access to electricity modern civilization can cool down almost anything it wants. But whether in a refrigerator or heat pump, the electricity demands can get out of hand quickly, and heat-driven systems often require dangerous or hard-to-get chemicals. But [Greenhill Forge] has crafted a system that creates effective refrigeration with only fire and salt… and a bit of electricity.

Heat-driven systems are called absorption coolers. In this design, water is used as a refrigerant and forced to a very low pressure so that it can boil at a low temperature. When it boils it absorbs heat from the surrounding environment, and then that water vapor can be moved and condensed where it gives off that heat. The build has a few distinct loops to make all of this happen. The generator loop holds the heat source and a tank of water mixed with road salt. Boiled water travels up a tube to a condenser. A valve here is opened slightly to allow the water to drip into the absorber section, where it is under low pressure and boils rapidly. The vapor is carried away by the third system, which uses a shower of the salt solution to quickly suck up the vapor and move it away from the cooled area.

There is a small amount of electricity needed to run pumps and fans, but to keep this off-grid this requirement is easily met by a small solar panel or battery. The bulk of the energy is from the fire which boils the saltwater solution. [Greenhill Forge] added a number of temperature and pressure sensors to monitor and control the system as well, and in his firsts tests the refrigeration system was able to get to about 5° C with an ambient temperature around 16° C. That’s not quite the temperature needed for a refrigerator, but not bad for only salt and fire. [Greenhill Forge] has a number of other ingenious off-grid builds like this sawdust stove and a magnetic induction water heater.

Text messaging has been around on cellular networks en masse for around three decades now. It’s so common that it’s difficult to remember a time without it. Its two-way quick messaging is incredibly useful, but for even simpler communications there’s a one-way system that predates it. Pagers are able to receive simple messages, but outside of hospitals are rarely used nowadays. Eventually some added in two-way communications like this Motorola T900, but they’re still mostly obsolete. That’s why [zindustries87] converted it to operate on the Meshtastic network instead.

To get this pager working, a lot of reverse engineering was needed. There is essentially no documentation on the chips in these devices, so the screen and keyboard both were reverse-engineered to work with other hardware. In this case, [zindustries87] found space for a Heltec V4 with an ESP32-S3, a popular Meshtastic node with a small form factor. Some programming was needed to get everything communicating together, but from the looks of things it seems to have basic functionality.

[zindustries87] points out that this is a prototype, and didn’t know going in if the keyboard and screen could be brought back to life, or if the other hardware would fit in the case. But with it working on this level, they plan to add a number of other features in and possibly build a drop-in PCB replacement for these devices. They were once fairly popular so there are plenty around, and they’re a good form factor for a dedicated Meshtastic device that doesn’t need a smartphone to work. The only other ways of bringing pagers back to life involve bootstrapping an entire pager network, and Meshtastic is a bit more useful than that now.

Those of us who grew up in the 70s and 80s might be familiar with the Atari 2600 console and its now relatively unrecognizable (by modern standards) controller with only a single button and stiff whole-hand joystick. By comparison, the Steam Deck has somewhere around 24 buttons and two joysticks depending on how they are counted. But even the Atari might be providing more user inputs than are really necessary for quality gaming. Take a look at the Dinoboy, a handheld console with only a single button.

Part of what makes this system work is that it’s playing the classic dinosaur jumping game first included in Google Chrome which loads when the browser can’t connect to the Internet, and the user’s single input was the space bar. In this case, the handheld has its single button where the user’s thumb naturally rests. The console itself is in two parts, hinged where the button is placed. When unfolded, the top half reveals a wide screen and the bottom half is held by the hand. The screen supports two color formats, a black and white style and another which replicates the dot matrix display of the original Game Boy.

The small handheld console has another trick up its sleeve too. [Paul], the system’s creator, built it as a way to stop doomscrolling so along with having this quick-deploying game on hand, there’s also an NFC tag hidden near the hinge which, when swiped passed a phone, also turns that phone’s airplane mode on. It’s a double-whammy of removing the gamer from the dark patterns and algorithms dominating the mainstream Internet. And, this isn’t [Paul]’s only dinosaur jumper console either. We recently featured a similar (but much larger) build of his housed in a classic arcade-style cabinet.

As a portable media player, Microsoft’s Zune simply couldn’t compete with Apple’s juggernaut iPod — the latter essentially becoming the de facto personal media player until smartphones took over. But in 2026 it might be Microsoft that gets the last laugh, as thanks to [rsheldiii] the Zune can now play Super Mario 64.

The software is based on sm64ex, and notably doesn’t include the ROM file necessary to actually run the game. But presuming a legal dump of a cartridge has been done, building and loading it onto a Zune HD is straightforward enough. From there the player is presented with a controller interface on the device’s touchscreen overlaid with the video output from the game. Some interesting things are happening in the background here as well, like using NVIDIA’s Tegra tools to pre-compile shaders so the 2009-era processor can handle the rest of the gameplay.

Although it didn’t enjoy the mainstream success of the iPod, the Zune was actually a pretty solid device, and even though the last of them rolled off the assembly line back in 2012, there’s still a fairly active userbase for it. Modern improvements have added Bluetooth and solid-state drive upgrades for them have been available almost since they were first released.

Flying and driving simulators can go as far as money will take you, and at some point it might end up being cheaper to buy a plane or race car than to keep adding capabilities to some of the sim rigs we’ve seen. But it can also be a fairly affordable hobby as well, with entry-level components being within reach for many. The price can drop precipitously from there too, provided some parts can be sourced and a 3D printer is made available, and [Jason] is demonstrating one of the lowest-cost H-shifters we’ve seen which only uses two parts at its core.

The two components only cover the electronics for the build, but this gets almost everything needed for the shifter squared away. A joystick like those found inside many game controllers is paired with an Arduino Pro Micro, with a very straightforward wiring configuration between them. These components are paired with a prototype 3D printed case and shift knob which provides the H pattern of choice. From there it’s as simple as uploading some readily-available firmware, which [Jason] also demonstrates, and which has many options for various configurations of shifters.

Although this was just a prototype, it shows was just a few off-the-shelf components and a 3D printer can provide to an affordable driving sim setup. Even then a 3D printer is not always necessary, like this three-pedal setup using extruded aluminum frame as a base. From there, all kinds of other features can be added like force feedback on the steering wheel.

The Internet, and large groups of people in general, tend to have a remarkably short collective memory. Whether it’s the nature of algorithms or the people themselves to always be chasing the next novelty, maintaining long-term engagement for even relatively small changes can be challenging. Distractions abound, and motivation tends to fade over time. This past spring, Discord’s unpopular decision to force age verification resulted in a brief flash-in-the-pan of outrage that dissipated when they promised to delay its roll-out. Rather than backtrack on unpopular policies, they’ve been slowly boiling the frog with incremental changes towards this same goal in the meantime. One of the options to deal with this is to migrate over to something like a Matrix server, which has a number of benefits over Discord including being open-source and self-hostable.

Unlike Discord, a closed platform subject to the whims of a private company, Matrix is a communications protocol and open standard. Its major server and client implementations are open source, so anyone can build tools around it and integrate it with other systems that also use this protocol. This protocol-vs-platform comparison mirrors email, which is another protocol that isn’t locked down by any one company, and which can easily be used to send messages across various providers. The most commonly used server-side software for Matrix is called Synapse and the most prominent general-purpose clients are the various implementations of Element, and my exploration uses these defaults.

Analysis Paralysis

One of the problems with choosing a Discord replacement for one’s family, friends, or online gaming community is that there are a huge number of options. In much the same way Linux itself fails to make a dent in the desktop operating system market, open-source and community-driven projects are relatively easy to code and release but difficult to market and build up a sustainable userbase. So, while there are platforms like Stoat, XMPP, and others which provide self-hosted text and video communication, many of these services have a very small userbase or have some other shortcoming, and on some deeper level it can feel like flipping a coin to choose between any one of them and their myriad of forks.

For me personally, my choice of Matrix over any other option was partially driven by the fact that it seems to have an active and helpful userbase compared to others, it has it has strong end-to-end encryption support which is generally enabled by default (for private chats), and it’s possible to host on computers that I own. Another big reason I picked Matrix to experiment with is that self-hosting Matrix is optional. There is a large and active server called matrix.org that functions as a default server of sorts, which allows almost anyone to sign up and start chatting without having to install anything other than a Matrix client like Element. In this way, matrix.org feels a lot like IRC in its golden age because these large servers allow mostly anonymous Internet users to communicate about various topics in dedicated chatrooms without any great effort.

Federation Is Also Optional

Matrix is often loosely lumped in with other “federated” social media like Lemmy or Mastodon because, like these ActivityPub-based systems, there is no central server like Discord or Reddit and no overarching authority policing the entire network. So a Matrix server can federate with other Matrix servers, allowing users on the two servers to participate in the same rooms and exchange messages. If one server goes offline or decides to defederate for whatever reason, that doesn’t bring down the rest of the network, although users and rooms hosted exclusively on that server will of course be affected. Federation is also optional, and independent servers for one’s own family or friends that don’t federate with any other server is just as possible as a large server federating with all of the major servers like matrix.org. Compared to Discord, this decentralized structure makes it much more robust to a single entity’s whims.

Although a different protocol from ActivityPub which is used for other federated social media, Matrix also has a bridging network that allow it to communicate with other platforms, including IRC and Discord, as well as numerous other messaging services. So, in theory, setting up a Matrix server doesn’t preclude anyone’s friends on Discord from communicating with them, and might make it easier to migrate a friend group to the more open platform over a period of time, rather than expecting everyone to pick up and move all at once.

Starting The Virtual Machines

To that end, setting up a Matrix server does take a little more effort than creating a channel in Discord. I have a Proxmox server that makes setting up new servers relatively easy, but the server- and client-side software runs just fine on most Linux distributions without the help of virtualization. To start, I spun up an LXC container to run Synapse which is easy enough, but only includes text and photo chatrooms on its own. I was able to make this available on the wider Internet using a Cloudflare tunnel at first. With the Cloudflare URL, encryption keys, and the Element clients on various machines owned by my family and friends, everyone was easily able to get in to the chat rooms and communicate, with full end-to-end encryption and with messages stored on a machine I physically control. If you’re following along and want to stop here with just text-based chat, that’s certainly a viable and simpler option.

However, this does fall short of matching Discord’s quick voice and video calling, and this is where Matrix server administration can start to get a bit cumbersome. The short story here is that, at the time I set up my servers, there was a legacy calling mode alongside a newer one, so to support both there were two additional servers that needed to be set up. The legacy mode needs a TURN server, and the modern voice and video calling system supported by Element generally needs a LiveKit server. Since I set up my servers, though, this architecture has been simplified with TURN becoming less central to typical Matrix servers.

The next hurdle for me was getting around my Internet service provider’s network address translation (NAT). This is part of the reason I started using a Cloudflare tunnel in the first place, but the free tier is basically only an HTTP/WebSocket proxy which has no way to accept the UDP connectivity that TURN and LiveKit normally require for media. To solve that problem I turned to a small VPS that I rent which has a public-facing IP address. (I actually put an OpenOSCAR server on here first, back when this project got popular, to test out its capabilities and get it ready for my Matrix server.) The TURN server is lightweight enough to run on the VPS directly, but LiveKit is much more resource-intensive than I’m willing to pay for. This means LiveKit has to run on my server, so I set up a WireGuard connection from the VPS back to its container on the Proxmox machine.

Part of what makes this setup a little more difficult than average, besides the NAT-induced headaches, is that even once these packets get to my router, which is also hosted on my Proxmox machine, they go to a DMZ on a separate VLAN in my home network so that public-facing traffic can never get through to the rest of my LAN. But that DMZ includes a number of other public-facing services which are managed by an nginx server, adding yet another layer to this onion of a system. So between the support services for the Matrix server, the network layers, the off-site VPS, and the Matrix server itself, my setup involves six virtual machines, some interaction with Cloudflare, and one additional (albeit relatively inexpensive) paid service. This also doesn’t count the services I run on the Proxmox host and in other VMs to monitor web traffic and improve network security.

Even this setup, once I spent a considerable amount of time troubleshooting, has its downsides. For some reason which still eludes me, users on iPhones running the Element X client are randomly unable to send picture messages to chats. Occasionally a service on one of my many VMs will fail and need maintenance, and this seems to only happen when I’m not near my laptop. But perhaps most notably is that my Matrix server still doesn’t federate with any others. This isn’t really a problem as much as it was a conscious choice, though; it’s something that’s possible with a public endpont of some sort, so it’s my VPS makes this an option for me, but I haven’t attempted it yet. Mostly this is because the people on my Matrix server that actively use it are family members who don’t need or want that kind of exposure to the deep Internet, and my broader experience on matrix.org was often marred by things like crypto scams and generally desolate chatrooms.

All of This Has Happened Before, and All of This Will Happen Again

If you’re still with us after that extremely convoluted journey, it might seem like this is a lot to ask to replace a free service that’s been fairly instrumental in making it easy for gamers to interact with each other over the Internet and which has also revolutionized online chatrooms (for better or worse). But they have demonstrated time after time that they’re willing to slowly erode user trust, privacy, security, and experience in favor of shareholder value, and as they start rolling out “features” like age and identity verification they introduce more categories of sensitive information that are stored somewhere, and more potential points of failure. Given the long history of major companies failing to protect user data, it seems inevitable that someone will eventually make a mistake and expose information that users never expected or wanted Discord to collect in the first place. So for those who still have intact memories of Discord’s prior attempts to implement extremely unpopular policies, or even memories of other companies who have failed to protect sensitive user information in the past, a Matrix server might be worth the attempt.