feat: WalletLinkForm support ens domain #121
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThe changes introduce asynchronous validation and resolution of wallet addresses, allowing users to input either raw blockchain addresses or human-readable ENS/SNS domain names. New utilities for ENS and SNS resolution and validation are added, and relevant code paths are updated to support async workflows and store resolved domain names alongside addresses. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant WalletLinkForm
participant DomainUtils
participant ChainUtils
User->>WalletLinkForm: Enter wallet (address or ENS/SNS)
WalletLinkForm->>DomainUtils: Validate format (ENS/SNS)
alt Domain name
WalletLinkForm->>DomainUtils: Resolve ENS/SNS to address
DomainUtils-->>WalletLinkForm: Return resolved address or error
else Raw address
WalletLinkForm->>ChainUtils: Validate address asynchronously
ChainUtils-->>WalletLinkForm: Return validation result
end
WalletLinkForm-->>User: Show validation result or error
Assessment against linked issues
Poem
✨ Finishing Touches🧪 Generate Unit Tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
The code looks fine. It would be good to also do it for .sol name as well not just for .eth |
|
Just a quick addition regarding optimization and the vem package — I noticed the package is quite large considering it's only used for ENS fetching. It might be more efficient to simply perform a GET request to a public gateway like this: REQ RES |
|
I like the redundancy / risk mitigation measure of including the raw address also |
|
I've updated a commit for supporting SNS. Regarding viem package's impact on build size. Here is a screenshot of two builds, the left one without viem, the right one with viem. The page to inspect is /profile/edit. Currently, the changes for ENS support without viem are not yet committed, as I would like advice.
|
|
Linking the docs here for reference / research: https://docs.ens.domains/web/resolution |
Looks like viem is more robust for resolution atm even if it costs the build size. Sol code looks good too. |
|
Want to take a step back first and properly architect how we store and fetch walletAddresses to be chain agnostic and cleanly handle multichain (esp relevant for ETH L2s). See comment here on storing ensName / snsName in the user table and adding a separate walletAddresses table using CAIP-2 / CAIP-10 With ENS names, there's a lot more to it than just linking it to a single address, since a name can now store profile info and also addresses for different chains etc. Therefore I think ens/sns names should be stored at the user level and not alongside wallet addresses. That way we can derive many addresses (and other info) for a certain user from their ENS. |
|
True, global storage better for multiple usecases like this checkmark but if you have planned an upcoming airdrop it can be good to have a very primitive version first to onboard more people for this batch. |
|
Thank you for the feedback! For ENS/SNS names, the current relevant user flow is that: The above flow only uses them for resolving wallet addresses that would be linked client-side. |
Ah ok, I see what you're saying now, its needed to resolve names on client side to validate them before saving them to github. In that case, as long as we make sure that code splitting / dynamic module loading is setup properly so that it only loads viem once the user is logged in and on the update address page, then it shouldn't have negative impact on majority of users. |
|
A commit is made to dynamically import domain name resolution dependencies for ENS (viem) and SNS (@solana/web3.js, @bonfida/spl-name-service) The following are the build output before and after the commit (particularly for the page /profile/edit) Before: After: |
Dangoz
force-pushed
the
link-wallet-from-ens
branch
from
1b815dc to
5fbe057
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (2)
src/lib/walletLinking/domain.ts (2)
14-30: Remove unnecessary continue statementThe continue is redundant as it's the last statement in the loop.
} catch (error) { console.warn(`Failed to connect to RPC endpoint ${endpoint}:`, error); - continue; // Try next endpoint }
87-101: Consider supporting broader character sets for ENSENS supports Unicode and underscores, but current regex is ASCII-only.
Would you like me to provide a more comprehensive ENS validation regex that supports Unicode characters?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
bun.lockis excluded by!**/*.lock
📒 Files selected for processing (8)
package.json(2 hunks)src/app/profile/edit/components/WalletLinkForm.tsx(5 hunks)src/app/profile/edit/hooks/useProfileWallets.ts(1 hunks)src/lib/pipelines/ingest/fetchWalletAddresses.ts(1 hunks)src/lib/walletLinking/chainUtils.ts(3 hunks)src/lib/walletLinking/domain.ts(1 hunks)src/lib/walletLinking/fetchWalletDataFromGithub.ts(1 hunks)src/lib/walletLinking/readmeUtils.ts(4 hunks)
🧰 Additional context used
🧠 Learnings (1)
package.json (1)
Learnt from: CR
PR: elizaOS/elizaos.github.io#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T18:24:14.074Z
Learning: Import order in TypeScript/React files should be: React, external libraries, local components (using @/components), then utility functions, to improve readability and maintainability.
🧬 Code Graph Analysis (5)
src/lib/walletLinking/fetchWalletDataFromGithub.ts (1)
src/lib/walletLinking/readmeUtils.ts (1)
parseWalletLinkingDataFromReadme(32-83)
src/lib/pipelines/ingest/fetchWalletAddresses.ts (1)
src/lib/walletLinking/chainUtils.ts (1)
validateAddress(116-126)
src/app/profile/edit/hooks/useProfileWallets.ts (1)
src/lib/walletLinking/readmeUtils.ts (1)
parseWalletLinkingDataFromReadme(32-83)
src/app/profile/edit/components/WalletLinkForm.tsx (2)
src/lib/walletLinking/chainUtils.ts (1)
validateAddress(116-126)src/lib/walletLinking/domain.ts (4)
validateEnsFormat(91-93)validateSnsFormat(99-101)resolveEnsDomain(67-85)resolveSnsDomain(38-59)
src/lib/walletLinking/readmeUtils.ts (1)
src/lib/walletLinking/chainUtils.ts (2)
SUPPORTED_CHAINS_NAMES(73-73)validateAddress(116-126)
🪛 Biome (1.9.4)
src/lib/walletLinking/domain.ts
[error] 25-25: Unnecessary continue statement
Unsafe fix: Delete the unnecessary continue statement
(lint/correctness/noUnnecessaryContinue)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Build
🔇 Additional comments (12)
package.json (1)
25-25: Verify package versions for security and compatibility.The new dependencies support SNS domain resolution and Solana validation as intended. Ensure these versions are current and free from known vulnerabilities.
#!/bin/bash # Check for latest versions and security advisories for new dependencies echo "Checking @bonfida/spl-name-service..." npm view @bonfida/spl-name-service version npm audit --audit-level moderate --package-lock-only 2>/dev/null | grep -A5 -B5 "@bonfida/spl-name-service" || echo "No issues found" echo "Checking @solana/web3.js..." npm view @solana/web3.js version npm audit --audit-level moderate --package-lock-only 2>/dev/null | grep -A5 -B5 "@solana/web3.js" || echo "No issues found"Also applies to: 43-43
src/lib/walletLinking/fetchWalletDataFromGithub.ts (1)
40-42: Correct async update.The await addition properly handles the now-async
parseWalletLinkingDataFromReadmefunction. This ensures asynchronous wallet validation completes before processing results.src/lib/pipelines/ingest/fetchWalletAddresses.ts (1)
114-114: Correct async validation update.The await addition properly handles the now-async
validateAddressfunction, ensuring dynamic validation libraries are loaded and validation completes before proceeding.src/app/profile/edit/hooks/useProfileWallets.ts (1)
63-64: Correct async parsing update.The await addition properly handles the now-async
parseWalletLinkingDataFromReadmefunction. The multi-line formatting enhances readability.src/lib/walletLinking/readmeUtils.ts (4)
10-11: ENS/SNS domain name support added.The optional
ensNameandsnsNamefields properly extend the schema to support domain names while maintaining backward compatibility.
32-34: Function signature updated for async validation.The async conversion enables asynchronous wallet address validation, which is required for dynamic imports of validation libraries.
59-71: Async wallet validation implementation.The replacement of synchronous
filterwith an asyncforloop correctly handles asynchronous address validation. Each wallet is properly validated before inclusion.
153-154: Domain names included in wallet generation.The conditional inclusion of trimmed
ensNameandsnsNamefields ensures domain names are preserved in the generated wallet data when present.src/app/profile/edit/components/WalletLinkForm.tsx (1)
114-150: LGTM!Clean domain resolution implementation with proper error handling.
src/lib/walletLinking/domain.ts (1)
38-85: Well-implemented domain resolution with dynamic importsGood use of dynamic imports for bundle optimization and proper error handling.
src/lib/walletLinking/chainUtils.ts (2)
27-40: Good async validator implementation with cachingEfficient use of dynamic imports and module-level caching.
45-64: Solid async Solana validation with proper error handlingWell-structured with dynamic imports and caching.
|
Three commits have been made to address the following:
|
Integrate Ethereum Name Service to WalletLinkForm.
On /profile/edit page, Instead of inputting user's full wallet address, user will also be able to reference one's wallet address by providing an ENS domain.
Considering the risk that an ENS domain gets expired or transferred and the user neglects to adjust one's README.md hidden comment, ENS is only used for initially getting the corresponding wallet address on WalletLinkForm, anything beyond resolves to the raw address.
If this flow makes sense, the same can perhaps be done for SNS (Solana Name Service)
Resolve #120
Summary by CodeRabbit
New Features
Bug Fixes
Chores