Monoverse: Building a Community Around an IRC Channel

The Internet doesn't need yet another social network.

What it still needs, however, are independent places where communities can meet, talk, publish content, and build their own identity without simply becoming a page, a group, or a server hosted inside someone else's platform.

Monoverse was born from this idea.

It is an open-source framework designed to build a community with an IRC channel at its core.

IRC remains the place for real-time conversation. Around it, Monoverse builds everything else: user identities, profiles, content, asynchronous discussions, a magazine, widgets, moderation tools, and integrations tailored to different kinds of communities.

We don't want to turn IRC into a social network.

We want to show that something new can still be built around IRC.

One framework, different communities

Monoverse wasn't designed with just one kind of website in mind.

From the beginning, the Community Edition has been designed so that its features can be combined differently depending on the community using it.

For now, we have identified four main use cases:

Traditional communities, where chat, profiles, Pings, Pongs, and content can extend the life of the community beyond real-time conversation.

Developer communities, which can combine chat with content and widgets dedicated to development and GitHub activity.

Web radio communities, where the IRC channel can once again become the place where listeners, hosts, and staff meet, while Monoverse integrates the player, station information, statistics, and song requests through services such as Icecast and AzuraCast.

Crypto communities, where cryptocurrency-related features can complement the usual social features without turning Monoverse into a financial intermediary.

These are the first four use cases. They don't have to be the last.

The goal is for the community to decide what to build around its channel, rather than for Monoverse to decide what a community should look like.

Security also starts with what you choose not to store

One of the principles behind Monoverse is very simple: if we don't need to possess sensitive data, we'd rather not possess it.

That's why Monoverse isn't designed to become a huge repository of credentials, passwords, and private keys.

Authentication can be delegated to an identity provider through OAuth, while Monoverse keeps only what is necessary for the community and its features.

The same philosophy becomes particularly important when cryptocurrencies are involved.

For years, many social platforms have talked about integrated wallets and payments. But building an actual custodial wallet means holding users' funds or keys, which can introduce operational, security, and regulatory responsibilities far beyond those of a normal social platform.

Monoverse has chosen a different approach.

When we integrate a self-custodial wallet, the wallet remains under the user's control. Keys are never handed over to the community, and Monoverse doesn't have to become the custodian of anyone's funds.

The Dogecoin features we're building follow exactly this principle through integration with MyDoge: Monoverse can provide DOGE-related social interactions without storing the user's private keys.

It's an architectural difference before it is an ideological one.

And it's also one of the things we find most interesting about the Open Internet: different services can cooperate without one of them necessarily having to own everything.

Ping and Pong: IRC is in the names too

The social side of Monoverse revolves around two concepts: Ping and Pong.

A Ping is content published within the community. It can contain text and, when the community configuration allows it, attachments and multimedia content.

A Pong is the reply.

The names aren't accidental.

PING and PONG are part of IRC's language and among its most recognizable mechanisms. We wanted to bring them outside the chat itself and use them to identify asynchronous conversations in Monoverse.

It's a small nod to the project's origins, but also a way to avoid copying the vocabulary of the big social networks yet again.

There are no tweets, posts, or toots.

There are Pings. And someone can reply with a Pong.

Chanzine: a community can tell its own story

A community doesn't produce conversations alone.

It produces knowledge, stories, guides, announcements, in-depth discussions, and content that deserves to survive beyond the flow of a chat or timeline.

That's why Monoverse includes Chanzine, its editorial component.

Chanzine allows a community to have its own magazine, organize articles into categories, and build an editorial section directly alongside its social features and chat.

And it doesn't necessarily have to be a publication where only the administrator can write.

Users can submit articles to the community's editorial team. Submissions remain separate from actual publication and can be reviewed before becoming part of the magazine.

It's deliberately different from unrestricted publishing: the community can participate in creating its own content while maintaining a genuine editorial direction.

Widgets give the community an identity

Installing the same software shouldn't mean ending up with a hundred identical communities.

That's why widgets and block areas are an important part of Monoverse's architecture.

A web radio can highlight what's currently playing and who's in the chat. A developer community can give prominence to its GitHub activity. Another community might prioritize its latest articles, most active users, or other elements that represent it.

Widgets aren't simply sidebar decorations.

They are meant to immediately answer one question:

what kind of place is this?

This is one of the goals we're focusing on the most: when entering a Monoverse community, its identity should be apparent before you even know everything the software can do.

IRC isn't an add-on

This is probably the most important distinction.

In Monoverse, IRC isn't a webchat bolted onto a CMS.

The channel is the starting point.

The presence of IRC users can become part of the web interface, community information can coexist with what's happening in the chat, and the entire site is built around the relationship between real-time activity and web activity.

The idea is simple:

who is here, what's happening, what are they saying, and what is this community doing?

A community should be able to communicate that the moment someone arrives.

RSS: letting content travel beyond Monoverse

If Monoverse wants to be part of the Open Internet, content published by the community shouldn't remain trapped inside the site.

That's why Ping and Chanzine will have their own RSS feeds.

It's a simple, open, established technology, and most importantly, it doesn't depend on a central platform.

The Chanzine feed allows community articles to be followed through any RSS reader or consumed by other services.

The Ping feed also has a particular role in the relationship between the web and IRC.

A bot can follow the feed and notify the channel when new Pings are published on the website. In our case, MediaBot will be able to do this, naturally bringing some of the activity happening on the web side of the community back into the IRC channel.

So the flow isn't only IRC → website.

It can work in the opposite direction too:

website → RSS → IRC.

It's another small example of the Monoverse philosophy: using open standards to allow independent components to communicate with each other instead of necessarily building everything into a single application.

Building on the Open Internet

Monoverse also comes from a broader belief.

Not everything needs to be rebuilt inside a single platform.

IRC can handle real-time communication. OAuth can handle identity. GitHub can handle collaborative development. A self-custodial wallet can handle keys and transactions. Icecast or AzuraCast can handle radio streaming. RSS can handle content distribution.

Monoverse can connect these worlds and build the community experience on top of them.

This modularity isn't a limitation.

It's the strength of an Internet made of protocols and services that can talk to each other.

The first beta

Monoverse is still a young project.

The first public beta isn't meant to present itself as a finished product or promise features that don't exist yet. It's the first release of a framework that we have already started using to build its own development community.

And that's exactly where we want to keep testing it.

Because Monoverse should grow in the same environment it was designed for: a real community built around an IRC channel.

If it works, every installation can become something different.

But at the center, there will still be something surprisingly simple.

A channel.
Some people.
A community.