slingamn
Joined 10 years ago
Joined 10 years ago
Live on our production network: https://ergo.chat/gamja/
Gamja: https://sr.ht/~emersion/gamja/
The one clunky thing is that you have to register your nickname with our NickServ and then become "always-on": `/msg nickserv set always-on true`
From pseudonymous support requests I've received in our IRC channel and on GitHub, I know of more deployments that are either private (requiring authentication to connect) or on the darknet (we have specific support for running as a Tor onion service). So I think that's our niche right now: small communities who want full autonomy in moderation and control of their data. I've taken a lot of inspiration from Darius Kazemi's runyourown.social: <https://runyourown.social/>
In terms of ongoing specification and development work, we take direction primarily from the IRCv3 working group, in which we are both participants: <https://ircv3.net/charter>
1. Most of the big problems with IRC as a protocol (nicknames, ghosting, missed messages) come from the assumption that the core of the network should be stateless. If the core of the network is stateless, you can't have nickname reservation, you can't transparently attach two clients to the same nickname, and you can't replay missed messages to people who were disconnected (hence the need for clients to maintain a TCP connection to the server at all times, hence netsplits being disruptive, etc.).
2. Conventional IRC setups solve some of these problems by adding a single privileged node, the "services framework" (Anope and Atheme are examples), that stores some persistent state (typically, nickname and channel reservations). This actually abandons the high-availability properties of the original IRC design: it is theoretically possible to design a highly available services framework (using a clustered database or whatever) but AFAICT none of the frameworks that currently exist are HA.
3. Oragono is a single instance that provides an integrated IRC server, services framework, and "bouncer" (history retention and playback). Client connectivity problems are solved by allowing transparent reattach to the original nickname after authentication with SASL, then automatically replaying history. (Client support for this is still patchy [2], but anything that supports znc.in/playback [3], like Textual, will work well; you can also configure Oragono to try and track what you missed and replay it on reconnection.)
4. To make Oragono highly available, it can be deployed in Kubernetes (virtualizing the embedded database file and the external IP, spinning up a replacement instance on failure).
[1] https://github.com/oragono/oragono
You're correct, we're not trying to be minimal at all, more "batteries-included". The largest deployments so far are in the low hundreds of users, with no performance or stability problems. Based on my stress testing I'd say an instance can scale comfortably to 10k clients, with at most 2k clients per channel.
a. Ergo [1] as the server for a greenfield setup
b. Gamja [2] and Goguma [3] ) as clients
c. Soju [4] as a bouncer for non-Ergo networks
[1] https://github.com/ergochat/ergo [2] https://sr.ht/~emersion/gamja/ [3] https://sr.ht/~emersion/goguma/ [4] https://sr.ht/~emersion/soju/