Implement ACL synchronisation across keynodes in gestalt

[joshuakarp]

From @CMCDragonkai : https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/188#note_591999167

Does gestalt trust automatically equate to cloning/pulling permissions for this version of Polykey? Or will there be separate sharing permissions for scanning, pulling and cloning? Maybe separate permissions for scanning and then pulling/cloning. Essentially how do vault sharing commands depend on the the gestalt trust or NodeACL and can they be changed independent of each other? This might affect how the vault sharing needs to be handled. Presumably also an untrusted NodeId won't have access to any scanning/pulling/cloning commands.

Gestalt Trust Synchronisation

No gestalt trust does not automatically mean cloning/pulling permissions. At this moment. Trusting another gestalt means that you allow any KN in that gestalt to send you "Vault Sharing Notifications". And by you I mean any KN in your gestalt. This is why gestalt trust is something that must be replicated across all the KNs in your gestalt. If the trust database is not replicated, this means that certain KNs in your gestalt won't accept the notification. However our trust database can be eventually consistent. This means that some KNs in your gestalt may not trust yet, but they will receive the trust information eventually.

How shall we do this eventual consistency? We can make use of some sort of targeted gossip protocol:

1. First we must "gossip" to our own gestalt about the trust database
2. How do we know who is part of our gestalt? By tracing the cryptolinks.
3. Cryptolinks are mutual, so for our KN to be part of a gestalt, they must be part of a cryptolink.
4. Use kademlia to resolve our cryptolink Node ID to the IP address
5. Connect to all of our cryptolinks and gossip to them. Only resolve gossip when they have answered they have received the information.
6. Those nodes will in turn gossip to other KNs... etc
7. Eventually all KNs in a gestalt will understand the state of the trust database
8. Because all KNs in a gestalt trust each other automatically (because you're part of the same gestalt!), then you automatically accept all change updates from other KNs
9. This means any KN that is compromised would also compromise other KNs in the gestalt, unless that KN gets exiled from the gestalt.
10. Exilation would indicate some sort of certificate revocation, we'll deal with this later.
11. In order to properly communicate changes to the gestalt trust database we have to represent changes to the database through some event type, and we have to resolve conflicts due to eventual consistency
12. The automerge library https://github.com/automerge/automerge seems to be capable of doing this - and I have previously asked about integration with leveldb: Add patches support to transactions automerge/automerge#331

Because a gestalt represents multiple identities that are connected to each other by a graph, changes to the gestalt trust database can come from the fact that the gestalts themselves are growing or shrinking or splitting.

[CMCDragonkai]

The implementation ACL synchronisation is the decentralised form of access control as compared to the centralised control-plane of Tailscale: https://tailscale.com/blog/how-tailscale-works/.

Just like tailscale has a decentralised data-plane relying on wireguard, PK has a decentralised data-plane as well, and additionally decentralised signalling and decentralised relaying. But also a decentralised control plane through the gestalt and acl sync. So wireguard's control plane could be considered a network-MAC (mandatory access control), whereas PK would be a network-DAC (discretionary access control).

[CMCDragonkai]

Closing in favour of #715 because this issue is not up to spec anymore.