QuickList
From NMDC Protocol
QuickList
This is the accepted version of the QuickList protocol as suggested by the QuickList team. The QuickList team did not exist until I wrote this sentence, but that doesn't stop me from drafting a couple of inspiring people into the group and give credit in no particular order. Many thanks to:
• Neimad
• Meltingfire
• fusbar
• ender
• Gumboot
• Sedulus
• TasMan
• Trem0r
• arnetheduck
• Knoton
I will use the terms NDC and NHUB to denote a client or hub not featuring QuickList and QDC and QHUB for those that do. The term DC is used when the type is not yet established or of no importance. EACH and ALL signals that a message is sent N times, one message for each connected user. Also note that the terms IF, MAY, SHOULD and MUST, have the same meaning as in the internet RFC specs.
Walkthrough
Connecting
1 A DC connects to QHUB and does nothing
2 QHUB sends $Lock which starts with EXTENDEDPROTOCOL
3 QHUB also sends $HubName
4 A DC must send $Key
5 A DC may also send '$Supports QuickList|' to signal in is in fact a QDC
6 QHUB responds with '$Supports QuickList|'
Identification
1 A QDC may but should not send $Version
1 A QDC must send $MyINFO
Authentication
1 QHUB may send $GetPass
2 QDC responds with $MyPass
3 QHUB may send $BadPass and disconnect
4 QHUB may send $ValidateDenide and disconnect
Acceptance
1 QHUB may send $LogedIn to signal that H: should not be incremented
2 QHUB sends all clients MyINFO to the QDC
3 QHUB sends $OpList to the QDC
4 QHUB may send $Hello to all clients but should send it to non QDC only
5 QHUB sends $MyINFO to all QDC clients
Explanation
Connecting
This part has been through some changes. There was an argument of having the client start with $Supports and then having the hub respond to that. Having the client start with $Supports as a response to EXTENDEDPROTOCOL is in a sense much cleaner.
• I have found that $HubName can be sent pretty much at any time. I do it in conjunction with $Lock.
• $Supports are in the same format as in the client protocol; '$Supports <feat1> <feat2> <feat3>|'
Identification
• sending $MyPass early has been removed from the spec.
Authentication
• As previously mentioned $GetPass is only sent if the user has an account and the $MyPass was not sent in the identification process. $BadPass or $ValidateDenide is sent when proper as usual.
Acceptance
From testing I have found that $Hello and $MyINFO can be sent together without having to wait for a $GetINFO.
• Let the hub decide if the account should be treated as a VIP, i.e. not increment H: in the tag, hence it is not mandatory for accounts. A QDC should only respond to this message for account logins only.
• $OpList was missing.
Commands Sent
Connecting
• $Lock
• $HubName
• $Supports
Identification
Authentication
• $GetPass
• $BadPass
• $ValidateDenide
Acceptance
• $LogedIn
• $MyINFO
• $MyINFO stream
Connected
• $To
• $Search
• $SR
• $ConnectToMe
• $RevConnectToMe
• $ForceMove
Commands Accepted
Messages that a QHUB listens to in each state, QHUB ignores otherwise;
Connecting
• $Key
• $Supports
Identification
• $Version
• $MyINFO
Authentication
• $MyPass
Acceptance
Connected
• $GetNickList
• $MyINFO
• $To
• $Search
• $SR
• $ConnectToMe
• $RevConnectToMe
• $Kick
• $OpForceMove
Notes
• $ValidateNick deprecated and ignored
• $GetNickList only valid when connected, a QDC does not receive a $NickList, but a series of $MyINFOs directly.
• $Hello deprecated and ignored
• $GetINFO deprecated and ignored
• $MyINFO is always accepted as valid and denotes a new or updated client.
Note by CrazyGuy:
Standard login using QuickList support ( not registered user ):
C: <connects> H: $Lock C: $Supports QuickList..... H: $Supports....... C: $MyINFO $ALL............. H: $MyINFO $ALL.............. (all users) H: $OpList
Standard login using QuickList support (registered user):
C: <connects> H: $Lock C: $Supports QuickList..... H: $Supports....... C: $MyINFO $ALL............. H: $GetPass C: $MyPass <pass> H: $MyINFO $ALL.............. (all users) H: $OpList
