$MyINFO $ALL <nick> <description>$ $<connection><magic byte>$<email>$<share size>$|
Command not allow $ and |, except them in nick is not allowed space.
Description, connection and email is optional. Client sending this command to hub on login and when some info changed. Hub sending this command to all connected client.
Is on end of description and looks for example like <++ V:0.699,M:A,H:1/0/0,S:2>
Tag is starting with < followed by client short name or short identification (here ++ for DC++) and followed by space. Next parts are separated by , and use one char identification followed by : and some text. Tag is ending with >.
One byte (char) after connection where bits are in original client used to show statuses. Because original software use only first 4 bits, newer software use other 4 bits to show support for protocol extensions. Hub is checking second 4 bits and broadcasting $MyINFO with enabled only bits for extensions that he is supporting.
Original bits used for statuses:
Extended bits used for extensions:
$MyINFO $ALL matisskka <StrgDC++ V:2.42,M:A,H:7/0/0,S:7>$ $1A$$36913421887$|
$MyINFO $ALL damon <++ V:0.761,M:P,H:5/0/0,S:10>$ $1000A$$105848991048$|
$MyINFO $ALL DRUIDASLT <ApexDC++ V:1.5.2,M:A,H:99/0/0,S:5>$ $0.1Ifirstname.lastname@example.org$98951178281$|
$MyINFO $ALL Laller26 <++ V:0.791,M:P,H:39/0/0,S:20>$ $0.5Aemail@example.com$0$|
$MyINFO $ALL PPK _@o*<Cz V:0.699,M:AA,H:0/0/1,S:1>$ $CableÉ$PPK@CzDC.org$77396125917$|
Common mistake is that magic byte is one byte integer where value 1 is normal, 2 and 3 is away, 4 and 5 is server, 6 and 7 is server away, 8 and 9 is fireball, 10 and 11 is fireball away. Many clients in older versions support it that way, but most of them fix that when extensions using unused bits were introduced.