Mike Macgirvin wrote the following card Tue, 05 Sep 2017 11:55:25 +1000
Zot VI
Zot has been in use continually for over five years, with only a handful of minor upgrades. Most of these involved extending the cryptography mechanisms to allow negotiation and deprecate older/insecure algorithms.
During this time. there have been a many changes in the external landscape and there are now some better ways of doing things which didn't exist in a stable form when zot was created. The goal of Zot VI is to bring the protocol in line with some of these changes. As an example we can now provide server-to-server authentication by making use of HTTP Signatures. There are a couple of other places in the protocol where we can reduce the complexity of interactions by using the same technology (increasing efficiency). As a side effect the entire protocol and message flow will be simplified and easier to integrate with external services.
The proposed delivery method for this work is to expose it through a protocol plugin, (just like the other protocol plugins) and ultimately remove communication protocol implementations from core code. As Zot VI will not be directly compatible with zot, this allows a migration path; and servers will be able to support both.
Zot has been in use continually for over five years, with only a handful of minor upgrades. Most of these involved extending the cryptography mechanisms to allow negotiation and deprecate older/insecure algorithms.
During this time. there have been a many changes in the external landscape and there are now some better ways of doing things which didn't exist in a stable form when zot was created. The goal of Zot VI is to bring the protocol in line with some of these changes. As an example we can now provide server-to-server authentication by making use of HTTP Signatures. There are a couple of other places in the protocol where we can reduce the complexity of interactions by using the same technology (increasing efficiency). As a side effect the entire protocol and message flow will be simplified and easier to integrate with external services.
The proposed delivery method for this work is to expose it through a protocol plugin, (just like the other protocol plugins) and ultimately remove communication protocol implementations from core code. As Zot VI will not be directly compatible with zot, this allows a migration path; and servers will be able to support both.
- Refactor zot-finger
- Refactor Delivery
- Refactor magic-auth
- Refactor Directory Services
- move to plugin
- Release timeline