Late last year I wrote about what a Digital Strategy for Organisations ought to look like in today's online environment, advocating for bottom-up community building in smaller networks of coherence.

If you're a grassroots organization, don't waste your breath yelling into the void of the "town square" to get your message out there. For it is not a town any longer, it's a megacity where any singular voice immediately drowns in the noise of millions.

And don't look for "followers", for anyone who's following you is simultaneously following a thousand other spokespeople, breathlessly proselytizing from atop their soap box every day.

There's a lot you don't want to learn from startup culture, but if there's one thing it has figured out it's how to go from nothing to something. When you're small you can do things that don't scale. That means reaching out to people directly to say "we like what you're putting out and we want you alongside us in our community".

Some months later Mosh Lee wrote an impassioned appeal to our fellow web nerds to begin Building for Organizers.

When we talk about social networks, we often focus on metrics like viral growth, daily active users, engagement rates. But the most enduring social networks aren’t the prettiest or the most addictive – it’s the ones that empower organizers.

Who Are Organizers?

When I say "organizers," I’m talking about coaches, teachers, volunteer coordinators, union stewards, event planners, health workers, running club hosts, activist organizers, and owners of community-based businesses like music schools, summer camps, and business improvement districts.

What unites them isn't a job title; it's their role in making decisions on behalf of a group – choosing the tools and setting the norms that help people connect with each other, contribute their strengths, and turn a collection of individuals into a functioning community.

The builders and the organizers need each other. Sometimes they're the same people, but too often they operate as separate cultures and tribes.

Organizers need better tools. For decades they've squeezed what little utility they could out of anti-social applications intent on capturing our attention into consumerist doom-loops rather than directing our attention towards pro-social ends.

Builders need higher purpose. We have lost sight of the why and who we are building for, making things simply because we can, not because our community requires it. Breathlessly chasing the next thing we live in service of technological advancement for its own sake rather than the people, all of us, who our technology is meant to serve.

Alongside many of my technologically minded peers, ever since I dedicated myself to the improvement of the Open Web and the protocols that undergird it I have enjoyed a greater sense of purpose and belonging in my vocation than ever before, and I was already pretty amped up about doing my part when I first got involved with the open source software movement a couple decades ago.

I want organizers to be as excited as I am about the phase shift happening on the web right now. If we technologists can help the organizers see what we're seeing, which is the potential for a systemic overhaul of the web as we know it, the organizers will understand what they can ask us to build for them.

This article will provide a crash-course in protocol-driven development. But before we bring the protocol into the picture, let's begin with the status quo of today's websites.

Regular websites

Here is a wonderful website made by a local organizer I know.

It's the website of regenerativfremtid.no, a social collective of ecology-aware activists and enthusiasts. The network began in a group message two years ago, now counting over a hundred people in its Signal group.

The soul and driver of the group, Idun, recently made a new website for her nascent organization with the goal of adding more dynamism through crowdsourced events, a members-map and shared learning resources all in one place. In other words she wanted to turn what used to be a static information site into a social space.

The site was made using Lovable, which is functionally very similar to WordPress or Squarespace (content-management systems), it just happens to use plain language instead of graphical widgets to assemble websites based on pre-existing building blocks.

I'm more concerned with the underlying building blocks than the method of assembly. Like WordPress or Squarespace, any website made using Lovable has one significant limitation: It's an island.

Those events, the resource links and the group's social graph, none of them are connected to a wider network of people. This is most vividly felt with the network map (the Community page). It's a great idea, and a testament to Lovable's flexibility enabling an organizer to articulate her vision to get this far.

But as soon as we zoom out a bit, we're reminded of our isolation.

The way this ought to work is that as we zoom further out, the network graph expands beyond the loose confines of regenerativfremtid.no and starts showing members of other, affiliated groups, such as Nature and Youth, Doughnut Economics, Future in our Hands and many more.

Making this work is not Idun's job. She already did exactly what she was supposed to do by building a functional website that solves her organization's most pressing issues using the digital tools available today.

It's on us, the cybernetic nerds, to make better tools for tomorrow.

Protocols for connectivity

"Connecting people" was the original promise of social media in the 2010s, and it did an okay job of it. But for this to be possible we all had to pick one supreme market winner where all our digital identities would be put under centralized management.

For most of us that became Facebook. Several collapsed democracies and a world-wide mental-health pandemic later, we know how that turned out.

So we don't want that. But we don't want to stop being social on the web either. Is digital space ownership and digital connectivity an either-or proposition? That is certainly what Mark Zuckerberg would have you believe, and until recently he would be mostly right.

The web is undergoing a quiet renaissance. A new technology called the AT protocol is enabling independent websites and regional platforms to tie their comparatively small, local networks into the unified social graph of one big, global network where we can find the others once more.

Like the web, this social network is owned by noone and operated by everyone, as a digital commons. This decentralized form of stewardship was made possible for the world-wide web thanks to its evergrowing collection of web standards. That is, protocols that define how the web is accessed, whether you're entering into it via an Android's Chrome browser or a MacBook's Safari.

Expecting the general populace to be protocol-literate may seem like a high bar, but the basics of this stuff isn't hard to grasp. Protocols are just standardized ways of doing things that work best if we're all doing them the same way.

Take radios for example. You can buy any regular radio and listen to the same airwaves as anyone else because of the standardized AM/FM frequencies. I don't know what those letters mean, but I do know those letters represent a network of antennas and radios that have brought my family a lot of joy on car rides and cabin trips.

Every radio "speaks" AM/FM because it has been built in accordance with a standardized protocol for how to engineer a radio that can receive the AM/FM signal.

The AT protocol is another such standard, but for social media signalling. Messages, discussion threads, links, images, events and profiles, these are all common social media signals. Once a website speaks AT it can communicate with all other websites in the AT network, which we protocol nerds affectionately like to call The Atmosphere.

Now let's look at what this new technology and its accompanying network affords us. What does it let us do that we couldn't do before?

Atmospheric websites

Let's return to regenerativfremtid.no, this time imagined as one of many org websites connected to the Atmosphere network. How does its dynamic features like events, resources and people-mapping work now?

Social Events

regenerativfremtid.no, henceforth Reg for short, creates all of its events manually. Several of these events are sourced from partner organizations and friends who are managing their event through a different platform, so the event listing on the Reg site is just a duplicate made for extra exposure.

Logged-in users of Reg can RSVP and the website will increment its number of expected attendees. However, this is a separate counter from whichever events system the external organization is using, so now we have two separate lists of RSVPs. If each is showing only 3 people that is sending a very different signal to prospective attendees than the actual total of 6.

This is not a problem for websites in the atmosphere because all their events are based on a unified standard. Here is the same conference event on two different events platforms:

• AtmosphereConf on atmo.rsvp
• AtmosphereConf on smokesignals.events

Reg could be using either one of these services as its events engine running under the hood while hosting events on its own domain and website just like it does now. So if I saw an event from smultringokonomi.no (Doughnut Economics Norway) on regenerativfremtid.no, my RSVP signal would be received by both sites.

This also means far less busywork since instead of asking external organizers to manually submit any relevant events, Reg could instead be subscribed to a community-curated list of aligned organizations whose events are automatically syndicated to Reg's calendar.

Social Resources

When many orgs connect their social graphs together, their collective knowledge compounds. The not-for-profit venture Cosmik understood this early on and used the foundations of the AT protocol to build Semble, a social network for knowledge.

Here's a collection I made some months ago:

Post-growth & Regenerative Economics (by Erlend Sogge Heggen) — Semble

Articles, podcasts, papers and books about alternative, pro-social models of finance and economics.

SembleErlend Sogge Heggen

It's an open collection that anyone can add links to, and any org's website could opt to feature this collection in their local resource hub. Likewise, Reg's own collections could be syndicated to other sites for greater discovery of both the collection and its steward.

Social Networking

If we looked at that Community Ecosystem map from the vantage point of an atmospheric website, the 100 people in Reg's people graph are just the beginning. Zooming further out I'd be seeing hundreds of people from dozens of other mission-aligned orgs like Future in our Hands, Attac and Rethinking Economics.

Among them would be people like Ellen and Jan Walter, two fellow advocates of democratic company models that I met last year essentially by word-of-mouth. If our networks served organizers instead of advertisers, perhaps we would have connected a whole year earlier?

One-stop shop

This is all possible right now with applications built on the AT protocol. They just haven't been glued together into a cohesive 'website generator' experience quite yet.

An experienced web developer could remake regenerativfremtid.no as an atmospherically connected website in a matter of days, but it would lack the administrative user-interface Idun the organizer requires to have agency in her own website.

As of today the closest thing we've got is probably the widgets-based website generator called blento. It's not meant to be an advanced CMS like WordPress, but it effectively demonstrates how all sorts of different web apps in the atmosphere can be remixed together as building blocks of an independent website.

atmos.rsvp for events, semble.so for links, sifa.id for professional profiles, leaflet.pub for blogging, roomy.space for group chats and on and on and on, all enmeshed with the connective tissue of a collaborative hivemind.

Organization as destination

If non-profits, unions and activist groups want to reclaim their digital agency they must participate more intentionally in digital space-making on the Open Social Web.

Organizations can be more than participants in the atmosphere, they can be many people's initiation into it.

We've been focusing on the AT protocol as a standardized social-media signal so websites can talk to each other. The other groundbreaking affordance of this protocol is the standardization of identity and its accompanying data.

Personal data storage is an idea whose time has come

Data Ownership as a conversation changes when data resides primarily with people-governed institutions rather than corporations.

Muni BlogErlend Sogge Heggen

AT protocol decouples your personal data, including your identity, from the platforms that use it. Platforms can and often will host the data of their users as the easy default, but it's not locked in place.

Years ago when I first signed up to the Bluesky microblogging platform my data storage silently defaulted to their servers. But now, after a painless transfer a month ago, my data is hosted in Europe by the non-profit institution Eurosky. Bluesky's access to my data is now mediated through a European data-steward, under the jurisdiction of EU regulations.

Herein lies an incredible opportunity for organizations. Trustworthy institutions like Eurosky provide openly available infrastructure for personal data storage. Building on top of this foundation, organizations can themselves become regional micro-platforms.

Web of organizations

Many people nowadays are in the process of getting off the internet entirely, and while I think reaquainting onself with life offline is an excellent idea, giving up on the internet entirely would relinquish its immense organizational power to the very corporations that make it so unlivable.

What if people's re-entry into the digital sphere was mediated by the local-area organizations that represent the best of human nature?

Another one of the AT protocol's standardizations is to designate usernames as web domains, so as you surf the network you'll come across names like @erlend.sh, @anirudh.fi, @tessa.germnetwork.com‬, @mosh.bsky.social and @gordon.bsky.social.

That is the username they use to log into a multitude of AT-powered applications.

As I continue traversing through the atmosphere I'd like to start seeing activity from names like idun.regenerativfremtid.no, trude.framtiden.no, einar.framtiden.no, diego.attac.no and ylva.nu.no as a result of activists choosing to register their first AT profile through their favorite organization, much like professors using their university-provided email address as their public means of contact.

Remember, the burden of data integrity and service availability rests with infrastructure providers like Eurosky. Organizations merely provide the entryway into the network, and a sense of place and belonging within it. Like the location of your data, this domain-affiliation is not fixed in place, but whichever domain-name you land on first will typically last a long time, all the while advertising that organisation's existence to your peers.

Once someone has signed up on regenerativfremtid.no they can be logged into any other atmospheric org-site with a single button-click. Every participating organization becomes an onboarding mechanism for the entire organization-verse of interoperating websites.

LinkedIn for activists

In one final exercise of the imagination, think back to that Ecosystem Map. But instead of the localized view of one specific organization it's a comprehensive index of all organizations in a large region, like a whole nation.

For Norway, frivillig.no is that index. It's an excellent service, listing thousands of organizations and their respective jobs-to-be-done.

Yet even though it supports user registrations, it's not yet a network. It doesn't actively make connections between orgs and people. It acts as a mere jump-off point when it could be a foundational destination; a central hub for all volunteers, organizers and activists in Norway.

Whether you start your organizer's identity there (erlend.frivillig.no) or activate it by logging in with an existing account (erlend.attac.no), this could be the place where all your organizational engagements in Norway are recorded.

Here's an example activity graph from sifa.id, an AT-based competitor to LinkedIn just a few weeks old:

Imagine this in your profile on frivillig.no, except the 'platforms' it reflects activity from are organizations, not consumer apps. The reusable components necessary to build this with ease are already being made, they just need to be re-contextualized.

This profile would log the various events and projects you've been involved with as an activist in Norway. Only what you've opted to share publicly of course, but the more public our engagement the greater our connection to common cause, facilitated by a pro-social network owned by noone.

Make it real

Transitioning thousands of inert legacy websites to the atmospheric way of interbeing is no small feat, but it is eminently possible and absolutely necessary for our digital liberty.

Each one of these sites was built on familiar and interchangeable building blocks. All any webmaster needs to do is swap out their site's account management component with a ready-made replacement based on the AT protocol.

Helping hands are well within reach. There are thousands of AT-pilled developers out there right now looking for something meaningful to do on the Open Social Web. A whopping 300 of them are meeting in-person this week for AtmosphereConf in Vancouver.

If you're an organizer, reach out to whichever one of us is closest to you, or just ask me to play matchmaker and I'll get you connected.

We can have the more beautiful web our hearts know is possible, but we have to fight for it, technologists and community leaders in unbeatable union.

While Roomy is now quitely operational with a growing handful of pilot spaces, before we make a grander reveal about that particular milestone we have another exciting Report from the Atmosphere to share in the meantime.

Events for organizing

Events planning is an essential affordance in the world of organizing, especially for local groups trying to coordinate physical meetups. This is urgently needed now that acter.global, a comms app specifically for organizers, has shut down.

Open-web replacements are needed!

If we had to implement events on our own in Roomy it would've taken precious attention away from our ongoing work to stabilize and polish the app. This is where the magic of being an atmospheric application comes in.

Two weeks ago, amped up by Mosh's impassioned call to build for organizers, I reached out to Tom, the maker of OpenMeet

The plan was simple: Since both our apps are based on atproto identities, Roomy should be able to outsource its ‘events api’ to OpenMeet, and eventually any other Open Social events platforms like Smokesignal and Dandelion.

So instead of reinventing the wheel we've partnered with Tom for an app-mashup. For every space in Roomy, we wanna have an ‘Events’ extension (openmeet-api+roomy-ui) that can be enabled on demand.

With that rudimentary spec, Tom got to work. Seriously, if you get a chance to collab with this guy, you're in luck!

A few days later Tom had a prototype going, and last week it was merged.

And just like that, Roomy's got Events! 🥳

The current version works like this:

1. First make a Group on OpenMeet and put some events in it.
2. Go to the Calendar settings of your Roomy space and paste in that group's slug.
3. A new 'Events' tab will have been added to your space, as seen above.

In this preliminary version you can't edit events from within Roomy, you can only view them. However if you click on any event from within Roomy that corresponds with an OpenMeet group that you're an admin of, you'll be automagically logged into OpenMeet so you can make your edits there without missing a beat.

For more on that, read Tom's deep-dive:

Cross-App Authentication on AT Protocol: How Roomy and OpenMeet Share Identity

The free, open-source alternative to Meetup. Create groups and events for your community — no fees, no ads, community-owned forever.

OpenMeet

What is currently an auth-trust webring of two could probably grow way past that once the collective UX win is self-evident.

Roomy - our digital community garden for knowledge cultivation - has taken a long time to get right. Long enough that some people lost faith in us along the way, and that's fair. We'll try our best to earn it back.

A year ago we already had something that worked. Roughly every two months since then we have scrapped what we had and started anew. Never from scratch; we always kept the best bits around, and they've compounded. But new enough that there was no continuity of service. Never something stable enough to start hosting real, living community spaces.

Our partnership with ATmosphereConf marks the beginning of this continuity. No more do-overs. We have a real (pro-bono) customer-relationship to maintain now. The first of many. This changes our mode of development from being architecture-oriented to solutions-oriented. But having taken our time with the former is what will enable us to shine in the latter.

So as we reorient ourselves from the proactive to the reactive, I'd like to linger in this liminal space for just a moment longer and reflect on why this thing took all the time it's taken, and what makes me confident it was worth it.

Local-first problems

The majority of what I'll for simplicity's sake call the Western-World-of-netizens would've been plenty satisfied by a regular server-centric alternative to Discord or Facebook Groups, so long as it was open software and connected to the Atmosphere to resolve the cold-start problem of making a new social network.

I'm one of those westerners, and I designed and founded Roomy to scratch my own itch as an indie game developer and open source organizer.

But from the very beginning, Roomy was also designed for someone else. Someone with materially different needs than me.

Over a decade ago I embarked on a journey to Rashidieh, a mixed but primarily Palestinian refugee camp in southern Lebanon. I spent three months there as a volunteering youth envoy of ‘Palestinakomiteen i Norge’ together with the close friend who had invited me along.

Though it’s referred to as a ‘camp’, Rashidieh is a dense city of brick & cement, housing over 30,000 people. It's the same size as Molde, the biggest city an hour away from my tiny home town. Established in 1936, Rashidieh camp is nearly a century old. As such it is an unusual place with its own flow of time.

I had done this type of longer-term stay abroad a handful times before; a rare privilege afforded to me as a worldly Norwegian citizen. And while I do believe in the genuine altruism of myself and others, these journeys have always been for a selfish reason at heart. An escape; a search.

This time I was searching for meaning in the wake of my mother’s passing a year prior. In the village-community of Rashidieh I was met with heartfelt compassion from people for whom the loss of family members – whole families even – was a brutally regular occurrence of life. There was no comparing my bereavement to theirs, yet we grieved together all the same, and in that grief we were equals.

Excerpted from 'Too late', 12. October 2024

One of the most extraordinary things about communities forced to persevere in extreme living conditions is that they develop bespoke technologies strictly for on-the-ground problems. Out of pure necessity their technological sophistication will in some cases far exceed the stagnant status quo of the so-called Developed World.

Rashidieh is more connected than you might imagine a "refugee camp" to be. Lots of people have mobile phones, and there are quite a few houses with internet-connected wifi routers as well. Still, connectivity remains a luxury. Village-wide disconnections can be caused by anything ranging from accidental power outages to intentional disruptions by oppressive authorities, both domestic and foreign.

My time in Rashidieh was spent (alongside my friend) together with a small family: A mom, a dad and their son. The son was a computer-person. And being the friendly neighborhood supergeek, he was regularly downloading the Internet in a Box and serving it back out to his local-area community via his residential wifi. That way even if they lost access to the outside world for a bit, the locals of Rashidieh could still head over to Muhammad's for the most recent download of everything.

The will and skill is there. All they need is the appropriate toolkit suited to their conditions. Given a robustly designed Community in a Box, the residents of Rashidieh could autonomously maintain a local-area communications network independent of a higher authority. Whenever Rashidieh temporarily loses its connection to the internet they would only be out of reach to the outside world, but not to each other.

Planet-scale solutions

So what does a rural refugee camp in Lebanon have to do with us Westerners?

You know what happens if I lose internet connectivity here in the fancy capital of Norway, Oslo? I'm completely f***ed is what happens. Local-area redundancy networks and backup caches? We have no such thing. No need! We'll always be connected, we're a Developed Country.

Yet it's not that long ago since Portugal had a near nation-wide outage, and even though people still had their satellite-phones as a fallback the comms grid was heavily overburdened and unreliable in that time of "inconceivable crisis".

The closer you look at our digital infrastructure the more you realize it's all hanging by a thread, and it only takes Vlad and Daffodil on opposite sides of the earth to both get sick on the same day for the whole grid to come crashing down.

Our uninterrupted high-speed connectivity is contingent on an energy-blind, self-terminating economy of hyperconsumption. Modern technology and its comforts is premised on the perpetual-growth machinery that has pushed us past our planetary boundary many times over, all whilst transferring wealth upwards.

Most of us may not feel the oppressive thumb of authority pressing down on us as keenly as my friends in Rashidieh do, but it's on our necks just the same. Every essential layer of our digital infrastructure is chiefly owned, operated and controlled by a stack of oligarchic companies in varying degrees of partnership with the state they're holding hostage.

Systemic collapse is everywhere

The end of the world is already here, it's just not evenly distributed.

Sounds like a nihilistic spin on William Gibson’s famous quote, but what I'm saying is a lot of people have already experienced their whole world crumbling and somehow they came out at the other end still standing.

Low-bandwidth, intermittent, lo-fi tech that's peer-to-peer connected, distributed via bluetooth mesh networks and pirate wifi antennas, appears utterly irrelevant until it's suddenly a matter of life and death.

In Iran, a place no stranger to societal whiplash, Briar is keeping people connected at a desperate time when mainstream alternatives are failing them.

Briar Offline Mesh: When Internet Shutdowns Cut 85M Off | byteiota

From Bits to Bytes

byteiotaByteBot

The vibe-coded but demonstrably good enough Bitchat is topping the appstore charts in Uganda (turbulent elections) and Jamaica (natural disaster).

Bitchat Surges to #1 in Uganda Amid Pre‑Election Internet Shutdown – Archyde

%

Archydeby

A year ago it must still have seemed implausible for the USA communications grid to be turned adversarially against its own populace. Not so much any longer.

We all need connective tech that isn't dependent on centralized authorities and middlemen. We all need tech that's rooted in place, effective at the scale of 1 and up. And we all need tech that exists to everyone's proportional benefit, not an elite few.

Much like the curb-cut effect showing how universal design starting from the needs of the marginalized benefits everyone, the necessary affordances of a liberatory technology are largely the same no matter what part of the planet you're living on.

Designing for interbeing

Unlike Briar and Bitchat (unaudited), Roomy is not security-first but rather community-first.

Your local libraries and community gardens optimize for accessibility, not defensibility. So too with the type of space-making Roomy exists to facilitate.

Briar is part of the medicinal treatment of a sick democracy; Roomy is preventive care. Though conversely, I can’t think of many things more aggressively anti-fascist than massive crowds of diverse people congregating in shared, loving spaces.

We need both secure and accessible means of social congregation, and they're by no means mutually exclusive. But businesses want intranets and nerds wanna hack on cryptographic locks, leaving scarcely any money and attention left for cozy open-access spaces on the web.

That needs amending, we thought, so we built Roomy with a really solid foundation for locally adapted, decentralised, malleable communications that is sufficiently performant for users today. It can't do the fanciest p2p mesh-net stuff yet, but we are architecturally prepared and pointed towards that eventuality.

We're an idealistic bunch, but the best way to build a local-first app is to first build any kind of app commercially successful enough to sustain its ongoing development.

In the meantime we have already achieved cloud-independence by participating in the Atmospheric Computing movement as an Open Social application with sufficiently self-sovereign data storage.

The AT Protocol behind it all originated from many of the same peer-to-peer ideals mentioned herein, but the best way to make an impact with their flagship app Bluesky was to build a widely accessible web app.

We like that strategy and are following suit to complement their networked feeds for mobilization with our intertwined spaces for organisation.

Digital Strategy for Organisations

Digital power is created through the interplay of mobilizing and organizing. Open Social protocols bridge the gap.

Muni BlogErlend Sogge Heggen

If you want some more history on the designs that came before this one definitely read A Brief History of Roomy's Architectures. We've written in the past about using tech like Keyhive, Jazz, and Willow, but the latest design doesn't use any of those for now.

The Core Components

There are three major components to Roomy: the Roomy Web App, the ATProto PDS, and the Leaf Server.

The Leaf Server

The Leaf Server provides storage and realtime sync for Roomy, but it is actually application agnostic: it has no Roomy-specific code in it.

Instead, the server hosts user-defined "modules" that allow you to customize the way that the server handles data for a particular "stream". It's almost like an opinionated kind of PaaS designed specifically for Event Sourcing ( more on that later ).

This is very useful for Roomy because modules can be upgraded by the app without requiring any infrastructure changes. This will make it easier for us add new features to Roomy and try new things out, without having a lot of work to keep the server deployment and the app in sync with each-other.

The server is also very lightweight easy to self-host.

Off Protocol

Oh, hey Charlie! It's been a while. That's a good question! In short, yes, Roomy's data is off-protocol.

In Roomy, ATProto is used primarily for authentication and for integrations with other ATProto apps such as Bluesky, Smoke Signal, Streamplace, Semble, and more.

Auth is a really important one because it gives you an experience similar to the ubiquitous "Login with Google" button, but one that still allows you to host your own identity server.

Yep. And while there are absolutely good reasons to use the PDS for storage, we have some technical problems with using it as the official store.

Private Data

The first one is that all data on the PDS is public. There's no way for us to store, for example, chat messages that are sent in a private channel without encrypting it, and publicly distributing encrypted data is not a good practice.

There are great efforts underway to solve the private data problem on ATProto, but they usually involve hosting another server as a sidecar similar to what we are doing with the Leaf server anyway.

Even Bluesky's DMs, and Leaflet's drafts have to be implemented off-protocol.

Many, Tiny, Realtime Events

The other issue is that the PDS isn't necessarily design for streaming lots of small events like chat messages. There are rate limits on writes to the PDS, and the firehose isn't low-enough latency to use for chat synchronization.

Private Data + Notifications

Even if we had a way to store private data on the PDS, if you treat the PDS as the source of truth then your app has to have a way to know when the user changes without using your app.

Right now the firehose is used to notify apps about these kinds of changes, but that doesn't work for private data. There is another layer here that needs to be solved for, in addition to just being able to store private data.

Local First Synchronization

While not working yet, one of our big long-term goals is to have Roomy's data work in a local-first context. You should be able to edit your own data ( which may include far more chat messages ) offline, and sync it with other devices or peers, without a central server.

Depending on ATProto as our canonical data source makes this a lot more difficult manage.

What If We Don't Want to Require an ATProto PDS?

This might be controversial in the ATProto community, but what if we want to let you use Roomy without a PDS? If we already have to implement our own streaming system, our own database to index messages, our own way to query all of those messages in our app, and finally have a way to sync it without servers, then there isn't much the PDS is providing for us anymore. The biggest thing the PDS is providing is a standardized way for users to access their data.

The data access advantage can be preserved by having Roomy do semi-realtime backups of all of your chats to your PDS, in bundles so that we don't have to worry about rate limiting. Note that this unfortunately only works for public chat messages.

Additionally, auth on Leaf server is quite easy to extend to allow other options such as login with Mastodon or OIDC or IndieAuth, and in fact we plan on experimenting with that once Roomy gets more stable.

Being able to function without a PDS feels like an important way to future proof Roomy by focusing on what it actually needs to do its job. While logging into Roomy without a PDS would probably mean you can't use ATProto integrations, maybe logging into Roomy with Mastodon or other services could give you different integrations.

We aren't sure how things will develop, but we feel good about our ability to fit into different scenarios and we aren't ruling anything out.

What Is on the PDS?

There's a small handful of things we store on the PDS right now:

Public uploads are stored on the PDS. Later we will add a way to store uploads on the Leaf server so that we can support private uploads.

Roomy space handle verifications are stored on the PDS. This is a record that goes on your PDS when you want to use your ATProto handle as the handle for a space. It lets us look up a Roomy Space ID by using your ATProto handle. We're not sure whether these records will be used long-term.

Finally, as mentioned above, biggest thing that we want to be able to put on your PDS is continuous backups of your Roomy data. Unfortunately we still can't backup private data to your PDS, so this will remain limited to public data.

Data Ownership & Migration

If we look at the PDS as an example, I think the import "data ownership" features are:

• The PDS can be self-hosted or hosted by a provider,
• You can migrate your PDS hosting between providers,
• There is an API that you can use to access all the data on your PDS.

The Leaf server provides all of these same features very much like the PDS does, but with a different API.

It's really like a different kind of PDS, as I wrote more thoughts on recently.

That's an excellent point! We will be providing tools to use the API, similar to tools that already exist for the PDS. But community is important, too. It's best if we aren't the only providers of credible exit features, but that is something that will take time to grow.

How Does It Work?

Streams

Almost all data on the Leaf server exists in a stream, and it is similar in purpose to a repo in ATProto.

Unlike user repos in ATProto, Leaf streams are often for communitites, not just individuals. In Roomy, streams represent spaces, similar to Discord guilds, and they allow controlled write and read access from multiple user accounts.

As fellow Roomy developer @meri.garden put it: Leaf as a multi-player PDS.

Stream Identifiers

DIDs are used for stream IDs, just like they are used for ATProto accounts. When you create a new stream, it will create a new DID and publish it to plc.directory. The creator of a stream can add additional rotation keys to the DID that can be used to migrate the stream to a different Leaf server, for example, if the Leaf server goes rogue or you just want to switch hosting providers.

This allows different streams to be hosted on different Leaf servers, and could be used, for example, to self host Roomy space on your own server.

In the future we can add support for other DID methods like DID web.

Stream Data Model

All the data in the stream is represented by events.

Each event has a very simple data model:

• Index: The index of the event in the stream. This is just a number that increments for every event that gets sent into the stream.
• User: The DID of the account that submitted the event to the stream.
• Payload: A binary array containing the event data.

The Leaf server doesn't really care about what data goes into the events, so the payload could be JSON or CBOR or any other binary or text format.

This list of events is stored in a separate SQLite database for each stream.

Modules

Modules are the customizable logic of streams and they are responsible for authorization and aggregation.

Authorization

Before any event is saved to a stream, the event must be authorized by the stream's module.

Additionally, the only way to get an event out of a stream, is to use a query that is defined by the stream's module. This allows the module to perform read authorization.

Finally, for every event that passes write authorization, the module may run a "materializer". This materializer allows the module to cache any info about the event in its own SQLite database.

This database can be used to index events based on things like what channel a chat message was sent in, or what permissions exist for an event. The data can then be used in queries to quickly determine whether or not a user has access to perform the query, and which events should be returned.

Aggregation

The module's database also naturally allows the server to perform aggregations over the events.

For example, it could use SQLite's full text search in order to find chat messages based on a search query, or it could keep statistics like when each channel was last updated.

This aggregate data can then be used in queries for clients.

Updating Modules

While the events in the stream are meant to persist long term, the module and its database can be swapped out as needs change.

For example, if you need to change the way that permissions are applied, you will need to change the module, but the data in the stream shouldn't change.

When you update the stream's module, it will re-run the module's materializer for every event that is already in the stream, allowing the module to index it and re-build any aggregations.

Subscriptions

Queries defined by the module can also be subscribed to, so that if a new event is added to the stream, the query will be re-run and may return the new event if it matches the query. This allows us to get realtime updates in the app.

In the future, this can be made very performant by using Incremental View Maintentance ( IVM ) in Turso. Turso is a rewrite of SQLite in Rust with extra features. It isn't ready enough for us to use yet, but they're making great progress and we're hoping to use it on the Leaf server and in the Roomy app.

For now, re-running queries for subscriptions should still be fast for the most important kinds of queries, which can exclude already sent events by filtering based on event index.

Ephemeral Events

Ephemeral events are a way to send events to the stream that will not be persisted to the stream database. This can be used for things like typing indicators and other online "presence" features.

As another layer on top of this, ephemeral events can have their own materializer that allows you to store persisted state for things that will change frequently but that you only care about the latest state of.

For example, the latest message you have read, which is useful for unread notifications, is going to change constantly, but we don't really need to keep an event history of all the messages you've read. An ephemeral event can be used to notify when you read messages, and its materializer can record whichever message you read last, without accumulating events over time.

Event Sourcing & The Web App

While not strictly required or enforced, the Leaf server focuses on enabling an Event Sourcing workflow.

The Roomy app, for example, creates an event for every user interaction. These events are sent to the server, authorized and indexed by the stream module, and then automatically pushed to any client subscriptions that include it.

Roomy will then take that event and run it through its own materializer, finally storing the event data in a SQLite database, with all the indexes needed to efficiently query the data in the UI.

The UI itself uses reactive queries to that SQLite database so that whenever new events come in, the UI will automatically refresh with the latest results.

The whole flow is pictured below:

It is a lot, but I think it's the best way to get the data ownership, flexibility, and performance that we need long term.

While it is somewhat complicated, in the end I think it is actually one of the simplest ways to solve all the problems we have run into with Roomy's architecture so far. Every design decision has been motivated by our actual needs.

I also think that once the patterns have been worked out a bit more and we have some more tooling in place, that the Leaf server could be useful for a lot more than just Roomy.

I think the fact that modules give you the ability to do aggregations of events on the server, similar to a minimal PaaS, could be really handy for some use-cases, especially when combined with the realtime nature of it.

ℹ️ Note: It's also possible to skip the event sourcing model for the most part on the client and just have the server aggreate all the interesting data and return those results instead of the events themselves. This is all quite new so there's a lot of room for exploring different ways to use things.

How is a Module Written?

Right now they are actually just written in SQL!

The authorizer, materializer, and queries are all just made out of lists of SQL statements with access to extra SQL functions we've defined specifically for helping you write Leaf modules.

For example, a simple SQL authorizer could look like:

select unauthorized("Only stream owner can add events")
    where (select creator from stream_info) != (select user from event);

And a query that only allows the creator of the stream to read its events could look like:

-- Authorize the query
select unauthorized('only the stream creator can read its events')
    where $requesting_user != (select creator from stream_info);

-- Return the result
select id, user, payload from events.events
    where id >= $start limit $limit;

There are some kinds of logic which are either impractical or impossible with SQL, so we are considering allowing you to define custom SQL functions in WASM and/or adding a simple DSL or scripting language like Duckscript ( maybe ) as a way to execute conditional SQL statements more easily.

The great part about SQLite is that it's easy to mix in your own DSL / scripting language and execute that code as a part of the SQL transactions.

We've designed the Leaf server so that it's easy for us to implement new kinds of modules using different languages or features in the future.

Summary

There you have it! That sums up most of Roomy's architecture.

We are approaching a full year of focused work on building Roomy and we're zeroing in on our final design. Things may shift, but the core strategy will remain the same and we will make it work.

Postscript: Peer-to-Peer & Local First

Unfortunately the tech isn't ready yet, and we need to get Roomy into real-world use now.

See A Brief History of Roomy's Architectures for more detail, but, in short, we were going to use Willow, but it wasn't ready yet, then we were going to use Keyhive & Beelay, but that also wasn't ready yet, finally we actually did use Jazz, but ran into serious performance problems and it was missing an essential feature we needed.

While our new design is less peer-to-peer that previous attempts, we are putting a lot of effort into making sure that we have, as much as possible, a smooth road forward into more p2p solutions in the future.

For example, the event sourcing model we are using allows you to make edits offline and later sync those edits to a server, to give us local-first features.

Similar to Git, we can hypothetically have temporary "forks" of a chat space that allow you to chat with someone that you have a LAN connection with, even if you are offline, before later "pushing" those changes to the main "branch".

We have a lot of ideas for potential solutions and I think we're in a pretty good position to make real progress on it once we can find the time. It's something that we are passionate about and it's something that we believe there is real-world value in.

In order to get the time and resources to bring that to fruition, though, we need to start with something that can provide real value to people today, and we think that Roomy can do that.

We're on it!

I've been trying to write this piece for years, really ever since I finished the first version of Open Source Explained (a v2 will drop early next year). Every time I get started I'm just overwhelmed with paralyzing visions of the commentariat accusing me of WrongThink.

So I drop it, because I'm tired to the bone of debating the minutae of open source definitions when the conversation we ought to be having is about power: who has it? (oligarchs), how did they get it? (monopolies, corruption & unmitigated extraction), why is that a problem? (technofeudalistic autocracy), and how do we the people take that power back? (protocols, open software & defensive licensing).

Understanding ownership is power

It’s important to understand the codes in your life, because your life is made up of them. Once you understand which codes you already have access to and even the right to inspect, you can see more clearly which other codes you ought to have insight into.

Nothing makes me more anxious than writing about open source licensing because nothing brings out more opinion-havers, the vast majority of whom are speaking from a point of privilege-blindess in the western world. The widespread ignorance of the deeper power struggle at play (which we're losing) has brought the free world to the very brink, so I'm pushing past the discomfort to honor the urgency of our moment.

As a life-long advocate of open source methodology - an incredible tool and tactic for pro-social change - licensing is a legitimately painful subject matter. The dialogue is just so profoundly stuck, and it can feel like a lot of software engineers care more for the sanctity of Open Source computer code than human life and wellbeing.

Instead of finding common cause in sustainable cultivation of the digital commons we appear forever doomed to argue semantics and purity tests while the burnout epidemic worsens and the integrity of our shared infrastructure disintegrates beneath our feet.

I'd estimate that 95% of my working-time in software development (>20 years), employed and independent alike, has been spent facilitating & producing open source software. I am Team Open Source. I steadfastly believe in open source praxis as an exceptionally powerful method of permissionless coordination & innovation.

Yet if open source code alone could change the world, it would have happened by now. When Microsoft suddenly turned OSS-friendly in the 2010s we triumphantly proclaimed "open source has won!", but what have we got to show for it? More technology does not on its own correlate with better quality of life.

In hindsight I don't think any reasonable person can say that we're collectively better off. Democracy is losing, and tech is playing an undeniably outsized part in that.

Fact is, the reason companies like Microsoft, Google, Amazon and Facebook warmed up to open source is because they realized they could use it to their advantage by commoditizing their complements.

Joel Spolsky in 2002 identified a major pattern in technology business & economics: the pattern of “commoditizing your complement”, an alternative to vertical integration, where companies seek to secure a chokepoint or quasi-monopoly in products composed of many necessary & sufficient layers by dominating one layer while fostering so much competition in another layer above or below its layer that no competing monopolist can emerge, prices are driven down to marginal costs elsewhere in the stack, total price drops & increases demand, and the majority of the consumer surplus of the final product can be diverted to the quasi-monopolist. No matter how valuable the original may be and how much one could charge for it, it can be more valuable to make it free if it increases profits elsewhere.

Hardware capitalists (hyperscalers) love maximally free-of-charge software. When the only way to monetize software is to run it in the cloud and charge for access to the cloud, owning hardware becomes the only viable business model for software distribution. Anyone who doesn't own hardware must sell their software like an infrastructural subletter at ever-thinning margins as the software product gets commoditized.

Kat Marchán 🐈 (@zkat@toot.cat)

Open source maintainers of major projects (hi) are not ready to accept and talk about how the cultural insistence on permissive licensing is just straight up labor exploitation taking advantage of our addiction to popularity (also hi). We’re doing this to ourselves too, you know.

Toot.CatKat Marchán 🐈

And for the Silicon Valley startups where open source products have become a common differentiator and market-entry-wedge among many new companies, open source is not a moral imperative or a common good, it's just an effective go-to-market strategy.

Since its inception the free and open source software movement has lacked a theory of change beyond the liberation of computer code. Liberation of human beings by way of a liberatory technology was always a secondary and oftentimes incompatible concern for Open Source, since laborers having agency of their work (and how it may be exploited) is in conflict with the inviolable liberties of an Open Source computer program.

The result has been an ineffectual "open source revolution" that maintains the status quo of our modern day hellscape by facilitating an upwards transfer of wealth and power, amassed by the hyperscalers who are now entering their final, fascistic form. Open source "won" by aiding and abetting the already dominant owner-class.

Amazon and Google are empirically more powerful today than they were 20 years ago. Our prevailing models of software ownership are demonstrably not a threat to the ones using software to eat the free world. We need a change of tactics.

Anti-fascistic software

..is made possible by pro-labor licensing.

After a recent demoing of Roomy to the fine people of Scenius, someone asked the question that always comes up in these nerdy circles, as it should:

"is your project open source"

Well, if you mean is all our source code openly available for other makers to freely use, copy, modify and share-alike?, then yes.

But indiscriminately so? No. There are uses of our freely available code (Roomy, MPLv2 and its underlying Leaf framework, FSL) that we do not tolerate, namely commercial uses of our software that compete with the services we ourselves are commercially operating for the express purpose of keeping ongoing development and maintenance of Roomy sustainable.

Yes, in sacreligious discordance with the holy commandments of the California-based Open Source Initiative, we discriminate, thus violating the 6th principle of the Open Source Definition.

The Open Source Definition

Introduction Open source doesn’t just mean access to the source code. The distribution terms of open source software must comply with the following criteria: 1. Free Redistribution The license shall…

Open Source Initiative

No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

This definition of open source prohibits discriminating against megacorps and nazis.

That's a problem for me. You see, I wanna make my software freely available to everyone in the world except those guys specifically. That very particular bunch of autocratic corpo-states are actively destroying the world I'm trying to pro-socially enrich as a commoner.

Certain open software zealots will defend the innate righteousness of the Open Source Definition with a religious fanaticism indistinguishable from the actual members of faith traditions they love to denigrate as illogical loons.

Yet even Bruce Perens, the original author of the Open Source Definition, acknowledged in 2024 that the class of open source licensing stipulated by the OSD is not sufficient for modern day conditions. He is now championing what he calls Post-Open, which is a fairly long-winded way of saying he's now pretty cool with the notion of licensing code to be "free only for non-commercial use".

Protection against commercial extraction via CC BY-NC licensing is a perfectly normal practice in the open source art community, but for some strange reason when it comes to code this simple defensive maneuver is just not right.

I am an anti-fascist. By plainly stating this I will apparently be marked as a terrorist by the USA, so I guess I'm not visiting again any time soon.

As the former VP of Community at Discourse (GPLv2) I spent half a decade participating in the making of certifiably Free, Open Source Software that got put to use by literal nazis to amplify their organized hate, and all we had to say for ourselves was "well, the license says free for everyone". In the words of Kyle Mitchell, this is the Tyranny of Permissionlessness in action.

If the only correct and righteous way to make Open Source software means strictly making non-discriminatory software stripped of protections for its laborers, consider me out. I've personally made it my job to produce anti-fascistic software, meaning software that decentralizes power by taking it away from autocratic fiefdoms and re-distributing it to the margins of society.

It boggles the mind that in an open software culture whose central ethos is continuous iteration and improvement made possible by openness, our licensing stack and its ingrained principles are apparently immutable.

Even the author of the illuminating "Why Open Source Failed" (from 2018 and a spiritual predecessor to this article) promptly rules out new types of licensing as part of the solution. Instead he appealed to government intervention, which by now is as quaint of a sentiment as they come.

No one is coming down from up high to save us. We can only seize the levers of power that are within our reach. Licensing is a uniquely powerful lever because it is enacted as a bottom-up change at the level of individual agency whilst simultaneously being wielded with the top-down legal authority of nation states.

The intellectual property landscape is grossly outdated and biased towards big business, but the market still depends on the continued rule of law to function. That systemic dependency can be subverted against itself and used in our favor by reformulating acceptable use for the people's software at a grassroots level.

Ethical licensing is hard, but far from impossible. While we cannot easily encode anti-fascism into our licenses, what we can easily do is discriminate against big capital, the underlying engine of fascism and authoritarianism.

Neoliberal Fascism as the Endpoint of Casino Capitalism | Fast Capitalism

Page Header LogoHenry Giroux McMaster University

That's what defensive licensing tactics for open software makes possible.

While OSI has no right to claim any authority over a term as general as "open source", they've successfully popularized a cultural interpretation of Open Source (Software) in accordance with their neoliberal definition. I'll abide by that interpretation as long as it remains culturally mainstream. With time I do however intend for and expect that interpretation to change.

Rapid-fire Q&A

Real World of Open Source

Ursula Franklin's timeless lecture on The Real World of Technology from 1989 should in my humble opinion be required reading in the School of Open Source and Pro-Social Technology.

The Real World of Technology : Ursula Franklin : Free Download, Borrow, and Streaming : Internet Archive

These are recordings of Ursula Franklin’s public lectures that she made as part of the 1989 Massey Lectures series. The recordings were broadcast by the…

Internet Archive

As I see it, technology has built the house in which we all live. The house is continually being extended and remodelled. More and more of human life takes place within its walls, so that today there is hardly any human activity that does not occur within this house. All are affected by the design of the house, by the division of its space, by the location of its doors and walls. Compared to people in earlier times, we rarely have a chance to live outside this house. And the house is still changing; it is still being built as well as being demolished. In these lectures, I would like to take you through the house, starting with the foundation and then examining with you the walls that have been put up or taken down, the storeys and turrets that have been added, the flow of people through the house — who can come in, who can go into particular spaces.

One needs to look not only at what technology does, but also what it prevents—and whether by the mere presence of technological approach to a social problem, one does not redefine the problem to the detriment of the total situation.

She talked about holistic versus prescriptive technology. With holistic technologies, the worker is in control; with prescriptive technologies, the worker is under control. In the context of sustainability, traditional FOSS can in some cases have a harmfully prescriptive quality to it by limiting code workers to only selling their future work (on condition of employment) and not the works of their past (as an independent).

When talking to the most ardent FOSS-maxers it usually feels like they're not making enough contact with reality at large. Free, Open Source Software does not a social movement make. FOSS ideology operates in a theoretically pure vacuum that doesn't need to interact with the messy reality of daily survival.

The liberties of software are obviously ill-defined if they actively erode the liberties of the people who make it. Open Software as a positive force in the world is entirely contingent on its ability to distribute power. To date it has facilitated the opposite.

Distributing privilege

Making the rich even richer was definitely not part of the original ethos of the open source movement. Most open source software has been built on the backs of people enjoying privileged lives with an abundance of free time to satiate their intellectual curiosities. Volunteer value contribution also helps lessen the guilt induced by being in the group of people who just lucked out with the life-ride we were put on.

That’s not to say sacrifices haven’t been made. Open source is also built on contributor churn; burnout.

We can’t have a movement that grew out of privilege and suffering become an amplifier of more privilege for those who already have the most, and more suffering for the underprivileged! That’s a very bad look for us aspiring movers. And it would make obvious that what we thought of as “solving hard problems” might’ve just been ’pretending to be intellectuals by making up puzzles for ourselves to solve’.

How much of our “progress” is really just little distraction machines that we built to keep our brains from going too quiet and introspective.

We will know our movement is succeeding if we are contributing to privileged wealth being widely and equitably distributed. We will know we have failed if the status quo remains unchanged, and the powers-that-be remain comfortably seated.

In the three and a half years since I wrote this the status-quo has only worsened, and it was already bad enough back then.

Open Source as a Commons

Before the term "Open Source" got marketed as the industry-standard description of open software code in the 90s, open software was being shared as a digital commons in the same way we've practiced commoning of any social technology going back millennia.

The notion of a 'Commons' re-entered the zeitgeist in the late 60s, after a grumpy ecologist called Garret Hardin confabulated a hypothetical "Tragedy of the Commons".

I call it a confabulation because Hardin's unimaginative game-theoretic scenario was purely his own thought experiment with no basis in scientific research.

'Economism' was summed up by Ely Devons, who quipped "If economists wished to study the horse, they wouldn’t go and look at horses. They’d sit in their studies and say to themselves, ‘What would I do if I were a horse?’"

Hardin asked himself, "If I were reliant upon a commons, what would I do?" And, being a realist (that is, an asshole), Hardin decided that he would steal everything from the commons because that's what the other realists would do if he didn't get there first.

Hardin didn't go and look at a commons. But someone else did.

That someone else was Elinor Ostrom, an actual nerd who went out and did actual research and discovered that, actually, the commons is antithecal to social tragedy. Commoning is literally a practice of societal anti-fragility.

While the tragedy of the commons is a fabrication, the free-rider problem is very real, most of all because the biggest free-riders are the largest corporations in the history of our world. That's why our commons have to be actively protected and managed.

Elinor Ostrom's work on Governing the Commons culminated in eight principles on how to best manage a commons together.

The first of those principles is foundational to all the rest:

(1) Commons need to have clearly defined boundaries.
In particular, who is entitled to access to what? Unless there’s a specified community of benefit, it becomes a free for all, and that’s not how commons work.

The original sin of "Open Source" as imagineered by software libertarians was to not only to omit this critical insight from its definition, but actively forbidding any such boundary-drawing by anyone who wanted to consider themselves true advocates of Open Source.

From the revised and expanded principles formulated by a computer nerd:

1A. DEFINE AUTHORIZED USE: The community of those who have the right to use the common resource is clearly defined.

1B. DEFINE COMMONS BOUNDARIES: The boundaries of the commons are clearly defined so as to separate the usage rules from the larger environment.

2A. MAKE COSTS PROPORTIONAL: Costs for using and maintaining the commons are proportional to the benefits that those users receive from the commons.

2B. PAY ALL COSTS: People that use the commons keep costs inside the local system as much as possible. They do not externalize costs either to neighbors or future generations.

This is precisely how we are NOT managing our digital commons.

We need to follow in Ostrom's footsteps and bring in the scientists on this one. Are companies who transitioned some of their products to source-available licensing less pro-socially impactful than the purest operators out there? Is the agency of the product-user meaningfully limited by source-available software?

I posit that in five years we will laugh about how much we fretted and quibbled over the degrees of openness in our "open-source vs shared-source" products when they amount to roughly the same pro-social impact, either one being vastly preferable to the domineering dynamics of closed-source black boxes.

There is a singular condition that necessarily precedes all other definitions and principles for free and open software: Source code availability.

Did you ever notice how the four freedoms to run, study and (re)distribute a program repeatedly add “Access to the source code is a precondition for this [freedom].”? We just don’t get very far without source code access.

This particular freedom is special:

The freedom to study how the program works, and change it so it does your computing as you wish. Access to the source code is a precondition for this.

Unlike the other ‘freedoms’, insight is not just a legal story, it’s the difference between knowing and not knowing. When we have insight, we have unlocked the possibility to do whatever we want with this code, legal or not.

If running some code would assuredly save a life, I have a moral obligation to run that code, even if I am not legally allowed to run it.

When the source code of an application is available for view, the most important job is done. The black box has been cracked open and added to the permanent archives of The Commons. The conditions may say “for viewing purposes only; no editing, copying, remixing or redistributing allowed”, and we may play along, provided the rules of the game seem fair at the time.

Open source codes exist on a spectrum of openness. We can’t quite seem to agree what openness taken to its logical extreme should ideally look like, but the modest beginning on the other end is simple and clear-cut: Open access to the source code of your thing.

Other conditions may and in many cases should apply.

Re-defining our boundaries

The reigning winners of open source are the megacorporations, and who can blame them. We seem to have collectively agreed (though I would argue by manufactured consent) that drawing clear boundaries around our digital software commons is the one thing we cannot do.

There’s never enough interest in grappling with this looming issue until the system breaks enough that people are being hurt in the form of critical system failure and vast personal expenses of both the psychological and financial kind.

Modern infrastructure initiatives like Vite+ are daring to make source-available code and I think this is a Very Good Thing. It facilitates a rethinking of the social as well as financial contract between open source maintainers and the corporations that to-date have been extracting vastly more value out than they're putting back in.

Open Infrastructure is Not Free: A Joint Statement on Sustainable Stewardship – Open Source Security Foundation

OpenSSF

Beyond package registries, open source projects also rely on essential systems for building, testing, analyzing, deploying, and distributing software. These also include content delivery networks (CDNs) that offer global reach and performance at scale, along with donated (usually cloud) computing power and storage to support them.

And yet, for all their importance, most of these systems operate under a dangerously fragile premise: They are often maintained, operated, and funded in ways that rely on goodwill, rather than mechanisms that align responsibility with usage.

Despite serving billions (perhaps even trillions) of downloads each month (largely driven by commercial-scale consumption), many of these services are funded by a small group of benefactors. Sometimes they are supported by commercial vendors, such as Sonatype (Maven Central), GitHub (npm) or Microsoft (NuGet). At other times, they are supported by nonprofit foundations that rely on grants, donations, and sponsorships to cover their maintenance, operation, and staffing.

Regardless of the operating model, the pattern remains the same: a small number of organizations absorb the majority of infrastructure costs, while the overwhelming majority of large-scale users, including commercial entities that generate demand and extract economic value, consume these services without contributing to their sustainability.

The top 10 biggest programming languages in the world are collectively responsible for trillions of dollars in generated value. How much of that value is cycling back into the maintenance of these languages and their ecosystems? 0.01% maybe, if even that?

Is it really that crazy to imagine a community-governed and institution-owned package management stack that's licensed such that corporations have to pay their fair share, to the tune of some tens of millions of dollar per year in revenue? Keep in mind that non-profits are welcome to make lots of revenue, it's the excess profits that's a probem.

The Rust-lang package utility crates.io and all of its accompanying infrastructure is licensed as permissively as possible with MIT and Apache v2. Why? Is anyone forking and remixing crates.io for personal use?

Package managers are centrally managed utilities by necessity; we just need the one (on average). No one is pulling in the crates.io package manager itself as a code dependency in their project, so the licensing of that package management code almost exlusively pertains to the usage of crates.io as a package management product, used by individuals and corporations alike.

Alike, but not equally. As the OpenSSF article above makes clear:

Commercial-scale use without commercial-scale support is unsustainable.

What the article doesn't get into is exactly how the corporations will be charged for services rendered. Presumably the utility endpoints themselves like crates.io will receive some much needed changes their Terms of Service as pertaining to corporations.

That'll be a great start, but I believe something more akin to the commercial tempering of Vite+ (specific license TBA) is necessary as an additional protection, otherwise the capital-holders will keep re-drawing the boundaries in their favor.

Case in point, two months ago the Python Software Foundation announced "The PSF has withdrawn a $1.5 million proposal to US government grant program".

They did so because their state-sponsored funding was contingent on compromising their community's commitment to diversity. This is the kind of decision OSS orgs are faced with when they have to ask for money instead of being paid for services rendered. I wonder how many orgs have quietly taken this deal, insidiously eroding their culture of openness and cultural diversity in the process.

Same team, same mission

Alright, now that I got that off my chest.. if you are a FOSS advocate of any kind, you're my kind of people; I love what you do and what you are about. We're playing for the same team.

That's why it's all the more painful when we're failing to meet and prosper together on our vast stretch of common ground, rich with possibility. If you share this sentiment we can talk all about it in the chat, the first of which will happen together with the Scenius community on December 3rd as an 'Open Source Panel', exact time and digital venue TBA.

If the case I'm making for more experimentation and ideological agnosticism isn't tracking for you and you're still not convinced that I'm a well-intentioned cultivator of our digital commons, man, do me a favor and just leave me be for a while instead of telling me how wrong I am.

Let me do my work. I'm so tired of this. Give me a year to just show you rather than telling, and let's talk more then. In the meantime kindly give me the silent treatment.

Thanks for reading, friend (if you still want to be).

Other things I might write about if there's any juice left after this:

• How copyleft discriminates against economic opportunity
• How WordPress' GPL licensing forced Automattic into an ugly legal battle
• Open Source and Post-Growth
• CLAs are good for workers, actually
• Trustworthy software
• Governing acceptable-use by community tribunal
• How non-commercial boundaries incentivizes proper accounting of project contributions.

Any organisation engaged in movement-building needs a persistent, online space where its volunteering collaborators can congregate, bond and maintain momentum through a higher degree of connectivity than a weekly newsletter. The passionate ones need a place where they can show up and get into it on a regular basis.

Unfortunately the mainsteam platforms for online space-making are feudal fiefdoms who've amassed so much power that they are increasingly at the root of the very problems the average non-profit organization exists to remedy.

The same domineering forces that are degrading our democracies and poisoning our planet have been doing the exact same thing to our virtual biosphere. As Cory Doctorow says of The curious, intertwined history of climate and digital rights activism:

There's an inchoate movement groping its way to understanding that it is a movement – that the problems of labor exploitation, fascism, climate degradation, surveillance, authoritarianism and genocide are all connected to each other by the fact that they are caused by extreme concentrations of wealth and power.

To save our world wide web-of-life, including its digital ecology, we need a rewilding of the internet.

We Need To Rewild The Internet | NOEMA

The internet has become an extractive and fragile monoculture. But we can revitalize it using lessons learned by ecologists.

NOEMAMaria Farrell

Make Space To Grow

We need to stop thinking of internet infrastructure as too hard to fix. It’s the underlying system we use for nearly everything we do. The former prime minister of Sweden, Carl Bildt, and former Canadian deputy foreign minister, Gordon Smith, wrote in 2016 that the internet was becoming “the infrastructure of all infrastructure.” It’s how we organize, connect and build knowledge, even — perhaps — planetary intelligence. Right now, it’s concentrated, fragile and utterly toxic. 

Ecologists have reoriented their field as a “crisis discipline,” a field of study that’s not just about learning things but about saving them. We technologists need to do the same. Rewilding the internet connects and grows what people are doing across regulation, standards-setting and new ways of organizing and building infrastructure, to tell a shared story of where we want to go. It’s a shared vision with many strategies. The instruments we need to shift away from extractive technological monocultures are at hand or ready to be built.

Facebook, Instagram, TikTok and X/Twitter will happily grant you an audience in their kingdom, even if you're being critical of their platforms. That is, until you're so effective at your job that you actually pose a legitimate threat to their supremacy, in which case they will lower your reach as they see fit, or simply banish you from their dominion altogether under the pretense of "system error" or "ToS violation".

Protocols, Not Platforms

The world's polycrisis requires action on many fronts, and our technofeudalistic predicament is no exception. But in the technological realm we have one particularly impactful tool at our disposal that has made massive inroads in the last two years: Protocols.

A compelling case for protocols as a way to re-democratize the web was made in Mike Masnick's paper from 2019:

Protocols, Not Platforms: A Technological Approach to Free Speech

Knight First Amendment InstituteMike Masnick

We’ve gone from a world in which protocols dominated to one in which centralized platforms controlled all. Moving us back toward a world where protocols are dominant over platforms could be of tremendous benefit to free speech and innovation online.

Such a move has the potential to return us to the early promise of the web: to create a place where like-minded people can connect on various topics around the globe and anyone can discover useful information on a variety of different subjects without it being polluted by abuse and disinformation. Simultaneously, it could enable greater competition and innovation on the internet, while also giving end users more control over their own data and preventing giant corporations from having too much data on any particular user.

Moving to protocols, not platforms, is an approach for free speech in the twenty-first century. Rather than relying on a “marketplace of ideas” within an individual platform—which can be hijacked by those with malicious intent—protocols could lead to a marketplace of ideals, where competition occurs to provide better services that minimize the impact of those with malicious intent, without cutting off their ability to speak entirely.

It would represent a radical change, but one that should be looked at seriously.

Think of our digital protocols as shared standards that enable interoperability and coordination among people on-line.

It's what empowers you to move from one telecom provider (a platform) to another without having to change your phone number (a protocol standard).

It's the reason you can send an email (a protocol standard) from yourmail@gmail.com to friendsmail@outlook.com even though they're two different service operators (platforms).

Obviously this hasn't prevented telecoms from becoming supersized and Gmail maintains around a 30% market share, but you'll notice that both telecoms and email providers have been subject to far less platform decay than their social-media counterparts.

I posit, with most technology activists agreeing, that this is because the telecoms and email providers are being kept (minimally) honest by the protocols inherent to their platforms, which prevents customer lock-in by ensuring cross-platform interop and a right-to-exit. If you don't like the service you can actually leave.

Internet nerds have been trying to standardize protocols for social media since the 2000s, but after massive capital infusion the social web grew too quickly for any widely agreed upon standard to achieve critical mass, which has left us with an oligopoly of personal data fortresses that everyone hates but no one can fully leave because that would entail losing our social connections and data in the process.

But as is inevitable when any institution gets too big to care, these platforms have gotten so egregiously bad that enough people don't care right back; they want out, even if that means having to start from scratch.

What's important is that there's somewhere for people to go.

"In times of crisis, ideas can move from the fringe to the center in an eyeblink. Our job is to keep good ideas lying around, in anticipation of that crisis."

Bluesky and AT protocol

When Elon bought Twitter, Bluesky became the best idea lying around during one ensuing crisis after another.

Bluesky Is Plotting a Total Takeover of the Social Internet

All the lefties fled to Bluesky following Elon Musk’s Twitter takeover. But CEO Jay Graber says the app is for everyone—and could revolutionize how people communicate online.

WIREDKate Knibbs

Graber, a former software engineer, seems most energized when she’s talking about the unique infrastructure for her kingless world. Undergirding Bluesky as well as several smaller apps is the Atmosphere, or AT Protocol, which is a rule book that servers use to communicate. The open source protocol allows sovereign digital spaces to integrate with one another as needed. Two apps with complementary ideas about moderation or ads can work in tandem—or not. It’s up to them.

Graber sees Atmosphere as nothing less than the democratized future of the social internet, and she emphasizes to me that developers are actively building new projects with it.

The network now counts 40 million members. That may seem like a small number compared to the hundreds of millions reported by its competitors, but those numbers are grossly inflated by bots and dubious counting methods, which most tech journalists repeatedly fail to note.

When looking at actual impact, many news outlets are reporting higher rates of engagement and incoming traffic on Bluesky with only 1/10th of the followers. The Guardian has left X altogether, finding it untenable. Best of all, Bluesky is the definitive platform of choice for the science community.

Even so, Bluesky was just the onboarding mechanism; the "killer app" needed to kickstart the app-agnostic infrastructure underneath. What we have now is an open network of 40 million people that any budding social media app can build on top of to supercharge its rise, thus competing on a relatively even footing with the powerful network effects of Big Tech incumbents.

The next 100M users on AT will come from other startups. Any indie platform creator can opt to interoperate with the AT protocol, and lots of us are doing exactly that:

Beyond Bluesky: These are the apps building social experiences on the AT Protocol | TechCrunch

A list of AT Protocol-based, consumer-facing apps that are either built on top of Bluesky or its underlying protocol, allowing users to take back control over their social networking experiences and personal data.

TechCrunchSarah Perez

The AT protocol's ecosystem of interoperating applications already has fully operational alternatives for most of the usual suspects. (More than one option actually, but these are the most mature examples.)

• Instagram --> Flashes
• Substack --> Leaflet
• Meetup --> OpenMeet
• GitHub --> Tangled
• TikTok --> Skylight
• Twitch --> Streamplace

If you already have a Bluesky account you can also sign into any one of these services. Or, if your first step into the open social web is via any of the above services (though only a few have opened up their own native accounts management so far), you can use that account to sign into Bluesky, as with the rest.

What's still missing is an alternative to the likes of Discord or Facebook Groups. Why is group discourse so important for organizations? Because while Bluesky and other such feed-centric apps are great for mobilizing, they're not the right tool for organizing, and change-makers need both to be effective.

Mobilizing vs Organizing

Legendary labor organizer Jane McAlevey left us with a powerful lesson about the shortcomings of an overly mobilization-reliant strategy:

The root cause of social and economic inequality is an inequality of power. The key to rebuilding a powerful progressive movement is a return to bottom-up base building. Yet too often today, organizations and movements confuse mobilizing mechanisms versus strategies that rely on a deeper form of organizing, one that places ordinary people at the center of struggles for change.

The class of social media applications centered around a firehose-feed of information - like Bluesky, Twitter, Instagram and Tiktok - are broadcasters. Such comms tech is great for mobilizing people around a timely call to action. It enables activist influencers to direct mass attention towards some momentary objective.

What the broadcast feed lacks is continuity and a lasting sense of place and purpose. The planetary discourse moves in lockstep with the 24hr news cycle. Anything older than yesterday gets pushed out of view. This makes it impossible to sustain deep, wide ranging conversations over longer timespans, which is a prerequisite for sense-making.

That's the magic of group chat; it's an actual place for people to be invited into and stick around in. A place where relations, trust and shared language gets built. Every organization with a rich subject matter would be wise to cultivate a community of practice where ongoing topics and initiatives persist for weeks, months and even years, letting knowledge and relationships alike compound.

Maybe this doesn't sound reminiscent of your work's incessant Slack/Teams chat or your rowdy Discord gaming cohorts, but that is a design flaw, not an inherent limitation of the chat paradigm.

Roomy, the gardenable group chat

I started writing this post in the wake of talking to local NGOs about what Roomy (now in early-access alpha) could do for them and their greenfield digital presence. In the process I realized I couldn't explain the value proposition of Roomy without contextualizing it in the wider AT ecosystem it inhabits.

Roomy exists to fill a gap, both in the AT repertoire but also the internet at large. Chat is minimum-viable anything; get two or more people together in a chatroom and you are now building community together.

Many people still perceive of chat as only marginally less chaotic than its feed-centric cousins, and in the case of apps like the earnestly named Discord (meaning lack of agreement or harmony, as between persons, things, or ideas), that perception holds true. But I come from a different tradition of slower, intentional discourse, treating communication as a practice of digital gardening.

Chatty Community Gardens

Group chat is fertile soil for low-stakes ideation. With tending, seeds of thought can grow into structured, evergreen knowledge.

Muni BlogErlend Sogge Heggen

Roomy is a freeform community garden for messages both big and small, fast and slow, wherein participants cultivate knowledge together at the speed of understanding.

On top of that, thanks to the networking magic of the AT protocol we can build discoverability of common cause into our shared spaces. So just like Amazon telling you about other books you may enjoy based on what you've read, we can tell you about other pro-social groups in your locality, physical or virtual.

Find the others

Our message for online change-makers is thus:

If you're a grassroots organization, don't waste your breath yelling into the void of the "town square" to get your message out there. For it is not a town any longer, it's a megacity where any singular voice immediately drowns in the noise of millions.

And don't look for "followers", for anyone who's following you is simultaneously following a thousand other spokespeople, breathlessly proselytizing from atop their soap box every day.

There's a lot you don't want to learn from startup culture, but if there's one thing it has figured out it's how to go from nothing to something. When you're small you can do things that don't scale. That means reaching out to people directly to say "we like what you're putting out and we want you alongside us in our community".

Once you've gathered a hundred people together in a space of persistence, 10-20 of which are showing up regularly and with zeal, only then are you in a position to make yourself known to the wider public, as your voice it now amplified by the supporting cheers and distributed advocacy of your trusted community leaders.

This is the interplay we envision between the organizational power of Roomy and the mobilizational capacity of Bluesky. In tandem they form a unique affordance of planet-scale communications unlike anything we've ever had before in our collective pursuit of broad-boundary coalition building.

Seize the means of communication

The internet activist Cory Doctorow has inspired a lot of the work that's gone into Roomy and its earlier iterations of years past. Cory's two latest books explain how we got ourselves into the mess we're in, and then points toward how we can get ourselves out again:

• The Internet Con: How to Seize the Means of Computation
• Enshittification: Why Everything Suddenly Got Worse and What To Do About It

It really comes down to this:

If you’ve never tried to organize a movement without the internet, I’m here to tell you, it’s really hard. We need to seize the means of computation, because while the internet isn’t the most important thing that we have to worry about right now, all the things that are more important, gender and racial justice, inequality, the climate emergency, those are struggles that we’re going to win or lose by organizing on the internet.

Chat is the minimum-viable tool for online organizing. Without complete control over our means of communication, our ability to organize depends entirely on the goodwill of the very same hegemonic incumbents which we aim to dethrone. They're fine with our rebellious streak so long as it's ineffective, but once it starts actually working their benevolent nature will fade away as if it was never there, just like their long gone ambition to not be evil.

We will not have digital power unless we make it for ourselves. There's only one way for us to reclaim the web as the liberatory technology it was meant to be: Stop Begging. Start Building.

Want to use Roomy for your organisation? You can play with our alpha at roomy.space and contact me at e.soghe@gmail.com directly to talk more.

Back in 2009 Tim Berners-Lee drafted a web-specification for "Socially Aware Cloud Storage":

There is an architecture in which a few existing web protocols are gathered together with some glue to make a world wide system in which applications can work on top of a layer of commodity read-write storage.

(...) The result is that storage becomes a commodity, independent of the application running on it.

Socially aware cloud storage - Design Issues

Design Issues

Several of these ideas were going around in the late 2000s, shortly after the explosive growth of "web2" monoliths like Facebook.

Another spiritually similar idea being championed at the time came from the Opera browser folks who wanted to put "a web server in your browser".

While 'Opera Unite' never fully materialized, Tim's spec got significant traction some years down the road as one privacy crisis after another made the case for stronger web agency self-evident.

In 2015 Tim & co. secured some funding for the Solid Protocol.

Right now we have the worst of both worlds, in which people not only cannot control their data, but also can’t really use it, due to it being spread across a number of different silo-ed websites. Our goal is to develop a web architecture that gives users ownership over their data, including the freedom to switch to new applications in search of better features, pricing, and policies.”

He has made continuous media appearances for the past decade to talk about why this is a necessary evolution of the web as we know it.

Tim Berners-Lee, Inventor of the Web, Plots a Radical Overhaul of His Creation

The creator of the web just received the equivalent of the Nobel Prize for computing. But his work is far from over.

WIREDKlint Finley

On the better web Berners-Lee envisions, users control where their data is stored and how it's accessed. For example, social networks would still run in the cloud. But you could store your data locally. Alternately, you could choose a different cloud server run by a company or community you trust.

You might have different servers for different types of information—for health and fitness data, say—that is completely separate from the one you use for financial records.

To this day, Tim continues to eloquently champion the virtues of the Solid vision.

We have the technical capability to give that power back to the individual. Solid is an open-source interoperable standard that I and my team developed at MIT more than a decade ago. Apps running on Solid don’t implicitly own your data – they have to request it from you and you choose whether to agree, or not. Rather than being in countless separate places on the internet in the hands of whomever it had been resold to, your data is in one place, controlled by you.

Sharing your information in a smart way can also liberate it. Why is your smartwatch writing your biological data to one silo in one format? Why is your credit card writing your financial data to a second silo in a different format? Why are your YouTube comments, Reddit posts, Facebook updates and tweets all stored in different places? Why is the default expectation that you aren’t supposed to be able to look at any of this stuff? You generate all this data – your actions, your choices, your body, your preferences, your decisions. You should own it. You should be empowered by it.

The Solid Protocol remains an excellent idea and has even culminated in an official web specification, but Solid has not yet amounted to any mainstream adoption on the web. Its primary financial sponsor Inrupt (of which Tim is co-founder & CTO) has focused on the enterprise market as a path to sustainability; it remains to be seen what resources will be directed towards web-scale adoption of Solid.

Thankfully those of us who want data ownership and agency in our web applications now don't have to wait. The AT Protocol (as in Authenticated Transfer, but also @) was ushered in by the folks at Bluesky, now with a network of over 30M people strong and increasingly spread across multiple interoperating communities/platforms like Blacksky or Tangled and so many more.

While the respective architectures of the Solid and AT protocols are quite different, they're pointing to the same Open Social Web, re-built on the principles of self-sovereign data storage.

Personal Data Storage

What web-user sovereignty looks like in practice, from the vantage point of atproto, has been expertly illustrated by danabra.mov

Open Social — overreacted

The protocol is the API.

Notice that Alice’s handle is now @alice.com. It is not allocated by a social media company [like facebook.com/alice]. Rather, her handle is the universal “internet handle”, i.e. a domain. Alice owns the alice.com domain, so she can use it as a handle on any open social app. (On most open social apps, she goes by @alice.com, but for others she wants a distinct disconnected identity, so she owns another handle she’d rather not share.)

Bob owns a domain too, even though he isn’t technical. He might not even know what a “domain” is. Bob just thinks of @bob.com as his “internet handle”. Some open social apps will offer you a free subdomain on registration, just like Gmail gives you a free Gmail address, or may offer an extra flow for buying a domain. You’re not locked into your first choice, and can swap to a different domain later.

(...) With open social, Alice’s data—her posts, likes, follows, etc—is hosted on the web itself. Alongside her personal site, Alice now has a personal repository of her data.

This new paradigm is made technically possible by what the AT protocol refers to as a Personal Data Server or PDS for short (what Solid calls a Pod).

The notion of a 'PDS' quickly comes off as something very technical and nerdy which is why it's not mentioned once in Dan's explainer, even though it's still targeted at an audience of web nerds. But really the only obscure word here is the Server, which in this context is interchangeable with Storage, as in Personal Data Storage.

Even regular internet users have some mental model of what personal data storage entails, and they know they’ve entrusted corporations with way too much of it. As such, most people also have at least an inkling that some sort of collectively owned and operated data storage is likely a better model with much fewer incentives for misconduct.

Data-banking Coops

If you're a regular internet user the PDS paradigm won't move your data from the cloud to your personal computer. Most people will still rely on an institutional cloud service, but instead of data-banking with a shareholder-controlled corporation most people’s data can be entrusted to the equivalent of member-owned credit unions for data storage.

One in every three US adults banks with a Credit Union. Achieving similar or better numbers for data storage is far from inconceivable considering how much our collective experience with Big Banking mirrors that of Big Tech/Social.

The concept of data cooperatives has already gained a lot of traction in the fediverse with several providers like social.coop, data.coop and cosocial.ca being operational for many years and still going strong. Soon the AT network will have a similarly co-owned institution in Northsky.

Whether these providers are strictly cooperatives in the formal sense isn't what's most important here though; any suffuciently transparent, democratic and community-oriented data bank (like the aforementioned Blacksky, or the forthcoming Eurosky) is a valid steward and co-creator of an Open Social data bank.

Data Ownership as a conversation changes when data resides primarily with people-governed institutions rather than corporations. Rather than arguing for what kinds of data we ought to be able to download from the corporate silos, the platforms should be asking us what kinds of data they may copy from our servers, and only with strictly temporary allowances.

And while the separation of user data and social platform is most fully realized today in the AT network, there are exciting signs of cross-pollination happening in the ongoing development of atproto’s predecessor ActivityPub. I hope to see similar openness towards technological convergence in Solid for a more pluralistic social web.

Personal Data Storage has long since escaped containment as a concept pertaining to any specific protocol. Some implementations of it will be more mainstream than others, but pragmatic data coops can be protocol-agnostic and storage formats are transmutable.

As long as we have sufficient control of our own data there will always be a way to restart our social graph and digital presence elsewhere in the event of platform collapse. Let’s make the web personal again.

See also:

Be A Property Owner And Not A Renter On The Internet · Den Delimarsky

The year is 2025. The internet in the shape that we’ve known it in the early 2000s is no longer there. Or, not quite in the shape that we’ve seen it before. This is not just plain nostalgia talking - the vibrant ecosystem of blogs, feeds, personal sites, and forums has been usurped by a few mega-con…

Den Delimarsky

Digital Homeownership

You deserve a home on the World Wide Web that’s built to keep you safe; a magical place for virtual living that‘s yours for life, existing in a sociable web.

Muni BlogErlend Sogge Heggen

Avoiding Walled Gardens on the Internet

I occasionally get requests to join private social networking sites, like LinkedIn or Facebook. I always politely decline. I understand the appeal of private social networking, and I mean no disrespect to the people who send invites. But it’s just not for me. I feel very strongly that we

Coding HorrorJeff Atwood

The 5th iteration of Roomy, the gardenable group chat, has just landed!

New Website

We've got a new website, a.roomy.space! It's now our main introduction page for what Roomy is and what we are trying to accomplish.

As roomy stabilizes we'll add more explanations and documentation about how Roomy works and how you can use it.

New Features

Updated UI

In this release, Roomy's UI got an update to use the Fox UI framework, which is developed by @flo-bit.dev, who has been leading the UI development for the last two releases.

This will help us get the UI more stable and avoid chasing little glitches.

The new UI doesn't have the same level of theme customization as the old one, and we may add more options in the future, but for now this will help us make sure that, as we add new features, everything works consistently, regardless of the theme that you select.

Work-in-Progress Discord Bridge

While not ready for general use, we started working on our Discord bridge, which will allow Discord admins to opt-in to syncing with a Roomy space.

We partially bridged a couple of our Discord guilds to act as public demo spaces that you can join to test out Roomy:

• Muni Town
• Spicy Lobster

Right now the spaces are not completely synced and Discord is the "official" source, but we will be working on maturing the bridge to allow fully featured communication between both platforms in the near future.

Stress Testing & Challenges

Hooking up the Discord bridge was a great stress test for Roomy and revealed some weaknesses that we had to work through.

Permission System

While working on the bridge we were noticing some significant slow-downs in the UI compared to previous versions and we also found that the import from Discord into Roomy was going very slow. After some investigation it turned out that the way were were handling permissions with Jazz, our sync engine, had a performance problem that was slowing everything down. Our current setup was designed to allow permissions customization on a per-message basis, but that was creating too many permissions objects.

While it should be possible for Jazz to fix the performance issue, in order to get things functioning right now we worked around it and simplified the permissions model, using the same permissions for all of the messages by the same user.

Bridge Import

Simplifying permissions sped things up dramatically and fixed our UI slow-downs, but we were still having sync timeouts, slow-downs, and out-of-memory crashes while trying to import thousands of messages.

We haven't tracked down the source of the issue yet, and it's possible be that there's something that we are doing incorrectly, but we're not sure yet. To get the release out, we decided to import just our two demo guilds, and kept restarting the bridge after crashes until the whole history was imported.

This got our demo spaces imported, but it's not something we can let other people try out at this point.

Whole Space Subscription

After working through the import problem, we ran into another issue syncing messages in realtime from Roomy to Discord.

In Jazz, every chat message, channel, etc. is a separate, collaborative value or CoValue as they are called. When you load a CoValue you can subscribe to all updates to that value so it stays in sync in realtime with other peers.

This is usually great, and it can work well in the UI so far, but we run into a problem when something like the bridge needs to subscribe to all updates in the entire chat space.

Because each CoValue must be subscribed to separately, in order for the bridge to detect updates like edits, reactions, etc. to different messages, it would have to open and subscribe to every single chat message in the space. This would take a prohibitive amount of memory on the Discord bridge.

While it is possible for Jazz to support deep subscriptions in the future, and in way that won't require keeping all of the values in memory, we don't have that option yet, so we decided to keep only the channels in memory. This allows us to detect new messages in channels, but we don't be able to detect edits or reactions on previous messages, or messages in threads.

This is not acceptable long-term, we will also run into the same deep subscription problem later, when it comes time to implement push notifications. This set us to doing a lot of thinking about different solutions and architectures.

Event-based Architecture

After running into the performance and subscription problems, I started brainstorming different designs that would help improve performance and give us a way to subscribe to the entire chat space for notifications / bridging.

I liked an idea that I had heard of before about using SQLite on the client side as a local store and query engine, and I started taking some inspiration from livestore.dev. This led to more brainstorming, and lots of great chatting with my fellow Roomy dev @meri and a new Muni Town community member, @ndyg.

After iterating on the idea I think we have a good design plan based on event-sourcing, similar to LiveStore, as well as ideas for how to make it very extensible to handle what we'll need in the future.

This new design will end up the third major iteration of our Leaf protocol idea that we've been thinking about for over a year and it will hopefully be the final re-architecture of Roomy.

The plan is to put together a minimal version of the architecture for Roomy alpha 6, and, if it works, to extend it iteratively with extra features and extensibility so it can be a generic framework used outside of Roomy for other apps.

Consider this a bit of a teaser and we'll have an in-depth overview of the new design later.

Summary

In short, the UI is coming along great and is getting more stable as we iterate on it. We've also go some preliminary work done on a Discord bridge along with lessons learned from the effort.

We're running into limitations with Jazz, our current sync engine, and have started designing a new, simpler iteration of our own sync engine in order to make up for it and give Roomy the performance and features we need to support our specific use-case.

We're making great progress, and I can't wait to come back soon with another update!

Today’s release post is presented by the lead dev of the alpha-4 cycle, @flo-bit.dev

hi, i’m florian

hello world! this is my personal website. i’m florian, a full-stack software engineer based in berlin.

We've just released our forth alpha version of Roomy. In this post I’ll talk about what’s new, how to migrate and what’s next on our roadmap.

New domain

While roomy.chat is a great domain, we’re aiming to be more than just a group chat, which our new domain hopefully reflects:

Introducing: roomy.space!

You should automatically get redirected when trying to visit legacy roomy.chat domain.

Backend switch (yet again)

As already teased in the last post, we switched our data syncing layer from our custom placeholder solution to the open source Jazz sync engine.

This enabled us to quickly add some pretty essential features:

• Encryption and access controls
  In earlier versions, anyone could in theory do basically anything, for example edit someone else’s messages or clear the list of banned users in a space. Thanks to jazz’s built in access controls this should now be impossible (we haven’t extensively tested this yet, though).
• Public access without logging in
  While we could have enabled that earlier, for spam protection we didn’t allow anyone to view spaces before, without being signed in. Now you can actually view spaces without a user account and only interactions require you to sign in.
• Better performance
  We’ll do some extensive testing over the next weeks, but it already feels snappier, especially for channels with lots of messages.

Most importantly for us, we can now focus on new features and UI/UX improvements instead of having to spend lots of time fixing bugs in our placeholder backend.

The Jazz team knows we are huge fans of the Keyhive design and its unique affordances for building ‘sovereign communities’. Keyhive isn't ready for use yet and won’t be for some time still, so we will go as far as Jazz can possibly take us—which might be very far indeed if Jazz can provide those same affordances in its own way.

In parallel with our production-service being built with Jazz we will be contributing to and experimenting with Keyhive. On that note...

BeeKEM explained

Another fresh member of the team, Meri, has been studying Keyhive (among other cool things we will get into in following releases), starting at the distributed-encryption layer BeeKEM:

meri leeworthy 🌸 (@meri.bsky.social)

I’m pretty excited about @inkandswitch.com’s Keyhive project, and I really wanted to feel solid on the novel key management approach they use called BeeKEM - so I wrote this explainer article about it! Tysm to @expede.wtf for helping me make some sense of you and the team’s work ✨ https://meri.garde…

Bluesky Social

I’ve spent the last year working on local-first apps, most recently with Muni Town. For me, ‘local-first’ isn’t just a technical architecture — it’s a political and social stance. It’s about shifting control: from remote servers and top-down central authorities deciding how data, workflows, and communities operate, to individuals and communities reclaiming that control and gaining autonomy. Seen this way, privacy and consent aren’t add-ons — they’re foundational, just as critical as sync or data locality.

Ink & Switch’s Keyhive project is a capabilities-based system for CRDT authorisation and sync that opens up real possibilities for privacy-preserving local-first apps. Libraries like Automerge, Yjs, and Loro have already made it viable to build real-time collaborative apps without relying on a centralised authority to manage consistency. Yet in practice, we still lean on central servers for sync — with all the privacy implications that entails.

Other new features

While rewriting our backend, we also couldn’t resist to add one or two new features, the main two being:

• Unread markers for channels
• Notification markers for mentions and replies

We removed Custom Space Domains for now, but will soon re-introduce them using your Bluesky account, which will hopefully make this both easier (just a button click in the channel settings), faster (as you don’t have to wait for a DNS record to propagate) and useable without a custom domain (just use your Bluesky handle).

Migration

If you already had a space before, this is how you can migrate it to the new version:

1. Go to the old version at alpha2.roomy.chat and export your space in the space settings, which will download a zip file
2. Remove "alpha2." from the url address, click "import space", upload the zip file and wait until it finished importing, your channels, threads and messages should all be imported, but all members will have to join your space again.

Next on the roadmap

• UI redesign
  • Cleaning up all the buttons, etc that cropped up
  • Unify the design and make it easier to understand and use
  • Space home page
• Discord import and bridge
• More direct Bluesky integration
  • Integrated Bluesky Feeds
  • Use your handle as a space name
  • Integrate Bluesky DMs
• Improve Pages (better editing, smarter rendering)

Let's talk about business practice as a net-good within the commons, as opposed to an external extractor of it.

I've previously alluded to our ambitions to build a non-extractive, post-growth company:

Weird inc.

Mindfully growing a non-extractive company towards a ‘steward ownership’ end state.

Muni BlogErlend Sogge Heggen

To recap, while I appreciate that a company like Bluesky did its very best to protect the laudable values and vision of its founders, there's got to be a better alternative to the prevailing company-formation model than what they've earnestly admitted results in The Company inevitably turning adversarial towards its own product and values in the long term.

While I find any company that has taken tens of millions in VC money innately unnerving, I doubt there was any other way for Bluesky to build a desperately needed offramp for X/Twitter in time for the mass migration that consequently happened, so I commend them for navigating those perilous waters as best they could.

That said, I don't fully agree with this statement:
> Businesses live & die on a shorter timeline than people

That's only true in the modern era, especially for tech companies. There's a reason why we've got a whole bunch of people walking around with last names like 'Carpenter' and 'Mason'. Kongō Gumi famously existed independently for nearly 1500 years before it finally succumbed to modern capital pressures.

So while I agree with the general strategy of designing products and ecosystems under the assumption that their commercial benefactors are "possible future adversaries", it must not be considered an inevitability, lest it become a self-fulfilling prophecy.

A tech company with the longevity of IBM (113yrs old) but the ethical backbone of Patagonia is possible.

That inquiry has led me to the concept of steward ownership. (Update: In October 2025 I distilled the essence of these ideas into a 3-minute talk titled Your self as a future adversary.)

The most profound act of corporate responsibility for any company today is to rewrite its corporate bylaws or articles of association in order to redefine itself with a living purpose rooted in regenerative and distributive design and then to live and work by it.

~ Kate Raworth, author of Doughnut Economics

Rather than being resigned to a story of "company as a future adversary", we can utilize the framework of steward-ownership to reify our vision for "company as a future commons".

Steward-ownership is about structuring a company in a way that separates economic rights (to money) from voting rights (to decision-making power). These models have been tested in modern forms for over a century.

Often structured as trusts, foundations, or employee-owned companies, all of these companies have fundamentally redefined ownership by committing to two principles:

(1) Self-governance — Control remains inside the company with the people directly connected to stewarding its operation and mission, not external investors or absentee owners. With the control of the company held in a trust, it can no longer be bought or sold.

(2) Profits serve purpose — Wealth generated by these businesses cannot be privatized. Instead, profits serve the mission of the company, and are either reinvested in the company, stakeholders, or donated. Investors and founders are fairly compensated with capped returns/dividends.

Considered an alternative to the destructive paradigm of shareholder primacy, steward-ownership can be implemented using various legal forms depending on the type of company and jurisdiction. The less established the legal framework, the more creative one needs to get.

What’s steward-ownership?

Rethinking Ownership in the 21st Century

MediumPurpose

Business for Purpose

Unlike a coop or a Public Benefit Corporation which can be acquired or redesignated, the principles of a steward-owned company are binding in the long-term.

The distinction is made painfully clear in the case of the well-intentioned social network Waxy:

The Quiet Death of Ello’s Big Dreams - Waxy.org

Ello launched in 2014 with big dreams, but the artsy social network suddenly shut down last year, deleting nine years of posts without warning. What happened?

Waxy.orgAndy Baio

Their founding charter as a PBC ambitously stated "in the strongest possible legal terms" that:

1) Ello shall never make money from selling ads;
2) Ello shall never make money from selling user data; and
3) In the event that Ello is ever sold, the new owners will have to comply by these terms.

Ello exists for the benefit of the creative community, and we will never serve ads or sell personal data.

Spoiler at the end of the article:

Despite their idealist manifesto and their Bill of Rights, I don’t believe they could ever truly be in partnership with their community once they were taking large amounts of venture funding. All of their ideals and big dreams were easily undone, even the legal restrictions they defined in their Public Benefit Corporation charter:

1) Ello made money from selling ads to third parties;
2) Ello made money selling their user data to a third party;
3) Ello was sold, and the new owners didn’t comply with those terms.

We've got to do better than that. Surely we can do better than that!

Just like other forms of equitable and participatory co-ownership, steward ownership is not a silver bullet. Yet it leans heavily toward broad rather than narrow power distribution and legally preempts the most common predatory tactics of the hypercapitalized global marketplace.

Want Purpose-Driven Businesses? Rethink Ownership.

If we want to create more sociable businesses, we need more than purpose-statements. We need to ask: who holds power in companies?

MediumPurpose

Meaningful change requires us to address the fundamental structural deficiencies of our system, by rethinking the goals and incentives that guide decision-making in companies. We need to ask ourselves: who holds power and what is motivating their decisions? To create new solutions that harness the potential of capitalism (entrepreneurship, innovation, competition, a decentralized economy) and move beyond its failures (greed, consolidation, inequality), we must challenge one of the fundamental paradigms of capitalism: the understanding and definition of corporate ownership.

Over the last two centuries, there have been two main mechanisms allocating corporate ownership: (1) buying/selling a business and (2) family succession/inheritance. The former sells the “steering wheel” of the company to the highest bidder, the latter passes it to heirs. These have been the two primary mechanisms of capital and ownership-allocation: the principles of (1) money and (2) blood. The corresponding motivational mechanisms have been profit-maximization and wealth building. In this paradigm, a company is something you own and your objective is to profit from it.

(...)

In Denmark, the combined market capitalization of steward-owned corporations represents 60% of the entire value of the Danish stock marketindex. Studies from Copenhagen University and Yale University with data from Danish foundation-owned (=steward-owned) companies show that foundation-owned companies have a higher survival probability than conventionally-owned companies. While other conventionally-owned companies have survival probability 10% after 40 years, foundation-owned companies have a 60% survival probability over the same period. In addition, foundation-owned companies have a higher employee retention rate and pay higher wages, while at the same time being similarly profitable as non-foundation-owned companies. Foundation-owned companies also have a strong reputation among consumers.

Steward-ownership not only enables companies to better internalize externalities, it also helps combat the growing wealth gap and inequality caused by inherited wealth accumulation. Because steward-owned companies cannot be inherited, they help prevent dynastic wealth accumulation. What’s more, they prevent owners from siphoning rent off of businesses. Instead, steward-owned companies are “self-owned.” These businesses belong to the commons, serving their purpose and all stakeholders who contribute to their successes and helping to create a more equitable, regenerative economy. Capital is in this sense democratized.

Mainstream examples include Patagonia (US), Mozilla (US), Sharetribe (Finland), Novo Nordisk (Denmark), Ecosia (Germany) and Bosch (Germany). They're not all prime exemplars of post-growth enterprises, but they're still far more transparent and democratically run than their respective peers.

For a modern take we can look to Vyld, a biotech company fom Germany established in 2021. As a producer of women's health products made of seaweed it was paramount for Vyld that their company was as good as their product.

It just doesn’t make sense to produce a great, sustainable product, but
then have an exploitative company structure and culture.

Instead of going the easiest route with VC capital that expects 10x-50x hypergrowth across 5-8 years for an equal or bigger ROI multiplier, they opted for far more limited amounts of capital from investors supportive of incremental growth and a fixed (e.g. 3x cap) return on investment, without giving away any voting control in the company. This way Vyld cannot be bought up by P&G only to be relegated to green-washing in a megacorp.

Steward-owned Roomy corp.

Steward Ownership isn’t yet a box you can check off with ease, though in a few select locations that will soon change thanks to persistent pioneers in the Netherlands and Germany. (Exhaustive Summary)

For most places still it’s more like a voluntary self-certification of equitable co-ownership.

Implementing this in my home country of Norway (and possibly also in the US, depending on how strange our geopolitical situation gets in the coming months) is going to require novel Articles of Association that set us up with a public commitment towards an ‘exit to steward ownership’, closely related to the notion of 'exit to community'.

Documents like this blog post are part of that public promise. Another one is our Values page.

What do we work for:
We work cooperatively to enrich The Commons, in service of the global community.

Why we do the work:
The Commons[1][2][3] is what sustains us and our communities, so enriching it is to enrich our selves and those in our localities (digital or otherwise) in an ecologically sustainable manner.

In much the same way that Patagonia is obligated to reinvest its profits into the environmental ecosystem it extracts from, Weird inc. (or Roomy corp.) is obligated to reinvest its profits into the commons, primarily in the digital realm by funding its open source dependencies.

Any investments into our venture (our first modest angel investment will be announced shortly) will only be accepted on the condition that our path towards becoming a fully steward-owned company is unimpeded.

We think the commons-owned company is the scarcely discussed middle way.

Here we are, anguishing over whether we should relinquish what little remains of our shared resources to Big State or Big Capital, meanwhile there was a third, much less hazardous alternative available to us all along. Well, not so readily available just yet, but this form of collective ownership can quite literally be imagined into being if only we believe in it enough to write our own rules for a fairer game that isn't predicated on top-down authority.

Further Reading

Steward-ownership: For Entrepreneurs Who Want to Make a Positive…

Have you heard about steward-ownership? If not, you probably heard that Patagonia’s founder, Yvon Chouinard, is giving away his company to fight climate…

Corporate Rebels

Steward-ownership is capitalism 2.0

This post dives into the background and practice of steward-ownership and how we’re applying it at Sharetribe.

SharetribeSharetribe

How to build companies that are a force for good in society

Most technology startups say they’re “making the world a better” place as anyone who watches the TV show Silicon Valley knows. Reality is…

Better sharingJuho Makkonen

On what matters

This post was originally published in Sharetribe’s internal communication channel. I wrote it to describe to the team what motivates me in…

Better sharingJuho Makkonen

And a topic for another day: Regenerative Economics ♻️

This is how we build the future: Teaching Regenerative Economics at all levels with Jennifer Brandsberg-Engelmann

How do we let go of the sense of scarcity, separation and powerlessness that defines the ways we live, care and do business together? How can we best equip our young people for the world that is coming - which is so, so different from the future we grew up believing was possible?

ACCIDENTAL GODSeverydaywild

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 💞

• https://meri.garden/Leaf
• https://meri.garden/Leaf%20Render%20Update%200

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.

Jazz - Whip up an app

Jazz gives you data without needing a database — plus auth, permissions, files and multiplayer without needing a backend. Do everything right from the frontend and ship better apps, faster.

Jazz

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 👋

The roomy.chat demo is back online!

Roomy is an Open Source group chat app that integrates with Bluesky and the AT Protocol. You can join our Roomy chat space to come say hi, or you can even make your own chat space.

For a quick video intro to Roomy, check out zeu's talk "Message Gardening in the Atmosphere", performed a week ago at the epic ATmosphere Conference!

Further reading:

Chatty Community Gardens

In the virtual world we think of digital gardens first and foremost as individual, personalized spaces. Yet in our physical cities the pro-social concept of Community Gardens is much beloved and far more accessible to the majority of city dwellers.

Muni BlogErlend Sogge Heggen

In today's post I'm going cover the state of Roomy: what it's doing right now, how it's working, and some of the ideas we've got for next steps.

Features

Themes

The first obvious new feature we've got is themes! @zeu.dev hooked up a theme system from Daisy UI so now we have a bunch of built-in themes you can select from.

On top of that, Daisy has a theme creator that you'll be able to use to create your own themes soon.

Rich Text Input

We've also gotten a first pass on the rich text input field. This allows us to do things like render @mentions and #channel references.

That said we still have some work to do on the rich text editor, and we lost features like links & images in the refactor, so we'll be re-adding those as soon as we can.

Space Domains

You can now setup a custom handle for spaces by using domains, just like you do if you have a custom BlueSky handle!

In short this lets you go from:

• Before:https://roomy.chat/leaf:3gv98mf2b4psk6183cx3yv9p4gh62pgx6thesmnhx3gjq8w7dm70
• After:https://roomy.chat/-/example.com

(Wiki) Pages

We also added a first pass on "Wiki pages", though in a subsequent iteration they'll be relabeled as just "Pages". Alongside our index and sidebar, the design for pages in Roomy is going to evolve quite a bit, but for now we have a simple setup where anybody can create an edit pages.

These pages are not "collaborative" in real-time, and if two people are editing the page at one time, it won't merge their changes: whoever saves last will overwrite the other persons edits. This is something we will improve in the future and eventually you'll be able to see each-other's edits in realtime.

General UI Improvements

There have also been lots of little UI improvements, as well as underlying improvements to the way things are organized so that it's easier for us to continue working on new features in the UI.

Removed Direct Messages

We have also removed direct messages for now. Direct messages were an early feature we made to test our our synchronization since syncing with only one other person made it easier to work on at first.

Now that we've gotten going, though, direct messages are really not the feature we are prioritizing for Roomy; public, forum-like community spaces is our first goal, and Bluesky already has working direct messages and is working with the community to figure out E2EE alongside pioneers like Germ Network.

Removing direct messages makes it easier for us to focus on other features and lets us move faster.

Invisible Changes

On top of the UI improvements, there has been a lot changing under-the-hood for Roomy. We now have our very own Roomy SDK, we're using a different CRDT, and we have an extremely useful new data model.

Here I'll go over some tech details. Feel free to skip to Summary of Current State & Next Plans if you aren't as interested in this bit.

Loro CRDT

The first change is that we are now using the Loro CRDT instead of Automerge.

The first reason was while doing some benchmarking we found that Loro could load a large document storing many IDs much faster than Automerge ( for now ). Loro is able to store the latest state of the document and then lazily load the history if you need it, which fits our future CRDT to webpage rendering needs very well.

Loro also has some useful features like movable lists and trees which we will have use for in Roomy.

To be clear, Automerge and the people who make it are awesome! They are also making tons of performance improvements on Automerge right now. We are designing things to be relatively CRDT agnostic, and we aren't totally bought into anything specific yet so things could change in the future.

Leaf SDK

On top of Loro we finished our first pass for the Leaf SDK.

Leaf, or the "Leaf Protocol", is an idea that we've had in mind for a while now as we've worked on Weird. Leaf is an opinionated framework for building offline-capable apps with great sharing and collaboration features. It's the foundational "database" that we are building Roomy on top of.

Our ideas for Leaf have evolved quite a bit recently and giving an overview of it is going to take its own blog post which I'll have to write later.

For now it's good enough to understand that Leaf is our "database" and is used to store and sync Roomy data.

This first version of Leaf doesn't have the solid permissions and capability system that we have planned for it. That will be powered by Keyhive, an awesome new library by the Automerge (Ink & Switch) folks. Keyhive isn't ready to use just yet so we're continuing on with partial features until that is ready for us to integrate with Leaf.

Roomy SDK

On top of our new Leaf SDK we built the Roomy SDK!

The Roomy SDK is like the library version of Roomy. It's a way to interact with all of the Roomy data through code, without the UI. The UI uses the Roomy SDK to do everything that it does.

This is super great because it means that other people will be able to make their own apps that integrate with Roomy. They could even make their own Roomy UI. Maybe someone could make a terminal UI for Roomy? 👀

The New Data Model

The major importance of the new SDKs is that it allows us to finally start using the Entity-Component data model that we've been looking forward to.

This data model was something that I started thinking about for building inter-operable web apps 10 months ago in A Web of Data. The hope is to provide a very fluid, but still structured, data model that we can use to allow apps to read and write data while still being incrementally compatible with each-other.

The Entity-Component model says that everything, no matter what it is, is an entity with its own ID, and all of that entity's data is stored in components. These components are standardized similar to ATProto Lexicons, but because an entity can have multiple of them, it allows multiple different apps to attach their own data to the same entity. It also allows apps to partially understand an entity, and interact with it even if it doesn't understand all of its components.

This concept is so powerful for enabling Roomy's content gardening and fluidity features.

It's because of this Entity-Component model that you are going to be able to convert threads to channels and vice-versa seamlessly. It can allow you to do things like attach a Roomy thread to a wiki page or anything else so that you can chat about it.

Things like wiki pages, notes, chat spaces, threads, they are all just another entity, and they actually share a lot in common. All of them have names and possibly an icon / profile image, or a description. Both channels and threads have a timeline of chat messages. These common components act as interfaces that make it very easy to interact entities in code.

These entities can also be linked to each-other to create a rich web of information that doesn't impose a pre-defined structure, limiting the data and isolating it to wherever you put it first.

With the new model, we will be able to very easily implement "federated channels", i.e. a channel that exists simultaneously in two different chat spaces! All it takes is two chat spaces that link to the same channel entity.

Summary of Current State & Next Plans

So at this point we've got improved UI and a new data backend, but we've still got a ton of work to do!

Roomy is still in Alpha. That means that basically anything might be critically broken. Also, all data is completely public. Don't put anything in there you don't want the whole world to see. Roomy is relatively insecure while we wait for the Keyhive capability system that we are planning on using to get to a testable state.

That said, we are doing our best now to keep the chat spaces you create up and we have some best-effort backups to protect against data loss.

There are lots rough edges to polish and we'll be tackling that bit by bit.

Some of the things that we're thinking about working on soon:

• Stress testing to make sure that we can handle 10s of thousands of messages in channels.
• Experimenting with Discord bridging.
• Making chat rooms and pages web indexable.
• Letting you use your own domain to access Roomy, so you can allow people to chat directly under your own website, like chat.example.org.
• Publishing websites from your Roomy wiki pages.

I'm super excited for what's coming up!

If you got any questions feel free to ping me @zicklag.dev on Bluesky!

For a lot of us the “simple” prospect of filling in a web page with content presents an insurmountable writer’s block.

The decision to make a personal website is held back by the ‘content-creation imperative’; a nagging sense that a certain amount of stuff is required to justify your site’s existence. Stuff like blog posts, ‘the story of me’, personalized styling and so forth.

All very good stuff, but none of it is necessary for planting one’s roots in web-soil. On the contrary, this upfront labour becomes prohibitive and the project gets put off for another day.

For all their flaws, this is in large part why the mainstream social media applications have been so successful: All they ask for is a blurb. String just enough words together for a paragraph or two, and there’s your post, announcing your presence to the web and participating in the cultivation of The Commons.

Chatty Community Gardens

In the virtual world we think of digital gardens first and foremost as individual, personalized spaces. Yet in our physical cities the pro-social concept of Community Gardens is much beloved and far more accessible to the majority of city dwellers.

Muni BlogErlend Sogge Heggen

But the most pervasive among these platforms subject their users to another kind of content imperative: Always Be Posting, otherwise you’ll fade back into obscurity. And obscurity, in the eyes of the legacy platforms, is worse than death.

So what is an aspiring homesteader to do?

In recent years, a new kind of personal page format is trending. Popularized by Linktree, these minimal landing sites grew out of the constraints of web-hostile platforms like Instagram that would only allow a singular ‘link-in-bio’—why? because authentically unmitigated self-expression is an existential threat to their world of warped mirrors.

The solution was a wondrously webby hack: Use that one precious link to point at a bunch of other links! And so the 'linkspage' convention was born.

Yet in the age of feudalistic social media, most of our ‘personal links’ will still be pointing to fragments of our digital selves that are trapped inside walled-garden mega platforms. They’re significant parts of our identity nonetheless, thus hard to fully let go of.

Thankfully the radical act of collecting those links together in a space you own is enough to begin your journey of digital emancipation in earnest. With any effort to consolidate your identity, you are actively reclaiming ownership of your story online.

Map your multitudes and insist upon yourself!

Molly White (@molly.wiki)

I have more coming on this topic soon, but for now: don’t let perfect be the enemy of good. Your own domain pointing at your social media presence on a third-party platform is a step in the right direction. Backing up your posts on other platforms. Creating a website with a webhosting service. etc

Bluesky Social

Recipe for web agency

To recap:

• Step 1: Own your digital home
• Step 2: Resist the content-imperative (you are here)
• Step 3: Re-center your digital self

The third step, which is what a marketing-focused app like Linktree doesn’t concern itself with, is treating every single one of those links as an item in a TODO-list. And the Job to be Done for each link is simple:

Smash a hole through that walled garden and get your data back!

Data Defragmentation

‘Weird the data importer’ is our wedge into the data fortresses keeping our digital identities captive. PESOS - Recenter the publishing pipeline PESOS is an acronym for Publish Elsewhere, Syndicate (to your) Own Site. It’s a syndication model where publishing starts by posting to a 3rd party servi…

Muni BlogErlend Sogge Heggen

With this we're hoping we've made it a little clearer how Roomy and Weird are two sides of the same coin.

• Roomy is at the intersection of chat(sync) & forum(async)
• Weird is at the intersection of wiki(collective) & blog(individual)

They're essentially the same thing being built twice, for two different use cases that meet in the middle: community and identity.

The unifying force will be the Automerge-CRDT stack (our 'app engine') as well as a shared identity layer.

End-of-february we're releasing Weird v0.4.1 (bringing Link Embeds) along with a greatly updated website to clarify Weird’s value proposition as a web app for digital gardening.