When implementing new networks, there are two factors that I consider most important:

a) How does the protocol work?
b) How does the user use the network?

Two simple questions, but wait, there's more to it. When I think "protocol", I don't just mean the raw implementation of it. I mean understanding the underlying logic, the flow, the concepts behind that, the concepts that resulted in the protocol implementation in the first place. Because if you understand the concept, the logic, then the specific implementation doesn't matter - it's just numbers, in different sequence, but the logic doesn't change. DHT-based systems are like that - for example, if you implement, say, Kademlia, by copy/pasting the code from eMule, w/o understanding HOW it works, then yes, you end up having Kademlia support, but you'v gained no knowledge on DHT's, which means next time you need to implement another DHT-protocol (either 3rd-party, or your own), you'r helpless.

And, let's face it, knowledge and understanding of how P2P systems work, finding out what logic makes something tick, is one of the things that I love about this project - you get to work with many different areas, and learn from them.

The second question was - how does a user interact with a protocol? ed2k is kinda "generic" type network - from users point-of-view, the style is shared between a number of networks, including FastTrack, G2, Ares ... you search, you queue up a lengthy list of downloads, you get your files, that's it.

However, other networks cannot be so easily thrown into same pot of tea. Bittorrent, for instance, doesn't have search, which means users go around in forums and websites, looking for torrents. Bittorrent also seems to be filled with "50x15mb-rar-torrents", something you only rarely see in ed2k. Seeding is an important part of Bittorrent, much closer to user than uploading in ed2k.

Other networks that I hope to implement in longer future also have very specific characteristics. DC++, for example, is chat-based. IRC (xdcc or smth) is a completely different beast as well. Newsgroups - whole new story - 3000-byte-messages, read by binary newsreader, merged together and hashed by some 3rd application - intrigueing topic :)

But, we'r getting off-topic. Bittorrent is the current plugin at hand, and my interest is in understanding what makes it tick, how do the users interact with the protocol, what are the problems users are having, what are the problems in the existing clients, what can we do to releave those problems... what I'm trying to avoid here is simply throwing out a ton of code, saying "ok, we have BT support", and moving on, w/o ever stopping to ask "did we solve the problem?". Heh, we don't even know yet what the "problem" is we'r trying to solve - and don't say "because HN is multi-net client and BT is a must-have-thing".

Rather, think of it like this: If I were to release a standalone Bittorrent client, what features should it have, what would it do better than the existing clients, how would it win the "market"? The rationale is that multi-net client ONLY justifies itself if EACH and EVERY ONE of it's plugins / supported networks is AT LEAST equally as strong as it would be as a standalone client. And thanks to the modular architecture of Hydranode, we actually CAN release standalone clients for different networks, as we see fit.

So what say you, long-time Bittorrent users?

Madcat, ZzZz