Implement cryptolink revocations in the sigchain

[joshuakarp]

Currently, all cryptolinks in the sigchain are considered as additions to the sigchain. That is, there's no notion of revocation. As such, getAllCryptolinks() simply retrieves all claims from the sigchain that have a claimType of 'cryptolink'.

To introduce revocations, we'll need to restructure the Cryptolink ClaimData type a bit to include a flag or different type that signals the cryptolink is being revoked, instead of being added. Once this is introduced, we'll need to alter getAllCryptolinks() to only include the cryptolinks that have not been revoked (i.e. start from the most recent link in the chain).

A better solution would be to persist a map of LinkId (or whatever the unique identifier of a cryptolink is) to the sequence number of the Claim in the sigchain. If a cryptolink is revoked, we would simply remove its entry in this map. Thus, to getAllCryptolinks(), we would simply get all the sequence numbers from this map, and return an array of Claims from these sequence numbers.

[CMCDragonkai]

Backchannel system has a section on linking and unlinking: https://www.inkandswitch.com/backchannel/#linking-multiple-devices

Their linking makes use of a shared secret. Not really relevant to us, except for when we generate QR codes, or other ways to allow users to establish a secure connection.

But the unlinking idea is interesting and should be considered for this feature.

[CMCDragonkai]

Should also investigate how CRLs work, and how to ensure this is efficient and scalable (consider algorithmic/network complexity).

[joshuakarp]

Recall our current node to node claim signing process, where we perform a cooperative signing process between both nodes, passing two claims back and forth between the nodes such that they both end up with their own node to node claim on their corresponding sigchains.

I imagine we'll also need a similar process to revoke these node claims.

However, just throwing this out there too, we'll also need to consider the case where a node is potentially compromised. In this case, they're unlikely to cooperate in the revocation process.

[joshuakarp]

When we start to look into this, it would also be worthwhile to consider improving the field names on our claims. Currently, we have the data in a node claim set according to the following type:

type ClaimData = ClaimLinkNode | ClaimLinkIdentity;
type ClaimLinkNode = {
  type: 'node';
  node1: NodeIdEncoded;
  node2: NodeIdEncoded;
};
// where it appears in the claim as ClaimData:
type Claim = {
  payload: {
    hPrev: string | null; // Hash of the previous claim (null if first claim)
    seq: number; // Sequence number of the claim
    data: ClaimData; // Our custom payload data
    iat: number; // Timestamp (initialised at JWS field)
  };
  signatures: Record<NodeIdEncoded, SignatureData>; // Signee node ID -> claim signature
};

Specifically, the fields node1 and node2 should be improved to be less ambiguous (i.e. does node1 refer to the node on which this claim appears?).

This was initially brought up here in the review of #320 (comment)

[CMCDragonkai]

@amydevs PKE private orgs are going the need to boot of nodes and revoking gestalt links.

[amydevs]

@tegefaulkes since this network segregation is now assigned to you, i'll assign this to u too