Interview series: cologic
June 21, 2011 Leave a comment
This is one part of a blog series where influential people in Direct Connect are interviewed about the past, present and future state of Direct Connect.
cologic is a developer known for his influence in the development of BCDC++, DC++ and ADC. He initiated the creation of BCDC++, introduction of hashes, Lua and more.
What follows are the questions I asked and the answers he gave.
- What and when made you start with Direct Connect?
I started using Direct Connect in 2002 primarily out of curiosity.
- When did you start with the development of DC++?
I first made BCDC++ and contributed to DC++ in 2003.
- What made you interested in the development of DC and DC++?
I found using DC, especially through DC++, interesting. However, due to DC++’s immaturity in 2003, it lacked useful features. The ones I wanted I had to find or write code for, creating interest in the development of DC and DC++.
- What prompted BCDC++?
(1) Upload limiting, though important to rendering DC usable, was commonly regarded as akin to cheating or faking. Thus, I involved myself in DC development to obtain a client providing it;
(2) Because many hubs allowed NMDC but not DC++, I desired NMDC client emulation. This was gone no later than 2005, by which time DC++ was near-ubiquitously allowed. However, that was first complemented then supplanted by…
(3) Description tags, conceded to persuade hub operators to stop banning DC++ per item 2, leaked excessive information and provided too much power to hubowners. They obviously weren’t disappearing from DC++, so I removed tags from BCDC++ for some years before description tag faking became more viable than outright tag removal. (BCDC++ has neither emulated clients nor faked description tags for more than three years.);
(4) It took surprisingly long for DC++ to encode $ and |, used in the NMDC protocol, such that one could use them in chat. I fixed that in BCDC++ before DC++ picked up a workaround;
(5) Lua scripting looked quite useful on the hub side and I wanted similar capabilities in a client. I thus incorporated a Lua scripting interface into BCDC++.
- What were your goals with BCDC++? Do you have any goals now for it? Do you see a future still for it?
I incorporated features both that hubowner-dominated DC politics kept out of the main clients and to satisfy niche desires of mine too obscure to justify including in a more mainstream client.
I plan now to merge the remaining important features from BCDC++ into DC++ and deprecate it. All recent major BCDC++ changes, such as NAT traversal, were promptly sent upstream to DC++. The remaining blocking feature is the script support, waiting upon a DC++ plugin API.
- You have been involved with the development of ADC. Do you have any goals and ideas?
Most broadly, I did and continue to push to remove NMDC’s flaws. These include, in reverse order of importance:
(1) plaintext password transmission. Combined with (2), this means that NMDC has no security against even passive eavesdroppers. ADC uses a challenge-response login protocol to fix this;
(2) lack of encrypted connection support. This continues to render NMDC vulnerable to even passive ISP interception. ADC supports SSL in the form of ADCS;
(3) in two symptoms of essentially the same issue, allowing trivial nick-faking and preventing multiple shares per client per port from functioning. ADC adds additional client-client session authentication to avoid these issues;
(4) finally, its lack of extensibility. People hijacked commands such as $SR and $To to implement CTCP-like messaging due to hubs routing only a small, fixed set of commands from one user to another. Towards this I supported the separation or message type from message content.
- What do you think will attract more users of DC in general? Would that be desirable?
I could not confidently predict what would attract more DC users in with specifics. Generically, reducing barriers of entry I would expect to work. Increased user volume seems necessary to keep DC above critical mass. Network effects dominate – I tend to believe that the value of the network is roughly proportional to the square of the number of users, so each gain or loss of users matters substantially.
- Would you change anything with DC, DC++, ADC etc if you could?
DC software I see as implementing a chat and filesharing system which supports indefinitely sized, browseable individual shares which allow people to organize and share personal collections; allow for private networks; tend to operate on a small scale by modern P2P standards; and support social interactions with the same set of users sharing files.
I support DC remaining primarily in this role because breaking those assumptions tends to result in other already-extant P2P software being highly competitive with the best DC software, whereas within that niche, DC clients, especially DC++ are the best solution I’ve found. Therefore, the DC topology broadly I find adequate.
Taking DC as given, DC++ implements the concept well. Its primary deficiencies are lack of plugin and scripting support and lack of multiple share support. I’m largely satisfied, however.
ADC, low usage levels aside, has worked out well as a protocol. I’d fix a couple of things though:
(1) the login password protocol is weak, not using secure cryptographic hash-based constructions. Standard solutions exist but aren’t backwards compatible and it’s unclear the current specification justifies breaking such compatibility. Further mitigating its impact, it’s irrelevant in ADCS. Still, it’s an obvious mistake;
(2) experience has belied the conceit that global identification works. It’s caused problems in private message routing and CTM routing, both revealing that not all hubs on which a given pair of users both are connected are functionally identical nor should they be treated as such. A private message is less private on some hubs than others, CTMs are blocked by some hubs but not others, and there’s no standard way to communicate these distinctions to a client. Untrustworthy heuristics emerged to work around a false assumption of substantial similarity between hubs that should have never been present.
- How much time do you spend on DC development nowadays?
Not much. I’ve written a couple of sizable features in the last few months – writing NAT traversal and rewriting bandwidth limiting (with BigMuscle’s help) were short, intense bursts – but it’s otherwise in maintenance mode.
- What would cause you to spend more time with development?
Finding something intriguing and novel best done within DC++ rather than on its own.
- What are your short and long term goals with DC that you would want to achieve?
I’d like to use ADCS to encourage more encryption use on the Internet. When governments unabashedly place dragnets in key routing nodes and shunt off all the traffic they can get – last year, the NSA monitored 1.7 billion emails per day, for example – and ISPs openly run deep packet inspection, encryption suggests itself.
- What is the most difficult thing you have done with DC?
Learning and working around sparsely-documented Windows RichEdit control quirks.
- What is the most important thing you have done with DC?
Introducing Tiger Tree Hashing. Their presence has fundamentally and positively altered DC. They’ve cleared hubs of the identically-named but undetectably and differently corrupt files that used to fill them. Further, TTHes allow for workable multisource downloading. Even single-source downloading is now actually reliably between users because it let old hacks such as rollback be removed. (Auto)search for alternate sources doesn’t depend on filename and thus works more reliably. DC is a much more reliable and usable network because it relies on TTHes.
- What is the most fun thing you have done with DC?
My favorite episode was the short-lived bier.lua fallout; “bier? ja lekker! :)” might trigger memories. Also amusing has been the continued reaction to displaying users’ IPs in the userlist, search frame, and transfer frame.