ADC? No, cancelled…

Back in the end of 2000’s when the 1.0 version of the ADC protocol was ready and the implementation had started to taking shape the protocol maintainers thought it’s a good idea to add information about the distinct new protocol of DC to Wikipedia. Besides linking to the technicals a brief description of what and why is ADC was added to the new Advanced Direct Connect Protocol page.

The page, professional and made according to the best Wikipedia standards, had been improved over time and stayed there for many years – until the end of last year when someone requested a complete removal, an uncontroversial deletion. This action was requested to be reverted (thanks to klondike) which means that per the Wikipedia rules the page itself cannot be requested to be removed again. However, a few weeks later, another admin made a lawnmover style deletion of the best part of the content of the page citing that the source of information, this very blog, where the most of the content are from the ADC protocol’s designers, maintainers and implementators, is unreliable.

Of course Wikipedia has its own rules and they have been controversial all the time. This time they’re clearly followed the rules unwisely and I guess it’s not worth to engage into an add/remove style fight with them anymore. Who knows, maybe cancel culture has reached Wikipedia as well or it’s just another attempt at making Wikipedia worse for technical purposes.

In any case we decided to preserve the removed document, originally added by Fredrik Ullner, here:

---

Advanced Direct Connect (ADC) is a peer-to-peer file sharing and chat protocol, using the same network topology, concepts and terminology as the Direct Connect (DC) protocol.

“ADC” unofficially an acronym for “Advanced Direct Connect”.^[1]

Contents

• 1 History
• 2 Design and features
• 3 Protocol
• 4 See also
• 5 References
• 6 External links

History

ADC was created to allow an extensible protocol and to address some shortcomings of the Direct Connect protocol. It was initiated by Jacek Sieka, under the influence of Jan Vidar Krey’s DCTNG draft.^[2] The first revision of ADC came in 2004 and the first official version in 2007-12-01.

Design and features

ADC is structured around clients that connect to a central hub, where the clients (users) can chat and download files from other clients (users). The hub provides routing between clients for chat, searches and requests for connections. The actual file transfers are between clients.

The protocol itself is split in two parts: a base protocol that every client and hub respectively must follow and extensions that are optional. The protocols allow signalling of protocol features (such as bloom filters), and messages can be constructed to only be routed to those who support that particular feature.

Each hub has their own rules and are commonly governed by hub operators.^[3] Hubs may define different capabilities for hub operators. The hubs themselves do not regulate discussion and files, but the hub operators. The hub regulate minimum share and maximum amount of simultaneous hubs; things that are sent by the client, rather than the user.

Lists of hubs ^[4] exist where a hub’s name, description, address and rules are specified. With the hub list, users can choose hubs that are similar according to the user’s liking of discussion topics and files.

The peer-to-peer part of the protocol is based on a concept of “slots” ^[5] (similar to number of open positions for a job). These slots denote the number of people that are allowed to download from a user at any time. The slots are controlled by the user of respective client.

ADC require that all text must be sent in UTF-8, which means that users with different system encoding (say, Russian and Chinese) are able to chat with respective native characters.

The protocol natively supports IPv6.

There are two modes a user can be in: “active” or “passive”. Clients in active mode can download from anyone else on the network. Passive mode users can only download from active users. Passive clients will be sent search results through the hub, while active clients will receive the results directly. An active searcher will receive (at most) 10 results per user and a passive searcher will receive (at most) 5 results per user. NAT traversal exist as a protocol extension,^[6] which allow passive users to connect to other passive users.

The base protocol does not require encryption, but extensions exist to provide encryption with TLS.^[7]

Files in client connections are identified by their hash, most commonly the Tiger Tree Hash. The hash algorithm is negotiated with the hub and used throughout the client-hub session, as well as subsequent client-client connections.

Protocol

The ADC protocol is a text-based protocol, where commands and their information are sent in clear text, except during password negotiation. The client-server (as well as client-client, where one acts as a “server”) aspect of the protocol stipulates that the client speak first when a connection has been made. For example, when a client connects to a hub’s socket, the client is the first to talk to the hub.

The protocol requires that all text must be sent as UTF-8 encoded Unicode, normalized in form C.

There are no port defaults, for hubs or clients.

Hub addresses are in the following form: adc://example.com:411, where 411 is the port.

During hub-client protocol information exchange, the client offers a set of hashes it supports. The hub will select one of these hashes, and that hash will be used throughout the hub-client session. If the hub deems that the client doesn’t support an (arbitrary) appropriate hash set, an error is raised.

The global identification scheme is based on the hash set producing two end-hashes, where one of them depends on the output of the other. During hub-client information exchange, the client will send these end-hashes, encoded with base32, which the hub will confirm to match. One of these base32 encoded hashes will be further sent to other clients in the network. The global identification scheme is this last string. The client may change its end-hashes on a hub-to-hub basis.

Each user, during a hub session, is assigned a hash that only lasts that particular session. This hash will be used for all client references in that hub. There is no dependency on nicks.

Each client information notification is incrementally sent.

An incoming request for a client-client connection is linked to an actual connection, with the use of a token.

Searches use a token, as well, to identify each result of a search.

There is no out-of-the-box ability for a client to kick or redirect another client from a hub. The hub, however, can kick and redirect arbitrarily. The hub can also require that all other clients in the hub must terminate their transfers with the kicked/redirected client. If a client is redirected to another hub, the redirecting client must use a referrer, similar to the HTTP referrer. The kicked/redirected client is not required to receive a notification message.

The peer-to-peer part of the protocol is based on a concept of “slots” (similar to number of open positions for a job). These slots denote the number of people that are allowed to download from a user at any time. These slots are controlled by the client. Automatic slot allocation is supported by the protocol.

The token in the client-client connection decides who should be allowed to download first.

Downloads are transported using TCP. Searches can be transported using TCP or UDP.

An active client has a listening port for TCP and another for UDP, though the ports don’t depend on each other.

Protocol delimiters are ‘\n’ and ‘ ‘ (space). The character ‘\’ is used as an escape sequence. Allowed escape sequences are “\n” (new line), “\s” (space) and “\\” (backslash).

The protocol allows for extensions such as compression with bzip2 or encryption with TLS.^[8] While the protocol does not mandate that these extensions be implemented, hubs may require them.

See also

• NeoModus Direct Connect protocol (NMDC)
• Comparison of ADC software

References

1. Fredrik Ullner (March 2007). “ADC: The run down”. DC++: Just These Guys, Ya Know? blog. Retrieved 2010-12-13.

2. Jan Vidar Krey (August 2006). “ADC: Protocol simplicity”.

3. Jan Vidar Krey. Archived from the original on 2013-01-30. Retrieved 2006-09-23.

4. Fredrik Ullner (March 2006). “Power + Person = Operator”. DC++: Just These Guys, Ya Know? blog. Retrieved 2010-12-13.

5. Fredrik Ullner (January 2007). “The parts of a hub list”. DC++: Just These Guys, Ya Know? blog. Retrieved 2010-12-13.

6. Fredrik Ullner (March 2006). “Slots, slots, slots…”. DC++: Just These Guys, Ya Know? blog. Retrieved 2010-12-13.

7. Fredrik Ullner (December 2010). “ADC Extensions – NATT – NAT traversal”. ADC Project. Retrieved 2010-12-13.

8. Fredrik Ullner (December 2010). “ADC Extensions – ADCS – Symmetrical Encryption in ADC”. ADC Project. Retrieved 2010-12-13.

9. En_Dator (March 2009). “TLS and Encryption”. ADCPortal. Archived from the original on 2011-07-07. Retrieved 2009-03-01.

External links

• The ADC Project
• ADC Protocol
• ADC Extensions
• DC Base – Discussion Forum for ADC Developers / Enthusiasts

---

Click here to see how the original Wikipedia page looked like before the content removal.

We’ve once had a very good overview of ADC at Wikipedia, a brief explanation of what it is all about so interested people can go further, contact, etc…. Now we have almost nothing. To compensate that I’ll also try to preserve this document another way by adding it to the ADC project site later.

May people with the powers to destruct valid and current information sleep better after each time they’re acting so.

Why DCNF uses HTTPS via Let’s Encrypt

All DCNF web services either use HTTPS or are being transitioned to HTTPS.

The US government’s HTTPS-only standard and Google’s “Why HTTPS Matters” describe how HTTPS enables increased website privacy, security, and integrity in general. ISPs, home routers, and antivirus software have all been caught modifying HTTP traffic, for example, which HTTPS hinders. HTTPS also increases Google’s search ranking and, via HTTP/2, decreases website loading time.

Somewhat more forcefully, Chrome 56 will warn users of non-HTTPS login forms, as does Firefox 50 beta and according to schedule, will Firefox 51. This will become important, for example, for the currently-under-maintenance DCBase forums.

Beyond the obvious advantages of not costing money, Let’s Encrypt provides important reduced friction versus alternatives in automatically and therefore scalably managing certificates for multiple subdomains, as well as ameliorating certificate revocation and security-at-rest importance and thereby HTTPS management overhead by such automation allowing more shorter-lived certificates and more rapid renewal. Additionally, as crypto algorithms gain and lose favor, such quick renewals catalyze agility. These HTTPS, in general, and Let’s Encrypt, specifically, advantages have led to adopting HTTPS using Let’s Encrypt.

Setting up multiple-subdomain HTTPS with nginx, acme-tiny, and Lets Encrypt

This guide briefly describes aspects of setting up nginx and acme-tiny to automatically register and renew multiple subdomains.

acme-tiny (Debian, Ubuntu, Arch, OpenBSD, FreeBSD, and Python Package Index) provides a more verifiable and more easily customizable than the default Let’s Encrypt client. This proves especially useful in less mainstream contexts where either the main client works magically or fails magically, but tends to offer little between those two outcomes.

The first step is to create a multidomain CSR which informs Let’s Encrypt of which domains it should provide certificates for. When adding or removing subdomains, this needs to be altered:
# OpenSSL configuration to generate a new key with signing requst for a x509v3
# multidomain certificate
#
# openssl req -config bla.cnf -new | tee csr.pem
# or
# openssl req -config bla.cnf -new -out csr.pem
[ req ]
default_bits = 4096
default_md = sha512
default_keyfile = key.pem
prompt = no
encrypt_key = no

# base request
distinguished_name = req_distinguished_name

# extensions
req_extensions = v3_req

# distinguished_name
[ req_distinguished_name ]
countryName = "SE"
stateOrProvinceName = "Sollentuna"
organizationName = "Direct Connect Network Foundation"
commonName = "dcbase.org"

# req_extensions
[ v3_req ]
# https://www.openssl.org/docs/apps/x509v3_config.html
subjectAltName = DNS:dcbase.org,DNS:www.dcbase.org

Then, when one is satisfies with one’s changes:
openssl req -new -key domain.key -config ~/dcbase_openssl.cnf > domain.csr
in the appropriate directory to regenerate a CSR based on this configuration. One does not have to change this CSR unless the set of subdomains or other information contained within also changes. Simply renewing certificates does not require regenerating domain.csr.

Having created a CSR, one then needs to ensure Let’s Encrypt knows where to find it. The ACME protocol Let’s Encrypt uses specifies that this should be /.well-known/acme-challenge/ and per acme-tiny’s documentation:
# https://github.com/diafygi/acme-tiny#step-3-make-your-website-host-challenge-files
location /.well-known/acme-challenge/ {
alias $appropriate_challenge_location;

allow all;
log_not_found off;
access_log off;

try_files $uri =404;
}

Where this needs to be accessible via ordinary HTTP, port 80, to work most conveniently, even if the entire rest of the site is HTTPS-only. Furthermore, this needs to hold even for otherwise dynamically generated sites — e.g., http://build.dcbase.org/.well-known/acme-challenge/, http://builds.dcbase.org/.well-known/acme-challenge/, http://archive.dcbase.org/.well-known/acme-challenge/, and http://forum.dcbase.org/.well-known/acme-challenge/ would all need to point to that same challenge location, even if disparate PHP CMSes generate each or they ordinarily redirect to other sites (such as Google Drive).

If this works, then one sees:
Parsing account key...
Parsing CSR...
Registering account...
Already registered!
Verifying dcbase.org...
dcbase.org verified!
Verifying www.dcbase.org...
www.dcbase.org verified!
Signing certificate...
Certificate signed!
When running acme-tiny.

Once this works reliably, the whole process should be run automatically as a cron job often enough to stay ahead of Let’s Encrypt’s 90-day cycle. However, one cannot renew too often:

The main limit is Certificates per Registered Domain (20 per week). A registered domain is, generally speaking, the part of the domain you purchased from your domain name registrar. For instance, in the name http://www.example.com, the registered domain is example.com. In new.blog.example.co.uk, the registered domain is example.co.uk. We use the Public Suffix List to calculate the registered domain.

If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate. Combined with the above limit, that means you can issue certificates containing up to 2,000 unique subdomains per week. A certificate with multiple names is often called a SAN certificate, or sometimes a UCC certificate.

Once Let’s Encrypt certificate renewal’s configured, Strong Ciphers for Apache, nginx and Lighttpd and BetterCrypto provide reasonable recommendations, while BetterCrypto’s Crypto Hardening guide discusses more deeply rationales behind these choices.

Finally, SSL Server Test and Analyse your HTTP response headers offer sanity checks for multiple successfully secured subdomains served by nginx over HTTPS using Let’s Encrypt certificates.

Old DC++ forums restored

DC++ used to have a forum where people would receive help, give suggestions on improvements and discuss protocol features. This forum migrated from SourceForge to the domain dcpp.net (now defunct, don’t use it). The entire site was then attacked and the forum was put offline. This was in 2007, and no forum has yet replaced the old DC++ forum as a whole.

The DCBase.org project is put in place to harmonize different content for Direct Connect. As such, the project host the DCBase forum (previously ADCPortal) where today’s discussions for (primarily but not exclusively) ADC development lies. However, it is also important to look in the past and what has been done and the discussions that were held then. As such, the old DC++ forum is now restored. This forum is now set up similar to the old forum, and the database is migrated as such. The entire forum is locked down (until someone want DC++ to regain that as a forum) so you can’t post anything.

I will probably create posts in the future where the old forum is referenced (in particular NMDC and ADC development and protocol discussions).

If anyone else have a forum, wiki or site that is now defunct, let me know. It is important that the content that we once produced isn’t completely lost.

A Decade of TTH: Its Selection and Uncertain Future

NMDC and ADC rely on the Tiger Tree Hash to identify files. DC requires a cryptographic hash function to avoid the previous morass of pervasive similar, but not identical, files. A bare cryptographic hash primitive such as SHA-1 did not suffice because not only did the files need identification as a whole but in separate parts, allowing reliable resuming and multi-source downloading, and per-segment integrity verification (RevConnect unsuccessfully attempted to reliably use multi-source downloading precisely because it could not rely on cryptographic hashes).

Looking for inspiration from other P2P software, I found that BitTorrent used (and uses) piecewise SHA-1 with per-torrent segment sizes. Since the DC share model asks that same hash function work across entire shares, this does not work. eDonkey2000 and eMule, with per-user shares similar to those of DC, resolved this with fixed, 9MB piecewise MD4, but this segment size scaled poorly, ensured that fixing corruption demanded at least 9MB of retransmission, and used the weak and soon-broken MD4. Gnutella, though, had found an elegant, scalable solution in TTH.

This Tiger Tree hash, which I thus copied from Gnutella, scales to both large and small files while depending on what was at the time a secure-looking Tiger hash function. It smoothly, adaptively sizes a hash tree while retaining interoperability between all such sizes of files files on a hub. By 2003, I had released BCDC++ which used TTH. However, the initial version of hash trees implemented by Gnutella and DC used the same hash primitive for leaf and internal tree nodes. This left it open to collisions, fixed by using different leaf and internal hash primitives. Both Gnutella and DC quickly adopted this fix and DC has followed this second version of THEX to specify TTH for the last decade.

Though it has served DC well, TTH might soon need a replacement. The Tiger hash primitive underlying it by now lists as broken due to a combination of a practical 1-bit pseudocollision attack on all rounds, a similarly feasible full collision on all but 5 of its 24 rounds, and full, albeit theoretical, 24-round pre-images (“Advanced Meet-in-the-Middle Preimage Attacks”, 2010, Guo et al). If one can collide or find preimages of Tiger, one can also trivially collide or find preimages of TTH. We are therefore investigating alternative cryptographic hash primitives to which we might transition as Tiger looks increasingly insecure and collision-prone, focusing on SHA-2 and SHA-3.

ADC 1.0.2 released

A new version of the base ADC protocol is now released, version 1.0.2.

The document may look slightly different, especially with the addition of commands in the table of contents. The document itself (its content) is not that much modified (except for state management, see below).

An important part of the document is a new addition, a terminology section where difficult words or phrases are specified. This list is obviously meant to be much more than mere four items but it’s at least a start.

The STA previously didn’t specify who had the responsibility for action when a STA is sent with the severity Fatal (2). This has always been the originator of the message, and this is now explicit.

The state management is re-worded and restructured. All information about state has now been moved to its own section, allowing an implementator a quick and comprehensive overview on the requirements for the state management. Previously, the state management was sprinkled all across the document, making it difficult for a person to properly implement a state machine in their software. This has meant that state management information is now removed from each command (only thing remaining is an explicit note about in which state each command is used). Certain information is also clarified, such as what to call the parties in a client to client connection (“client party” and “server party”) and state transitions.

Version 1.0.1 of ADC was also ambiguous in state management when it came to one important part: who shall send the first INF in a client to client connection. This is important because it has the ramification that it makes multi-share difficult. The current specification is now not ambiguous, and makes the following stance: the first party to send the INF is the connecting party (“client party”). No known implementation suffer from this explicit note, as all manage this scenario just fine. Basically, this change means that multiple shares (per hub) may not be too far off.

The new version also brings in a new time where we can safely and appropriately update the base document. There was an announcement period when the document was going to be released which meant that developers have had time to adjust their software and give feedback in a timely manner.

Propose your ideas

Hi people just wanted to share relevant information regarding ADC Development

We recently updated our mediawiki installation and now that its updated i decided to rewamp the proposal list so that mr. Ullner gets a good tool when looking at extensions to include in the protocol.

Proposed Extensions

The idea is that everyone with an wiki account helps out and adds and removes ideas if they are included or denied entry and we use the protocol idea forum on adcportal as an official place if you wanna add just the spec or a link to the spec thats fine as long as it gets posted there so Ullner doesnt have to chase the idea over the net.

Hope this will improve development and document who did what in the future :)

DSLReports DC FAQ gets updated

The popular Direct Connect FAQ at DSLReports existed and served as a primary source of DC related information and howto’s for a long time. However, some parts of it has become really outdated over the years, but now we can annouce that the complete FAQ list has been updated in the recent weeks.

Dead links and pages about depreciated features are corrected, the related DC++ changelog entries updated, so the currently existing pages should have correct and recent information about DC++ and the whole DC network. Of course the whole FAQ could be improved with new questions and answers but that’s another story…

People now can visit the site and if anything you think is missing or not correct, you can leave feedback on the bottom of every FAQ page. Any corrections or suggestions welcomed…

Documenting ADC

The state of ADC has flourished a bit since I last wrote about it, and there are a couple of things to note.

The basic ADC document is basically untouched since it’s last release at 1.0.1. The major updates have occurred on the extensions side of ADC.

The extensions version is currently as of writing at 1.0.3 as the official version. There is a 1.0.4 brewing but it’s something that will be released later on.

ADC extensions are relatively simple to suggest and I’ll happily add the extension as an official one if it has grown traction by developers and a consensus on the extension specification has been agreed upon. Usually, to suggest an extension, pop in to the forums and specify as thoroughly your extension and what implementations exist. Additionally, it’s possible to go to our developer hub, but you might want to still post in the forums as chat can be cumbersome to reference. Updates to the extensions document are usually grouped in one update, so we don’t have multiple updates on the same document and even the same extension in a relatively short while, causing implementations to be potentially invalid.

There is a started ADC recommendations document, basically aimed at providing guide lines for developers, but it’s hardly complete. The idea is to get more people involved in this document so new developers can benefit from old developers’ wisdom of ADC, quirks in implementations and more.

Do note that I am not the only one with access to the official ADC documents; there are others as well, so you can contact the other members of the ADC project if I’m not available.

ADCH++ 2.4 pushed out

Hi

Well a new version of ADCH++ is out due to the fact that we kinda messed up the 2.3 release so for all of you that are out there running 2.3 update to 2.4 and you will be fine.

We also added documentation from ADCH++ on the website for any developer wanting to help out by making plugins or lua scripts.

http://adchpp.sf.net/doc/

changelog:

• 222. By Pietry
  edited installer, changelog, version
• 221. By poy
  fix command dispatching
• 220. By poy
  fix ban reason
• 219. By poy
  add +topic (and aliases), shortcut to +cfg topic
• 218. By poy
  add history & motd to the default scripts list

ADCH++ (Windows Bin Zip File)

ADCH++ (Windows Installation)

ADCH++ (Source Windows/Linux)