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

feat(access-api): access-api version endpoint has publicKey property #317

Merged
merged 1 commit into from
Dec 15, 2022

Conversation

gobengo
Copy link
Contributor

@gobengo gobengo commented Dec 14, 2022

...which is always the underlying did:key publicKey, even if signer.did() is a did:web

Motivation

Rants

  • try to avoid calling things 'did' when you mean 'public key'. Or assuming that things called 'did' will always be a did:key
  • we often say 'did' or 'did:key' when we mean 'keypair', which is confusing because:
      1. a 'did' may have zero keypairs
      1. a 'did:key', on its own, has no private key. You can't make a 'signer' from only a did:key string.

…he underlying did:key publicKey, even if signer.did() is a did:web
@@ -42,7 +43,7 @@ export interface Env {

export interface RouteContext {
log: Logging
signer: Signer
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This Signer didn't resolve to anything before in my tsc setup, so was treated as any

@gobengo gobengo temporarily deployed to dev December 14, 2022 23:48 — with GitHub Actions Inactive
@gobengo gobengo requested a review from Gozala December 14, 2022 23:49
@gobengo gobengo changed the title access-api version endpoint has publicKey property feat(access-api): access-api version endpoint has publicKey property Dec 14, 2022
@gobengo gobengo requested a review from alanshaw December 15, 2022 17:24
@gobengo gobengo merged commit 474d561 into main Dec 15, 2022
@gobengo gobengo deleted the issues/316-version-signer branch December 15, 2022 17:57
gobengo pushed a commit that referenced this pull request Dec 16, 2022
🤖 I have created a release *beep* *boop*
---


##
[4.2.0](access-api-v4.1.0...access-api-v4.2.0)
(2022-12-15)


### Features

* **access-api:** access-api version endpoint has publicKey property
([#317](#317))
([474d561](474d561))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).
gobengo added a commit that referenced this pull request Apr 11, 2023
…317)

...which is always the underlying did:key publicKey, even if
signer.did() is a did:web

Motivation
* #316
* historically there has been a `did` property, which is (historically)
always a `did:key` (so a public key)
* now we deal with non-key dids like `did:web`. So the did may not be
identical to the public key (you have to resolve a `did:web` to
determine its pubkeys)
* we should have a property that is explicitly only ever a public key
(serialized as a `did:key` string)
* e.g. for code like this to rely on:
https://github.com/web3-storage/w3protocol/blob/main/packages/access-client/src/cli/utils.js#L40
(which I think will break when version endpoint's `did` property is a
`did:web`)

Rants
* try to avoid calling things 'did' when you mean 'public key'. Or
assuming that things called 'did' will always be a `did:key`
* we often say 'did' or 'did:key' when we mean 'keypair', which is
confusing because:
  * 1. a 'did' may have zero keypairs
* 2. a 'did:key', on its own, has no private key. You can't make a
'signer' from only a `did:key` string.
gobengo pushed a commit that referenced this pull request Apr 11, 2023
🤖 I have created a release *beep* *boop*
---


##
[4.2.0](access-api-v4.1.0...access-api-v4.2.0)
(2022-12-15)


### Features

* **access-api:** access-api version endpoint has publicKey property
([#317](#317))
([83dcb45](83dcb45))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants