Uh oh!
There was an error while loading. Please reload this page.
feat: auto-publish soldiers ranking + prize zaps from results podium - #52
Merged
Merged
Conversation
Ranking automation: - scripts/publish-soldiers-ranking.mjs: headless version of the /soldados "Recrear ranking" admin action — self-signs with LACRYPTA_NSEC and republishes the ranking Nostr snapshot. No-ops without the secret; never fails the reports build. Chained into build-hackathon-reports.mjs (skip with SKIP_RANKING_PUBLISH=1) and exposed as `pnpm run ranking:publish`. - build-hackathon-reports.mjs: stop silently dropping hackathons whose report dir has no .md source (identity/commerce data predates the script) — preserve their existing reports.json entry instead of wiping it. Prize zaps on the results podium: - Wire the existing PrizeZapButton into VotingHero's ClosedHero podium + runner-up rows, keyed by each winner's recipientPubkey (frozen at close in results.winners). Moved PrizeZapButton to components/voting/ since it's now shared by the home and hackathon pages. - New GET /api/prize-recipient: resolves the recipient's Lightning address from their kind-0 profile lud16 ONLY (never nip05 — that's an identity handle, not a payout address). Server-side cached lookup, which is reliable where the client-side single-shot relay fetch was flaky. - PrizeZapButton gates on the admin pubkey (NEXT_PUBLIC_LACRYPTA_ADMIN_NPUB), matching every other admin control, instead of the publisher key. - Resolve the destination in handlePay before paying so it no longer depends on the flaky client-side findZapEndpoint (the "No encontré el perfil" error). - Fix stuck-disabled pay buttons: the receipt-check effect depended on the inline `target` object, re-running every render and pinning `checking`. Depend on target's primitive fields instead. Signer probe dedupe: - lib/auth.ts: dedupe probeSignerAvailable per session so many useAuth consumers (one PrizeZapButton per podium slot) share a single window.nostr.getPublicKey() call instead of flooding the extension. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughAdds a ChangesPrize Zap Recipient Resolution
Auth Signer Probe Caching
Soldiers Ranking Republish Pipeline
Estimated code review effort: 4 (Complex) | ~55 minutes Sequence Diagram(s)sequenceDiagram
participant VotingHero
participant PrizeZapButton
participant PrizeRecipientAPI
participant LacryptaPubkeysAPI
participant payPrizeZap
VotingHero->>PrizeZapButton: render with hackathonId, recipientPubkey, sats
PrizeZapButton->>LacryptaPubkeysAPI: fetch admin pubkeys
LacryptaPubkeysAPI-->>PrizeZapButton: adminPubkey
PrizeZapButton->>PrizeRecipientAPI: GET /api/prize-recipient?pubkey=...
PrizeRecipientAPI-->>PrizeZapButton: lightningAddress, zapEndpoint, source
PrizeZapButton->>PrizeZapButton: handlePay computes effectiveTarget
PrizeZapButton->>payPrizeZap: pay(effectiveTarget)
sequenceDiagram
participant BuildScript as build-hackathon-reports.mjs
participant ReportsJSON as reports.json
participant PublishScript as publish-soldiers-ranking.mjs
participant RankingAPI as /api/soldiers/ranking
BuildScript->>ReportsJSON: load previous entries
BuildScript->>BuildScript: regenerate or preserve per-hackathon entries
BuildScript->>ReportsJSON: write updated reports.json
BuildScript->>PublishScript: spawnSync (unless SKIP_RANKING_PUBLISH=1)
PublishScript->>PublishScript: sign kind 27235 event with LACRYPTA_NSEC
PublishScript->>RankingAPI: POST signed event
RankingAPI-->>PublishScript: soldier count, generated timestamp
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@app/api/prize-recipient/route.ts`:
- Around line 17-20: Harden Lightning-address handling in
lightningAddressToLnurlpEndpoint and the zapEndpoint flow by parsing the address
as a real hostname instead of relying on split("@"), and reject malformed or
unsafe hosts before constructing the LNURL URL. Update the /api/lnurl-invoice
validation to block private/reserved IP ranges and path-bearing or otherwise
unsafe domains, not just localhost/loopback/.local, so only safe destinations
can be returned. Apply the same validation logic in app/hackathons/[id]/page.tsx
where the Lightning address is used to build the endpoint.
In `@components/voting/PrizeZapButton.tsx`:
- Around line 160-162: The payout-source comments in PrizeZapButton are out of
sync with the `/api/prize-recipient` contract and still mention a submission
nip05 fallback. Update the nearby comments around the recipient resolution logic
to state that the API resolves profile lud16 only and that this is the supported
payout source, keeping the description aligned with the server-side rule and
removing any fallback wording. Match the wording in both comment locations tied
to the recipient resolution flow so future changes aren’t misled.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6175ed37-4966-4954-b3c4-40be42234de4
📒 Files selected for processing (9)
CLAUDE.mdapp/api/prize-recipient/route.tsapp/hackathons/[id]/page.tsxcomponents/voting/PrizeZapButton.tsxcomponents/voting/VotingHero.tsxlib/auth.tspackage.jsonscripts/build-hackathon-reports.mjsscripts/publish-soldiers-ranking.mjs
Comment on lines
+17
to
+20
| function lightningAddressToLnurlpEndpoint(address: string): string | null { | ||
| const [name, domain] = address.split("@"); | ||
| if (!name || !domain) return null; | ||
| return `https://${domain}/.well-known/lnurlp/${encodeURIComponent(name)}`; |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash# Verify the downstream invoice route validates endpoint scheme/host before fetch.
rg -n -C4 'lnurl-invoice|endpoint|fetch\\(' app lib componentsRepository: lacrypta/lacrypta-dev
Length of output: 272
🏁 Script executed:
#!/bin/bashset -euo pipefail
rg -n -C3 'lnurl-invoice|lightningAddressToLnurlpEndpoint|payPrizeZap|recipientZapEndpoint|fetch\(' app lib componentsRepository: lacrypta/lacrypta-dev
Length of output: 39782
🏁 Script executed:
#!/bin/bashset -euo pipefail
sed -n '1,220p' app/api/lnurl-invoice/route.tsRepository: lacrypta/lacrypta-dev
Length of output: 4707
Harden Lightning-address parsing before building the LNURL endpoint.split("@") still turns malformed lud16 values into fetchable URLs, and /api/lnurl-invoice only blocks localhost/loopback/.local, not private/reserved IPs or path-bearing domains. Parse the address as a real hostname and reject unsafe hosts before returning zapEndpoint. Also applies to app/hackathons/[id]/page.tsx:128-131.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@app/api/prize-recipient/route.ts` around lines 17 - 20, Harden
Lightning-address handling in lightningAddressToLnurlpEndpoint and the
zapEndpoint flow by parsing the address as a real hostname instead of relying on
split("@"), and reject malformed or unsafe hosts before constructing the LNURL
URL. Update the /api/lnurl-invoice validation to block private/reserved IP
ranges and path-bearing or otherwise unsafe domains, not just
localhost/loopback/.local, so only safe destinations can be returned. Apply the
same validation logic in app/hackathons/[id]/page.tsx where the Lightning
address is used to build the endpoint.
Comment on lines
+160
to
+162
| // Otherwise (e.g. the results podium only knows the pubkey), resolve it | ||
| // server-side: profile lud16 → submission nip05 fallback (see | ||
| // /api/prize-recipient). Fills "Destino" and gives the pay step an endpoint. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Keep the payout-source comments aligned with the API contract.
/api/prize-recipient resolves profile lud16 only, but these comments still describe a submission nip05 fallback. That contradicts the route’s payout safety rule and can mislead future changes.
Suggested comment fix
- // server-side: profile lud16 → submission nip05 fallback (see- // /api/prize-recipient). Fills "Destino" and gives the pay step an endpoint.+ // server-side: profile lud16 only (see /api/prize-recipient). Fills+ // "Destino" and gives the pay step an endpoint.
...
- // Resolve the destination reliably from the server (profile lud16 →- // submission nip05) instead of depending on the display effect having+ // Resolve the destination reliably from the server (profile lud16 only)+ // instead of depending on the display effect havingAlso applies to: 214-215
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@components/voting/PrizeZapButton.tsx` around lines 160 - 162, The
payout-source comments in PrizeZapButton are out of sync with the
`/api/prize-recipient` contract and still mention a submission nip05 fallback.
Update the nearby comments around the recipient resolution logic to state that
the API resolves profile lud16 only and that this is the supported payout
source, keeping the description aligned with the server-side rule and removing
any fallback wording. Match the wording in both comment locations tied to the
recipient resolution flow so future changes aren’t misled.
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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
Two related pieces of hackathon-results tooling, plus supporting fixes.
1. Ranking auto-publish
scripts/publish-soldiers-ranking.mjs— a headless equivalent of the/soldados"Recrear ranking" admin button. It self-signs the authorization withLACRYPTA_NSECand republishes the ranking Nostr snapshot viaPOST /api/soldiers/ranking, so new hackathon results propagate to/soldadoswithout a manual browser click.LACRYPTA_NSECisn't set; best-effort (never fails the reports build).build-hackathon-reports.mjs(skip withSKIP_RANKING_PUBLISH=1); alsopnpm run ranking:publish.build-hackathon-reports.mjs: it was silently dropping theidentity/commercehackathon entries fromreports.jsonon every run (their data predates the script and has no.mdsource in-tree). Now it preserves an existing entry when a hackathon has no.mdfiles, instead of wiping it.2. Prize zaps from the results podium
PrizeZapButtonintoVotingHero's closed-results podium + runner-up rows, keyed by each winner'srecipientPubkey(already frozen at voting close inresults.winners). MovedPrizeZapButtontocomponents/voting/since it's now shared by the home and hackathon pages.GET /api/prize-recipient: resolves the recipient's Lightning address only from their kind-0 profilelud16— nevernip05(that's an identity handle, not a payout destination). Server-side cached lookup, reliable where the client-side single-shot relay fetch was flaky.handlePayresolves the destination up front, so payment no longer depends on the flaky client-sidefindZapEndpoint(the source of the "No encontré el perfil Nostr del ganador" error).Supporting fixes
PrizeZapButtonnow gates on the admin pubkey (NEXT_PUBLIC_LACRYPTA_ADMIN_NPUB) like every other admin control, not the publisher key — so the button actually shows for the admin.targetobject (new every render), pinningchecking→ permanently disabled. Now depends ontarget's primitive fields.lib/auth.tsdedupesprobeSignerAvailableper session, so manyuseAuthconsumers (one button per podium slot) share a singlewindow.nostr.getPublicKey()call.Testing
tsc --noEmitclean./api/prize-recipientverified to resolve winners' reallud16addresses (blink.sv, primal.net) — all valid LNURL-pay endpoints withallowsNostr: true.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes