Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backwards Compatibility of Discovery Mechanism #740

Closed
amydevs opened this issue Jun 13, 2024 · 2 comments · Fixed by #741
Closed

Backwards Compatibility of Discovery Mechanism #740

amydevs opened this issue Jun 13, 2024 · 2 comments · Fixed by #741
Assignees
Labels
development Standard development r&d:polykey:core activity 3 Peer to Peer Federated Hierarchy

Comments

@amydevs
Copy link
Contributor

amydevs commented Jun 13, 2024

Specification

In order to adhere to a federated system, we need to adhere to the following principles when dealing with non-breaking changes:

  1. version schema is a single number that changes if it is truly a compat break
  2. the whole discovery system must be forwards compatible
  3. the whole discovery system must be backwards compatible

What happened here, is that it was a field addition, but the logic that would process a claim without the field addition was removed.

For forwards compatibility, this would still allow an old node would be able to discover a new node.

But for backwards compatibility, this prevented the ability, the removed logic would no longer be able to discover an old node.

Additional context

#737

Tasks

  1. Return old discovery logic
@amydevs amydevs added the development Standard development label Jun 13, 2024
Copy link

linear bot commented Jun 13, 2024

@amydevs
Copy link
Contributor Author

amydevs commented Jun 13, 2024

{
  c241cd7219eafd37258af82de0b18cb3: {
    payload: {
      iat: 1718152555,
      iss: 'vcj3ufun2506jn44q7rr9bc1hv4c6eebicusfj1bl9sr27ookknlg',
      jti: 'v0pj8tllneho0169hv7vbh2g39o',
      nbf: 1718152555,
      prevClaimId: 'v0phklr879to0169hv7vbh2g39o',
      prevDigest: 'z2DrjgbJrZvLH1h319LrUMkgeQY4DXrAGMXwZoRZaezC4mq4nNP',
      seq: 2,
      sub: '["github.com","CMCDragonkai"]',
      typ: 'ClaimLinkIdentity'
    },
    signatures: [ [Object] ]
  },
  '25cc937e27085b05360926af70925192': {
    payload: {
      iat: 1714728656,
      iss: 'vcj3ufun2506jn44q7rr9bc1hv4c6eebicusfj1bl9sr27ookknlg',
      jti: 'v0phklr879to0169hv7vbh2g39o',
      nbf: 1714728656,
      prevClaimId: null,
      prevDigest: null,
      seq: 1,
      sub: '["github.com","CMCDragonkai"]',
      typ: 'ClaimLinkIdentity'
    },
    signatures: [ [Object] ]
  }
}

console.log from Discovery domain shows that both claims are processed ^

@CMCDragonkai CMCDragonkai added the r&d:polykey:core activity 3 Peer to Peer Federated Hierarchy label Aug 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development Standard development r&d:polykey:core activity 3 Peer to Peer Federated Hierarchy
Development

Successfully merging a pull request may close this issue.

2 participants