-
Notifications
You must be signed in to change notification settings - Fork 200
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: use did:key flag #1029
Merged
Merged
feat: use did:key flag #1029
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
5553179
feat: add useKeysInProtocol config param
genaris 719b2ab
feat: implement useDidKey config in RFC 0211
genaris 16f3563
test: add cases for useDidKey
genaris 7edc15a
test: restore e2e test
genaris ea20c04
Merge branch 'main' into feat/use-did-key
genaris 5fb4e86
fix: always store keys in base58 format
genaris 0028b14
feat: update did:key flag in each related message
genaris File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
9 changes: 9 additions & 0 deletions
9
packages/core/src/modules/connections/repository/ConnectionMetadataTypes.ts
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
export enum ConnectionMetadataKeys { | ||
UseDidKeysForProtocol = '_internal/useDidKeysForProtocol', | ||
} | ||
|
||
export type ConnectionMetadata = { | ||
[ConnectionMetadataKeys.UseDidKeysForProtocol]: { | ||
[protocolUri: string]: boolean | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specific reason for making this a key/value object instead of an array with string uri's?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The goal of this metadata key is to override agent settings, based on what we learn from the connection. So if our agent is set to always use did:key by default and we learn that the other side is not using it for a certain protocol, we'll set the key for that protocol to false.
And we could also have the opposite case: we don't use did:key but it happens that the other side is using them, so we set the key for that protocol to true. Also we might change our agent settings afterwards, and it will still take into account the metadata key for the given connection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. I thought we would only use it to say a protocol does support did:key, but there is also the case where we explicitly store a protocol doesn't store it.
Is this also updated autmoatically when this changes? E.g. we have stored false so we keep sending base58 keys, but then the other agent sends a did:key, do we update it automatically? Or is it set once and kept like this forever?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it depends on each protocol/service but generally the best would be to update it automatically. As of current AFJ support for mediator role, it does not add so much value because we only support Mediation Grant and Keylist Update request/response. However, considering a future support of Keylist queries and responses it's better to handle it right from the start.
So I'm adding automatic handling for both recipient and mediator in the messages we currently support. Hopefully in 0.3.x we'll support all of them 😄