diff --git a/2025-03-27.multi-user-x11-shenanigans.md b/2025-03-27.multi-user-x11-shenanigans.md
new file mode 100644
index 0000000..3b61297
--- /dev/null
+++ b/2025-03-27.multi-user-x11-shenanigans.md
@@ -0,0 +1,80 @@
+# Multi-user X11 Shenanigans _(feat. `ssh` and PipeWire)_
+
+Generally I avoid putting any files or applications which have to do with my work on my personal computers; however, after a hardware failure and a shipping delay left my work machine unusable for several days, I realized there were some minimum tasks which _REQUIRE_ I install the chrome web browser, slack, and a couple of other efficiency / office tools.
+
+I realized that [X11 forwarding](https://wiki.archlinux.org/title/OpenSSH#X11_forwarding), which I've used for some gui-required remote applications, might actually let me run the application _with an underprivileged user_ while still _using my same desktop_.
+
+So: easy-peasy!
+Slap the `-X` flag onto `ssh` and we _should_ be off to the races.
+
+With google chrome securely installed to the user, `ssh -X work-user@localhost` seemed to work immediately!
+I slapped this in an easy-to-find, launcher script on my `PATH` and quickly added slack and the other tools.
+
+BONUS: I could set the _default web browser_ for this user to be google chrome and then clicking links in slack would automagically open the work user's chrome without adjusting my _personal_ defaults!
+
+## Problems tho
+
+At least it SEEMED like everything was working immediately.
+I ran into two sticking points.
+
+### Clipboard?
+
+Clipboard seemed to work... one way!
+Anything I copied from applications on my main user pasted just fine into the application, but I couldn't copy things _from_ google chrome.
+I tried to figure out why, but then eventually [tried **`-Y` instead of `-X`**]( and it just worked.
+Something something trust me bro (says both X11 and the Arch Wiki), so I stopped trying to figure it out since it seemed like a WAY deeper dive than I'd hoped.
+
+So since I wanted the clipboard forwarded (and I suppose the localhost, I'm-managing-this-user-myself level of trust seems _Fine by me_), I just swapped them all out for the `-Y`
+
+```
+# somewhere conveniently in my PATH called "slack"
+#!/bin/sh
+ssh -Y work-user@localhost -C slack
+```
+
+### Audio... but only on SOME setups
+
+On one computer, audio worked just fine!
+When I went to propagate this to my secondary personal, however, I ran into a weird issue where the USB audio card just wasn't available in the `ssh -Y` environment.
+It took me a bit of digging through "Help me, I have no audio at all" articles (a Linux-forum CLASSIC), before I finally found some articles talking about some oddities when sharing audio through simultaneous users.
+
+Let me just admit that I know _very little_ about the whole Linux sound ecosystem.
+When the Arch Wiki told me to switch to PipeWire... I did.
+Especially since there's ["support for PulseAudio"](https://wiki.archlinux.org/title/PipeWire), and it worked out-of-the-box with all the weird audio-controller scripts I've written over the years, I had little reason _not_ to mindlessly upgrade to the new, improved(?), low-level multimedia framework.
+
+SO.
+From what I understand:
+- [PulseAudio](https://wiki.archlinux.org/title/PulseAudio) is a _server_ which serves as a higher-level interface to PipeWire
+- [PipeWire](https://wiki.archlinux.org/title/PipeWire) is the low-level audio framework which runs a separate _session_ for every _user_, initializing PulseAudio or other servers as necessary
+- _some_ audio interfaces (particularly the integrated ones) can be seamlessly used across several servers & sessions
+- ... but not ALL of them
+
+After trying the recommended "make sure everybody is in the `audio` group" and "make sure your PipeWire is configured right" and "make sure you restart all the `pipewire` and `pulseaudio` services" and what felt like dozens of useless, unhelpful suggestions, I finally landed in the right place.
+Apparently my USB device was reporting "busy" to the work user's audio configuration (no thanks to the SUPER helpful error message `audio open error: Device or resource busy`).
+We can _fix_ this by making sure the `pipewire` instance for the work user is configured to point to the _same_ server being used by my primary user.
+
+Two pieces to that:
+#### 1. Enable PulseAudio server forwarding
+
+I managed this with a _PipeWire_ configuration file:
+
+```
+# under the PRIMARY user
+# ~/.config/pipewire/pipewire-pulse.conf.d/share-audio-with-other-users.conf
+
+pulse.properties = {
+	server.address = [
+		"unix:native"
+		"tcp:4713"
+	]
+}
+```
+
+#### 2. Use the forwarded PulseAudio server on the other user
+Since I'm literally never going to log in to this user any other way, I adjusted the default configuration (but I think you can achieve the same thing with the [`PULSE_SERVER` environment variable](https://wiki.archlinux.org/title/PulseAudio#Environment_variables)):
+```
+# under the WORK user
+# ~/.config/pulse/client.conf
+
+default-server = tcp:127.0.0.1:4713
+```