Roomy Chat Alpha 3

It has been a while since alpha-2, but we're finally ready for our third alpha release, helped along by several new contributors! Read on for a clarification on the Roomy/Weird co-existence and our impending transition to Jazz.
Feature Highlights
We've gotten tons done in the last month, rather quietly so as we've still got some reliability engineering pending that's keeping us somewhat in limbo; we're due for more production testing in a few weeks.
- Overall more mobile friendliness and polish, courtesy of @michaelwschultz
- desktop/mobile app PoC (ideally including test-stage publication to play store (maybe fdroid first) and TestFlight)
- Boards 🛹 (essentially done but could use a bit further forumification, e.g. reply-counts etc., and the toggle will be taken out of the sidebar)
- Basic Moderation
- Search
- Pages📃 (v0.1 proof-of-concept done with BlockNote. Still needs lots of polish.)Pages
- Login/register with web address (via Bluesky ID or [soon] Roomy ID as well as BlackSky, NorthSky etc.)
- Roomy 3D Worlds! 🏝️ (new version cooking in roomy-worlds)
Dedicated posts will follow for all of these as they reach minimally production-grade maturity in the coming weeks/months.
Roomy and Weird
Weird may have appeared rather neglected these last few months, but now that Roomy has mostly settled our architecture for a "local-first social media" application engine, Weird will be ported over as an extension of the Roomy core.
The relationship between Roomy & Weird is highly analogous to WordPress & bbPress, a modular blog engine with a forum(chat) extension.
Roomy+Weird just does the opposite: A modular chat engine (Roomy) with a website/blog (Weird) extension. We consider messaging more fundamental; it’s the primordial staging ground for identity-making in the digital realm.
Practically everyone in the world has a digital chat-identity, usually a handful. Meanwhile maybe 0.01% of people have a website/blog-identity—more like 1-10% when counting microblogs, but still not nearly as pervasive as chat.
Subsequently we've begun distinguishing between the two post-modes that Roomy and Weird occupy respectively as:
- Roomy: filled-room posting—convivial, group-first.
- Weird: empty-room posting—solitary, individual-first.
Yet before we had a chance to complete this technical transition and the slight rebranding it would entail, someone submitted Weird to HN and we trended to the front page!
Even though the plan of remaking Weird as a Roomy extension still feels like our best long term bet, we’ve organically defaulted to a standalone implementation to prototype this thing, primarily in leaf-render by Meri Leeworthy who previously worked on organ-pages and loads of other tech that's superaligned with the Muni tech stack.., so we're having a go at joining our projects together 💞
You can kinda think of Weird as a startup venture that is intentionally building towards a “Roomy acquisition”, the way a lot of VC startups are explicitly built to be acquired by Big Tech. Except of course in our case what happens isn't an "exit" but rather an amicable merger of two things forming a new and greater whole together.
(Stay tuned for our forthcoming post on steward-ownership for more on our aspirational company structure.)
Temporary Backend Pivot
Right now, Roomy is built on the Loro CRDT with a simple, custom sync protocol, but we don't really want to be using our own sync protocol. A sync protocol is a project in-and-of-itself, and we want to be able to focus on our app. That said, our planned sync engine, Keyhive, is not ready for use yet, so we just threw our own thing together quickly to get Roomy working.
At this point we are feeling a bit of friction because our temporary sync engine isn't cutting it. We've got performance issues, and we also have a limited ability to secure chat spaces against bad actors with our moderation tools.
For our next release we are transitioning to Jazz, which we've deemed our best bet for getting to production-readiness asap.
Using Jazz now will allow our UI developers to continue improving the app and user experience, and not using our temporary solution will free up our backend engineers to focus on the long-term Keyhive-based solution. In other words, it makes it easier for both frontend and backend devs to focus more on making essential features.
Our hope is that Jazz will increasingly build their stack towards the "emerging Keyhive spec" for local-first access controls.
Reimplementing all of Keyhive's essential affordances within the Jazz architecture would be the best way for Jazz.tools to keep Roomy running on Jazz indefinitely. Whether the Jazz team's roadmap aligns with our particular requirements for community-sovereignty in the long term remains to be seen, but for now the Jazz stack is exactly what we needed.
Our move to Jazz is well underway. Once done we will put the call out for another round of testing. See you soon 👋