The next version of ADC will be released in the near future. My first suggestion is that the version to be called 1.1 or something more important, because 1.0.1 suggests only a small revision of not such big importance. Another reason is that ADC versions are not released that often that we actually need a "0" in there. ( there will probably not going to be 1.0.2, 1.0.3 , 1.1.0 and so forth ) My suggestion is to version the ADC something like 1.1, 1.2 and so forth until a major change or stability with extensions will make the need of moving to 2.0.
My personal desire for the next ADC version is to include the extensions that make ADC a better protocol and bring up the things that people always appreciated about it.
Here is a list of the extensions that should be included (and wait until they are mature enough to include)
- PING - Pinger extension, which is already approved and it will surely be in the next version
- DFAV - Distributed favorites, the same goes for this extension as well
- ADCS - ADC Secure , still a real specification needs to be done, but this extension is mandatory if we are to move to the next level of direct connect
- BLOM - Bloom Filters, already with preliminary implementations, this extension also can bring the plus that can turn more attention to ADC
- SHA1 - SHA 1 hashes, because currently ADC relies on TIGR only, even if SHA is a broken algorithm, one can still easily use it with no problems in the network
- UCMD - User commands , because ADC clients really need this feature and it can bring a more human face to the hubs using ADC
- REF - Hub refferal on C-C connections because it's a simple way to figure out sources for CTM attacks
- UPQU - Upload Queue , already with implementations in clients, because users need a better way of queueing on uploads
- TYPE - Typing notification extension, can make the protocol more IRC-like and some developers may think of using the protocol for an IRC-DC hub in order to create a more social network.
When I say this I also think about the new ideas like darkKlor's MSTR admin extension, or the URI form extension that have been presented here on ADCPortal. Also, interesting ideas that are worth investigating are BigMuscle's DHT extension or the hash set for multiple files implementation, which will both add more features to ADC that will approach it to torrent-like functionality.
I do hope that the next ADC version will have this extensions included , if they are mature enough to be included and not neglige them because I think all of them are more or less important for somebody in the network who might use them, and this was the whole purpose of extensions and the extensibility of ADC, to make the protocol friendly for everybody wanting to use it.
Last but not least, I am eager to find the HI field back in the INF command because it had a practical use and it was interesting, and still implemented in many ADC software used today.