You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<divclass="paragraph"><p>Hubowner login is meant to help hubowners to edit information about their hub directly from the hublist portal.
2702
2702
It is usually an email address where the account/password information should be sent.</p></div>
2703
2703
<divclass="paragraph"><p>Hub category provides information about hub categorization such as Public, Private, Chatonly, Failover and Redirect.</p></div>
2704
-
<divclass="paragraph"><p>Character encoding provides information about character encoding currently used on hub, this helps a hublist to display correctly encoded hub information such as hub name, description, $MyINFOs, when converting texts to UTF-8.</p></div>
2704
+
<divclass="paragraph"><p>Character encoding provides information about character encoding currently used on hub, this helps a hublist to display correctly encoded hub information such as hub name, description, <strong>$MyINFO</strong>, when converting texts to UTF-8.</p></div>
2705
2705
<divclass="paragraph"><p>Common encodings are: CP1250, CP1251, CP1252, CP1253, GB18030 and UTF-8, but are not limited to.</p></div>
2706
2706
<divclass="paragraph"><p>If the hub address is 127.0.0.1, a hublist pinger will/is supposed to remove the hub from its database.</p></div>
2707
2707
<divclass="paragraph"><p>Add <strong>HubINFO</strong> to the <strong>$Supports</strong> to indicate support for this.</p></div>
<tdalign="left" valign="top"><pclass="table">Hub count, x/y/z (where x is the number of hubs as a normal user, y as the number of hubs as registered and z as the number of hubs as operator)</p></td>
2864
+
<tdalign="left" valign="top"><pclass="table">Hub count, "x/y/z" - where "x" is the number of hubs as a normal user, "y" as the number of hubs as registered and "z" as the number of hubs as operator</p></td>
<divclass="paragraph"><p>Bit 5 and Bit 6 of the 32-bit status flag are used to indicate wether a user is an OP or wether the $IN string send by the hubsoft belongs to a bot.
2952
+
<divclass="paragraph"><p>Bit 5 and Bit 6 of the 32-bit status flag are used to indicate whether a user is an OP or whether the <strong>$IN</strong> string send by the hubsoft belongs to a bot.
2953
2953
These values are read-only and should never be changed by a client.
2954
2954
The hubsoft must disconnect for this.
2955
2955
If a client connects and has successfully logged in with the correct password, the hubsoft will set bit 5 of the status flag and sends this part to all connected users, including the newly connected OP.
2956
2956
The connecting client must save the status flag it received from the hub and use it when updating status such as away and fireball.
2957
2957
However, as said, it is not allowed to set or reset bit 5 and bit 6 of the status flag.</p></div>
2958
2958
<divclass="paragraph"><p>Bit 7 of the 32-bit status flag indicates if the client is in DND-mode (Do-Not-Disturb).
2959
-
Unlike Away mode, this mode will prevent the client to receive any PM’s.
2959
+
Unlike "Away" mode, this mode will prevent the client to receive any PMs.
2960
2960
Clients are responsible themselves for setting/resetting this bit.
2961
2961
Once this bit is set, and the hub receives a <strong>$To:</strong> string for a client in DND-mode, the hub must ignore the <strong>$To:</strong> and reply to the sender with a message that the receiver is in DND-Mode.
2962
2962
A client having this bit set, should automatically reset this bit when sending a pm itself.
<divclass="paragraph"><p>Add <strong>FeaturedNetworks</strong> to the <strong>$Supports</strong> to indicate support for this.</p></div>
3032
3032
<divclass="paragraph"><p>Syntax:</p></div>
3033
3033
<divclass="paragraph"><p>An APN MultiHubChat message normally has this format:</p></div>
3034
-
<divclass="paragraph"><p><strong><(YYY)XXXXX> MMMMMMM|</strong> - where YYY is the entry point prefix, XXXXX is the username and MMMMMMM is the message.</p></div>
3034
+
<divclass="paragraph"><p>"<(YYY)XXXXX> MMMMMMM|" - where "YYY" is the entry point prefix, "XXXXX" is the username and "MMMMMMM" is the message.</p></div>
3035
3035
<divclass="paragraph"><p>To allow the different entry point handlers to identify which messages are coming from other multi hub chat entry points, there is a command send by the hub after login called <strong>$FeaturedNetworks</strong>:</p></div>
3036
-
<divclass="paragraph"><p><strong>$FeaturedNetworks YYY$$YYY$YYY$$|</strong> - YYY stands for one entry point to the chat network.
3036
+
<divclass="paragraph"><p>"$FeaturedNetworks YYY$$YYY$YYY$$|" - "YYY" stands for one entry point to the chat network.
3037
3037
In the biggest currently running instance of the APN MultiHubChat system, five or more different prefixes are used.</p></div>
<divclass="paragraph"><p>Is exactly the same as <em>raw</em>, except that the command should only be run once per <strong>%[nick]</strong>.
3334
+
<divclass="paragraph"><p>Is exactly the same as <em>raw</em>, except that the command should only be run once per "%[nick]".
3335
3335
This is to prevent the client from sending out more than one message that disconnects someone.
3336
3336
Generally, this is only useful in the User-File context (e.g. viewing search results) where it is possible to select one user multiple times.</p></div>
<divclass="paragraph"><p>This indicates that the client doesn’t need either <strong>$Hello</strong> or* $NickList* to be sent to it when connecting to a hub.
3368
+
<divclass="paragraph"><p>This indicates that the client doesn’t need either <strong>$Hello</strong> or<strong>$NickList</strong> to be sent to it when connecting to a hub.
3369
3369
To populate its user list, a <strong>$MyINFO</strong> for each user is enough.
3370
3370
<strong>$Hello</strong> is still accepted, for adding bots to the user list.
3371
3371
DC++ still sends a <strong>$GetNickList</strong> to indicate that it is interested in the user list.
<divclass="paragraph"><p>Signals support for BZip2 compressed file list instead of the Huffman encoded list that NMDC pioneered.
3989
-
The compressed file list is available for download under the name <strong>MyList.bz2</strong> instead of <strong>MyList.DcLst</strong> and <strong>files.xml.bz2</strong> instead of <strong>files.xml</strong>.</p></div>
3989
+
The compressed file list is available for download under the name "MyList.bz2" instead of "MyList.DcLst" and "files.xml.bz2" instead of "files.xml".</p></div>
3990
3990
<divclass="paragraph"><p>Add <strong>BZList</strong> to the <strong>$Supports</strong> to indicate support for this.</p></div>
3991
3991
</div>
3992
3992
<divclass="sect3">
3993
3993
<h4id="_chunk">4.6.14. CHUNK</h4>
3994
-
<divclass="paragraph"><p>This is a protocol extension by Valknut that allows retrieval of sections of a file through a modified $Get syntax.
3994
+
<divclass="paragraph"><p>This is a protocol extension by Valknut that allows retrieval of sections of a file through a modified <strong>$Get</strong> syntax.
<divclass="paragraph"><p>This feature offers passwords to be salted and hashed, which means that passwords are no longer sent in plaintext.
4019
4019
This adds "random data" to the <strong>$GetPass</strong> command.</p></div>
4020
4020
<divclass="paragraph"><p>The random data should be Base32 encoded.</p></div>
4021
-
<divclass="paragraph"><p>The data that is sent back in the <strong>$MyPass</strong> shall be the password followed by the random data, passed through the Tiger algorithm and then encoded with Base32.
4022
-
I.e., base32( tiger_hash( password + data ) ).</p></div>
4021
+
<divclass="paragraph"><p>The data that is sent back in the <strong>$MyPass</strong> shall be the password followed by the random data, passed through the Tiger algorithm and then encoded with Base32: "base32( tiger_hash( _password + _data ) )"</p></div>
4023
4022
<divclass="paragraph"><p>Add <strong>SaltPass</strong> to the <strong>$Supports</strong> to indicate support for this.</p></div>
4024
4023
<divclass="paragraph"><p>Note that the example below for <strong>$MyPass</strong> is not literal.</p></div>
4025
-
<divclass="paragraph"><p>The algorithm here is a port from ADC’s GPA/PAS.</p></div>
4024
+
<divclass="paragraph"><p>The algorithm here is a port from ADC<ahref="https://dc-protocols.github.io/ADC.html#_gpa">GPA</a> and <ahref="https://dc-protocols.github.io/ADC.html#_pas">PAS</a>.</p></div>
Clients should use the same TCP and UDP ports for both IPv4 and IPv6 if both are supported.
4052
4051
The connection mode (passive, active, SOCKS5) can be different.</p></div>
4053
4052
<divclass="paragraph"><p>The hub is required to set the IPv6 bit in the <strong>$MyINFO</strong> command.</p></div>
4054
-
<divclass="paragraph"><p>The connection mode in the <strong>$MyINFO</strong> tag changes from "M:X" where X is the connection mode (A = Active, B = Passive, 5 = SOCKS5) to "M:XY" where X is the connection mode of IPv4 and Y is the connection mode of IPv6.
4053
+
<divclass="paragraph"><p>The connection mode in the <strong>$MyINFO</strong> tag changes from "M:X" where "X" is the connection mode (A = active, P = passive, 5 = SOCKS5) to "M:XY" where "X" is the connection mode of IPv4 and "Y" is the connection mode of IPv6.
4055
4054
If a client does not support IPv4 or the IPv4 check failed, the first character will be "N" for not supported.</p></div>
4056
4055
<divclass="paragraph"><p>Add <strong>IP64</strong> to the <strong>$Supports</strong> to indicate support for this.</p></div>
4057
4056
<divclass="paragraph"><p>A client that support IPv4 and IPv6 will only use one form when sending messages to a hub.
<divclass="paragraph"><p><strong>Int</strong> and <strong>IntPas</strong> might be set to zero "0" - which means that user is actually allowed to search without time limit, and might be set to "-1" - which means that user is not allowed to use search at all due to low profile or any other kind of restrictions.</p></div>
4290
4289
<divclass="paragraph"><p>Meaning of this extension is to avoid extra search requests to the hub, which are not going to bring any search results to the user anyway.
4291
4290
Atleast the user will know the reason of search results not appearing for him on a specific hub.</p></div>
4292
-
<divclass="paragraph"><p>Add <strong>SearchRule</strong> to the $Supports to indicate support for this.</p></div>
4291
+
<divclass="paragraph"><p>Add <strong>SearchRule</strong> to the <strong>$Supports</strong> to indicate support for this.</p></div>
4293
4292
<divclass="paragraph"><p>Hub softwares currently known to support this extension: Verlihub</p></div>
<divclass="paragraph"><p>Client should not spend any resources on parsing the URL, it is enough to use the <em>getHubUrl()</em> method as is (see DC++ source).</p></div>
4314
+
<divclass="paragraph"><p>Client should not spend any resources on parsing the URL, it is enough to use the "getHubUrl()" method as is (see DC++ source).</p></div>
4316
4315
<divclass="paragraph"><p>Meaning of this extension is to collect statistics about hub addresses being used in a hub by its users, and also to extend address checking functionality to redirect users to most preferable hub address or port.</p></div>
4317
4316
<divclass="paragraph"><p>The idea was also to implement <strong>$SetHubURL</strong> command to specify preferable hub address without need to reconnect to the hub, in case it was accessed from hub favorites list.
4318
4317
We are hoping to finish this last part of the implementation very soon.</p></div>
0 commit comments