Skip to content

Latest commit

 

History

History
263 lines (245 loc) · 15.5 KB

history.md

File metadata and controls

263 lines (245 loc) · 15.5 KB
Raw

History

juno-ircd was born a fork of pIRCd (the Perl IRC daemon) but has since been rewritten (multiple times) from the ground up.

  • pIRCd: Born in the 20th century and written by Jay Kominek, pIRCd is a very buggy, poorly-coded, feature-lacking (well, compared to those now) IRC server. During its time, it was one of only a number of IRCds featuring SSL support. Having been abandoned in 2002, pIRCd is ancient history.

  • pIRCd2: A PHP novice, I was convinced by someone to learn Perl. I discovered pIRCd and spent hours trying to change something without breaking it. pIRCd2 allowed you to use the dollar sign ($) in nicknames, adding support for users such as Ke$ha. Truly revolutionary to IRC as a whole.

  • juno-ircd (juno1): A fork of pIRCd2, juno-ircd introduced a handful of new features: five prefixes (~&@%+), hard-coded CAP multi-prefix support, channel link mode (+L), internal logging channel (inspired by InspIRCd), network administrator support and the corresponding NA:line, self-expiring temporary oper-override mode (+O), channel mute mode (+Z, inspired by charybdis +q), KLINE command for adding K:lines from IRC, an almost-but-never-fully working buggy linking protocol, and a network name (NETWORK in RPL_ISUPPORT) option. juno-ircd's name was chosen by Autumn after the Roman goddess Juno. Unfortunately it introduced dozens of new bugs along with its features, and it included some of the ugliest code in all of Perl history. An example of the attention juno-ircd received from the Atheme community:

[04:15pm] -Global- [Network Notice] Alice (nenolod) - We will be upgrading to "juno-ircd" in 5 seconds.

  • juno (juno2): At some point, some IRC bullies made me realize how horrific juno-ircd was. I decided to dramatically announce that I would no longer be developing the project, but I could not resist for long. I soon started from scratch, dropping the '-ircd' from the name. juno was actually quite complete and surprisingly reliable. Unlike pIRCd and its derivatives, it introduced an interface for modules which later became a separate project, API Engine. It brought forth more new features than can be mentioned, namely: host cloaking, server notices, channel access mode (+A), GRANT command, D:line, and lots more. juno unfortunately was completely incapable of server linkage.

  • juno3: It occurred to me one day that an IRC server incapable of linking is somewhat impractical (as if one written in Perl were not impractical enough already). I decided to put the past behind and say goodbye to juno2. Another complete rewrite, juno3's showcase improvement was a dazzling linking protocol. It was even more extensible than ever before with greatly improved module interfaces. juno3 was also the first version to make use of IO::Async, exponentially boosting its speed efficiency. Although it required more memory resources than juno2, it was prepared to take on a massive load, tested with many tens of thousands of users. It was less buggy but also less featureful, lacking many standard IRC functions due to my shift of focus to a reliable core.

  • juno-mesh (juno4): It was recommended to me by Andrew Sorensen (AndrewX192) that I should implement mesh server linking. It seemed that it would be easy to implement, so I forked juno3 to create juno-mesh. In addition to mesh linking, it introduced several new commands and a new permission system with a method by which additional statuses/prefixes can be added.

  • juno5: It turned out that mesh linking required more code and effort than intended and introduced countless bugs that I didn't want to bother correcting. I knew that if I started from scratch again, it would never reach the completeness of the previous generation. Therefore, juno5 was born as yet another fork with a new versioning system. It removed the mesh linking capability while preserving the other new features that were introduced in juno-mesh. juno5 also reintroduced channel access (+A), this time in the form of a module.

  • kedler (juno6): Named after a Haitian computer technician, kedler was a continuation of juno5. Its main goal was to implement the missing standard IRC functions that had never been implemented in the third juno generation. kedler reintroduced hostname resolving, a long-broken feature that had not worked properly since juno2. kedler featured new APIs and improvements to the linking protocol.

  • vulpia (juno7): Romanian for a female wolf, vulpia was named after the alias of a dear friend, Ruin. It included several improvements, making the IRCd more extensible than ever before. The Evented::API::Engine replaced the former API Engine, allowing modules to react to any event that occurs within juno. vulpia completed the relocation of JELP (the linking protocol) to an optional module, opening the doors for additional linking protocols in the future. Additionally, it established fantasy command support; the Reload module, which makes it possible to upgrade the IRCd to the latest version without restarting or disconnecting users; and a new Account module, helping users to better manage nicknames and channels.

  • kylie (juno8): Named after the adored Kyle, kylie introduced several previously-missing core components including ident support and channel modes: limit, secret, and key. APIs for IRCv3 extensions were added, leading to SASL, multi-prefix, and message tag support. An improved IRC parser allowed drastic code cleanup and improved efficiency. A new event-driven API made user commands more extensible than ever before. The migration of all non-modular packages into modules significantly improved the stability and reloadability of the IRCd.

  • agnie (juno9): Named after the beautiful and talented Agnes, agnie introduced lots of new functionality: the ability to manage oper flags from IRC, much-improved account management, and command aliases to name a few. It opened a new door of possibility by adding partial TS6 protocol support, and it even supports Atheme now to some extent. New channel modes include invite exception (+I), free invite (+g), channel forward (+F), oper only channel (+O), and mute ban (+Z, missing since juno2); also, the TopicAdditions module added convenient commands to prepend or append the topic. Some missing commands were added: ADMIN, TIME, USERHOST; and several commands that previously did not work remotely now do. agnie introduced a new mechanism for storing and enforcing bans (functionality missing since juno2), followed by K-Line and D-Line support in the form of independent modules. In addition to the existing RELOAD command, agnie includes new ways to manage servers remotely, including repository and configuration management directly from IRC.

  • yiria (juno10): An acronym for our slogan (Yes. It really is an IRC daemon.), yiria's primary goal was to complete the implementation of the TS6 protocol. Doing so while retaining support for the Juno Extensible Linking Protocol (JELP) involved efficient TS6<->JELP command conversion and vigorous mode translation, among other challenges. But we pulled through, and now juno almost fully supports a variety of TS6 servers such as charybdis and elemental-ircd, as well as many pseudoserver packages like Atheme IRC Services and PyLink relay software. Adding TS6 resulted in a positive side effect: several improvements within JELP in order to stay competitive with the newly-supported protocol. Aside from server-to-server improvements, new noteworthy features in yiria include built-in DNSBL checking, private channels, and IRCv3 away-notify support. As always, there were lots of bug fixes and efficiency improvements too.

  • janet (juno11): Upon the release of mihret (juno12), a new versioning system was adopted. Releases now occur at the start of the next major version (in this case, v12.00), rather than at an arbitrary version as before. So janet and mihret are actually the same release. See below. This new system is less confusing and makes it easier to release patches.

  • mihret (juno12): A lot was accomplished during the short-lived development of mihret. Several new channel features were introduced, including IRCv3 extended-join, permanent channels (+P), op moderation (+z), color stripping (+c), registered only (+r), and SSL only (+S), all implemented as modules. Internal support for new user modes, deafness (+D) and bot status (+B), was also added. mihret furthered the support of external IRC services packages by reworking the SASL module to support relaying authentication over both server protocols. Nickname enforcement, nickname reservations, and channel reservations are now supported as well. For the first time in its history, juno now has a decent hostname cloaking interface with a charybdis-compatible implementation. The netban module was rewritten from the ground up in an objective fashion. New APIs make it very easy to extend netban functionality from additional modules. The TS6 netban implementation was mostly completed too. A new IRCd support interface makes it easy to add special rules for certain IRC software and also features inheritance of properties for derivative software. As usual, there were astounding improvements to TS6 and even some enhancements to JELP.

  • ava (juno13): Several new IRCv3 features were added, particularly the improved IRCv3.2 capability negotiation, cap-notify, userhost-in-names, SASL reauthentication, and the MONITOR client notification system. Additional new channel features include WHOX support, KNOCKing, join throttle mode (+j), no forward-mode (+Q), and the long-planned MODESYNC mechanism, which helps maintain network-wide channel mode synchrony even when some modes are not enabled on all servers. The built-in DNS blacklist checker now supports IPv6 blacklists and has improved caching helping to decrease the effects of malicious attacks. Further work on TS6 and JELP includes improved ban propagation and more S2S security measures.

  • dev (juno14): Yet to be named, the next release will be based on the current git, a continuation of ava under active development.