release 0.3.1: cash_consolidate delivery fix, LUD-06 chain parsing, zap invoice helper - #28
Merged
Merged
Conversation
…ash_transfer's CashConsolidateParams.ParseResult unconditionally decrypted new_wallet_token as if it were keyed to the caller, like cash_transfer. cash_consolidate actually keys it to the target: plaintext for a bearer/connection_key target, encrypted to that pubkey for a third-party target. Both cases failed client-side with a decrypt error even though the merge itself already succeeded on the Hub. ParseResult now only decrypts when the target is the caller's own pubkey (added Credential.ownIdentityPubkey to check this without building a new proof), and otherwise passes the token through as received.
…helper Closes the private-vs-exported gap from issue #27: relay/verification.go's profile worker already parsed a LUD-06 pay response's chain/* metadata entries, but only for its own internal score, with no way for a client to reuse that logic. utils.ParsePayMetadataChains and utils.FetchLud16PayResponse export it directly; verification.go now calls the exported helper instead of keeping its own copy. Also adds nip57.RequestZapInvoice, a high-level zap helper: resolve a recipient's LUD-16 address, build and sign the zap request, and fetch back an invoice, in one call. ZapRequestParams gained a Content field so a zap can carry a comment.
… tests Fixes the three staticcheck QF1012 findings golangci-lint v2.13 reports on the RequestZapInvoice test handlers.
…eep the raw value Replaces the ownIdentityPubkey gating from the previous nipcash fix with a simpler rule that doesn't depend on which party the Hub keys a pubkey target's delivery to. ParseResult passes a bearer/connection_key target's token through unchanged (it arrives in the clear), and for a pubkey target always attempts to decrypt with the first source's credential. If decryption fails it preserves the raw value instead of returning an error, since the merge itself has already succeeded on the Hub. Drops Credential.ownIdentityPubkey and its implementations, adds a test for a third-party pubkey target whose delivery is encrypted to the caller, and rewords the 0.3.1 changelog entry to match.
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.
Summary
Everything that goes into 0.3.1. The
[0.3.1]section is already inCHANGELOG.md, so merging this putsmainin the state the release workflow expects.CashConsolidateParams.ParseResultalways decryptednew_wallet_tokenand returned an error if that failed, even though the merge itself had already succeeded. A bearer/connection_key target has no real pubkey yet, so the Hub delivers the token in the clear and decryption always failed for it.ParseResultnow passes that token through unchanged; for a pubkey target it still decrypts with the first source's credential, but a decryption failure now preserves the raw value instead of returning an error.Credential.ownIdentityPubkeymethod. The last commit replaces that with the simpler rule above and removes the method (it was unexported, so no API change). The changelog entry describes the final behavior.utils.ParsePayMetadataChains/utils.FetchLud16PayResponse(previously private inside the relay's profile-verification worker, which now calls the exported helper), and addsnip57.RequestZapInvoice(resolve a LUD-16 address, build and sign the zap request, fetch an invoice in one call).ZapRequestParamsgains an optionalContentfield.Write([]byte(fmt.Sprintf(...)))forfmt.Fprintfin the zap invoice test handlers (staticcheck QF1012, which the lint job flagged).Closes #27
Test plan
Run locally with
GOWORK=offagainst the module's own pinned dependencies (same as CI):gofmt -l .— cleango build ./...go vet ./...go mod tidy—go.mod/go.sumunchangedgolangci-lintv2.13.2 — 0 issuesgo test -race ./...— all packages pass (after the last commit, re-run for./nipcash/...; full suite is covered by CI)After merge
Run the Release workflow (
workflow_dispatch, leaveversionempty) — it tagsv0.3.1from the topCHANGELOG.mdentry and publishes the GitHub release.