Conversation
- Changed references from TradeTrust to TrustVC throughout the document. - Updated example links and images to reflect TrustVC branding. - Clarified address book column names and import process. - Added new images for TrustVC's address resolver features.
- Updated the description of the third-party address resolver to clarify its functionality. - Simplified the setup instructions for creating a resolver endpoint and hosting options. - Added supported JSON response formats for better guidance on implementation. - Improved clarity and structure of the configuration steps in the settings page.
- Added a note on securing the resolver endpoint for production use. - Included instructions for configuring API headers and keys. - Clarified the description of the endpoint input with an example URL.
- Included a security notice about the exposure of API headers/keys in the TrustVC web app. - Recommended using a server-side proxy for resolver calls to protect sensitive credentials. - Suggested alternatives for environments where a proxy cannot be used, such as short-lived tokens.
…PI keys - Deleted the security notice regarding the exposure of API headers/keys in the TrustVC web app. - Removed recommendations for using a server-side proxy and alternatives for environments without a proxy.
…tion Tt 1342/address resolver documentation
fix: rmeove identifier as per new sample requires name and address keys
- Introduced a new guide to assist in migrating decentralized renderers to support W3C Verifiable Credentials alongside OpenAttestation documents. - Updated sidebars to include the new migration guide for easier navigation.
- Updated the error handling for the FileReader in the address resolver example to use the onerror event instead of checking for an error property, ensuring proper rejection of the promise.
- Updated package version from 0.0.0 to 0.0.1 in package-lock.json. - Revised references from TradeTrust to TrustVC across multiple documentation files for consistency. - Enhanced contact information in the Astron address whitelist error documentation. - Clarified CORS-related instructions in various how-to guides to reflect TrustVC branding.
chore: update documentation and versioning for TrustVC
…nsition - Revised the title and sidebar label in the migration guide to accurately represent the transition from TradeTrust libraries to TrustVC SDK. - Updated references within the guide to ensure consistency with the new branding.
docs: update migration guide to reflect TradeTrust to TrustVC SDK tra…
Feat/renderer migration
Contributor
|
ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThis PR rebrands documentation from TradeTrust to TrustVC, updates support contact details, rewrites address-resolver and QR-code how-tos, adds an OA+W3C migration guide for decentralized renderers, and bumps package/sidebar metadata. ChangesTrustVC Documentation Rebranding & W3C VC Migration Guide
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 19
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (5)
docs/community/contributing.md (1)
19-19:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winStandardize GitHub organization name casing to "TrustVC".
URLs across this file use inconsistent casing for the GitHub organization name:
- Line 19:
TrustVC/trustvc- Lines 28, 43, 54:
trustvc/trustvcWhile both variants resolve correctly due to GitHub's case-insensitive handling, standardize all references to match the canonical organization name "TrustVC" (as shown in the PR URL) for consistency throughout the documentation.
🤖 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 `@docs/community/contributing.md` at line 19, Normalize GitHub organization name casing in docs/community/contributing.md by replacing all occurrences of "trustvc" and "TrustVC/trustvc" with the canonical "TrustVC" casing (e.g., use "TrustVC/trustvc" -> "TrustVC/trustvc" or better "TrustVC/trustvc" depending on context) so every URL and reference consistently uses "TrustVC"; update the lines referenced in the diff where the repository string appears (the occurrences shown as "TrustVC/trustvc" and "trustvc/trustvc") to the standardized "TrustVC" form.docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-code.mdx (2)
107-107:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winTypos: "identified" and "seperate"
-> Merkle Root cannot be used to uniquely identified seperate transferable records. +> Merkle Root cannot be used to uniquely identify separate transferable records.🤖 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 `@docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-code.mdx` at line 107, Fix the typos in the sentence "Merkle Root cannot be used to uniquely identified seperate transferable records." by changing "identified" to "identify" and "seperate" to "separate" so the sentence reads "Merkle Root cannot be used to uniquely identify separate transferable records." Locate and update that exact phrase in the wrapping-document content.
54-55:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winExample code still references
tradetrust.ioafter TrustVC rebrandingThe
identityProof.locationfield in the example document (line 54) and its wrapped counterpart (line 83) still usetradetrust.io. While these are illustrative examples, they create brand inconsistency after the surrounding prose was updated to say "TrustVC document". Updating to a TrustVC domain (e.g.,trustvc.io) would make the example coherent.📝 Proposed fix
- "location": "tradetrust.io", + "location": "trustvc.io",🤖 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 `@docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-code.mdx` around lines 54 - 55, Update the illustrative example's identityProof.location values that currently read "tradetrust.io" to the TrustVC domain "trustvc.io" so the example and wrapped document stay brand-consistent; specifically change the identityProof.location fields in the example document and its wrapped counterpart (the objects referenced as identityProof.location) to "trustvc.io".docs/how-tos/open-attestation/verifiable-documents/dns-did/dns.mdx (1)
11-18:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winInconsistent branding after partial update
Line 11 was updated to "TrustVC" but line 18 still reads "TT-compliant decentralized renderer" where "TT" is the TradeTrust abbreviation. This creates a confusing mix of brand names within the same paragraph block. Line 16 also still references
example.tradetrust.ioas the issuer domain, which may mislead readers after the re-branding.Consider updating line 18 to use "TrustVC-compatible" and assess whether the example domain on line 16 should be updated.
📝 Proposed fix
-In this guide, we will bind the document issuer's identity to a valid domain name. This domain will be displayed as issuer every time the document is rendered in an TT-compliant decentralized renderer. +In this guide, we will bind the document issuer's identity to a valid domain name. This domain will be displayed as issuer every time the document is rendered in a TrustVC-compatible decentralized renderer.🤖 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 `@docs/how-tos/open-attestation/verifiable-documents/dns-did/dns.mdx` around lines 11 - 18, The paragraph mixes old and new branding: replace the "TT-compliant decentralized renderer" phrase with "TrustVC-compatible decentralized renderer" and update the example issuer domain `example.tradetrust.io` (if you want full consistency) to a TrustVC-themed domain (e.g., `example.trustvc.io`) so all occurrences—specifically the "TrustVC" mention, the example domain `example.tradetrust.io`, and the renderer phrase—use consistent branding; ensure the sentence reads naturally after substituting those strings.docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli.mdx (1)
28-30:⚠️ Potential issue | 🟠 Major | ⚡ Quick winUpdate wrapping and DNS command examples to use
trustvcCLIThe code blocks in this file and similar files (e.g.,
dns.mdx,signing-document-cli.mdx) still reference thetradetrustbinary for wrapping and DNS operations, while the rest of the documentation usestrustvccommands. Update lines 28, and corresponding examples in related files, to:
tradetrust wrap→trustvc wraptradetrust dns→trustvc dnstradetrust sign→trustvc signThis aligns with the current CLI naming after the TrustVC rebranding and prevents user confusion across the documentation.
🤖 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 `@docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli.mdx` around lines 28 - 30, Replace legacy CLI command tokens in the examples: update any occurrences of the binary name "tradetrust" to "trustvc" in the wrapping/document CLI examples (e.g., change "tradetrust wrap" to "trustvc wrap"), and apply the same replacements for DNS and signing examples ("tradetrust dns" → "trustvc dns", "tradetrust sign" → "trustvc sign") in wrapping-document-cli.mdx and the related files (dns.mdx, signing-document-cli.mdx) so all example blocks consistently use the current trustvc CLI name.
🧹 Nitpick comments (1)
docs/glossary/glossary.md (1)
29-31: ⚡ Quick winUpdate Title Escrow and Token Registry glossary entries for consistency
Lines 49 and 53 reference
https://github.com/TradeTrust/token-registrywhile the Document Store entry (line 31) was updated to point to a TrustVC repository. Decide whether these should also point to TrustVC equivalents (if they exist) or remain on TradeTrust as the canonical source.🤖 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 `@docs/glossary/glossary.md` around lines 29 - 31, The Document Store glossary entry was changed to point at a TrustVC repo but the Escrow and Token Registry entries still point to TradeTrust; decide and apply a consistent source: either update the Escrow and Token Registry links to their TrustVC equivalents (if repositories exist) or revert the Document Store link back to the canonical TradeTrust URLs. Locate the glossary headings "Document Store", "Escrow", and "Token Registry" and update the bracketed link targets so all three entries reference the same project namespace (TrustVC or TradeTrust) and ensure each link URL and display text match the chosen canonical repository.
🤖 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 `@docs/how-tos/advanced/wallet-management.md`:
- Line 7: Replace the phrase "As of today, TrustVC uses metamask browser
extension as its wallet management solution." with a neutral, correctly
capitalized sentence such as "TrustVC uses the MetaMask browser extension as its
wallet management solution." Update the "metamask" token to "MetaMask" and
remove time-sensitive wording ("As of today,") in the file content near the
sentence referencing the ADR to ensure stable documentation phrasing.
In `@docs/how-tos/decentralized-renderer/decentralized-renderer-guide.md`:
- Line 211: The inline comment above the import for Wrapper.tsx is inconsistent
with the actual import path; update the comment to match the real package or
adjust the import so both refer to the same source. Specifically, either change
the comment that currently says "From TrustVC generic-templates" to reference
"@tradetrust/decentralized-renderer-components" (or the correct package name)
next to the Wrapper import, or change the import path to the TrustVC
generic-templates package if that is the intended source, ensuring Wrapper.tsx
and its import/comment are consistent.
In `@docs/how-tos/implementing-qr-codes.md`:
- Around line 163-165: The fenced code block containing the header line
"Access-Control-Allow-Origin: *.tradetrust.io" is missing a language identifier;
update the opening fence to include a language (e.g., change ``` to ```http) so
the block becomes ```http followed by the header line and closing ``` to satisfy
markdownlint MD040.
In `@docs/how-tos/issuer/dns-did.md`:
- Line 41: Replace the two misspelled instances of "etheruem" with "ethereum" in
the DNS-DID explanation sentence that references merkleRoot and proof.signature
and the tt-verify library; while editing, also fix the possessive "it's" to
"its" in the clause about the DID document being signed so the sentence reads
correctly when referring to the ethereum wallet address and signature
verification.
In `@docs/how-tos/issuer/dns-txt.md`:
- Line 95: Update the wording around `netId` so it no longer refers specifically
to “different Ethereum networks”; replace that phrase with a generalized term
such as “blockchain networks” or “supported networks” in the sentence mentioning
`netId` (the sentence at the `netId` description). Ensure the sentence still
points to the Chain ID reference link if desired and that it accurately reflects
that the table includes non-Ethereum chains.
In `@docs/how-tos/open-attestation/transferable-records/overview.mdx`:
- Line 11: Fix the grammar in the overview sentence: update the line starting
"Transferable Records are documents which extends on Verifiable Documents, to
allow a document to have an owner and a holder, is the second core pillar of
TrustVC framework." to use correct verb agreement and include the definite
article "the" before "TrustVC framework" (e.g., rephrase to "Transferable
Records are documents which extend Verifiable Documents to allow a document to
have an owner and a holder, and are the second core pillar of the TrustVC
framework. These records reference properties..."), and correct "extends" →
"extend" and "references" → "reference".
In `@docs/how-tos/open-attestation/transferable-records/raw-document.mdx`:
- Line 18: Replace the grammatical typo "Because TrustVC is build using Open
Attestation" with "Because TrustVC is built using Open Attestation" in the
affected raw-document.mdx files; specifically update the sentence in the
transferable-records variant and the two other raw-document.mdx variants
mentioned (dns-did and dns-txt) so the phrase reads "is built" instead of "is
build".
In
`@docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli.mdx`:
- Line 15: Replace the incorrect phrase "ready to be issue" with "ready to be
issued" in the sentence within the wrapping document paragraph (the line
describing wrapping from `raw document` to `wrapped document`), so the sentence
reads "Only then, the document is ready to be issued." Ensure the grammar change
is applied exactly to that sentence in wrapping-document-cli.mdx.
In `@docs/how-tos/open-attestation/verifiable-documents/dns-did/overview.mdx`:
- Line 11: Fix the grammatical errors in the sentence "Building upon
OpenAttestation framework, our Verifiable Document form one of two core pillars
for TrustVC framework." by adding the missing article before OpenAttestation and
correcting subject–verb agreement; change it to read: "Building upon the
OpenAttestation framework, our Verifiable Documents form one of two core pillars
for the TrustVC framework." Ensure the updated sentence replaces the original in
overview.mdx.
In `@docs/how-tos/open-attestation/verifiable-documents/dns-did/raw-document.mdx`:
- Line 18: Fix the grammar in the sentence that currently reads "Because TrustVC
is build using Open Attestation..." by changing "build" to "built" so it reads
"Because TrustVC is built using Open Attestation..."; update the phrase in the
raw document (the sentence containing "Because TrustVC is build using Open
Attestation, we will be using OpenAttestation v2.0 schema.") to correct the
tense.
In
`@docs/how-tos/open-attestation/verifiable-documents/dns-txt/configuring-dns.mdx`:
- Line 16: The caption still uses the old domain string "example.tradetrust.io";
update that literal to the current TrustVC domain used elsewhere in this
document (match the domain shown on lines 12 and 18) so the screenshot caption
is consistent—search for and replace "example.tradetrust.io" in the caption text
with the same TrustVC example domain used in the surrounding content.
In `@docs/how-tos/open-attestation/verifiable-documents/dns-txt/overview.mdx`:
- Line 12: Fix the grammar in the sentence containing "our Verifiable Document
form one of two core pillars" by changing "form" to "forms" so it reads "our
Verifiable Document forms one of two core pillars"; update the string in the
document (the sentence in overview.mdx that starts with "Building upon
OpenAttestation framework...") accordingly.
- Line 48: Summary: Remove the incorrect indefinite article before "TrustVC
document data". Fix: In the sentence beginning "The decentralized renderer gives
the TrustVC document a human-readable look." replace the phrase "a TrustVC
document data" with "TrustVC document data" (i.e., remove the leading "a" in the
substring "a TrustVC document data") so it reads "...which will take TrustVC
document data as input..." to correct the grammar.
- Line 20: Update the bullet "Issue a TrustVC Verifiable document that interacts
with Ethereum Smart Contract." to include a hyperlink to the TrustVC guide using
the same markdown/nav pattern as the other bullets (as seen at lines referencing
other guides); replace the plain text with a linked version pointing to the
TrustVC guide URL (use the actual TrustVC guide path in the codebase) so the
bullet becomes a clickable link; locate the string "Issue a TrustVC Verifiable
document that interacts with Ethereum Smart Contract." in overview.mdx and wrap
it with the appropriate markdown link to the TrustVC guide.
In `@docs/how-tos/open-attestation/verifiable-documents/dns-txt/raw-document.mdx`:
- Line 18: Fix the grammar in the sentence starting "Because TrustVC is build
using Open Attestation" by changing "build" to "built" so it reads "Because
TrustVC is built using Open Attestation"; update the corresponding sentence that
references the OpenAttestation v2.0 schema and the `raw document` wording in
raw-document.mdx so the corrected past participle is used consistently.
In `@docs/how-tos/open-attestation/verifiable-documents/overview.md`:
- Line 9: Update the sentence starting "There are 2 type of verifiable
documents..." to correct the grammar to "There are 2 types of verifiable
documents..." and change the `Document Store` hyperlink target from
https://github.com/Open-Attestation/document-store to
https://github.com/TrustVC/document-store so the link matches the Glossary and
the wording is grammatically correct; ensure the rest of the sentence structure
(mentions of DNS-TXT and DNS-DID issuer methods and the distinction between
committing a fingerprint to the Document Store vs signing for DID) remains
unchanged.
In `@docs/migration-guide/migration-tr-v5.md`:
- Line 13: Replace the misleading phrase "combines several TrustVC libraries"
with wording that references the underlying TradeTrust libraries/modules; update
the sentence that mentions "TrustVC" so it reads something like "combines
several TradeTrust libraries/modules, including Token Registry v5, W3C
Verifiable Credentials, and OpenAttestation Verifiable Documents," ensuring the
phrase "TrustVC" is used only to name the library itself while the
family/modules are attributed to TradeTrust.
In `@docs/migration-guide/trustvc.md`:
- Around line 134-136: The section heading "Integration with Other TrustVC
Libraries" is misleading because the body lists TradeTrust packages
(`@tradetrust/tradetrust`, `@tradetrust-tt/tt-verify`); change the heading text
to a neutral, accurate title such as "Integration with Related Libraries" (or
"Integration with OpenAttestation and TrustVC Libraries") so it matches the
content, and ensure the H3 heading string in the document is updated accordingly
where the heading token appears.
- Line 9: The description incorrectly calls the token registry packages "TrustVC
libraries"; update the phrasing to accurately state that token registry
integration uses TradeTrust packages by replacing references to "TrustVC
libraries" with the actual package names (`@tradetrust/tradetrust` and
`@tradetrust-tt/tt-verify`) and/or label them as TradeTrust integrations so
readers can find the correct libraries (ensure the sentence referencing TrustVC
and token registry V4/V5 mentions TradeTrust packages explicitly).
---
Outside diff comments:
In `@docs/community/contributing.md`:
- Line 19: Normalize GitHub organization name casing in
docs/community/contributing.md by replacing all occurrences of "trustvc" and
"TrustVC/trustvc" with the canonical "TrustVC" casing (e.g., use
"TrustVC/trustvc" -> "TrustVC/trustvc" or better "TrustVC/trustvc" depending on
context) so every URL and reference consistently uses "TrustVC"; update the
lines referenced in the diff where the repository string appears (the
occurrences shown as "TrustVC/trustvc" and "trustvc/trustvc") to the
standardized "TrustVC" form.
In
`@docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli.mdx`:
- Around line 28-30: Replace legacy CLI command tokens in the examples: update
any occurrences of the binary name "tradetrust" to "trustvc" in the
wrapping/document CLI examples (e.g., change "tradetrust wrap" to "trustvc
wrap"), and apply the same replacements for DNS and signing examples
("tradetrust dns" → "trustvc dns", "tradetrust sign" → "trustvc sign") in
wrapping-document-cli.mdx and the related files (dns.mdx,
signing-document-cli.mdx) so all example blocks consistently use the current
trustvc CLI name.
In
`@docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-code.mdx`:
- Line 107: Fix the typos in the sentence "Merkle Root cannot be used to
uniquely identified seperate transferable records." by changing "identified" to
"identify" and "seperate" to "separate" so the sentence reads "Merkle Root
cannot be used to uniquely identify separate transferable records." Locate and
update that exact phrase in the wrapping-document content.
- Around line 54-55: Update the illustrative example's identityProof.location
values that currently read "tradetrust.io" to the TrustVC domain "trustvc.io" so
the example and wrapped document stay brand-consistent; specifically change the
identityProof.location fields in the example document and its wrapped
counterpart (the objects referenced as identityProof.location) to "trustvc.io".
In `@docs/how-tos/open-attestation/verifiable-documents/dns-did/dns.mdx`:
- Around line 11-18: The paragraph mixes old and new branding: replace the
"TT-compliant decentralized renderer" phrase with "TrustVC-compatible
decentralized renderer" and update the example issuer domain
`example.tradetrust.io` (if you want full consistency) to a TrustVC-themed
domain (e.g., `example.trustvc.io`) so all occurrences—specifically the
"TrustVC" mention, the example domain `example.tradetrust.io`, and the renderer
phrase—use consistent branding; ensure the sentence reads naturally after
substituting those strings.
---
Nitpick comments:
In `@docs/glossary/glossary.md`:
- Around line 29-31: The Document Store glossary entry was changed to point at a
TrustVC repo but the Escrow and Token Registry entries still point to
TradeTrust; decide and apply a consistent source: either update the Escrow and
Token Registry links to their TrustVC equivalents (if repositories exist) or
revert the Document Store link back to the canonical TradeTrust URLs. Locate the
glossary headings "Document Store", "Escrow", and "Token Registry" and update
the bracketed link targets so all three entries reference the same project
namespace (TrustVC or TradeTrust) and ensure each link URL and display text
match the chosen canonical repository.
🪄 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: 8ffcd10c-94f6-452f-b1c3-b9ff50ea0b01
⛔ Files ignored due to path filters (17)
package-lock.jsonis excluded by!**/package-lock.jsonstatic/docs/reference/tradetrust-website/address-resolved.pngis excluded by!**/*.pngstatic/docs/reference/tradetrust-website/local-csv.pngis excluded by!**/*.pngstatic/docs/reference/tradetrust-website/qrcode.pngis excluded by!**/*.pngstatic/docs/reference/tradetrust-website/return-search.pngis excluded by!**/*.pngstatic/docs/reference/trustvc-website/address-resolved.pngis excluded by!**/*.pngstatic/docs/reference/trustvc-website/address-resolver-empty-form.pngis excluded by!**/*.pngstatic/docs/reference/trustvc-website/address-resolver-filled-form.pngis excluded by!**/*.pngstatic/docs/reference/trustvc-website/api-gateway.pngis excluded by!**/*.pngstatic/docs/reference/trustvc-website/create-key.pngis excluded by!**/*.pngstatic/docs/reference/trustvc-website/create-project.pngis excluded by!**/*.pngstatic/docs/reference/trustvc-website/enable-api.pngis excluded by!**/*.pngstatic/docs/reference/trustvc-website/local-csv.pngis excluded by!**/*.pngstatic/docs/reference/trustvc-website/return-search.pngis excluded by!**/*.pngstatic/docs/reference/trustvc-website/route53.pngis excluded by!**/*.pngstatic/docs/reference/trustvc-website/settings-address-book.pngis excluded by!**/*.pngstatic/docs/reference/trustvc-website/settings-address-book1.pngis excluded by!**/*.png
📒 Files selected for processing (39)
docs/common-issues/astron-address-whitelist-error.mddocs/common-issues/cors-error.mddocs/community/contributing.mddocs/glossary/glossary.mddocs/how-tos/advanced/address-resolver.mddocs/how-tos/advanced/wallet-management.mddocs/how-tos/bitstring.mddocs/how-tos/contexts.mddocs/how-tos/decentralized-renderer/decentralized-renderer-guide.mddocs/how-tos/decentralized-renderer/template-advanced-features.mddocs/how-tos/decentralized-renderer/using-generic-templates.mddocs/how-tos/implementing-qr-codes.mddocs/how-tos/issuer/did-web.mddocs/how-tos/issuer/dns-did.mddocs/how-tos/issuer/dns-txt.mddocs/how-tos/open-attestation/transferable-records/dns.mdxdocs/how-tos/open-attestation/transferable-records/overview.mdxdocs/how-tos/open-attestation/transferable-records/raw-document.mdxdocs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli.mdxdocs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-code.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-did/create.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-did/dns.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-did/overview.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-did/raw-document.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-cli.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-code.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-txt/configuring-dns.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-txt/overview.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-txt/raw-document.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-cli.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-code.mdxdocs/how-tos/open-attestation/verifiable-documents/overview.mddocs/how-tos/transactions.mddocs/migration-guide/decentralized-renderer-oa-w3c-migration.mddocs/migration-guide/migration-tr-v5.mddocs/migration-guide/trustvc.mddocs/tutorial/decentralized-renderer.mdpackage.jsonsidebars.json
👮 Files not reviewed due to content moderation or server errors (1)
- docs/tutorial/decentralized-renderer.md
| --- | ||
|
|
||
| For any signed transactions, a wallet private key is always needed. As of today, Tradetrust uses metamask browser extension as its wallet management solution. This [ADR](https://github.com/Open-Attestation/adr/blob/master/wallet_management.md#survey-of-key-management-solutions) provides a good background context on various key management solutions. | ||
| For any signed transactions, a wallet private key is always needed. As of today, TrustVC uses metamask browser extension as its wallet management solution. This [ADR](https://github.com/Open-Attestation/adr/blob/master/wallet_management.md#survey-of-key-management-solutions) provides a good background context on various key management solutions. |
Contributor
There was a problem hiding this comment.
Use stable wording and correct product capitalization.
At Line 7, use “MetaMask” (official capitalization) and avoid “As of today,” which can become stale in docs. A neutral phrasing is clearer long-term (e.g., “TrustVC uses the MetaMask browser extension…”).
🤖 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 `@docs/how-tos/advanced/wallet-management.md` at line 7, Replace the phrase "As
of today, TrustVC uses metamask browser extension as its wallet management
solution." with a neutral, correctly capitalized sentence such as "TrustVC uses
the MetaMask browser extension as its wallet management solution." Update the
"metamask" token to "MetaMask" and remove time-sensitive wording ("As of
today,") in the file content near the sentence referencing the ADR to ensure
stable documentation phrasing.
|
|
||
| ```tsx | ||
| // From TradeTrust generic-templates/src/core/Wrapper/Wrapper.tsx | ||
| // From TrustVC generic-templates/src/core/Wrapper/Wrapper.tsx |
Contributor
There was a problem hiding this comment.
Package reference comment inconsistency.
The comment states "From TrustVC generic-templates" but the actual import path shown is @tradetrust/decentralized-renderer-components. This creates confusion about which package to use.
📝 Proposed fix
If the package remains under @tradetrust namespace:
-// From TrustVC generic-templates/src/core/Wrapper/Wrapper.tsx
+// From `@tradetrust/decentralized-renderer-components` generic-templates/src/core/Wrapper/Wrapper.tsxOr if it should reference TrustVC package location:
-// From TrustVC generic-templates/src/core/Wrapper/Wrapper.tsx
+// From TrustVC's fork of generic-templates/src/core/Wrapper/Wrapper.tsx📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| // From TrustVC generic-templates/src/core/Wrapper/Wrapper.tsx | |
| // From `@tradetrust/decentralized-renderer-components` generic-templates/src/core/Wrapper/Wrapper.tsx |
🤖 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 `@docs/how-tos/decentralized-renderer/decentralized-renderer-guide.md` at line
211, The inline comment above the import for Wrapper.tsx is inconsistent with
the actual import path; update the comment to match the real package or adjust
the import so both refer to the same source. Specifically, either change the
comment that currently says "From TrustVC generic-templates" to reference
"@tradetrust/decentralized-renderer-components" (or the correct package name)
next to the Wrapper import, or change the import path to the TrustVC
generic-templates package if that is the intended source, ensuring Wrapper.tsx
and its import/comment are consistent.
Comment on lines
163
to
165
| ``` | ||
| Access-Control-Allow-Origin: *.tradetrust.io | ||
| ``` |
Contributor
There was a problem hiding this comment.
Add language identifier to fenced code block (markdownlint MD040).
Line 163 starts a fenced code block without a language tag; this will keep markdownlint warning active.
Suggested fix
-```
+```http
Access-Control-Allow-Origin: *.tradetrust.io</details>
<details>
<summary>🧰 Tools</summary>
<details>
<summary>🪛 markdownlint-cli2 (0.22.1)</summary>
[warning] 163-163: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
</details>
<details>
<summary>🤖 Prompt for AI Agents</summary>
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @docs/how-tos/implementing-qr-codes.md around lines 163 - 165, The fenced
code block containing the header line "Access-Control-Allow-Origin:
*.tradetrust.io" is missing a language identifier; update the opening fence to
include a language (e.g., change tohttp) so the block becomes http followed by the header line and closing to satisfy markdownlint MD040.
</details>
<!-- fingerprinting:phantom:triton:hawk -->
<!-- d98c2f50 -->
<!-- This is an auto-generated comment by CodeRabbit -->
| | TXT | sandbox.tradetrust.io | "openatts net=ethereum netId=1 addr=0x9db35C07350e9a16C828dAda37fd9c2923c75812" | | ||
|
|
||
| The `netId` corresponds to the [chain ID for the different Ethereum networks](https://chainid.network/). Here is a list of TradeTrust supported networks: | ||
| The `netId` corresponds to the [chain ID for the different Ethereum networks](https://chainid.network/). Here is a list of TrustVC supported networks: |
Contributor
There was a problem hiding this comment.
Fix network scope wording in the netId sentence.
Line 95 says “different Ethereum networks,” but the table includes multiple non-Ethereum chains. Please generalize this to avoid incorrect guidance.
Suggested text fix
-The `netId` corresponds to the [chain ID for the different Ethereum networks](https://chainid.network/). Here is a list of TrustVC supported networks:
+The `netId` corresponds to the [chain ID](https://chainid.network/). Here is a list of TrustVC-supported networks:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| The `netId` corresponds to the [chain ID for the different Ethereum networks](https://chainid.network/). Here is a list of TrustVC supported networks: | |
| The `netId` corresponds to the [chain ID](https://chainid.network/). Here is a list of TrustVC-supported networks: |
🧰 Tools
🪛 LanguageTool
[grammar] ~95-~95: Use a hyphen to join words.
Context: ...nid.network/). Here is a list of TrustVC supported networks: | Chain ID | netI...
(QB_NEW_EN_HYPHEN)
🤖 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 `@docs/how-tos/issuer/dns-txt.md` at line 95, Update the wording around `netId`
so it no longer refers specifically to “different Ethereum networks”; replace
that phrase with a generalized term such as “blockchain networks” or “supported
networks” in the sentence mentioning `netId` (the sentence at the `netId`
description). Ensure the sentence still points to the Chain ID reference link if
desired and that it accurately reflects that the table includes non-Ethereum
chains.
| ## Understanding TrustVC Document Schema | ||
|
|
||
| Because TradeTrust is build using Open Attestation, we will be using OpenAttestation v2.0 schema. It defines the shape of data for the `raw document` - the data before the wrapping process. It is defined in [JSON Schema](https://json-schema.org/) format. | ||
| Because TrustVC is build using Open Attestation, we will be using OpenAttestation v2.0 schema. It defines the shape of data for the `raw document` - the data before the wrapping process. It is defined in [JSON Schema](https://json-schema.org/) format. |
Contributor
There was a problem hiding this comment.
Grammar: "build" → "built" (same fix as in the other raw-document.mdx files)
🤖 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 `@docs/how-tos/open-attestation/verifiable-documents/dns-txt/raw-document.mdx`
at line 18, Fix the grammar in the sentence starting "Because TrustVC is build
using Open Attestation" by changing "build" to "built" so it reads "Because
TrustVC is built using Open Attestation"; update the corresponding sentence that
references the OpenAttestation v2.0 schema and the `raw document` wording in
raw-document.mdx so the corrected past participle is used consistently.
|  | ||
|
|
||
| There are 2 type of verifiable documents which uses different types of issuer method, a blockchain issuer method (DNS-TXT) and a DID issuer method (DNS-DID). For the blockchain issuer method (DNS-TXT), the fingerprint of the wrapped TradeTrust file is then committed to a [Document Store](https://github.com/Open-Attestation/document-store) smart contract on the Blockchain, which serves as an immutable ledger. For the DID issuer method (DNS-DID), the document is signed instead of being committed to the blockchain. | ||
| There are 2 type of verifiable documents which uses different types of issuer method, a blockchain issuer method (DNS-TXT) and a DID issuer method (DNS-DID). For the blockchain issuer method (DNS-TXT), the fingerprint of the wrapped TrustVC file is then committed to a [Document Store](https://github.com/Open-Attestation/document-store) smart contract on the Blockchain, which serves as an immutable ledger. For the DID issuer method (DNS-DID), the document is signed instead of being committed to the blockchain. |
Contributor
There was a problem hiding this comment.
Document Store link inconsistency and grammar nit
- The
Document Storehyperlink on line 9 still points tohttps://github.com/Open-Attestation/document-store, while the Glossary (glossary.mdline 31) was updated in this PR to point tohttps://github.com/TrustVC/document-store. These should be consistent. - Minor grammar: "There are 2 type of" → "There are 2 types of".
📝 Proposed fix
-There are 2 type of verifiable documents which uses different types of issuer method, a blockchain issuer method (DNS-TXT) and a DID issuer method (DNS-DID). For the blockchain issuer method (DNS-TXT), the fingerprint of the wrapped TrustVC file is then committed to a [Document Store](https://github.com/Open-Attestation/document-store) smart contract on the Blockchain, which serves as an immutable ledger.
+There are 2 types of verifiable documents which use different types of issuer method, a blockchain issuer method (DNS-TXT) and a DID issuer method (DNS-DID). For the blockchain issuer method (DNS-TXT), the fingerprint of the wrapped TrustVC file is then committed to a [Document Store](https://github.com/TrustVC/document-store) smart contract on the Blockchain, which serves as an immutable ledger.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| There are 2 type of verifiable documents which uses different types of issuer method, a blockchain issuer method (DNS-TXT) and a DID issuer method (DNS-DID). For the blockchain issuer method (DNS-TXT), the fingerprint of the wrapped TrustVC file is then committed to a [Document Store](https://github.com/Open-Attestation/document-store) smart contract on the Blockchain, which serves as an immutable ledger. For the DID issuer method (DNS-DID), the document is signed instead of being committed to the blockchain. | |
| There are 2 types of verifiable documents which use different types of issuer method, a blockchain issuer method (DNS-TXT) and a DID issuer method (DNS-DID). For the blockchain issuer method (DNS-TXT), the fingerprint of the wrapped TrustVC file is then committed to a [Document Store](https://github.com/TrustVC/document-store) smart contract on the Blockchain, which serves as an immutable ledger. For the DID issuer method (DNS-DID), the document is signed instead of being committed to the blockchain. |
🤖 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 `@docs/how-tos/open-attestation/verifiable-documents/overview.md` at line 9,
Update the sentence starting "There are 2 type of verifiable documents..." to
correct the grammar to "There are 2 types of verifiable documents..." and change
the `Document Store` hyperlink target from
https://github.com/Open-Attestation/document-store to
https://github.com/TrustVC/document-store so the link matches the Glossary and
the wording is grammatically correct; ensure the rest of the sentence structure
(mentions of DNS-TXT and DNS-DID issuer methods and the distinction between
committing a fingerprint to the Document Store vs signing for DID) remains
unchanged.
| **TrustVC Integration** | ||
|
|
||
| - **TrustVC** is a comprehensive library that combines several TradeTrust libraries, including Token Registry v5, W3C Verifiable Credentials, and OpenAttestation Verifiable Documents. By using **TrustVC**, you can manage both credential documents and token-based credentials seamlessly in a unified solution. | ||
| - **TrustVC** is a comprehensive library that combines several TrustVC libraries, including Token Registry v5, W3C Verifiable Credentials, and OpenAttestation Verifiable Documents. By using **TrustVC**, you can manage both credential documents and token-based credentials seamlessly in a unified solution. |
Contributor
There was a problem hiding this comment.
Correct the library-family wording for accuracy.
Line 13 currently says “combines several TrustVC libraries,” which is misleading. It should refer to underlying TradeTrust libraries/modules to avoid conceptual confusion in migration guidance.
Suggested text fix
-- **TrustVC** is a comprehensive library that combines several TrustVC libraries, including Token Registry v5, W3C Verifiable Credentials, and OpenAttestation Verifiable Documents. By using **TrustVC**, you can manage both credential documents and token-based credentials seamlessly in a unified solution.
+- **TrustVC** is a comprehensive library that combines several TradeTrust ecosystem libraries, including Token Registry v5, W3C Verifiable Credentials, and OpenAttestation Verifiable Documents. By using **TrustVC**, you can manage both credential documents and token-based credentials seamlessly in a unified solution.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| - **TrustVC** is a comprehensive library that combines several TrustVC libraries, including Token Registry v5, W3C Verifiable Credentials, and OpenAttestation Verifiable Documents. By using **TrustVC**, you can manage both credential documents and token-based credentials seamlessly in a unified solution. | |
| - **TrustVC** is a comprehensive library that combines several TradeTrust ecosystem libraries, including Token Registry v5, W3C Verifiable Credentials, and OpenAttestation Verifiable Documents. By using **TrustVC**, you can manage both credential documents and token-based credentials seamlessly in a unified solution. |
🤖 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 `@docs/migration-guide/migration-tr-v5.md` at line 13, Replace the misleading
phrase "combines several TrustVC libraries" with wording that references the
underlying TradeTrust libraries/modules; update the sentence that mentions
"TrustVC" so it reads something like "combines several TradeTrust
libraries/modules, including Token Registry v5, W3C Verifiable Credentials, and
OpenAttestation Verifiable Documents," ensuring the phrase "TrustVC" is used
only to name the library itself while the family/modules are attributed to
TradeTrust.
| [**TrustVC**](https://github.com/TrustVC/trustvc) is a comprehensive library designed to simplify the signing and verification processes for [TrustVC W3C Verifiable Credentials (VC)](https://github.com/TrustVC/w3c) and [OpenAttestation Verifiable Documents (VD)](https://github.com/Open-Attestation/open-attestation/). It adheres to the **W3C VC Data Model v2.0** ([W3C Standard](https://www.w3.org/TR/vc-data-model/)), ensuring compatibility and interoperability for Verifiable Credentials. | ||
|
|
||
| With **TrustVC**, developers can seamlessly handle both W3C Verifiable Credentials and OpenAttestation Verifiable Documents through an integrated set of functionalities. The library not only simplifies signing and verification but also imports and integrates existing TradeTrust libraries and smart contracts for token registry (V4 and V5), making it a versatile tool for decentralized identity and trust solutions. | ||
| With **TrustVC**, developers can seamlessly handle both W3C Verifiable Credentials and OpenAttestation Verifiable Documents through an integrated set of functionalities. The library not only simplifies signing and verification but also imports and integrates existing TrustVC libraries and smart contracts for token registry (V4 and V5), making it a versatile tool for decentralized identity and trust solutions. |
Contributor
There was a problem hiding this comment.
Potentially inaccurate claim: token registry described as "TrustVC libraries"
Line 9 states the library "imports and integrates existing TrustVC libraries and smart contracts for token registry (V4 and V5)". However, line 143 reveals that the token registry integration is via @tradetrust/tradetrust and @tradetrust-tt/tt-verify — TradeTrust packages, not TrustVC packages. Calling them "TrustVC libraries" is misleading to readers who may try to find them under the TrustVC org.
📝 Proposed fix
-With **TrustVC**, developers can seamlessly handle both W3C Verifiable Credentials and OpenAttestation Verifiable Documents through an integrated set of functionalities. The library not only simplifies signing and verification but also imports and integrates existing TrustVC libraries and smart contracts for token registry (V4 and V5), making it a versatile tool for decentralized identity and trust solutions.
+With **TrustVC**, developers can seamlessly handle both W3C Verifiable Credentials and OpenAttestation Verifiable Documents through an integrated set of functionalities. The library not only simplifies signing and verification but also imports and integrates existing TrustVC and OpenAttestation libraries (including token registry V4 and V5), making it a versatile tool for decentralized identity and trust solutions.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| With **TrustVC**, developers can seamlessly handle both W3C Verifiable Credentials and OpenAttestation Verifiable Documents through an integrated set of functionalities. The library not only simplifies signing and verification but also imports and integrates existing TrustVC libraries and smart contracts for token registry (V4 and V5), making it a versatile tool for decentralized identity and trust solutions. | |
| With **TrustVC**, developers can seamlessly handle both W3C Verifiable Credentials and OpenAttestation Verifiable Documents through an integrated set of functionalities. The library not only simplifies signing and verification but also imports and integrates existing TrustVC and OpenAttestation libraries (including token registry V4 and V5), making it a versatile tool for decentralized identity and trust solutions. |
🤖 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 `@docs/migration-guide/trustvc.md` at line 9, The description incorrectly calls
the token registry packages "TrustVC libraries"; update the phrasing to
accurately state that token registry integration uses TradeTrust packages by
replacing references to "TrustVC libraries" with the actual package names
(`@tradetrust/tradetrust` and `@tradetrust-tt/tt-verify`) and/or label them as
TradeTrust integrations so readers can find the correct libraries (ensure the
sentence referencing TrustVC and token registry V4/V5 mentions TradeTrust
packages explicitly).
Comment on lines
+134
to
+136
| ### 3. Integration with Other TrustVC Libraries | ||
|
|
||
| **TrustVC** is designed to work seamlessly with other TradeTrust libraries, extending their functionality and making it easier to integrate decentralized identity solutions. By leveraging existing TradeTrust tools, **TrustVC** enhances its capabilities for signing, verifying, and managing credentials and documents. | ||
| **TrustVC** is designed to work seamlessly with other TrustVC libraries, extending their functionality and making it easier to integrate decentralized identity solutions. By leveraging existing TrustVC tools, **TrustVC** enhances its capabilities for signing, verifying, and managing credentials and documents. |
Contributor
There was a problem hiding this comment.
Section heading says "TrustVC Libraries" but body references TradeTrust packages
The heading on line 134, "Integration with Other TrustVC Libraries", was updated from TradeTrust → TrustVC, but the subsection on line 143 explicitly lists @tradetrust/tradetrust and @tradetrust-tt/tt-verify as integrated libraries. The heading overstates the TrustVC scope and will confuse developers looking for these packages under the TrustVC GitHub org.
Consider a neutral heading such as "Integration with Related Libraries" or "Integration with OpenAttestation and TrustVC Libraries".
📝 Proposed fix
-### 3. Integration with Other TrustVC Libraries
+### 3. Integration with OpenAttestation and TrustVC Libraries🤖 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 `@docs/migration-guide/trustvc.md` around lines 134 - 136, The section heading
"Integration with Other TrustVC Libraries" is misleading because the body lists
TradeTrust packages (`@tradetrust/tradetrust`, `@tradetrust-tt/tt-verify`);
change the heading text to a neutral, accurate title such as "Integration with
Related Libraries" (or "Integration with OpenAttestation and TrustVC Libraries")
so it matches the content, and ensure the H3 heading string in the document is
updated accordingly where the heading token appears.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
rongquan1
approved these changes
May 7, 2026
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
2 participants
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 by CodeRabbit
Documentation
Version