"The Synchronet IRC Network" a proposal by Randy Sommerfeld ----- 1.0 -- Purpose The purpose of this document is to establish a reason for creating a new IRC network, new IRC daemon software, and related services (especially as they relate to Synchronet.) This document should be considered a request for discussion about the creation of this new IRC network and its related services, especially as they pertain to its operation and protocol. The purpose of creating the Synchronet IRC network is to develop a method by which individual BBS's may connect their individual "multi-node chat" areas together. Unlike existing QWK-based or FTN-based networks, which exist to share the exchange of public messages on a per-group basis, there currently exists no 'standard' by which to link together multiple BBS chat areas. Furthermore, it seems ironic that IRC was originally established for this purpose, but there seems to be no active implementation of it for such a purpose. Furthermore, it only makes sense to allow 'anonymous' (i.e. those who have not formally gone through the BBS registration procedure) inbound client connections from users who wish to use their own IRC client as opposed to the BBS's internal chat area. It is important to retain compatibility with existing IRC standards (for the purposes of this document, RFC1459) so that to a user using the network, it will seem to be just as any other IRC network available. In particular, the author has decided to mold some protocol extensions around the DALnet/Bahamut IRC daemon. 100% compliance with the DALnet/Bahamut IRC daemon is desirable only in so far as ensuring a stable and complete implementation. Connecting a server to the Synchronet IRC network should be as relatively easy as it is to connect to DOVE-Net, and should follow a similar procedure. A new Sysop should be able to download the Synchronet software, install it, and then be able to sign up for DOVE-Net and Synchronet IRC on the same day. Thus, a user who then signs up to the new BBS, and then enters the "multi-node chat" area will be on the Synchronet IRC network from that BBS, able to speak to all of the clients on the network at large. ----- 2.0 -- Naming and Network Structure Names and naming solidarity are important for the smooth functioning of an IRC network. In particular, this ensures that there are no attempts by a client or otherwise to misrepresent themselves as something they are not. While the IRC daemon can enforce some of these restrictions (such as Q:Lines for disallowing the usage of certain 'sensitive' nicknames; Sysop, IRCop, ChanServ, and soforth), other restrictions are purely the responsibility of those who run the IRC network. The domain name 'synchro.net' should be used for the establishment of all connecting servers. No servers outside this domain should be allowed to connect, except in exceptional circumstance. This ensures that the Sysop who wishes to connect has gone through correct procedure of A) setting a valid and unique QWK-id, and has B) established a valid IP address attached to that QWK-id via Synchronet's dynamic IP service, and C) has set a password which will be used to authenticate the server when it connects to the network. This introduces a flexible, but sufficient authentication mechanism which will prevent "just anyone" from deciding to link a server to the network. Furthermore, it establishes a barrier of entry, so that if a troublesome server must be permanently disconnected from the network, the IP address or other information can be denied access at the "QWK-id registration" level if they try to register for a new (i.e. not banned) QWK-id. Most IRC networks follow a "tree" structure for the connection of servers. This is to say, a European server should not connect to a Japanese server 1000ms away, but it should instead connect to a local European server which has faster transport links to the network at large. The Synchronet IRC network should be no different, however, due to the anarchistic nature that this network will take (i.e. certain BBS's will only be up certain times of the day), server connects and disconnects from 'leaf' servers will not be an uncommon occurance. This is especially true when one considers that many bulletin boards currently running Synchronet are simply background processes on a home machine that may be rebooted often. Therefore, three different server types must be defined throughout the network: * A single 'master' server which takes care of validating QWK-id registrations and allowing links to the network (it would make the most sense to have vert.synchro.net as the current master) [It would be prudent to have a secondary master which would have a read-only mirror of QWK-id authentication information in the case that the primary goes down.] * One or more 'hub' servers which allow inbound server connections, which will be online for extended periods of time, are in geographically diverse parts of the world, have appealing backbone connections (when possible), and have been extensively validated "by hand" outside of the normal automatic QWK-registration scope. Thus, European sysops would connect to the European hub, Japanese sysops to the Japanese hub, and soforth. * Many 'leaf' servers which are essentially the hobbyist BBS's that wish to connect to the network on a permanent or quasi-permanent basis but cannot be trusted to be on the network at any given time. These servers must have special restrictions placed on them so that "network poisoning" is not an issue. Most IRC operator commands, for example, should be limited to local connections only and any attempt to poison the network silently dropped and logged to all online IRC operators. Leaf servers are not allowed to have other servers connect 'behind' them. An example Synchronet network could then look like this: tokyo.synchro.net \ \ osaka.synchro.net \ | japanbbs.synchro.net bobsbbs.synchro.net / \ \ / \ \ / korea.synchro.net somebbs.synchro.net---rrx.synchro.net | berlinbbs.synchro.net | | services.synchro.net---vert.synchro.net---england.synchro.net | \ | \ nix.synchro.net finlandbbs.synchro.net / \ / \ ottawa.synchro.net joesbbs.synchro.net With 'rrx', 'nix', 'england', and 'japanbbs' being example HUB servers and 'vert' as a master. All other servers would be 'leaf' servers (with the special exception of 'services', discussed in section 4.0.) It is thus recommended that certain QWK-id's be reserved in the name of having them as valid synchro.net hostnames for the purposes of allowing clients to connect to a randomly assigned IRC server, or, a server close to their geographical area. For example, 'irc.synchro.net' would be a round-robin DNS that would point to all the available IRC servers, while 'eu.synchro.net' would be a round-robin DNS that would point to all European servers, 'us.synchro.net' for the United States, 'ca.synchro.net' for Canada, and soforth. It may be more worthwhile to use 'xx.irc.synchro.net' instead, where xx is the two-letter country/geographical area code. The QWK-id of 'services' should also be marked as reserved as it is a typical prefix used by IRC networks for the establishment of IRC services (ChanServ, NickServ, and soforth.) A sysop who registers a QWK-id of 'services' could then connect to the network as 'services.synchro.net' and trick users who are more familiar with other networks (in particular, DALnet, or any other network offering services, such as BBSnet) into giving up channel or nick passwords for those other networks. When a client connects to the IRC server, they may give the 'PASS' command along with their 'USER' and 'NICK' pair to authenticate against the local Synchronet user database. If a password match isn't found, the server SHOULD silently ignore the 'PASS' message and allow registration to continue as if the user was anonymous. Anonymous users MUST be marked with a tilde (~) as the first character of their 'user prefix' (username as passed by 'USER'), which allows other users to easily identify anonymous connections. Authenticated connections will omit the tilde (~), and have their user prefix (username) replaced by a 10-character truncated version of their Synchronet username. A tilde (~) MUST NOT appear anywhere in the nick!user@host format unless the connection is anonymous, and only then as the first character in the username portion. If a client connects from the local host, they SHOULD be given the hostname of the local server as their hostname originator. For example, a user connecting locally (i.e. from the BBS) from localhost on rrx.synchro.net would appear as Nick!user@rrx.synchro.net ----- 3.0 -- BBS Chat Integration Since the primary purpose of the project is to offer seamless integration with the local BBS chat area, it is perhaps the most important part of this document. In particular, a user who enters "multi-node chat" should not be able to tell the difference between the 'old' (single-BBS) chat area, and the 'new' (IRC-based) chat area. Thus, it is important to have the interface very similar and in spirit with the style of BBS multi- node chat. In particular, the local chat 'client' must not depend on any local IRC server being available, although it should have facilities to allow connecting to an external network (not necessarily just the Synchronet IRC network) It should also automatically connect to the local IRC server if one is available. Since Synchronet chat actions are such a large part of any Synchronet chat experience, but are implemented in a different way than traditional IRC actions, cross-protocol translation is recommended. There already exists a facility within the IRC CTCP protocol called 'ACTION' which will display on most stock IRC clients as: * Nick However, since Synchronet actions are typically comprised of multiple lines, colors, and not necessarily begin with the user's nickname as the first argument, this poses a small problem. Thus, it is recommended that each Synchronet action be outfitted with an IRC equivalent, so that the local chat action be displayed to local chat users verbatim, while it is sent out as the IRC action to IRC clients. Furthermore, when receiving an IRC action, it can be matched against the known action list and translated back into the relevant Synchronet BBS action (including formatting and colors.) For example: SLAP (Synchronet): SLAP! Cyan disrespectfully slaps The Guru on the cheek. SLAP (IRC): * Cyan disrespectfully slaps The Guru on the cheek. HISS (Synchronet): HISSSSSS..... Cyan is hissing at The Guru. HISS (IRC) * Cyan is hissing at The Guru. HELLO (Synchronet): Cyan says "HELLO" to The Guru with great enthusiasm. HELLO (IRC) * Cyan says "HELLO" to The Guru with great enthusiasm. Non-matching inward IRC actions should be displayed verbatim. IRC actions SHOULD be colorless, since many traditional IRC users find colors to be highly annoying and intrusive. However, if a user insists on using colors, they should be translated from their CTRL-A codes to their correct IRC color counterparts. Inversely, incoming IRC color codes should be translated back to their CTRL-A code values. Please note that this is independant of Synchronet Actions; Synchronet actions can still be 'colorful' while having their translated IRC counterparts being 'colorless.' An alternative, as proposed by Deuce, is to introduce a new CTCP type known as "SYNCACTION" or similar, which would contain either just the action name (i.e. "SYNCACTION SLAP") or all of it. However, this isn't recommended due to the fact that there are currently no IRC clients in existence which will interpret the new CTCP correctly, and some of them may even take it as a hostile CTCP. Furthermore, the current CTCP ACTION command is already there, so there is little point in re-inventing the wheel, per se. ----- 4.0 -- Services Most IRC networks (with the notable exception of EFnet) provide Channel and Nickname management and registration services. These services allow users to take ownership of their nickname (preventing others from impersonating, for example) and channels (i.e. for the management of channel operators, so that they may be auto-opped upon entry, or for the establishment of ban lists to keep troublesome users out, etc) Services are by and large an expected condition of any modern IRC environment and were originally pioneered by DALnet in 1994. Services are especially important on the Synchronet IRC network, since a user who registers his username on a BBS should be able to use that username on the IRC network without difficulty. However, this is not always possible due to the possibility of two different people having the same username across two different bulletin boards. Therefore, there are two possible solutions, each with their own pros and cons: (1) Implement a traditional set of IRC services by utilizing a pseudo- server named 'services.synchro.net.' This server would be either home-brew JavaScript code OR an existing services set (typically written in C.) Nicknames are handed out on a "first come, first serve" basis, and any subsequent users of the same nickname would be denied and told to use a different nickname until the registered nickname expires. PRO: The traditional services model has been the one most widely tested, and the one most users are familiar with. It establishes a central point of authentication, so being able to poison the network with bad registration data is impossible. The existing services set is robust and stable, and creating home-brew services would be easy. Traditional services applies network-wide, so it doesn't matter what server a user is on, their registration information is always available. CON: Integration with Synchronet isn't as tight, however, this can be overcome through the use of custom usermodes. Services already makes use of these modes (+d and +r) which users DO NOT see in order to keep track of users. A custom mode, (mode +z for example) could be used to pass a message to services indicating the user has successfully passed the local user authentication test. Nicknames could then be linked against local BBS usernames, simplifying the process even further. (2) Each server would have its own copy of 'services' which would manage its own user database and authentication. These services would be invisible to other servers so that each set of services could co-exist without colliding against one-another. PRO: Tight integration with Synchronet, and distribution of the services database. CON: Highly vulnerable to security issues, and there is currently no workable method by which to prevent collisions network-wide. For example, if a user were to have a nickname of "SomeUser", register it with their local services, and then if that server were to die, there would be no way of authenticating that user's right to that nickname. Then, if a different user were to register with a new server, and the old server were to connect, the registrations would collide and there would be no way to authenticate which user has the right to their registration. Allowing per-server services like this would require allowing unchecked mode commands, which also opens the entire network to poisoning. The author highly recommends going with option one (1) for now, and then offering individual minor services on a per-server level later. See below. ----- 5.0 -- The Future Ultimately, being able to perform more BBS functions from IRC would also be a worthwhile goal. Here are a few examples of how this may be accomplished in the not-so-distant future, and some other innovative features: * FileServ * A per-server service which links IRC to the individual BBS file area. One would be able to "/MSG FileServ@vert.synchro.net" and request a certain file by filename, search for files by description, or even upload new files. This would be accomplished by utilizing IRC's DCC protocol. * MessageServ * A per-server service which would inform you of new inbound email, messages, or other relevant information. You would also be able to compose simple messages, or browse your email. Again, this service would be reachable per-server (with /MSG MessageServ@qwkid.synchro.net) so that you could check messages across multiple boards from IRC. * Channel Mirroring * A method by which a pseudo-server (such as services) creates a new channel and multiple 'fake' names inside of that channel while only being a regular client on a remote IRC network. This would allow people to experience their favourite channel on a remote network while remaining on the Synchronet IRC network. This is similar to how newslink mirrors USENET groups, for example. By and large, the channel functions just as a real channel would. * IRC Games * An easy method by which users (or the sysop) can create simple IRC bots by utilizing some Synchronet IRC API. These bots would allow users to play simple games across the network, such as trivia games, or simple RPG's. Such games would be accessible to regular IRC clients, however, would presumably be enhanced with CTRL-A codes and the like for local Synchronet users. ----- 6.0 -- Conclusion The Synchronet IRC network has the possibility to grow into a mid- sized network in short order. The reason for this is its highly flexible nature (allowing leaf servers to connect and disconnect at will), and its distribution (it would be possible to have hundreds of BBS's linked together in this fashion.) This makes the Synchronet IRC network more appealing than most networks due to the sheer number of servers to choose from. Furthermore, it will also bolster the BBS community and increase BBS interest substantially, since in my experience most users simply get bored and log off if they have nobody to speak to in their local multinode chat. Creating a network such as this would retain users' interest, which would in turn support local sysops. Following the recommended procedures and protocols in this document will help to ensure that the network will remain safe, scalable, and secure no matter how large it may become.