1. An operator on the network adds the new server to the services
2. The new server is started and given the address of a server in the network to join
3. Server-server handshake
4. Connection initialisation - the new server identifies as such
5. The target server bursts the entire services database, network database etc. to the new server
6. The new server updates its databases and disconnects from the network
7. The new server reconnects to the network as if it were already a part of it

While the server is obtaining network data and preparing to join the network, it will refuse all incoming connections from anywhere.

This method is based on public key cryptography. It relies on the server being connected to having the public key of the server that is connecting (which can only occur if the server has actually been added to the network).

1. The source server sends it's identifier string
2. The target server sends a fixed-length random string, concatenated with its public key, to the source server, encrypted with the source server's public key
3. The source server decrypts the message, and uses the public key to send the random string back to the target server encrypted
4. The target server decrypts the message, and compares the string to the one sent
5. The source server is notified that the handshake was successful

The handshake must happen before the connection attempt times out. When the connection attempt times out, the handshake is cancelled by the target server and the connection must start again from scratch.

One of the problems on most chat infrastructures is that even intentionally shutting down a server causes clients to be disconnected. Wouldn't it be great if all of the clients from a server could be moved to other servers before a shutdown, completely seamlessly? This is something we would like to achieve. This also opens the door for both server-side load balancing and clients requesting server changes, all without any interruption to the user. It could even be expanded to clients maintaining a redundant link to the network for seamless recovery from a server disconnect.

1. Server chooses a client to move, and a server to move it to (based on its knowledge of the loading of the network)
2. A request ID is generated
3. A notification, containing the request ID, is sent to the server the client is being moved to
4. A redirect request is sent to the client
5. Client makes a connection to the recipient server
6. Client sends handover request, containing the request ID from the originating server
7. Recipient server compares ID to pending requests
8. New connection is established
9. Recipient server notifies source server of handover complete
10. Source server closes old connection
11. Client swaps connections as soon as old connection is closed

The client can refuse the request - this is an unenforced request (since enforcing something on the client is both complex and intrusive), but it is hoped the feature is useful enough that clients choose to use it.

1. The client sends a refusal to the server (including the ID)
2. The server sends a cancellation to the destination server

The request is assigned a timeout at both ends. Once the timeout is over, the request is cancelled at each end independently.