** ircd.js : The Synchronet IRCd ** by: Randy Sommerfeld 1 ...... Introduction 2 ...... Configuration 3 ...... Linking to the Synchronet IRC Network (irc.synchro.net) 4 ...... A Word from the Author 5 ...... Known Issues & Ideas for the Future =======- [1] -- Introduction -================================================ The Synchronet IRCd is a Synchronet service that is 100% compatible with RFC1459, the Internet standard that defines the IRC protocol. Many BBS users use it to chat on the Synchronet IRC Network, and many sysops connect their own IRC servers to the network. If you're not familiar with IRC, it will be helpful to learn the basics first. This document will assume that you know IRC terminology. If you're not familiar with the Synchronet IRC Network, you might want to point your favourite IRC client at irc.synchro.net and take a look around. You might also want to take a look at https://www.irchelp.org/ If you are familiar with IRC, then the Synchronet IRCd might be a nostalgic trip to the past for you. Feature-wise it's about on par with a late 90's IRC server (like the original irc2 server or DreamForge), and it's full of anachronisms from that era. =======- [2] -- Configuration -=============================================== [2.1] - Introduction Versions of the IRCd prior to 2.0 used an irc2-style "line" configuration file. Versions 2.0 and later use Synchronet-style .ini files. Both are still equally supported, but the .ini file is preferred. The easiest way to configure the Synchronet IRCd is to use ircdcfg.js with jsexec. This is a configuration TUI based on Synchronet's UIFC. It has online help hints, but still assumes a fair bit of IRC technical knowledge. Most sysops won't need to configure anything at all, the IRCd is pre- configured out of the box. [2.2] - Conversion from old .conf format Load the old .conf based configuration into ircdcfg.js like this: jsexec ircdcfg.js -f /path/to/old.conf Look around the various menus to make sure the data from the old config was imported correctly. If all looks well, "save as" from the main menu, and inspect the resulting .ini file. [2.3] - Service or JSexec? The IRCd can run either as a Synchronet Service (in which case it will start and stop whenever Synchronet does), or standalone with jsexec. Many sysops prefer to keep their IRCd running with jsexec since then it is not affected by BBS restarts. The choice is yours. [2.4] - Operator Flags The following single-character flags determine what permissions IRC operators inherit after using the /OPER command. These get very granular, but most sysops will want to use only "o": r - Can use the /REHASH command R - Can use the /RESTART command D - Can use the /DIE command g - Can use the /GLOBOPS command w - Can use the /WALLOPS command l - Can use the /LOCOPS command s - Can use the /CHATOPS command X - Can use the /EVAL command c - Able to /SQUIT locally C - Able to /SQUIT globally k - Able to /KILL locally K - Able to /KILL globally b - Can use the /KLINE command B - Can use the /UNKLINE command n - Only able send global notices locally N - Able to send global notices globally A - Operator is server administrator S - Operator password is the Synchronet system password o - An aggregate of rgwlckbBn flags O - An aggregate of rgwlckbBnCKNs flags [2.5] - Server Flags These single-character flags alter server behaviour. Most sysops won't have any use for these. They're mostly for controlling the QWK master behaviour. q - Check password against QWK database w - Send QWK passwords to this server for upstream authentication k - Passwords received from this server go to the QWK master =======- [3] -- Linking to the Synchronet IRC Network (irc.synchro.net) -===== 1) Ensure that you have a DOVE-Net node established. Although you aren't required to be a member of DOVE-Net to be a member of the Synchronet IRC Network, you need to at least go through the same automatic registration process to obtain and configure your QWK-ID. Instructions about obtaining your QWK-ID can be found here: http://www.synchro.net/docs/dove-net.txt 2) Setup the "dyndns.js" module with your appropriate QWK-id information so that the hostname "mybbs.synchro.net" will point towards your correct IP address. This is required so that users who try to reach your IRC server will be able to resolve the hostname used on the IRC network. That way, if anyone wishes to connect to your server/BBS specifically, they'll be able to use "mybbs.synchro.net" (i.e. if your server happens to be faster, closer, or offers interesting BBS features.) 3) Launch ircdcfg.js with jsexec, and navigate to the "Servers" section. There, add a new server and save the ircd.ini with these details: TCP/IP Address: vert.synchro.net TCP/IP Port: 6667 Outbound Password: Inbound Password: * ServerName: vert.synchro.net IRC Class: 10 Flags: Hub: true Note that "IRC Class" may differ if you've changed the defaults. The "Flags" are intentionally left blank. You might want to add another server for "cvs.synchro.net", but it's not strictly necessary since both of these servers are in the same location and offer little redundancy from each other. 4) Restart your BBS (or, if you know how to become an IRC operator, simply use the /REHASH command), and you should see a message similar to the following in your Synchronet console: srvc 0008 IRC Routing: Auto-connecting to vert.synchro.net srvc 0008 IRC Routing: Connected! Sending info... srvc 0008 IRC 0018 Accepted new connection: 71.95.196.34 port 6667 srvc 0008 IRC Routing: Link with vert.synchro.net established 5) If you have received those messages, then you're connected! You should be able to join #synchronet and chat with people across the network. =======- [4] -- A Word from the Author -====================================== When I first started writing this two decades ago, the intention was to create an IRC server that would be integrated with the hosting Synchronet BBS in some meaningful way. The most obvious way would be to have the BBS chat the same as IRC, so a user could flip between the two and still chat with the same people on either one. The idea would be to provide a seamless experience to the user so that they wouldn't know they're using IRC on the backend. This hasn't materialized, and considering it's been over two decades, I don't expect it to. With that being said, I'm still surprised two decades on that people are still using this thing on a daily basis. When I first started writing the IRCd, RFC1459 was only ten years old. There have been some remarkable milestones. In 2021, ircstats.org reported that Synchronet IRCd accounted for 2.2% of all IRC servers on the IPv4 Internet. In 2022, that rose to 2.7%, a larger share than charybdis (used by Libera), or even the IRCd's spiritual ancestor Bahamut (used by DALnet). Of course, this only happened because the IRCd is riding Synchronet's coat-tails. It's more a statement about Synchronet's install base, but it's still noteworthy. The unfortunate reality of the IRCd is that despite two decades of development, it really doesn't have any BBS-centric features that make it stand out from its peers. What's the difference between a sysop running the Synchronet IRCd and a standalone IRCd written in C? Not much, really. In many ways, MRC has achieved many of the goals that the IRCd originally set out to accomplish. If you want a more "BBS-like" experience in your chat, you should definitely give MRC a try. As for me, after two decades of development, it's time to step aside. I'm now in my forties and my priorities now are much different than they were when I started this thing. I'd like to thank DigitalMan and Deuce in particular. Without their help, the IRCd would never have been written, and it only exists because they helped carry me across the line. When I first started writing the IRCd, I figured there'd be an influx of people interested in discussing the IRC protocol, design decisions, BBS integration, operations, etc. Those are all passions of mine and my twenty- something self was excited about contributing. Now that I'm two decades older I can see that this is a niche hobby that very few have a passion for. As of January 2024, the IRCd will become unmaintained software. I hope that someone can take up the torch. Sysops should consider migrating their chat to MRC, a maintained IRC network, or a maintained IRCd. Finally, I wanted to express my appreciation for authors of open source software as a whole. People like DigitalMan, Deuce, Linus Torvalds, and other open source authors are able to keep writing despite an immense amount of pressure and noise. They're made of much tougher stuff than I am. -Cyan. =======- [5] -- Known Issues & Ideas for the Future -========================= [5.1] - Known Issues [5.1.1] - IRC Services The current version of IRC Services (that is, the software that runs ChanServ, NickServ, et al) on the Synchronet IRC Network is ircservices-5.1.24 written by Andy Church in 2009. On Church's website, http://achurch.org/services/ there is a disclaimer about the current state of the software that reads: No assistance or patches will be provided for this software, and the author does not accept any liability for any damage caused by this software, even in the case of security bugs. Synchronet should move to its own IRC Services instead of relying on unmaintained software. This is an opportunity to integrate things like NickServ or MemoServ with the BBS. [5.1.2] - RBL Lookups Currently RBL lookups are a blocking operation. That is to say, when an RBL lookup happens, the IRCd is unable to process anything else until the lookup completes. The check_dnsbl() function that handles RBL lookups in the IRCd should be migrated to dns.js instead of resolve_ip(), since dns.js allows for asynchronous lookups that do not block. [5.1.3] - IRC Network Hub-and-Spoke Model The Synchronet IRC network follows a hub and spoke model, where vert and cvs are major hubs. This creates a single point of failure and the whole network is rendered useless (sometimes for days at a time) whenever something happens at DigitalMan's house. The network should consider migrating its IRC hub to a stable platform (such as a server in a multi-homed datacenter). This server could still be left in control of DigitalMan and forward its QWK passwords up to vert in a cryptographically secure way. [5.1.4] - QWK Uplinks Related to the above, there exists code in the IRCd for passing passwords upstream to a QWK master for authentication. Most of the code is under the "PASS" command in server.js, but is currently disabled. This should be altered to send the password in a cryptographically secure way, and perhaps have a hashing method added so that servers can still be authenticated when the QWK master is offline. [5.1.5] - 005 Numeric is Incomplete The 005 numeric has evolved a lot over the decades, and it's no longer complete on the Synchronet IRCd. In particular TARGMAX= needs to be fixed. [5.1.6] - SSL Support The IRCd does support SSL, but it is hard coded to be present on ports 994 and 6697 only. The groundwork has been laid in the .ini configuration to allow a [Port] section to specify SSL=true so that SSL support can be flipped on or off per port. [5.2] - Ideas for the Future [5.2.1] - IRC Services Related to 5.1.1 above, there's an opportunity to make the IRC network unique by creating IRC services that have BBS-specific features. One idea is that every server should run its own set of services with special non- colliding nicks. For example, if you have an account on vert, you could then identify to it with something like this: /MSG NickServ@vert.synchro.net IDENTIFY password There would need to be a method to resolve conflicts (i.e., an account on vert will override an account from a BBS that just joined the network). [5.2.2] - File Serving via IRC Related to the above, it could be possible to create a "FileServ" service that offers BBS files over IRC and DCC. [5.2.3] - MRC Compatibility This is an easy one, but it will rely more on the future IRCd author (whoever that may be) collaborating with the MRC authors to make it happen. But it seems like an easy win for both IRC and MRC. [5.2.4] - Meaningful BBS Integration This would require a lot of collaboration between the various stakeholders, but it's still possible to achieve the IRCd's original design goal. [5.2.5] - Host Cloaking Host Cloaking is a method of obscuring a user's real hostname or IP address through a cryptographic hash. For example, my /WHOIS output on DALnet looks like this: *** [Cyan] (~cyan@e21e-3e5a-1440-d392-7fe2.7001.80b.2602.ip) The hash is constructed in a way where it reveals some portion of the IP, but not all of it, so it's still useful for making hostmasks (like for bans). When the Synchronet IRCd was written, host cloaking on IRC was a fairly rare thing. These days, it's almost an expectation. [5.2.6] - IRCv3 Compatibility The IRCd already parses IRCv3 tags from the IRC protocol through the IRC_parse() and IRC_parse_tags() functions in irclib.js This would form the basis of any future work on making the IRCd compatible with IRCv3. [5.2.7] - Reducing Netsplit Noise Since the Synchronet IRC Network allows anyone to link any kind of IRC server to it, there is a lot of "noise" on the network. For example, it's easy (and acceptable!) to run Synchronet and its IRCd on a Raspberry Pi, so whenever the Pi is unplugged from the wall, it could cause a visible netsplit. When this happens across dozens of connected machines, the noise starts to become annoying, and it's a frequent complaint from users. A solution to this would be to implement a channel mode that would squelch netsplit noise. This could be accomplished in a few different ways: 1) "Hold" the netsplit users in their channels until the server comes back. If a message is sent to the split users, the server could send a NOTICE back informing the sender of the split. This would need a timeout (15 minutes seems reasonable) before the client-facing QUIT messages were sent for the split. When the split server comes back, any messages queued up would be sent over as part of the resync. 2) Don't display JOIN/PART/QUIT messages in a channel unless a user has talked first. That is to say, when a user sends PRIVMSG to a channel, only then will the JOIN take place. =======- EOF -================================================================