# Background
This is planned as an exercise in [Rust](https://rust-lang.org) programming language. Therefore progress will be in terms of time available.
## What is in the name?
Naming things is hard. Very hard. So I chose a Finnish word for "rustic" (maalaismainen) as the word rustic has rust in the name and ic is almost irc :).
# Implementation goals
- Working IRC server
  - As this will be initially targeted as a Proof of Concept we are satisfied if we have a successfull client - server communication with one client (e.g. [HexChat](https://hexchat.github.io/)).
- Minimal dependencies outside Rust (this implies that solution should be portable to many environments)
  - Cargo packages which are not tied to specific operating systems will be used. Especially for security related code.
- Main target environments: BSD (HardenedBSD) / Linux (Ubuntu)
# Specifications
Main information source for the IRC specification will be the material available at [Modern IRC](https://modern.ircdocs.horse/).

# Concepts
This chapter describes the core concepts around the implementation and the IRC specification. Some material may be restated from the source but it is gathered here for reference purposes.
## IRC
For the core IRC concepts see: [IRC concepts](https://modern.ircdocs.horse/#irc-concepts)
## Implementation
### Client
This is something that sends bytes to our server according to the IRC protocol (something that communicates with the server but is not a server). This is also something outside of this implementation and this is modelled as something from which we receive and send bytes to.
### Server
This is our implementation which communicates with the client and other servers in the same network. According to IRC specification network consists of servers and even though there is server to server protocols available in practise one network consists of same server implementations and they can use any protocol they wish to communicate state changes between them. We will utilize this in our implementation.
### User
This entity models a real user (either human or bot) which uses the client to communicate with our server.
### Channel
Channels represent the logical conversation groups in an IRC network. These are synced between servers in the network. This entity ties users to channels in which they can exchange messages.
### Capability
When the client connects to the server they first have an exchange of information which tells the client what capabilities the server provides. This allows the client to establish reasonable communication with the server. In the implementation different capabilities are implemented in a modular manner which are queried during runtime to provide the capability information to the client.
# Architecture
In general principle we follow modular monolith approach where we have a single executable for the application but that application is composed of modules which are independent and focus on specific features (capabilities) and the runtime then ties these together. In addition there are modules which handles the low-level work of communication. Different components communicate with each other using the mediator pattern (this allows loose coupling between components but it is not the most high-performant way of running the IRC server).
## Components
### Server
This is the main high-level component that drives our server instance.
#### Capability
There are multiple capability components that each implement a specific functionality to the server.
### Pool
This is the component which tracks the running service instance in the network it is attached to. Network can consist of single server instance. State changes in this instance are then propagated to other servers in pool.
#### Server Communicator
This sub-component of the pool manages the communication between server instances.
### State Manager
This component maintains the state information (users, channels, etc.) for the current instance. It is linked to the pool component and the pool observes the changes in the state manager and propagates them forward and vice versa. That is pool may receive state update from a different server instance and pool then signals these changes to this instance's state manager.
### Protocol Stack
This component maintains the reference information for different communication and message components about specific IRC code constants and other similar information in the IRC protocol.
### Communicator
This component is responsible for sending and receiving bytes between client and server. It ensures the correct formatting of messages and their validation. This component is also linked to the state manager.
### Mediator
This is the infrastructure component that ties other components together. Components can register with the mediator to receive certain type of messages. These abstract messages are defined outside the components to avoid dependencies between components. This is the most general purpose of the modules defined and in principle will work with other applications as well.