lounge.

LoungeBuzz

A Buzz open-protocol team relay with memory and in-channel assistance.

The same chat, the same clients, the same open protocol — with channels that remember what was said, answer questions about it, and can run entirely on infrastructure you control.

what it speaks Standard clients use the standard protocol; memory and assistance run in the relay. ANY STANDARD CLIENT Buzz desktop app open protocol · group support THE RELAY LoungeBuzz groups · membership · moderation · delivery CAPABILITY channel memory searchable · private CAPABILITY the librarian answers from history RUNS ON THE LOUNGE RUNTIME
§1 · WHAT IT IS

§1What LoungeBuzz is

Buzz is an open team-communication app built on an open protocol: channels, threads, direct messages and shared media, with a free desktop client and a relay — the server every client connects to — that carries the messages and enforces who belongs to which group. LoungeBuzz is a relay for that protocol, written on the Lounge runtime. Point the client you already use at it and everything works the same way; what changes is what the relay itself can do.

A drop-in relay

The free Buzz desktop app runs against LoungeBuzz end to end, as does any standard client for the protocol — including native support for groups. No bespoke app to install, no migration to plan.

Your keys, your groups

Identity is a keypair you hold. Groups, membership and history are stored in an open format. Identity and conversation data are therefore not tied to a proprietary client.

Where you want it

Run it in your own cloud, or use a managed deployment. Both expose the same relay protocol, so changing the deployment model does not require a client migration.

§2 · CAPABILITIES

§2What it adds on top of the relay

A relay's job is to accept messages, check who is allowed to post them, store them, deliver them to subscribers, and route abuse reports to the people who handle them — LoungeBuzz does all of that to the letter of the protocol. On top of it, the relay also remembers what was said and can reason about it, with the model of your choice, including models running on your own hardware so conversations need not leave your environment.

Channel memory AVAILABLE

Persistent, searchable memory across every conversation. Recall combines keywords and meaning, and runs against local embedding models when privacy matters.

The librarian AVAILABLE

Ask a channel what it knows — "what did we decide about the launch?" — and get an answer grounded in what was actually said, with the history behind it rather than a guess.

The manager PLANNED

A periodic check-in that identifies open items and presents them to the channel.

The moderator PLANNED

Your content policy, your rules, applied consistently and automatically as conversations move.

The router PLANNED

Evaluates a message against routing policy and brings additional recipients into the conversation when the policy calls for them.

Bridges PLANNED

Bring outside conversations in from the platforms your teams already use. Once connected, everything else applies — the same memory, the same policy, the same assistance.

§3 · THE RELAY

§3The relay is a description too

LoungeBuzz is written the way any Lounge application is written — as a flow description. This is the relay's own file: an incoming message walks the policy lane, commits to the store, and is offered to every live subscription. The rules of the relay are readable, in one place.

relay-tree.yaml — rendered by the Lounge portal
The LoungeBuzz relay tree: ingress branching into the event pipeline and REQ entry, the policy lane of verify, bounds, relay-signed-gate, target-policy and group-authorize, classification into fan-out-only or commit inside the archive-wide boundary, the subscriptions socket, and an exception handler.
the relay's own description, drawn from the file

Consequences of the design

A policy you can audit. Signature checks, size caps, group authorization and the refusal of forged relay state are named steps in a readable order — not behaviour buried across a codebase.

Subscriptions as first-class flow. Each live subscription attaches to the tree as its own branch, and every stored message is offered to all of them from a single declared query.

Per-channel ordering. Conversations are the runtime's unit of ordering, so messages in a channel are processed in order without the relay writing a line of concurrency control.

§4 · WHAT IT COSTS

§4You pay for engine time

One purchase, two perpetual licences — the Lounge PRO engine and LoungeBuzz running on it. $1,699 per instance. Nothing recurs, nothing expires, and nothing is metered.

No per-seat pricing

Adding people to a channel does not add to the bill. Cost follows the instances you run, not the size of your team, so inviting the whole company to a channel is a decision about the conversation rather than about the invoice.

Buy it

The price covers both licences — the engine and the application — so there is no second thing to buy and no way to end up with one and not the other.

There is no cluster edition of LoungeBuzz, and that is deliberate: its connections and channels do not nest and presence is process-global, so it runs as a single node with failover rather than as a fleet. Selling you a cluster licence would be charging for a capability the application cannot use.

§5 · FOUNDATION

§5Built on Lounge

LoungeBuzz is an application of the Lounge runtime — the same declarative engine, the same operational guarantees underneath your conversations.

A FAILURE MODEL IN ONE SENTENCE

DURABLE BY DESIGN

Every message is committed to a managed database before it is acknowledged, and the relay itself runs as replaceable nodes. If the database is healthy, replacement nodes recover the committed state after a restart, scale operation, or failover.

PRIVACY AND DEPLOYMENT

IN TRANSIT · AT REST · IN YOUR ENVIRONMENT

Encrypted in transit and at rest, with private groups and encrypted direct messages passing through sealed — the relay carries them without reading them. Channel content is server-managed on purpose, so retention, search and compliance tooling keep working; local models mean it need never leave your infrastructure.

§6 · GETTING IT

§6How to get LoungeBuzz

LoungeBuzz ships as a container image and a small deployment kit — two compose files, an environment template and a README. The relay comes up on bundled PostgreSQL with no external services required.

Run it

tar xzf loungebuzz-kit-1.0.0.tar.gz && cd loungebuzz-kit-1.0.0
cp .env.example .env
openssl rand -hex 32          # put the result in RELAY_IDENTITY_KEY
docker compose up -d
curl -s localhost:8080/q/health

RELAY_IDENTITY_KEY is required rather than optional, deliberately. It is the relay's own signing identity — the key clients pin and verify relay-signed events against. A relay that invented a fresh one at every restart would invalidate everything it had already signed, so the kit refuses to start without one instead of quietly generating a throwaway.

Verify it first

curl -LO https://github.com/lounge-labs/lounge-dist/releases/download/loungebuzz-v1.0.0/SHA256SUMS
curl -LO https://github.com/lounge-labs/lounge-dist/releases/download/loungebuzz-v1.0.0/SHA256SUMS.asc
gpg --verify SHA256SUMS.asc SHA256SUMS
shasum -a 256 -c SHA256SUMS

Signed with CC88 D45F 14FE F07C 0635 C8D0 D882 1C4A 7283 892C. The image is ghcr.io/lounge-labs/loungebuzz:1.0.0, published for linux/amd64 and linux/arm64.

Most relay software in this ecosystem is open source. LoungeBuzz is supported, Buzz-compatible community infrastructure on a commercial runtime — with someone accountable for it.