Distributed Relay Chat, DRC for short, is an attempt at a fully-distributed, low-maintenance chat network platform. Its target audience includes, but is not limited to, IRC network administrators.

After having administered an IRC network for a couple of years, I'd started to tinker with writing IRC bots and simple clients. The combination of these experiences was enough to realise a few things:

• The IRC network topology has no redundancy,
• IRC attracts people who like to Denial of Service attack on the basis of personal vendettas,
• The Internet itself isn't always 100% stable,
• The combination of the above three points means there are often netsplits causing noticable disruption,
• The IRC protocol is basic and inflexible, meaning most advanced features, including services, are (ugly) hacks on top of it,
• Many parts of the "de facto" standards (in the form of RFCs) are not followed, and most implementations contradict a RFC in at least one way.

• Network Topology
• Message Routing
• Services

• Message Protocols
• Interaction Protocols

(Stuff goes here when I think of it but haven't put it anywhere proper!)

In-channel registration

• 'register' message instead of 'identify' message as first message
• After registration, reset connection state and go back to 'identify'

Multi-location signon

• Services store a list of nodes where a user is present
• Local client manager has a 1-to-many mapping of user to connection/client object
• How would this interact with other services, e.g. file transfer?

Application protocols not implemented network-wide

• Server: forward if broadcast, silently drop if not supported?
• Client: notify if not supported?

Premises:

1. A user has an account, and no client can connect without authenticating (except for account registration)
2. A user may desire to connect from multiple locations
3. A user should not be forced to register multiple accounts

Solution:

• (This should follow the XMPP concept of “resource” mostly)
• A user authenticates to their account, but also supplies a “resource” (or more simply put, a “location”)
• A “Username/Resource” combination must be unique at any point in time
• Messages addressed to “Username/Resource” are delivered to that particular client
• Messages addressed to “Username” are delivered to all connected clients
• Supplying a resource is the responsibility of the client
• Not supplying a resource means the client is only accessible via “Username”

• Potentially useful papers/articles:
  • BASE: AN ACID ALTERNATIVE
  • Should you go Beyond Relational Databases

SARC stands for Self-Aware Relay Chat.

Some time in early 2006, after having spent a few years administering an IRC network, I thought that it would be awesome if it were possible to have an almost-zero-maintenance chat network which also had true redundancy.

Anybody who has spent a significant amount of time on an IRC network will know what a netsplit is - when a connection between servers dies for some reason, leaving part of the network isolated. These can be inconvenient on many level - for the users who miss messages, for the users who end up with several hundred “part” messages in their chat windows, for the administrators who have to be on the ball to route around the problem.

IRC is based fundamentally on a minimum spanning tree topology, and this means the network is inherently hierarchical and while the network is distributed, there is no redundancy and bottlenecks can exist higher up in the hierarchy. This means it is possible for the failure of a single node or a single connection to significantly impact the operation of the network. Yes, most IRC daemons are capable of re-connecting themselves to the network, but this almost always requires more tweaking by the administrators to get a sensible network map. Because there is only one route between any two nodes on an IRC network, the network map must be micromanaged to be as efficient as possible.

This means that to maintain a usable network, nodes must be running on very high availability servers, and even then if that node does fail the network can fall apart (root nodes of IRC networks are important Denial of Service targets).

The aim of SARC in this area is a network with multiple redundancy, which is “self-healing”, requiring no human intervention in repairing the network. Multiple redundant links prevent the network from being affected by node failures or connection failures - the Internet would literally have to split in half to break the network. Since one link failing doesn't stop a node being reachable, it's possible to give the network a certain amount of intelligence for identifying where faults lie, avoiding particular connections, etc.

Services are an important part of large chat networks. They allow users to mask their real identity and protect their network identity from misuse. However, all implementations of IRC services at the moment are single-instance affairs - they are generally a pseudo-server with pseudo-users for interaction with real users. If the services are disabled in some way, this can lead to chaos on a large network, with people using the identity of others, stealing channels, etc. The alternative is stopping anything significant happening while the services are away, which is a major inconvenience for all concerned.

SARC aims to provide a completely distributed services system which is not in any way impaired by loss of nodes.