OCTAGRAM

Where is it implemented? Looked into sources of FlyLink and StrongDC for several hours already. Everything is so asynchronous, and folders indeed eventually get TTH somehow, but I have no clue how does it happen with them. Wiki with "Hash set extension" description is dead, and my attempts to recalculate hash completely independently in Ada (using XMLAda, AdaCF and Adagio's Tiger Tree implementation). TTH for files works fine. Can't make it work for folders. I always thought that it's just TTH of sorted concatenated hashes, and I can reimplement it at any time, but time has come, and I just can't get through. I tried to sort or not sort hashes. I tried to reverse endianness or not reverse endianness. I tried to reverse endianness before or after sorting. I tried raw TIGER or TTH. I just can't make it match. I'm totally destroyed.

Well, I can tell the difference between MediaInfo implementations in Shareaza, GreyLink and FlyLink. Shareaza has pretty full metainformation gathered in a single file. This allows browsing filelist as either folder hierarchy or medialibrary grouped by artist and album; season and episode and so on. GreyLink doesn't build such file, but it is possible to send a query for a single file. FlyLink includes metainformation into filelist, but this metainformation only tells about audio and video quality. E. g. no artist name. I can tell which clients support .dcls metafiles (sublists) in which way. Historically, the first evidence was IceDC++ that has sublists named ".DcLst". GreyLink (being the most advanced in many ways) names sublists as ".dcls". It looks like independent implementation, so .dcls was chosen independently. GreyLink supports recursive sublists. Recursive sublist has a metafile virtually put in the directory it describes. This is not important when someone uploads a metafile to a website, because metafile remains available on a website. However, it makes big sense when metafile and the directory it describes are being spread via magnet link to metafile. Availability of the small metafile becomes vital to downloading the virtual directory it describes. Finally, FlyLink developers were forced to implement dcls because users demanded. However, in order to be distinguished (they knew for sure that GreyLink uses .dcls) or maybe they have a wisdom overflow (не знаю, как по–английски «от большого ума»), either way FlyLink uses .DcLst. I can tell for another features of modern DC++ clones. But the ones listed in this question are often I've never heard of, and I've never seen non-ADC-compatible DC++ clone. .PDC++? What is this? Never heard of. iDC++? What's the hell is this? Never heard of. Why are we talking about ADC support in 2011? It's a checkpoint that was passed long ago.

Like this idea too. An analogy I have in mind is what would the user experience be if any network program could only function when exclusivelly holding access to network. E. g., user can't run browser and messenger simultaneously. The only way to manage this is to bundle browser and messenger together in a single program. That's what happening in p2p world (Shareaza is apogee). p2p connection is exclusivelly controlled by a single program, and this program incorporates too many use cases. In a perfecter world I would use Miranda, Pidgin, Colloquy or whatever else plugin for p2p chat. And Virtual Shell Namespace (or GVFS) for browsing files. My p2p needs are mostly satisfied by greylink dc++. Somehow greyteam manages to both have a sense how things should be done (lots of features missing in ApexDC++ or implemented improperly) and also time and skills to implement it. But this kind of request is not likely to be done by greyteam.

Well, when I right click on a folder and choose

There are several ways to get integrity lost. There are options