It's been a while since I posted an update about my work. Some might have worried that I was less involved in Hive. It was quite the opposite. This means that I isolated myself in my cave so as not to be distracted and to focus on a specific task.
The last job I worked hard on was to finalize the decentralization of HiveAuth.
What, HiveAuth isn't decentralized?
Let's call a spade a spade: no! At the moment HiveAuth is only partially decentralized. Remember the diagram describing the Hive Authentication Services:
In this diagram, there are three parts:
On the left, the applications. I have provided several app examples as well as several open-source libraries so that apps can interact with the HiveAuth infrastructure. Depending on the apps you use, we already have several decentralized solutions running on this side.
On the right you have Hive Keychain Mobile which is the only wallet that has actually implemented HiveAuth support. But I also provided open-source code that allows anyone to run their own Private Key Storage App (PKSA) or develop an application similar to Keychain. We can therefore also consider this part as decentralized.
In the center, there remains the HiveAuth infrastructure which was until now the only part not yet decentralized, because I'm the only one to operate it and the code isn't open-source yet.
Why so you will ask? Here are the main reasons for this:
1. Technology
The first reason is purely technical. Until now, the code wasn't designed to run multiple interconnected nodes.
Interconnecting several authentication nodes, making them communicate with each other without hitches, and making your network of nodes reliable and resilient is not an easy task.
I first carried out an analysis and many tests with existing technologies like ipfs, redis, peer-js, orbitdb, ... But each time I ran into one or more problems that made me abandon these solutions, either for reasons of excessive dependence on third-party code, added complexity, or for security reasons.
My requirement was to make the HiveAuth network highly resilient and not dependent on anything centralized to start its nodes or for them to communicate with each other, which would be an unacceptable single point of failure for me.
Therefore, I completely redesigned and redeveloped this layer of the HiveAuth infrastructure. The result is that HiveAuth's code is not only independent from any third-party libraries or infrastructures, but simpler, perfectly suited for the work it has to do, and easier to debug and maintain.
2. Security
As many on Hive already know, security is my top priority!
No way for me to open-source code that could reveal easily exploitable flaws or compromise the confidentiality of the information that is exchanged, especially for a solution that makes it easy to authenticate and sign transactions.
And to be honest, while testing and hacking my own infrastructure, I found a tricky "replay attack" security flaw. As I had no easy fix at hand, it could only be contained thanks to the fact that I was the only one running a HiveAuth node.
For history, as it often happens in such cases, fixes we think at first turn out to be complex, twisted, and often unsatisfactory or even unsuitable as they could break an existing working solution. You then find yourself for weeks in a "Think Think Think" posture like Winnie the Pooh.
In such cases, I have the habit (of pretending) to let go of my thoughts by devoting myself to other tasks until, after a good nap or getting out of a envigorating shower, I suddenly exclaim "Eureka!"
Thanks to a simple and elegant solution, I was not only able to solve that nasty flaw discovered months earlier but I also strengthened the privacy and overall security of the protocol I had designed.
As the saying goes, "Rome wasn't built in a day".
3. Scalability
Another important constraint was not to break what already exists. HiveAuth has now been running without any issues for over a year.
Nevertheless, the implementation of the fix mentioned above requires a small but backward incompatible change in the HiveAuth protocol.
So I did everything to be able to ensure a smooth transition for both applications and PKSAs. Luckily, Keychain being the only HiveAuth-compatible wallet to date, this is made easier. Huge thanks to @stoodkev who is ready to work on an upcoming update.
What's next?
As mentioned, the Keychain team is preparing an update that will allow us to upgrade the HiveAuth infrastructure and make it fully decentralized.
On my side, I'm busy updating the documentation and creating material for app developers (updating examples and libraries).
I also plan to write more posts to explain how HiveAuth works with multiple nodes and invite people who want to spin their own nodes. This is a less fun part for me because I like to deliver quality documents and it usually takes as much effort as writing clean code, if not more.
The great news is that I will now be able to open-source the code for the HiveAuth nodes, which was part of my commitments in the HiveAuth proposal.
I can't wait for this to finally become a reality! Soontm
Note: I intentionally made this post readable for non-tech-savvy people. If you are a developer of an app that supports the HiveAuth protocol, more technical posts will come soon and describe the (very) few updates you will need to implement. Stay tuned!
Check out my apps and services
