Currently, there is a basic claimchain.py which implements a basic in-band ClaimChain concept which is a research topic in the nextleap project. This needs to be refined. Based on discussions with @azul we likely want a PeerChain for each peer where we see keys from, and an OwnChain for our own key data and out-of-band verification events. The L1 peer and our own state are then what is sometimes called a materialized or synthesized view (see http://milinda.pathirage.org/kappa-architecture.com/ for background on this common append-only-log + view architecture).
Keeping track of all gossiped, direct and verified key materials also allows for better debugging. One can inspect how a recommendation comes about, what the input was to the algorithm. Also fixes and Improvements to the recommendations algorithm (see #26) can work on this append-only log. The current py-autocrypt peer state is by contrast always also just a synthesized view (history is lost) and we can not deploy fixes or refinements after we have processed incoming mails (some of which might be by now deleted).
Currently, there is a basic
claimchain.pywhich implements a basic in-band ClaimChain concept which is a research topic in the nextleap project. This needs to be refined. Based on discussions with @azul we likely want aPeerChainfor each peer where we see keys from, and anOwnChainfor our own key data and out-of-band verification events. The L1 peer and our own state are then what is sometimes called a materialized or synthesized view (see http://milinda.pathirage.org/kappa-architecture.com/ for background on this common append-only-log + view architecture).Keeping track of all gossiped, direct and verified key materials also allows for better debugging. One can inspect how a recommendation comes about, what the input was to the algorithm. Also fixes and Improvements to the recommendations algorithm (see #26) can work on this append-only log. The current py-autocrypt peer state is by contrast always also just a synthesized view (history is lost) and we can not deploy fixes or refinements after we have processed incoming mails (some of which might be by now deleted).