1. Abstract

These are the official extensions to ADC. This document is based on the information contained in the ADC wiki and ADC forum - spefications from there are moved here when they are mature and stable enough.

2. Version history

The latest draft of the next version of this document as well as intermediate and older versions can be downloaded from $URL: https://adc.svn.sourceforge.net/svnroot/adc/trunk/ADC-EXT.txt $.

This version corresponds to $Revision: 72 $.

2.1. Version 1.0

Jacek Sieka <arnetheduck@gmail.com>, 2008-05-02

  • Initial release created from original ADC 1.0 text.

  • Added PING extension for hub pingers.

2.2. Version 1.0.1

Fredrik Ullner <ullner@gmail.com>, 2009-08-04

  • Added timestamp field to MSG.

  • Added DFAV extension for distributing hub addresses.

2.3. Version 1.0.2

Fredrik Ullner <ullner@gmail.com>, 2010-04-04

  • Added UCMD extension for user commands.

2.4. Version 1.0.3

Fredrik Ullner <ullner@gmail.com>, 2010-05-26

  • Removed optional keywords from UCMD.

  • Added BLOM extension for bloom filters.

2.5. Version 1.0.4

Fredrik Ullner <ullner@gmail.com>, 2010-06-29

  • Added magnet link extension to UCMD.

  • Added NAT traversal extension NATT.

  • Added referral field to STA.

  • Added upload queue field to STA.

  • Added partial file sharing extension PFSR.

2.6. Version 1.0.5

Fredrik Ullner <ullner@gmail.com>, 2010-09-16

  • Added locale field to INF.

  • Modified user parameter line in UCMD to handle multiple inputs.

  • Added hidden in enumeration of CT field in INF.

  • Added error code Invalid feature in STA.

2.7. Version 1.0.6

Fredrik Ullner <ullner@gmail.com>, 2010-09-29

  • Added KEYP extension for providing certificate substitution protection in ADCS.

  • Added note to signal DFAV.

  • Added SUDP extension for encryption of UDP traffic.

  • Added TYPE extension for chat state notifications.

  • Added FEED extension for RSS feeds.

  • Added SEGA extension for grouping of file extensions in SCH.

  • Added failover hub addresses to the hub’s INF.

  • Added free slots to the client’s INF.

  • Added ADCS extension for encryption in ADC.

3. Extensions

3.1. TIGR - Tiger tree hash support

3.1.1. General

This extension adds Tiger tree hash support to the base protocol. It is intended to be used both for identifying files and for purposes such as CID generation and password negotiation

3.1.2. TIGR for shared files

All files shared by TIGR supporting clients must have been hashed using Merkle Hash trees, as defined by http://www.open-content.net/specs/draft-jchapweske-thex-02.html. The Tiger algorithm, as specified by http://www.cs.technion.ac.il/~biham/Reports/Tiger/, functions as the hash algorithm. A base segment size of 1024 bytes must be used when generating the tree, but clients may then discard parts of the tree as long as at least 7 levels are kept or a block granularity of 64 KiB is achieved.

Generally, the root of the tree (TTH) serves to identify a file uniquely. Searches use it and it must be present in the file list. Further, the root of the file list must also be available and discoverable via GFI. A client may also request the rest of the tree using the normal client-client transfer procedure. The root must be encoded using base32 encoding when converted to text.

In the file list, each File element carries an additional attribute "TTH" containing the base32-encoded value of the Tiger tree root.

In the GET/GFI type, the full tree may be accessed using the "tthl" type.

"tthl" transfers send the largest set of leaves available) as a binary stream of leaf data, right-to-left, with no spacing in between them. <start_pos> must be set to 0 and <bytes> to -1 when requesting the data. <bytes> must contain the total binary size of the leaf stream in SND; by dividing this length by the individual hash length, the number of leaves, and thus the leaf level, can be deducted. The received leaves can then be used to reconstruct the entire tree, and the resulting root must match the root of the file (this verifies the integrity of the tree itself). Identifier must be a TTH root value from the "TTH/" root.

In the GET/GFI namespace, files are identified by "TTH/<base32-encoded tree root>".

In SCH and GFI, the following attributes are added:


Tiger tree Hash root, encoded with base32.


Tree depth, index of the highest level of tree data available, root-only = 0, first level (2 leaves) = 1, second level = 2, etc…

3.2. BZIP - File list compressed with bzip2

This extension adds a special file "files.xml.bz2" in the unnamed root of the share which contains "files.xml" compressed with bzip2 1.0.3+ (www.bzip.org).

3.3. ZLIB - Compressed communication

There are two variants of zlib support, FULL and GET, and only one should be used on a each communications channel set up.

3.3.1. ZLIB-FULL

If, during SUP negotiation, a peer sends "ZLIF" in its support string, it must accept two additional commands, ZON and ZOF. Upon reception of ZON the peer must start decompressing the incoming stream of data with zlib before interpreting it, and stop doing so after ZOF is received (in the compressed stream). The compressing end must partially flush the zlib buffer after each chunk of data to allow for decompression by the peer.

3.3.2. ZLIB-GET

The alternative is to send "ZLIG" to indicate that zlib is supported for binary transfers using the GET command, but not otherwise. A flag "ZL1" is added to the to the SND command to indicate that the data will come compressed, and the client receiving requests it by adding the same flag to GET (the sending client may ignore a request for a compressed transfer, but may also use it even when not requested by the receiver). The <bytes> parameter of the GET and SND commands is to be interpreted as the number of uncompressed bytes to be transferred.

3.4. PING - Pinger extension

This extension can be supported by both clients and hubs, and when present, if hub supports it, it must send additional information to the client ( otherwise normal base client).

It’s purpose is to send to hublist pingers additional information about the hub that otherwise it would be impossible to get as a normal user (eg. minimum share, maximum user count, etc).

3.4.1. INF

Contexts : F

When the client supporting the PING extension connects, the hub must send its normal INF along with the following added fields ( none mandatory, if not present, it means hub has no restrictions in that matter, or non existent):

Code Type Description



Hub Host address ( DNS or IP )



Hub Website



Hub Network



Hub Owner name



Current User count



Total share size



Total files shared



Minimum share required to enter hub ( bytes )



Maximum share for entering hub ( bytes )



Minimum slots required to enter hub



Maximum slots for entering hub



Minimum hubs connected where clients can be users



Minimum hubs connected where client can be registered



Minimum hubs connected where client can be operators



Maximum hubs connected where clients can be users



Maximum hubs connected where client can be registered



Maximum hubs connected where client can be operators



Maximum possible clients ( users ) who can connect



Hub uptime (seconds)



Hub name (from BASE)



Hub description (from BASE)



Hub software version (from BASE)

The hub must continue to send the user list as for a normal user (move to NORMAL state). The pinger may decide to go through or disconnect (eg. if it doesn’t require additional information about the users).

-hub- ISID ..
-hub- IINF NIhubname DEcurrent\stopic VE.. HHexample.org:555 WShttp://example.org/ OWmyname UC2231 SS.. SF.. MS0 ML0 MC5000
- (pinger may disconnect)

3.4.2. Hub - Hublist communication

The same extension goes for hub- hublist communication. This way, the hub takes the role of the client and the hublist of the server.

The hublist may send INF about itself with NI field which would become hublist name and WS hublist web address.

-hublist- IINF NIhublist_name WShublist_address
-hub- HINF  NIhubname DEcurrent\stopic VE.. HHexample.org:555 WShttp://example.org/ OWmyname UC2231 SS.. SF.. MS0 ML0 MC5000
-( disconnect )

3.5. TS - Timestamp in MSG

Timestamp of the moment when the message was sent, expressed in seconds since the Unix Epoch (January 1 1970 00:00:00 GMT).

3.6. DFAV - Distributed Favorites

The idea behind this extension is to generate a public hublist from the users favorite hublist. Implementations should separate between public and private hubs in the favorite hublist of an user, in order not to distribute private hubs where one can not connect to anyway.

Signal DFAV in SUP and the INF’s SU field.

3.6.1. GFA


Contexts: T, C

Asks all users within the same hub with the correct feature to send all publicly available hubs, in their favorite hub list to the requesting client.

3.6.2. RFA


Contexts: C

Response of a client.


Hub address


Last succesfull login time ( number of seconds since the epoch (1970), (UTC) )

All INF fields from BASE are inherited. All INF fields from PING extension are inherited.

3.7. UCMD - User commands

CMD name

Contexts: F

States: NORMAL

User commands are used to send hub-specific commands to the client which provide useful shortcuts for the user. These commands contain strings which must be sent back to the hub and keyword substitutions in the strings. Each user command has a display name, a string to be sent to the hub, and one or more categories where it may appear. The strings passed to the hub must first be passed through a dictionary replacement that replaces all keywords in the string and then through the equivalent of the C standard function "strftime", with the current time.

Name uniquely (per hub) identifies a particular user command. The name may contain "/" to indicate a logical structure on the viewing client, where each "/" introduces a new submenu level. Other than name, the command also has a number of flags that further detail what to do with it.


1 = Remove Command


Message Category, 1 = Hub command, client parameters only, 2 = User list command, client and user parameters, 4 = Search result command, client, user and file parameters, 8 = File list command, client, user and file parameters. Multiple types are specified by adding the numbers together.


The full text to be sent to hub, including FOURCC, parameters and keywords.


1 = Constrained, when sending this command on multiple users (for example in search results), constrain it to once per CID only


1 = Insert separator instead of command name (name must still be present to uniquely identify the command).

3.7.1. Keywords

Keywords are specified using "%[keyword]". Unknown keywords must be replaced by the empty string. Additionally, all %-substitutions of the C function "strftime" must be supported.

The following tables specify the keywords that must be supported.

Client parameters


Client CID




One for each flag on that particular hub; for example, myI4 and myNI

User parameters


User CID


User SID


One for each flag on the user sent; for example, userI4 and userNI


Prompts the user for input where info is the displayed text description for the user input. info can be used for multiple values (combobox etc), and should be structured as "general info/default selection/value0/value1/…/valueN". The general info can be viewed as the caption of the user input dialog. Default selection is an integer k which signifies the default value to be used. Note that N >= k >= 0 and N >= 1. Note that values are 0-index based. Values are separated with a forward slash (/). If a forward slash is part of a value, it should be escaped by using an additional forward slash (//).

File parameters


One for each flag contained within a search result or file list entry (see RES)


Specify magnet link. Magnet links are used to reference files across networks and applications. Clients may ignore parameters it does not understand, but are free to pass on the parameters to other programs.

Hub parameters


One for each flag of the hub; for example, hubNI and hubVE

3.7.2. Example

ICMD ADCH++/Hub\smanagement/Register\snick TTHMSG\s+regnick\s%[userNI]\s%[line:Password\s(leave\sempty\sto\sun-reg)]\s%[line:Level\s(facultative;\sdefaults\sto\syour\sown\slevel\sminus\sone)]\n CT2

ICMD ADCH++/Hub\smanagement/Reload\sbans TTHMSG\s+loadbans\n CT3

ICMD ADCH++/Hub\smanagement/Reload\sscripts TTHMSG\s+reload\n CT3

ICMD ADCH++/Info TTHMSG\s+info\s%[userNI]\n CT2

ICMD ADCH++/Info TTHMSG\s+info\n CT1

3.8. BLOM- Bloom filter

Bloom filters allow the hub to filter certain searches using bitmap that represents the hashes of the files in the users share. BLOM is an extension that allows hub software to create a map (bloom filter) of the shared files on the hub, but with minimal effort, e.g. the hub doesn’t keep a list of files, but a filter that never produces false negatives but only possible false positives. This can potentially save bandwidth and effort on the client side. When the user updates the share, the client must send an INF containing the flag SF. The hub may at any time request that the client sends an updated version of its bloom filter by sending a GET command to the client. The client will then respond using SND and send the bloom filter binary data.

3.8.1. Legend


Number of bits used for file hashes


Number of files in the user’s share


Size of the bloom filter in bits


Number of sub-hashes constructed from the file hash


Number of bits to use for each sub-hash


Propability of a false positive

The hub chooses k, h and m.

3.8.2. Restrictions

k * h < = b

h < = 64

2h > m

m mod 64 == 0

3.8.3. Probability

p == (1 - (1 - 1 / m)(k * n))k

False positives

p == 0

False negatives

3.8.4. Protocol changes

Signal BLOM in SUP.

For the SND type, adds H as message type.

For the GET type, adds I as message type.

For the GET type, adds "blom" as type.

For the GET type, "/" shall be used as namespace.

For the GET type, 0 (zero) shall be used as start position.

For the GET type, m / 8 shall be used as byte amount.

Updates GET with the following flags;


Specify k.


Specify h.

3.8.5. Algorithm

The client constructs the bloom filter by creating a bit array of m bits set to 0 (zero). For each file it then sets to "1" k positions constructed from the file hash. Seeing the file hash as a stream of bits (starting from the lowest bit of the first byte, ending at the highest bit of the last byte), the client should use h bits starting at the first bit of the first byte to create an integer and apply modulo m to get the position in the bit array, then redo the process k times advancing the starting position by h each time.

Once the hub has received the bloom filter bit array, for each search command it processes, if it contains a hash search term, it can skip broadcasting the search to a particular client if at least one of the k bits in that clients bit array is "0", calculating positions as the client does when setting bits to "1". The hub has to evaluate the filter for each client that it has a bloom filter for, for each search.

3.8.6. Probability calculations

p = (1 - (1 - 1 / m)(k * n))k, thus p becomes smaller as m grows and larger as n grows. Larger m means more bits to transfer but also fewer false positives. The optimum value for k given m and n is (m / n) * ln 2. The largest k supported by a hash of a certain size is b / h, so if the hub wants the smallest p possible, it should choose the smallest possible h which gives the largest k, and then calculate m = k * n/ln 2, checking that the resulting m < 2h. 2h should much be larger than m (at least 3-4 times), because of how the modulo operator works. Also, with m grows the required bandwidth to transfer the bloom filter, so the hub may wish to cap m. In that case, it should still choose k according to m / n * ln 2, but send an h as big as possible to alleviate biasing problems.

3.8.7. Sample implementations


For TTH roots, b is 192 and a reasonable value for h is 24, giving a maximum k = 8 which means that m = 8 * n / ln 2 ≈ 11.5 * n. The required bandwidth then becomes 11.5 * n / 8 bytes, so approximately 1.44 bytes per file in the users share. For 20000 files, m should then be 230016 (taking into account the modulo 64 requirement), giving a p = 0.004, in other words ~99.6% of all searches that don’t match a users share would not be sent, saving valuable upload bandwidth for the hub. The client calculates i valid positions, if x is an array of bytes containing the hash of the file, on a little-endian machine, by doing pos = x[0+i*h/8] | (x[1+i*h/8] << 8) | (x[2+i*h/8] << 16) for i = [0;k). This is of course a special case where h % 8 = 0, the actual algorithm has to take into consideration values for h where the integer crosses byte boundaries.

For test vectors, see the ADC wiki talk page.

3.9. NATT - NAT traversal

NAT traversal allow two passive clients to connect to each other. For more information about NAT traversal, see Passive Mode C-C Connections and NAT Traversal.

If a client does not support TCP4 or TCP6, it will send an RCM to the client it is trying to connect to. If the other client also doesn’t support TCP4 (or TCP6 correspondingly), NAT traversal may instead be used. Signal NATT in the INF’s SU field.

Do note that the hub must forward I4 or I6 for respective clients' INF.

3.9.1. BASE RCM updates

When receiving an RCM and the client does not support TCP4 or TCP6, and if NAT-T is supported in the remote client, a NAT command should be sent repeating the protocol and token. The port shall be the outbound port to the connected hub.

3.9.2. NAT

NAT protocol port token

Contexts: T

States: NORMAL

Upon receiving this, try and connect to the specified port. An RNT command should be sent repeating the protocol and token. The port shall be the outbound port to the connected hub. Upon receiving this, try and connect to the specified port.

3.9.3. RNT

RNT protocol port token

Contexts: T

States: NORMAL

Upon receiving this, try and connect to the specified port.

3.9.4. Example

Client A is connected to hub A with the outbound port 1000 and client B is connected to hub A with the outbound port 2000. Client A has the SID AAAA and client B has the SID BBBB.

Client A: DRCM AAAA BBBB ADC/1.0 foobar

Client B: DNAT BBBB AAAA ADC/1.0 2000 foobar

<Client A connects to client B’s IP address and port 2000>

Client A: DRNT AAAA BBBB ADC/1.0 1000 foobar

<Client B connects to client A’s IP address and port 1000>

3.10. RF - Referrer notification

Extends the RF field of the INF to STA, allowing a client to notify clients and hubs upon SUP-negotiation from where the C-C or C-H originated from.


URL of referrer

3.10.1. Example


CSTA 000 referrer RFadc://example.com:1234

3.11. QP - Upload queue notification

This extension’s purpose is creating a queue on a client, when multiple other clients want to download from it, but they have no slots. Currently, when a slot is being freed, the first connecting client gets it. Other clients that don’t have the luck of getting in time to attempt to download, have to wait again. The client who creates a queue must have a ticket number for each connecting client, which must be kept internally , and a difference between current connecting client’s queue number and the currently uploading client’s be provided to the connecting client, so that the clients are being deserved in the order they originally connected. The client could have a ticket incrementing starting from 1 for each session. Connecting clients must use the same token as they used when originally connected.


Queue number, representing how many others are in front in the queue.

3.11.1. Example

The following example will notify that the client’s slots are full and that there are three uploads in the queue.

CSTA 253 No\sslots\savailable QP3

3.12. PFSR - Partial file sharing

Partial File Sharing allows sharing of files which are available in user’s download queue or in finished downloads list. As a result of this, new files will be spread much faster over whole network.

When client receives search request (SCH), it looks into shared list to see whether requested hash is available between shared files. If it’s found, everything is processed as normally. In other case, it looks into download queue (then, into finished downloads list) and receives a list of available chunks for requested hash. It mustn’t take every chunk, but only that ones which are fully downloaded and has already been verified (e.g. against TTH leaves).

The feature should be signalled in SUP as PFSR.

3.12.1. PSR


Contexts: F, U

States: NORMAL

Information about downloaded and verified chunks is sent to requester with this command. When the requester is active command is sent over UDP (with U type) else it is sent over hub (with D type).


UDP IPv4 port or 0 if we don’t want receive a response. If UDP port is not zero (it must be when we are passive user), a PSR receiver must respond us with PSR including his available (and verified) chunks. The client must also set UDP port to zero to avoid infinite PSR sending.


Same as U4 but with IPv6 port.


File hash


Count of downloaded (and verified) chunks the user has.


Comma separated list of start and end index of chunks the user has. If a user has a continous block of chunks, the intermittent start and end indexes may be omitted. For example, if a user has chunk 0 and 4 of total 5 chunks, then PI is "0,1,4,5". If the user has chunk 0, 1 and 4, then PI may be "0,1,1,2,4,5" or "0,2,4,5".

3.13. LC - Locale specification

This extension’s purpose is to notify the hub which user locale the client is using as well as the default locale for the hub. This allows hubs to customize text sent to clients, depending on language, left-to-right or right-to-left and more. If the hub does not directly support the client’s locale, it should attempt to fall back to the same language group (e.g. hub supports en-US but not en-AU, so falls back to en-US), and if this is not available, then fall back to the hub’s own locale.

BCP47 should be used as reference for locale structure.


User locale

Note that the standard suggest that the language should be in lowercase and the country in upper case. Note that the country code may be more than two characters. Additionally, dash (-) and underscore (_) are acceptable seperators.

3.14. Hidden status for client type

This extension will add to the CT field enumeration in the INF to denote a user as "hidden". Other clients shall as appropriate not display the user in user lists etc.



Full updated and comparable text;


Client (user) type, 1=bot, 2=registered user, 4=operator, 8=super user, 16=hub owner, 32=hub (used when the hub sends an INF about itself), 64=Hidden. Multiple types are specified by adding the numbers together.

3.15. "Invalid feature" error code

This extension will add "Invalid feature" as error code in STA. Invalid features are features the hub or client deem inappropriate or simply not welcome. The error code should not be used for features the hub or client does not know of.


Invalid feature. Flag "FC" is the FOURCC of the invalid feature(s). If multiple features are invalid, use comma between the features (i.e. FCQWER,ASDF,ZXCV).

3.16. KEYP - Certificate substitution protection in conjunction with ADCS

This extension adds a simple, but secure way to protect against man-in-the-middle attacks against ADC when wrapped with TLS (1.0 or later). It does not require setting up a CA or signing keys, but that is still possible if desired.

The extension introduces a keyprint parameter to the ADCS URI. The keyprint parameter is a hash of the server certificate.

The extension also requires clients to publish their own certificates' keyprint in the KP field in the INF. Assuming one trusts the hub enough not to maliciously change the keyprints en route (a reasonable assumption given the hub’s existing position of trust), and given that the connection to the hub has been similarly authenticated (either as above or via a directly downloaded trusted certificate), client-client connections are also protected against attempted man-in-the-middle attacks - without messing around with having to get everyone’s certificates signed in advance.

The keyprint parameter consists of a hash name, followed by a forward slash (/), followed by the Base32-encoded cyrptographic hash of the certificate.

The hash used shall be SHA256. Other extensions may add other hashes, given sufficient security contemplation.

INF field;


The client’s own certificate keyprint.

3.16.1. Keyprint replacement behaviour

If a client receives a KP field in an FINF broadcast via a hub it is connected to using ADCS and a trusted key as above (or otherwise), it should be regarded as the valid and correct keyprint for that client’s IP/port/hub combination, replacing any earlier keyprint for that IP/port/hub combination.

3.16.2. Keyprint verification

When initiating a TLS handshake with a remote host where the keyprint is known, the client can verify that a man-in-the-middle attack is not occurring by checking if the hash given in the keyprint exactly matches that of the certificate presented during the handshake by the remote host.

Suppose the client is aware of a remote host’s keyprint and is in the process of connecting to that host. A certificate substitution attack is in place if the hub presents itself with a certificate that does not match and where the certificate is not the root of the valid signature chain covering the certificate. If the client detects such an attack, the client should abort the connection and notify the user with a message stating, for example, "Crypto error: Detected attempted man-in-the-middle attack, aborting". (This error quite possibly represents a real attempted attack that has been foiled; we may try auto-reconnecting but we should NEVER ignore it, or it will succeed. We may wish to avoid stating the keyprint of the certificate that was actually received.)

Optionally, when receiving a TLS handshake, if the client knows what the remote host’s keyprint ought to be, the client could also verify this. However, note that only the initiating side needs to check this for the man-in-the-middle protection to be valid; specifically the hub doesn’t need to remember, or even understand, clients' keyprints.

3.16.3. Security Considerations


The certificates, including the name fields, are sent in the clear during the initial handshake. Therefore it is recommended to avoid identifying marks in the certificates CommonName fields (for example) that would clearly single them out as being TLS keys used by ADCS:, and the CID field most definitely should not appear. Quite possibly no name fields should appear, or they should be blank.


The keyprint in the ADCS URI prevents a clandestine man-in-the-middle (certificate substitution) attack on the TLS session with the hub, if and only if the kp parameter hasn’t been modified by an attacker.

Suggested countermeasures against this include the following;

  • Even if otherwise unprotected, an attacker would likely only have a maximum of one opportunity to make the substitution (by changing the kp parameter when the URL is first sent to the user); if it’s changed later, it will be detected. ("Casual first-use" security, as often used in SSH.)

  • Checking the fingerprint or transferring the hub URL out-of-band (for example by telephone, or in person) could reveal or thwart man-in-the-middle attacks; something’s wrong if you don’t have the same URL as the hub operator gives out. (PGP-style "sneakernet" security.)

  • We would be protected if the URL were in a file signed by some secure means by a party we have already decided we trust not to change the URLs maliciously. Encryption would not be necessary, only a signature to ensure no untrusted party has modified the KP fields. (A signed hublist, possibly.)

Finally, we would be protected were the hublist/URL retrieved from an https: site signed by a CA we trust not to issue signatures for any domain to someone who doesn’t own that domain, and the owner of that domain trusted not to modify the KP fields. (SSL-style security.)


We are, in particular, trusting the hub not to maliciously modify the KP fields sent by the clients through their INF broadcasts. However;

  • The hub would gain nothing from swapping the keyprints of its users, as it would not gain anything from mounting a man-in-the-middle attack on its own users that it does not already have the ability to do, as it’s the hub; and

  • If the client do not trust the hub enough not to maliciously modify the data, why is the client choosing to connect to the hub and transmit the client’s IP address through the hub?

  • It could be detected by cross-checking with other clients/hubs, as connecting through a malicious hub would clearly show to have a different keyprint to any other hub; therefore any hub doing this would obviously be quickly removed from hublists.

3.16.4. Example


3.17. SUDP - Encrypting UDP traffic

This is an extension that allows UDP traffic to be encrypted.

While assymetric encryption may be optimal in sense of security, a symmetric cipher will protect perfectly against outside adversaries given the hub-client connections is also running ADCS. New is that senders now create a random IV for their "request command" (e.g. searches) and send it along the "response command" (e.g. search result).

Signal SUDP in SUP and in the INF’s SU field.

If a client signal support for SUDP in an ADCS hub, it may extend commands that will generate a response (e.g. SCH) with a KY-field as the encryption key. Clients shall only include the flag in ADCS hubs.


16 byte encryption key in BASE32. 128 bit AES encryption shall be used.

For example, a SCH command will result in 29 Bytes of overhead ("<separator>KY"+26 Bytes Base32 encoded key).

A client that has a response for the command can now encrypt the response message by prepending 16 bytes of random data and afterwards encrypting it with AES/CBC/PKCS5Padding (Cipher/Blockmode/Padding) using 16 zero bytes as IV for CBC.

In above scenario, the response would be a RES command.

3.17.1. Decryption notes

In the case of searching, the searching client in return for decryption first has to guess which commands it receives are encrypted and which are not. It can do so for example by simply trying decryption with all currently active keys. If a key is wrong or the message was not encrypted, padding will fail and decryption is unsuccessful!

Client may otherwise verify if the message is a U-type message, followed by a known command (and a space). If that is not the case, the client takes the most recent key and decrypts. If that succeed, the message is valid.

There is a potential chance that decryption succeed with what is a bad key. If that is the case, the client should verify that the data is not garbled.

Note that in a normal circumstance, the client will most likely be using relatively few active keys.

3.18. TYPE - Typing notification

This extension adds a typing similar to Jabber’s "Chat state notifications".

Signal TYPE in SUP and the INF’s SU field.

3.18.1. TPN

TPN code

Contexts: F, T

States: NORMAL

Command should be sent to the Reply-To user (PM field in MSG, if present). All TPN messages are sent when the event occur.

Code values:



Closed tab, minimized window, etc

Should be sent.



Changed tab, window became unfocused (but not closed or minimized), etc

Should be sent.



Paused typing.

Should be sent.



Now in this tab, reading message and is actively participating in the chat session.

Must be sent.



Currently typing a message.

Must be sent.

3.19. FEED - RSS feeds

The extension adds RSS feed support.

Signal FEED in SUP and the INF’s SU field.

3.19.1. RSS

RSS url

Context: F, T

States: NORMAL

url is the URL to the feed.

Additional fields:


Name of the author.


Name of post.


Content summary of post.


Direct link to post


Feed name


Feed description


Time of publish. Specified in seconds since UNIX epoch.


1 = Remove feed from aggregator.

3.19.2. Examples

Publish a new feed called Example_feed and with a description description_of_feed:

RSS http://example.com/rss FNExample_feed FNdescription_of_feed

Remove a feed:

Publish a new post New_post from John_Doe:

RSS http://example.com/rss TINew_post DEdescription_of_post LIhttp://example.com/entries/new_post DT1253628000 CRJohn_Doe

3.20. SEGA - Grouping of file extensions in SCH

In BASE, clients add EX fields to SCH to denote which extension files should have. This can lead to a situation where the large bulk of extensions are of similar "type", e.g. audio files or documents. This extension intend to add a field GR which groups multiple extensions. In addition, the field RX shall be used for group-exclusion; if all extensions in a group but two are desired, field RX will be used to exclude those group items.

Signal SEGA in the INF’s SU field for support of this extension.

Field GR values, where multiple groups are specified by adding the numbers together:



















Field RX:


Extensions in a group that are not desired. E.g., "GR1 RXMP3 RXWAV" would include all extensions in the audio group except MP3 or WAV.

3.21. FO - Failover hub addresses

If a hub goes down, the client’s only option is to keep re-trying the last known hub address. This extension will add a list of failover hub addresses, field FO, that the client can try to connect to, if the main hub address fail.

Clients should decide the frequency of connection attempts (for the main hub as well as the failover addresses). The client should try connecting in the specified order. The client may decide what to do after the FO-list is exhausted, but recommended is to try to connect to the main hub and continue with the list as before.

The client should display an appropriate message to the user that it has connected to a failover address.

This extension should be implemented, at a minimum, for favourite hubs. If clients have any concerns about where a hub may redirect users to, or about storing the extra state information, then it may avoid implementing this for non-favourite hubs.

Field FO in the hub’s INF:


Failover hub addresses. Specify well formed ADC or ADCS URI addresses, with multiple addresses separated with a comma. Example; FOadc://example.com:1234,adc://example.net:1234

3.22. FS - Free slots in client

This is an extension that will broadcast the amount of free slots the client has available.

Field FS in the client’s INF:


Free slots available.

3.23. ADCS - Symmetrical Encryption in ADC

ADCS is an extension that has the goal of adding the TLS/SSL layer just over the TCP layer and beneath the application layer (where ADC runs). This way, the ADC protocol remains unchanged while the connections are encrypted. The connecting party performs a TLS handshake immediately after the TCP connection is established. The ADC handshake is performed and once the TLS connection is established the ADC handshake proceeds as usual.

Encrypted ADC connections can be established using a TLS tunnel, both for hub and for client connections. Certificates can be used to authenticate both hub and user, for example by making the hub the root CA, and only allow clients signed by the hub to connect. Ephemeral keys should be use to ensure forward secrecy when possible. A future extension or revision of this extension will provide ways to handle certificate based logins, who creates which certificates and who signs what, and all that is not specified in this revision.

3.23.1. Client-Hub encryption

TLS client-hub connections can be initiated either by negotiating the feature "ADCS" on connection or by using the protocol adcs:// when initiating the connection.

3.23.2. Client-Client encryption

TLS client-client connections can be established either by negotiating the feature "ADCS" on connection or by specifying "ADCS/1.0" in the CTM protocol field. Clients supporting encrypted connections must indicate this in the INF SU field with "ADCS".