Merged
Conversation
With `2.0.1` @Nobel added the `.js` extension to the export map — meaning you can no longer import without the extension in esm.
bb10a84 to
759018a
Compare
Coverage Report
File Coverage |
This release will now be 1.0.0 and so the deprecation message should reference the _next major version_.
Better aligns nuc-ts and nuc-rs builder apis.
- Renames `build()` to `sign()` to make the cryptographic operation explicit - Renames chained builder methods for semantic accuracy (`extendingDelegation`, `invokingFrom`) - Fix automatic policy inheritance when extending delegations — eg policies shouldn't be copied between tokens
dc9b788 to
576913a
Compare
- Replace legacy signed-payload auth with Nuc bearer tokens with attenuated commands - To make the payer's intentions explicit the payload now includes `payer_did` and `subscriber_did` fields - Url query parameter changed from `public_key` to `did` for subscription status - Removed legacy `createSignedRequest` utility - Methods now accept `Keypair` and `Did` objects instead of raw strings
- Rename Builder factory methods for clarity and alignment with `nuc-rs`: - `extendingDelegation` -> `delegationFrom` - `invokingFrom` -> `invocationFrom` - `...FromString` variants updated accordingly - Add an convenience method `keypair.signer()` - Update integration tests to use the `did:key` method
Key ordering must match exactly what nilauth expects otherwise it results in diffent digests. See NillionNetwork/nilauth#50.
Using the `@deprecated` tag was noisy as even using `did:key` still gets flagged in editors.
6024536 to
a9a8645
Compare
For libraries to consume this correctly there needed to be an easier way to construct the keypair with the correct signer — otherwise all nucs would need to be manually signed. To be honest this might break the model — eg do we just need a Signer abstraction and do away with keypair? I'm punting that decision given how close we are to release.
…Client` The `paySubscription` method coupled payment execution with validation, making it difficult to integrate with custom wallet providers or handle payment flows that require user interaction (like browser wallet confirmations).
With the move to support web3 signers, the keypair became an unnecessary intermediate abstraction where consumers would need to unnecessary create both keypair and a signer instances. - Replace Keypair.generate() with Signer.generate() - Replace Keypair.from(privateKey) with Signer.fromPrivateKey(privateKey) - Replace keypair.toDid() with await signer.getDid() - Replace PayerBuilder.fromKeypair(keypair) with PayerBuilder.fromPrivateKey(privateKey)
Collaborator
Author
|
Given timelines I'm going to merge as-is so we can cut 1.0.0-rc.2. There is more work to be done here but I will have to circle back. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.