Hi everyone! The ALPN proposal is online for quite some time, and there was only positive feedback so far (minus minor things related to the wording).
If anyone have any concerns or comments, please do write a comment on the proposal:
If not, I think it's time to proceed with the implementation on the client-side.
The hub side is already done - we have a functional hub running at:
And had no issues related to the protocol detection so far.
For other existing hubs, the status is:
- ADCH++ (poy) - client first, see below
- Verlihub (RoLex, FlylinkDC-dev) - client first, see below
- uhub (janvidar) - development discontinued; maybe later
We also have a pinger with ALPN support for NMDC/ADC that is being integrated into most major hublists:
- dcnf.github.io/Hublist (Kcchouette)
- dchublist.org (Hades)
- dchublist.biz (provolone)
The te-home.net (RoLex) also supported the proposal and already integrated HTTP ping described in the proposal.
The consensus on the client side also seems positive (correct me if I'm wrong):
- poy (DC++)
- maksalaatikko (AirDC++, based on DC++)
- FlylinkDC-dev (FlylinkDC++)
- Crise (ApexDC++) ?
But someone needs to do the first step on the client side. For DC++ and DCNF it seems to be poy, but if anyone can help with it - let me know.
I opened an issue in DC++ to track the progress on the implementation:
It also contains a specific function name and example to make implementation easier for C/C++ and openssl.
Please do not be indifferent! I understand that all of us have lives and other things to do.
But if you care about DC network, please find some time to do this - it's the first step to make the network popular again.
I want to answer some FAQs upfront as well.
Q: Dexo, why don't you just send a PR to the client?
A: The truth is, I'm not a C/C++ programmer anymore. I used this language ~8 years ago. Thus, it will take me multiple days just to get started.
So I need you help, especially from client maintainers. You already know the codebase, and the change is so trivial that you won't need much time to enable it.
Also, as you know, I already dedicated an immense amount of time to implement a hub and pinger from scratch to support the proposal and show that it's practical.
Now someone has to flip the switch and enable it in the client. I think DCDev hub exists specifically for this - to coordinate development. As a community.
Q: Seems like the change is so massive that you have to develop a new hub for it?
A: No, not at all. The change is literally few lines of code on the client side, since clients already support both protocols.
But most hubs don't. So I have to develop a new hub that supports both protocols to demonstrate the protocol negotiation in action.
Q: TLS is a complex security-related topic. How can I implement ALPN without digging deep into the crypto?
A: Although ALPN is part of TLS, it has nothing to do with security. It merely transfer some application-related metadata about protocols (in clear text).
In our case it's a string "adc" and/or "nmdc". No crypto involved. All existin TLS libraries already support it, so it's a single call to openssl.
Q: Why does it matter? Clients already can connect to ADC and NMDC hubs with no issues.
A: Correct, there appears to be no difference from the first look.
But it opens a lot more practical possibilities than you might think:
- Safer connectivity, since ALPN only runs over TLS.
- It allow clients to use a different protocol for C-C than the one used for C-H. Will eventually allow to deprecate NMDC for C-C connections completely.
- Hubs cannot migrate from NMDC. With ALPN it will be possible to gradually change NMDC feature by feature without breaking anything and possibly migrate to ADC.
- Allows more significant changes to the protocol flow. For example: UTF-8 in NMDC by default!
- For both protocols, it allows to "bake-in" extensions that become a de-facto standard. Good examples are NoHello in NMDC and SEGA in ADC.
I can continue this list, but the main point is that it will "unfreeze" protocols, effectively allowing to fix existing issues without breaking anyone.
Q: It seems contradictive. We are changing things, but nothing will break. How it's possible?
A: This was exactly the reason why ALPN was implemented in TLS in the first place. The idea is that client and server sends a list of supported protocols.
If one of the side doesn't support ALPN, the other side will know it and fallback to the default - same as it is right now.
But if both sides support ALPN, they can agree on a specific protocol to use. Let's say both say "nmdc", and start using it. This is the first step for integration: "nothing changed" and nothing is broken.
The next step is to start issuing new protocol "revisions", for example "nmdc/1" which will have UTF-8 by default. And keep revisions small to boost adoption.
But instead of forcing the immediate switch to nmdc/1, the switch can be gradual - client declare support for both "nmdc" and "nmdc/1" and agree on a specific revision both sides support.
So nothing will break, but up-to-date clients will have some advantage over old clients.
Q: It looks good from a technical point of view, but what is the benefit for our users?
A: You are right, users won't see any benefits from ALPN immediately, except that they won't need to bother with "adc://" prefix in the hub address.
But, they do care about features that ALPN enables!
- UTF-8 for NMDC is impossible without ALPN. It will make a huge difference for users that connect to hubs in other countries. Especially for downloaded filelists.
- Remember the "friend list" problem for NMDC? Well, it's solvable with ALPN since we can change the protocol to include CIDs now.
- Users raised concerns about ADC exposing IPs of all users by default. Again, can be solved with ALPN easily.
So it's the first step to provide a solid foundation for future changes in a backward compatible way.