Server protocol:Changes

Below we outline the changes in the server-to-server (S2S) protocol between latest 3.2.x version and 3.4-alpha.

Note that all traffic we discuss here is server-to-server traffic. At no point we expose such traffic to regular clients (eg: the use of UID's).

Removed features
The following features were removed in 3.4.x

SJB64 (Base64 timestamps)
This feature was removed because it only saves a few bytes of bandwidth per line at a cost of complicating the code too much.

ZIP (Zip links)
This feature was removed when the I/O engine was rewritten. It may or may not be re-introduced at a later point.

NS (Server numerics)
Server numerics have been removed but have been replaced by SID's (see next section)

New features
These are new features that you can choose to enable (or not).

SID's
Server id's (SID's) work very similar to the removed server numerics feature and consist of 3 alphanumerical characters which uniquely identify a server (where the first character is always a digit). No base64 encoding involved. You can (theoretically) use a SID anywhere a server name is used, like: :server.name NOTICE #chan :Hello Can become: :001 NOTICE #chan :Hello

SID command
When a server links in you now receive a "SID" rather than a "SERVER" command.

/*
 * m_sid
 * parv[0] = sender prefix
 * parv[1] = servername
 * parv[2] = hopcount
 * parv[3] = sid
 * parv[4] = serverinfo

TODO: add documentation reference to serverprotocol command rather than paste here

UID's
When you enabvle SID you also get user id's (UID's). UID's consist of alphanumerical characters and can (theoretically) be used at any place where you use a nick name. The first 3 characters identify the SID of the server where the user is on (this is part of the UID) and thus a UID will always start with a digit.

The benefit of using UID's is that it really uniquely identifies a user regardless of the current nick name. This allows us to solve some long-standing problems where nick collisions and race conditions cause desynchs such as 'ghosts' in a channel.

Example: :One NOTICE Two :Hi there Can become: :001AAAAAA NOTICE 002AAAAAA :Hi there

As you can see, it doesn't necessarily shorten the length. That isn't the purpose of UID. The benefit of UID is the uniqueness described earlier.

UID command
Instead of "NICK" protocol messages you will receive "UID".

** m_uid
 * parv[0] = sender prefix
 * parv[1] = nickname
 * parv[2] = hopcount
 * parv[3] = timestamp
 * parv[4] = username
 * parv[5] = hostname
 * parv[6] = UID
 * parv[7] = servicestamp
 * parv[8] = umodes
 * parv[9] = virthost, * if none
 * parv[10] = cloaked host, * if none
 * parv[11] = ip
 * parv[12] = info

TODO: add documentation reference to serverprotocol command rather than paste here

Recommendations
If you want to support SID's and UID's then we suggest:
 * store the SID & UID in your server & client structs
 * make functions like find_person also search this field. UID's and SID's just look like regular names after all, except they start with a digit
 * ensure you handle the SID and UID commands
 * send SID in PROTOCTL to indicate your software supports SID & UID