Recent submissions

Comment · 4 years ago
Comment · 5 years ago
Comment · 5 years ago
This is (1) a totally legit idea (2) achievable nearly out of the box with Ergo and Gamja!

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`

Comment · 5 years ago
We're listed on ircstats.org (under our old name of Oragono) as having 84 deployments on the public Internet last year: <https://www.ircstats.org/servers/oragono>

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/>

Comment · 5 years ago
Comment · 6 years ago
Clarification, I'm the one of the maintainers of Oragono [1], an IRCv3 server project, but I don't speak for IRCv3 as a whole. In fact, I think my take is somewhat controversial in the IRCv3 community. But here goes:

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

[2] https://github.com/ircv3/ircv3-specifications/pull/393

[3] https://wiki.znc.in/Playback

Comment · 6 years ago
I'm one of the Oragono maintainers. Thanks for the kind words :-)

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.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton