I’ve been thinking a lot about the direction of OnlineVibes.

The roots of this project go back much further than the current codebase.

In the mid-to-late 90s, I remember using ICQ and being genuinely amazed by the idea of real-time online presence. Not just messaging, but knowing who was online, who was available, and being able to instantly connect.

Then, in the early 2000s, I discovered Jabber/XMPP — and free Jabber clients — and it completely changed how I thought about communication software. Open protocols. Federated identity. Real-time messaging. Presence as a first-class concept.

There was another influence too.

In my early twenties, my friends and I used to do a kind of “YouTube DJing” at parties in the London underground music scene. Someone would put on a track, someone else would jump in with a related one, then someone would take it somewhere completely unexpected. It was collaborative, chaotic, social, and very human.

That experience has stayed with me.

Part of the drive behind OnlineVibes has always been to bring some of that feeling online: shared rooms, presence, music, conversation, discovery, and a more peer-to-peer sense of participation.

There was also an earlier version of the OnlineVibes idea around 2011: an online marketplace for DIY musicians, bands, and independent labels. At the time, I was interested in how small music communities could use the web not just to promote themselves, but to connect more directly — sharing music, building scenes, finding collaborators, and creating lightweight alternatives to the increasingly centralised platforms that were starting to dominate online culture.

That idea never fully became the thing I imagined, but it left an important trace. OnlineVibes has always had this tension inside it: part communication tool, part community space, part music discovery platform, part experiment in giving people more direct ways to gather online.

Around 2016, I started properly experimenting with ejabberd. Since then, OnlineVibes has gone through many iterations: different deployment approaches, different ideas about user experience, different levels of complexity, and plenty of false starts.

The biggest change recently has been simplification.

Now that the stack is Docker-based, the project is much easier to run, reason about, deploy, and evolve. What once felt like a fairly niche personal experiment is starting to look like something much more practical.

That creates an interesting fork in the road.

On one hand, OnlineVibes feels like an ideal candidate for a new Empathy / elib-base / bdcli quickstart template — alongside projects like elib-blog, elib-cms, elib-acl, and others. A ready-made foundation for building real-time chat, presence, and community applications.

On the other hand, there may also be commercial potential here.

Could OnlineVibes become a closed-source platform?

Could it become a licensable piece of infrastructure for building AI-enabled chat room and presence software?

Could it sit somewhere between those two worlds — with an open developer template at the base, and commercial products or services built on top?

That’s the part I’m still working through.

The hardest challenge right now is not really technical. It is getting people to actually use it early enough to help shape it. Some close friends and family have been enthusiastic, but turning that enthusiasm into regular usage and useful feedback is difficult.

That puts the project in a strange place: technically much more mature than before, but still looking for the right initial user loop.

Still, I think that is a good problem to have.

After years of experimenting with XMPP, ejabberd, Docker, Empathy, deployment automation, and the social mechanics of online presence, OnlineVibes is becoming less of a vague idea and more of a reusable foundation.

Maybe it becomes a community template.

Maybe it becomes a commercial platform.

Maybe it becomes a licensable technology layer for AI-enabled chat and presence software.

Or maybe it becomes some combination of all three.

Either way, it still comes back to the same idea that first grabbed me years ago: being online should feel alive.

I've pretty much only been listening to this EP from 2024 by Australians, Garage Sale for the past six weeks.  Check it!

Coming soon in the form of new Empathy releases for bdcli and base-docker. The platform features are using the same philosohy as my orginal Empathy MVC - fun, light, simple.  (KISS, DRY).  It's taken a long time to get to this point but the webiste you are viewing right now is running and deployed in this fashion (the same for my other sites) and some of the platform code is yet to be published on github.  It will probably be under "elib-platform".  I still want to do a slight documentation overhaul for bdcli/base-docker to run a new user through the entire deployment of this setup end-to-end in time for these releases. More info coming soon.

Overview:

This architecture is split into four main concerns: build/test, source control and artifacts, edge routing, and production runtime.

Build / Test Environment

A Test/Build server (currently a Raspberry Pi) runs Docker. Inside Docker:

• Jenkins is used for CI/CD orchestration.
• Web app 1 runs as a test or staging instance.

Jenkins is responsible for building, testing, and coordinating deployments, but it does not serve public traffic.

Source Control

A private Git server hosts the application source code.

• The Test/Build server accesses the Git server over SSH.
• No VPN or overlay network is used for Git access.

Container Images and Artifacts

GitLab is used as a central artifact store, specifically for Docker images.

• GitLab hosts a Docker Container Registry.
• Application images are built and maintained using Packer.
• Both the Test/Build environment and the Production environment pull Docker images from this registry.
• The registry acts as the single source of truth for deployable artifacts.

Edge and Routing

Cloudflare is the public-facing entry point for all external traffic. It owns and manages the following hostnames:

• *.tublr.com
• www.tublr.com
• www.mysite.com

Depending on the hostname, Cloudflare routes traffic to different backends:

• Some traffic is routed directly to the Production server.
• Some traffic is routed to an AWS EC2 Proxy server.

The Proxy server runs Caddy directly on the host (not in Docker). Within Caddy:

• www.tublr.com is explicitly handled.
• Requests for that hostname are reverse-proxied to the Test/Build server.

The reverse proxy connection between the Proxy server and the Test/Build server runs over Tailscale. This is the only place Tailscale is currently used in the system.

Production Environment

The Production server runs on AWS EC2 and hosts Docker.

• Docker runs Web app 1 as the production instance.
• Production receives:
  • Public HTTP(S) traffic directly from Cloudflare
  • Deployment actions from the Test/Build server

Production does not receive traffic via the Proxy server.

Deployment Flow

Deployments are initiated from the Test/Build server:

• Jenkins coordinates deployments.
• Production pulls the required Docker image from the GitLab container registry.

Capistrano-style deployments (atomic release switching and fast rollback) are planned, but are not yet implemented.

Design Principles Reflected

• Build, deploy, and runtime concerns are separated.
• Only real network paths are described.
• No aspirational infrastructure is included.
• Artifacts are immutable and centrally managed.
• Public traffic and control traffic are distinct.
• The system is intentionally v1-focused, with broader orchestration (e.g., ECS) reserved for a future iteration.

New Empathy discord server. Come and ask me anything!

Go to https://empathy.sh and click the community link!