The fading of Direct Connect

I was planning a development overview article about ADC and DC++ as a whole for a longer time, but today I got the inspiration since an asshole someone who actually does not do any developement banned me (again) from DCDev Public Hub (also called "Toast's Playground Hub" or "STFU Hub"). So I started collecting some of the reasons why Direct Connect is fading away.

Advanced Direct Connect?

In 2006 we were enthusiastic about the new Direct Connect protocol called ADC (Advanced Direct Connect). Back then we thought it would offer a lot of great features to the end-users so they would stay on Direct Connect hubs instead of switching over Bittorrent trackers. We even started Elite Istenhub which was the first ADC-hub run by Hungarian operators and when the ADC hublist was set as the default hublist in DC++ it became the largest ADC hub of the world with more than 2000 users in a few days from nothing! So we all agreed that - despite of the unstable hub software we had - it was a good idea to have an ADC hub and were waiting for the more advanced features to come both on end-users' and hub owners' side.

We were posting on the Official DC++ Blog pointing out the advantages of ADC over the old style protocol called NMDC. ADC finally allows users to have UTF-8 encoded texts on the chat which means that there would be no more problem with chatting on languages which has different special characters in their alphabet (ő, ű, ş, etc.). The users could change their nicks on the hubs just like they do it on IRC. There were discussions about the possibility of different shares for different hubs which was a long-awaited feature even in that time. Cologic even posted an article about it to the DC++ Blog in 2007. In the spirit of waiting for "multiple share for multiple hubs" we were planning to start a specialized hub for sharing high-quality audio (lossless) and video files. ADC also supports "extensions" which means that hub and client developers could add features without breaking the compatibility with other clients. I made an extension draft also in 2007 which would allow users to see their position in line so instead of getting a general "No slots available", they would see how many people are waiting before them. So more and more ideas were coming, developers announced that they would not extend NMDC anymore since new features were going to be added to the new protocol instead.

So let's see an incomplete list of possibilities what ADC could or can do for the end-users:

• Users can use any kind of character-sets on the hubs so they can chat on any languages including Hungarian, Russian and Japanese.
• Users can change their nicks if the hub allows it.
• ADC makes possible to use different share for different hubs so users could join to specialized hubs with a different set of shared files.
• ADC could be extended for easily allowing users to create chat rooms with their friends just like on Steam (select their friends -> right click -> "Open chatroom"). We actually have a draft for this special extension.
• ADCS, the secure version of ADC would allow users to use encrypted transfers so they could trick the traffic shaping of ISPs limiting the p2p transfers.

Let's see which of the above is currently can be done on an ADC hub:

• You can use UTF-8 for Winamp-spam.

Probably it's the most important feature of ADC, so we can consider it to be a great success.

Where did the possibilities go?

Users do not care about technical details. So there's no point of telling them to switch to ADC because of the protocol is not so ugly than before. Do they see it? No. They need hubs to connect to. But why should hub owners switch to ADC? In other words: what motivate hub owners to run an ADC-hub?

Switching to ADC from NMDC has a serious downside: the hub address must be changed, and since DC++ does not have automatic protocol detection, this can't be done seamlessly. So by doing that, you will lose dozens of users. Why would you do it anyway? For example, if you wanted to offer new features to your users which are not available on NMDC. But what features do they have?

They can use UTF-8. Okay, it's fun, but since most users are using single language on hubs it's not the pussy magnet of ADC. They can speak in third person for real. OK, they have "real /me" now, but do your users see it at all? Most of them are using StrongDC++ and its mods which hide the lack of /me on older style hubs too, so it's not a feature for them either. They could change their nicks, but not every client has a /nick command (BCDC++ has), and again: the ability of chaning nicks without reconnecting does not motivate you to switch to ADC. One of the "real" features would be the multiple share profiles thing, but that's not supported. But still, if you can't even provide new features to your users, you still could switch to ADC. But a hub owner needs a hub which actually works and usable. This includes the following requirements:

• The hub should not crash often and should not use a lot of CPU
• Operators should be able to configure the hub either by using built-in commands or by manipulating the config file then reload it (uglier method)
• Operators should be able to manage user accounts: register them, remove them, and track them (last login time, who registered the user and some other basic info)
• A hub must allow operators to ban and filter the unwanted users. Also, other operators should be able to track who banned who and why.
• The hub should allow extensions via scripts so the missing things can be done easily. If the hub does not support scripting, it should have a lot of built-in commands and features.

The reason no hub owners are switching to ADC is the following:

• The number of hub softwares with at least covers 50 % of the previous list: 0 (it is a number which is smaller by 1 than "1")

uHub is stable, but does not support Lua scripts, and you can't manage the user profiles from the hub. It also lacks good banning methods. ADCH++ has Lua-support, but the API is the most ugliest I've ever seen in my whole life, although I have written a lot of Lua scripts earlier (including Oxygene, or ASLib which provided a multihub/multiuser - text based - gaming system for NMDC/ADC hubs). So that's why the number of 3rd party ADCH++-sripts is also zero.

In Direct Connect development we can notice a change. In the past, most DC-hubs were originated from Sweden. Later it started moving over to Central Europe, so we had a lot of Czech and Hungarian hubs, and - along with them - a lot of developers writing scripts for hubs, or creating client and hub softwares (Verlihub, PtokaX, StrongDC++, etc.). As I noticed, lately Direct Connect became popular in Russia, which continues the trend moving Direct Connect to the east. They have the power to develop something. It's enough to think of EiskaltDC++ which is a DC++-mod built in a short time providing the first usable client for the Linux users after a very long time. So the ideas are still coming continously, but they are not always being heard.

Years ago the developers of DC++ opened a hub called DCDev Public which was an open hub for developers sharing their thoughts and experiences about development and moving Direct Connect forward. We also hosted DCDev Public for a time on our own server. Lately the hub is run by a people with the nick Toast, and it seems he thinks he created the whole Direct Connect: he does not like russians, so he kills them out from the hub whenever he gets a chance. Also, when someone points out that not everything works perfectly, then he starts bitching that someone is against "their" opinion. Probably he doesn't like me because I tell him what he does is harmful for Direct Connect. Finally banned me from DCDev Public because told him "he don't speak good English". Neither I, but at least I try.

So, despite of developers' effort, the progress of client and hub development became a parade: two inebriate men tries to decide what should happen to Direct Connect and who can participate in it. They have a few developers who work hard like poy who is fixing bugs constantly and tries to polish the GUI or eMTee who recently commited the not-yet-released "automatic connection detection" feature. But unfortunately it won't be enough for at least keeping the users from going away.

Farewell

ADC is a great protocol despite of having a few downsides. When it started, we all though it could bring Direct Connect to a new level. But five years is a lot of time. For example, your children go to school at the age of six. In technology, time goes even faster, but all we have is the ability of the UTF-8 Winamp-spam.