Ergo Chat – A modern IRC server written in Go

A modern Go-based IRC server called Ergo is prompting renewed interest in self-hosted chat as an alternative to platforms like Discord, Slack, and Teams. Commenters highlight features such as always‑on multi‑client support, server‑side history, and built‑in WebSocket access that make IRC feel closer to contemporary messaging apps while remaining lightweight and understandable to run at home or for small communities. The conversation also contrasts open protocols (IRC, XMPP, Matrix) with proprietary “walled gardens,” debates whether persistent chat history is a benefit or a liability, and touches on the practical hurdles of getting non‑technical users to adopt yet another chat app.

Self-hosting Ergo and Feature Set

  • Several commenters run Ergo (formerly Oragono) for small private communities (friends/family, long-running small networks).
  • Praised for: easy hosting, low resources, understandable Go codebase, built‑in websockets, and modern IRCv3 features.
  • “Always-on” and multiclient support plus modern clients (e.g., Goguma, Gamja) make it feel like a contemporary chat system; many users don’t realize it’s IRC.
  • Some are considering migrating from traditional IRC daemons (ngircd) to Ergo for better onboarding and server-side history.

IRC vs. Discord/Slack/Teams and “Walled Gardens”

  • Strong dislike for Discord and Slack lock‑in: non-indexable history, repeated conversations, weak search, and risk of data loss or opaque reuse.
  • Debate over whether IRC is a “walled garden”:
    • One side: not walled; open protocol, multiple clients/servers, easy logging, no enforced central platform.
    • Other side: in practice many networks lack public archives, so conversations can be as ephemeral as Discord.
  • Some see lack of history as a feature that encourages moving durable knowledge to blogs/docs/forums.

Onboarding, App Fatigue, and Family Use

  • Recurrent theme: people are tired of “yet another chat app.”
  • Barriers: installing new clients, remembering server/credentials, and spreading conversations across many apps.
  • Others report that moving a group chat is surprisingly feasible; people already juggle multiple platforms.
  • WhatsApp’s phone-number login is seen as easier for non-technical users than usernames/passwords.

Matrix, XMPP, Signal, and Other Alternatives

  • Mixed views on Matrix:
    • Critiques: complexity, Python Synapse resource usage, perceived single-company control, slow stabilization.
    • Defenses: large deployments exist; Matrix 2.0 and newer servers (e.g., Dendrite, Conduit) aim to improve performance.
  • XMPP seen as mature, resource‑light, and suitable for self-hosting (Prosody, ejabberd, Snikket), but sometimes harder to deploy (especially on Kubernetes).
  • Signal’s lack of multi-device history sync is viewed by some as a key privacy protection, by others as a usability limitation.
  • P2P options like Jami/Briar are discussed as interesting but with tradeoffs (online-at-same-time requirements, mobile UX).

Protocol Design and Philosophy

  • Some criticize IRC’s archaic, ad‑hoc text protocol; others argue it’s simple enough and battle‑tested.
  • Broader wish for a “Gemini‑for-chat”: a very small, modern, federated messaging protocol—but recognition that full-featured, E2EE, async group chat inevitably brings complexity.