Add the `/link` browser approval page

[blockchain-maxis]

The page the CLI's printed link opens. It must show the developer exactly what they are approving — which deploy public key is about to be attached to which handle — and let them approve or reject.

apps/web/app/(dashboard)/components/sign-in-gate.tsx already gates dashboard surfaces on a Sign-In With Stellar session and can be reused.

Why it matters: this is the human consent step. A link flow that attaches a wallet without showing the developer the key and the handle is an approval in name only.

Acceptance: /link?code=… requires a valid session, renders the deploy public key and target handle, offers approve and reject, refuses an expired or malformed code with a clear message, and never renders a code it cannot verify.

[babawo96]

@babawo96 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I have reviewed this issue and I would like to work on it

ℹ️ Repo Maintainers: To accept this application, review their application or assign @babawo96 to this issue.

[Anambraboi-1]

@Anambraboi-1 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Understanding: This is the human-consent surface for the whole linking flow — /link?code=… is what the developer's browser opens after signet link prints it. Its whole job is to make the approval legible and safe: show exactly which deploy public key is about to be attached to which handle, require an authenticated session, and never render anything for a code it can't actually verify (expired, malformed, or otherwise invalid codes must fail closed with a clear message, not render a blank/partial approval).

Approach:

Gate the page on a Sign-In With Stellar session, reusing sign-in-gate.tsx from the dashboard rather than reimplementing auth.
On load, verify the code server-side (or via an API route) before rendering anything tied to it — resolve it to the target handle + deploy public key only if verification succeeds.
Render the public key and target handle clearly, with explicit Approve / Reject actions.
Handle invalid states explicitly and distinctly:
Expired code → clear "this link expired, request a new one" message.
Malformed code → clear "invalid link" message.
No session → routed through the sign-in gate first.
On Approve/Reject, notify the backend/loopback callback of the outcome so the waiting CLI (per #258/#256) receives it correctly.

Verification plan:

Test: valid code + valid session renders the correct public key and handle, and Approve completes the flow.
Test: valid code + Reject sends a rejection, not a silent failure.
Test: expired code renders the expired-state message and does not render the key/handle.
Test: malformed code renders the invalid-state message and does not attempt to render key/handle.
Test: no session redirects to sign-in before any code verification detail is shown.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Anambraboi-1 to this issue.

[Samaro1]

@Samaro1 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Gm gm boss. I would like to take this one on. I can build the /link?code=… page reusing sign-in-gate.tsx to require a valid Stellar session, render the deploy public key and target handle clearly for approval or rejection, refuse expired or malformed codes with a clear message, and ensure it never renders a code it can't verify. Please assign it to me.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Samaro1 to this issue.

[yustech-alt]

@yustech-alt has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi Maintainer, I’d like to work on this issue. I have experience handling similar tasks and can start immediately.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @yustech-alt to this issue.

[ZuLu0890]

@ZuLu0890 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I would love to resolve this issue and give it a higher quality PR

ℹ️ Repo Maintainers: To accept this application, review their application or assign @ZuLu0890 to this issue.

[kelvinokwudili52-stack]

@kelvinokwudili52-stack has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I’d like to work on Issue #267 because the /link page is the human-consent step in the wallet-linking flow. Before a deploy wallet is attached to a profile, the developer needs to clearly see which public key is being linked and which handle it will be associated with, with an explicit opportunity to approve or reject the request.

I will first review the existing dashboard authentication flow, particularly components/sign-in-gate.tsx, along with the CLI pairing and challenge endpoints. I will trace how the pairing code is created, validated, and associated with the deploy public key and target handle so the page never displays unverified pairing information.

I will then create the /link browser approval page that accepts the pairing code through the query parameter and requires a valid Sign-In With Stellar session before displaying any sensitive linking details.

Once the code has been successfully validated server-side, the page will clearly show the deploy public key that is about to be attached and the target handle it belongs to. The user will have two explicit actions: Approve and Reject.

The page will fail safely for malformed, expired, already-consumed, or otherwise unverifiable pairing codes. In those cases, no unverified public key, handle, or approval controls will be rendered, and the user will receive a clear message explaining that the request is invalid or expired.

I will connect the approval action to the existing pairing completion flow while keeping the actual trust boundary on the server. The browser will not be treated as proof of wallet ownership; it will only provide the authenticated profile consent that is combined with the CLI-side cryptographic proof.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @kelvinokwudili52-stack to this issue.

[chikawobishie-sketch]

@chikawobishie-sketch has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello maintainer, I will love to work on this issues, kindly assign it to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @chikawobishie-sketch to this issue.

[drips-wave]

Congratulations, @Anambraboi-1! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @Anambraboi-1: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊