docs: add advocate welcome kit and update SDK quickstart #134
Conversation
WalkthroughThis pull request adds documentation for a new Advocates Welcome Kit program, completes previously unfinished SDK quickstart sections, and updates navigation references across multiple documentation pages. Changes are purely documentation-focused with no code implementation. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 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 |
|
Hello @AllenAJ, thank you for submitting your first pull request to the docs.request.network repository. We value your contribution and encourage you to review our contribution guidelines to ensure your submission meets our standards. Please note that every merged PR is automatically enrolled in our Best PR Initiative, offering a chance to win $500 each quarter. Our team is available via GitHub Discussions or Discord if you have any questions. Welcome aboard! |
|
Thank you for your submission! As you prepare for the review process, please ensure that your PR title, description, and any linked issues fully comply with our contribution guidelines. A clear explanation of your changes and their context will help expedite the review process. Every merged PR is automatically entered into our Best PR Initiative, offering a chance to win $500 every quarter. We appreciate your attention to detail and look forward to reviewing your contribution! |
Greptile SummaryThis PR enhances the documentation by adding an Advocates Welcome Kit for community onboarding and completing the "Updating a Request" guide with working code examples. The Node.js quickstart now includes a request update section and viem integration example. Key Changes:
Issues Found:
Confidence Score: 3/5
Important Files Changed
Sequence DiagramsequenceDiagram
participant User as Developer/Advocate
participant Docs as Documentation
participant SDK as Request Network SDK
participant Node as Request Node
participant IPFS as IPFS Network
Note over User,Docs: New Advocate Onboarding Flow
User->>Docs: Access Advocates Welcome Kit
Docs-->>User: Program details, tools, rewards
Note over User,SDK: Request Update Workflow
User->>SDK: Initialize RequestNetwork client<br/>with signatureProvider
User->>SDK: fromRequestId(requestId)
SDK->>Node: Fetch request data
Node->>IPFS: Retrieve request content
IPFS-->>Node: Request data
Node-->>SDK: Request object
SDK-->>User: Request instance
User->>SDK: request.accept(signerIdentity)
SDK->>SDK: Sign update with private key
SDK->>Node: Submit update transaction
Node->>IPFS: Store update
Node->>Blockchain: Store CID hash
SDK-->>User: Updated request data
User->>SDK: request.waitForConfirmation()
SDK->>Node: Poll for confirmation
Node-->>SDK: Confirmed
SDK-->>User: Confirmed request data
Note over User,SDK: Payment Flow (with viem)
User->>SDK: Create viem clients
User->>SDK: Convert to ethers v5 signer
SDK->>SDK: Check funds & approval
User->>SDK: payRequest(requestData, signer)
SDK->>Blockchain: Execute payment transaction
Blockchain-->>SDK: Transaction receipt
SDK-->>User: Payment complete
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Additional Comments (4)
-
docs/advanced/request-network-sdk/get-started/quickstart-node.js.md, line 197-200 (link)logic: Uses
mainnetchain but the rest of the quickstart uses Sepolia. Should be consistent.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
-
docs/advanced/request-network-sdk/get-started/quickstart-node.js.md, line 205-207 (link)logic: Chain should match Sepolia for consistency with the rest of the quickstart.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
-
docs/advanced/request-network-sdk/get-started/quickstart-node.js.md, line 211-213 (link)logic: Should use
sepoliainstead ofmainnetfor consistency.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
-
docs/advanced/request-network-sdk/get-started/quickstart-node.js.md, line 210-214 (link)logic: The viem
WalletClient.transportis not directly compatible with ethersWeb3Provider. Check the implementation inquickstart-browser.md:274-284which properly extracts account and chain info from thewalletClientbefore creating the provider.
5 files reviewed, 4 comments
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
docs/SUMMARY.mddocs/advanced/request-network-sdk/get-started/quickstart-node.js.mddocs/advanced/request-network-sdk/sdk-guides/request-client/updating-a-request.mddocs/faq.mddocs/general/advocates-welcome-kit.md
🧰 Additional context used
📓 Path-based instructions (1)
**/*
⚙️ CodeRabbit configuration file
**/*: - Only comment on issues that would block merging — ignore minor or stylistic concerns.
- Restrict feedback to errors, security risks, or functionality-breaking problems.
- Do not post comments on code style, formatting, or non-critical improvements.
- Keep reviews short: flag only issues that make the PR unsafe to merge.
- Limit review comments to 3–5 items maximum, unless additional blockers exist.
- Group similar issues into a single comment instead of posting multiple notes.
- Skip repetition — if a pattern repeats, mention it once at a summary level only.
- Do not add general suggestions; focus strictly on merge-blocking concerns.
- If there are no critical problems, respond with minimal approval (e.g., 'Looks good'). Do not add additional review.
- Avoid line-by-line commentary unless it highlights a critical bug or security hole.
- Highlight only issues that could cause runtime errors, data loss, or severe maintainability issues.
- Ignore minor optimization opportunities — focus solely on correctness and safety.
- Provide a top-level summary of critical blockers rather than detailed per-line notes.
- Comment only when the issue must be resolved before merge — otherwise, remain silent.
- When in doubt, err on the side of fewer comments — brevity and blocking issues only.
- Avoid posting any refactoring issues
Files:
docs/advanced/request-network-sdk/get-started/quickstart-node.js.mddocs/general/advocates-welcome-kit.mddocs/SUMMARY.mddocs/faq.mddocs/advanced/request-network-sdk/sdk-guides/request-client/updating-a-request.md
🪛 LanguageTool
docs/general/advocates-welcome-kit.md
[style] ~20-~20: The noun “invitation” is usually used instead of ‘invite’ in formal writing.
Context: ...ols * Notion: You will receive an invite to our private Advocates workspace. * ...
(AN_INVITE)
🪛 markdownlint-cli2 (0.18.1)
docs/general/advocates-welcome-kit.md
47-47: Bare URL used
(MD034, no-bare-urls)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Greptile Review
| // Convert viem WalletClient to ethers v5 Signer | ||
| const provider = new providers.Web3Provider(walletClient.transport, { | ||
| chainId: mainnet.id, | ||
| name: mainnet.name, | ||
| }); | ||
| const signer = provider.getSigner(account.address); |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
viem http transport EIP-1193 compatible ethers Web3Provider
💡 Result:
Short answer — use viem's custom transport for an EIP‑1193 provider (like ethers' Web3Provider/window.ethereum) and viem's http transport for JSON‑RPC endpoints. Example patterns:
-
Use an injected EIP‑1193 provider (MetaMask / ethers Web3Provider.window.ethereum) with viem wallet/public clients:
import { createWalletClient, createPublicClient, custom } from 'viem'
import { mainnet } from 'viem/chains'// EIP‑1193 provider (window.ethereum or providers.Web3Provider(window.ethereum).provider)
const eip1193 = window.ethereumconst walletClient = createWalletClient({
chain: mainnet,
transport: custom(eip1193),
})const publicClient = createPublicClient({
chain: mainnet,
transport: custom(eip1193), // or use http() for a read‑only RPC
}) -
Use HTTP RPC for a read/backup transport:
import { createPublicClient, http } from 'viem'
const publicClient = createPublicClient({
chain: mainnet,
transport: http('https://eth-mainnet.g.alchemy.com/v2/<API_KEY>'),
})
Notes:
- If you already wrap window.ethereum with ethers' providers.Web3Provider, pass its underlying provider (.provider) or window.ethereum directly to viem's custom transport — viem expects an EIP‑1193 request interface. [1][2][3]
Sources:
[1] viem — Custom transport (EIP‑1193).
[2] viem migration examples (Web3Provider -> custom).
[3] viem http/fallback transport examples.
🌐 Web query:
viem WalletClient to ethers v5 Signer conversion
💡 Result:
Summary — simple approach
- Wrap the WalletClient's EIP‑1193 transport in an ethers v5 Web3Provider and call getSigner(account.address). This yields an ethers v5 Signer that delegates signing to the same wallet. [1][2][3]
Example (TypeScript)
- Assumes you have a viem WalletClient instance named walletClient with walletClient.account.address and walletClient.transport (EIP‑1193 provider, e.g. window.ethereum).
import { providers } from "ethers";
function walletClientToEthersSigner(walletClient: any) {
const provider = new providers.Web3Provider(walletClient.transport as any);
return provider.getSigner(walletClient.account.address);
}
Notes
- If walletClient.transport is window.ethereum (or another EIP‑1193 provider), Web3Provider will work directly. If you only have the account address but not the transport, you must create a provider (e.g., new providers.Web3Provider(window.ethereum)) and then call getSigner(address). [1][2][3]
Sources
- Wagmi example: converting a viem client to an ethers Signer. [1]
- viem WalletClient docs (WalletClient, transports, accounts). [2]
- viem migration guide (Signers → Accounts mapping). [3]
🌐 Web query:
ethers v5 Web3Provider constructor requirements EIP-1193 provider
💡 Result:
Short answer:
-
ethers v5's Web3Provider accepts an "ExternalProvider" that is either a Web3-compatible provider or an EIP‑1193 provider. It will accept one of these provider method signatures (first match used): provider.request(request) → Promise; or legacy provider.sendAsync(request, callback); or provider.send(request, callback). [1]
-
If you supply an EIP‑1193 provider, it should implement the EIP‑1193 request(...) API and the event methods required by EIP‑1193 (on, removeListener, and emit the connect / disconnect / chainChanged / accountsChanged semantics). See the EIP‑1193 spec for the required request signature and event semantics. [2]
Sources:
[1] ethers v5 docs — Web3Provider / ExternalProvider (ethers.js).
[2] EIP‑1193: Ethereum Provider JavaScript API (request, events).
🏁 Script executed:
cat -n docs/advanced/request-network-sdk/get-started/quickstart-node.js.md | sed -n '180,220p'Repository: RequestNetwork/docs.request.network
Length of output: 1481
Fix the viem-to-ethers conversion; current code will fail at runtime.
The walletClient is created with viem's http() transport (line 206), which is a JSON-RPC transport and not EIP-1193 compatible. Passing it to ethers' Web3Provider constructor (line 210) will fail because Web3Provider expects an EIP-1193 provider with a request() method. The working pattern requires an EIP-1193 compatible transport created with viem's custom() function, not http().
🤖 Prompt for AI Agents
In docs/advanced/request-network-sdk/get-started/quickstart-node.js.md around
lines 209-214, the conversion from a viem WalletClient to an ethers v5 Signer is
incorrect because the WalletClient was created with viem's http() transport (a
JSON-RPC client) which is not EIP-1193 compatible; instead create an
EIP-1193-compatible transport using viem's custom() helper (or otherwise wrap
the transport to expose a request(method, params) function) and use that
EIP-1193 provider instance when constructing ethers.providers.Web3Provider so
provider.getSigner(account.address) works at runtime. Ensure the
WalletClient/provider initialization is switched to the custom() pattern (or an
adapter exposing request) before passing to Web3Provider.
2 participants
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.