
             ** ircd.js : The Synchronet IRCd **
           by: Randy Sommerfeld <cyan@synchro.net>

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: <your actual DOVE-Net QWK 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 -================================================================
