Two Hours With Buzz: Notes From a RaidGuild Spike

We spent two hours spiking Buzz with a couple of developers. That was enough to get a self-hosted community stack running, find several real client issues, and decide it was worth a wider test. We are now kicking off a two-week RaidGuild community experiment. This is the recap of the spike; the verdict comes afterward.

Why we tried it

Buzz is an early, Apache 2.0-licensed workspace where people and local agents share rooms. It uses Nostr for messaging and includes Git and observable agent workflows. Those claims come from the official README and architecture documentation. Our interest was practical: could we host it ourselves, connect it to our existing systems, and get a few Raiders working in it without committing the Guild to another platform?

The short answer from the spike was yes, with caveats. Setup was manageable, the code was moving quickly, and the rough edges showed up immediately.

What we deployed

We self-hosted the community stack on Railway. A few community Railway templates already existed, but the ones we found looked behind the current Buzz topology. With some small configuration changes and robot assistance, we got a working deployment together quickly.

By the end of the spike we had demonstrated relay restart persistence, client reconnection, private object storage, pairing, adapter delivery, checkpointing, deduplication, and Prism Memory ingestion. This was no longer just “deploy Buzz and look around.” It was a working community stack we could hand to more testers.

We kept one boundary explicit. Buzz membership does not grant authority inside Prism. Buzz is the collaboration and event surface; Prism owns organizational memory, reviewed knowledge, durable workflows, credentials, and policy. Private agent context also stays separate from organizational memory.

What we liked

The code is open and self-hostable. We could inspect the stack, change it, and keep the experiment under our control.
Local agents operate in shared rooms where people can see the work happening instead of sending prompts into an invisible bot process.
Git support and agent workflows live close to the conversation that starts the work.
Standard messages, links, and threads remain compatible with official desktop and mobile clients even when our fork adds optional features.
The upstream repository is actively maintained. During our short test window, the desktop client moved from 0.5.1 to 0.5.2 and several problems we encountered changed underneath us.

What broke

Linux exposed the most obvious client problems. Huddles could not access the microphone or camera because media streams were disabled in the WebKitGTK webview. Notification sounds also failed because desktop playback depended on browser behavior that did not work correctly in the Linux client. Invite and pairing flows were changing at the same time, which made onboarding harder to evaluate against a stable version.

The video experience is still not something I would call ready for routine Guild use. Installation also asks more from a new participant than clicking a Discord invite. Those are meaningful costs for a community tool.

What we fixed and learned

Our RaidGuild Buzz fork now carries a Linux Huddle media fix and native Linux notification audio, including cancellable sound previews. Invite and mobile relay behavior also improved as we synced current upstream work around the 0.5.2 release. The distinction matters: some fixes came from our fork, while others arrived through an upstream project that was moving quickly during the spike.

Building the Linux client gave us a useful rollback pattern. The host machine lacked the GTK development libraries, so we built the .deb in a reusable Ubuntu container and reused the existing sidecars. We extracted each build into a versioned directory under ~/.local/opt and switched a buzz-current symlink. The running client kept using its old executable until restart, so testing a new build did not interrupt the session and rolling back was simple.

The pull-request process was useful too. Automated review caught a real playback-cancellation gap in the notification work. An unrelated flaky end-to-end test was isolated by rerunning only the failing shard instead of treating every red check as evidence that our patch was wrong.

This is becoming a real community desktop fork, not a permanent pile of local patches. A future RaidGuild-branded build should use separate application storage and keyring entries. That cleaner boundary may require members to import their identity again, so it needs to be introduced deliberately. Calendar, Jitsi links, action items, Projects, Workflows, and Prism should remain optional desktop modules with ordinary-client fallbacks rather than requirements baked into a custom relay.

The two-week experiment starts now

The two-hour spike answered the first question: we can run Buzz, modify the client, and connect it to Prism. It did not tell us whether people will enjoy using it, whether onboarding holds up outside the setup crew, or whether the agent and Git workflows improve real collaboration.

For the next two weeks, Raiders can install the client, join the hosted community, try messaging, Huddles, agents, Git workflows, pairing, and mobile handoff, and report what works or breaks. We will publish a follow-up after the experiment with the community’s experience and a clearer recommendation.