docs: clean up quickstart docs#2214
Conversation
shrugs
commented
May 27, 2026
shrugs
commented
- disables prettier auto-formatting embedded code (i.e. graphql)
- enabled prettier plugin format-on-save for vscode
- simplifies the omnigraph quickstart examples
- moves the more complex concepts to /concepts and expands upon them with examples and more prose
- expands terminology
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
|
📝 WalkthroughWalkthroughThis PR restructures ENS Node documentation and tooling configuration. It adds Prettier and VS Code formatter setup, introduces a new Omnigraph core concepts documentation page, condenses the Omnigraph index and related content, simplifies quickstart code examples, updates sidebar navigation, and adds terminology definitions for beautified and resolvable names. ChangesDocumentation Restructuring and Tooling Configuration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
🚥 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 docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint skipped: no ESLint configuration detected in root package.json. To enable, add 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 |
Greptile SummaryThis PR cleans up the Omnigraph quickstart documentation: it simplifies the walkthrough code examples, moves the deep-dive concepts (Namegraph, Unigraph, canonicality, polymorphism, Interpreted Names, Events, Permissions) to a new
Confidence Score: 5/5Documentation-only changes with no runtime code impact; safe to merge. All changes are confined to markdown/MDX documentation, VSCode workspace config, and Prettier config. No application logic, schema, or API surface is touched. The new concepts page is well-structured with accurate content; the only minor issue is a misleading empty-string snippet in a callout. docs/ensnode.io/src/content/docs/docs/integrate/omnigraph/concepts.mdx — one prose nit in the InterpretedNames danger callout. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
OI[omnigraph/index.mdx\nSimplified overview] -->|links to| OC[omnigraph/concepts.mdx\nNew Core Concepts page]
OI -->|links to| EX[omnigraph/examples\nExisting]
OC -->|references| TERM[reference/terminology.mdx\n+ Beautified Label/Name\n+ Resolvable Name]
SIDEBAR[integrate.ts sidebar] -->|adds entry| OC
QS1[quickstart/v1.13.1.mdx\nSimplified enskit example] -->|removed| WARN[HostedInstanceSdkVersionWarning]
QS2[quickstart/v1.15.0.mdx\nSimplified enskit example] -->|removed| WARN
PRETTIER[.prettierrc.json\nembeddedLanguageFormatting off] -->|now covers| ALLDOCS[docs/ensnode.io/**/*.md,mdx]
Reviews (10): Last reviewed commit: "Merge branch 'main' into docs/level-one-..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pull request overview
This docs-focused PR streamlines the Omnigraph quickstart, moves deeper Omnigraph concepts into a dedicated page, expands terminology, and updates editor/Prettier configuration for docs authoring.
Changes:
- Simplifies the Omnigraph overview and quickstart walkthrough examples.
- Adds a new Core Concepts page with expanded GraphQL examples and terminology links.
- Updates VS Code and Prettier settings for Markdown/MDX/Astro formatting.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
docs/ensnode.io/src/content/docs/docs/reference/terminology.mdx |
Adds Beautified Label/Name and Resolvable Name terminology. |
docs/ensnode.io/src/content/docs/docs/integrate/omnigraph/index.mdx |
Replaces long-form concepts content with a concise overview and first query. |
docs/ensnode.io/src/content/docs/docs/integrate/omnigraph/concepts.mdx |
Adds the new expanded Omnigraph Core Concepts documentation page. |
docs/ensnode.io/src/content/docs/docs/integrate/ensv2-readiness.mdx |
Tightens ENSv2 readiness prose around Unigraph and Omnigraph. |
docs/ensnode.io/src/components/walkthroughs/quickstart/v1.15.0.mdx |
Simplifies the v1.15.0 quickstart code examples. |
docs/ensnode.io/src/components/walkthroughs/quickstart/v1.13.1.mdx |
Simplifies the v1.13.1 quickstart code examples. |
docs/ensnode.io/config/integrations/starlight/sidebar-topics/integrate.ts |
Adds the Core Concepts page to the Omnigraph sidebar. |
.vscode/settings.json |
Sets Prettier as formatter for Markdown, MDX, and Astro. |
.vscode/extensions.json |
Recommends the Prettier VS Code extension. |
.prettierrc.json |
Disables embedded language formatting across docs Markdown/MDX files. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
docs/ensnode.io/src/components/walkthroughs/quickstart/v1.13.1.mdx (1)
2-2:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winUnused import:
HostedInstanceSdkVersionWarningis no longer rendered.The component is imported but not used in the file after simplification.
♻️ Proposed fix
import { LinkCard, CardGrid, Aside } from "`@astrojs/starlight/components`"; -import HostedInstanceSdkVersionWarning from "`@components/molecules/HostedInstanceSdkVersionWarning.astro`"; import OmnigraphStaticExampleSet from "`@components/organisms/OmnigraphStaticExampleSet.astro`";🤖 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/ensnode.io/src/components/walkthroughs/quickstart/v1.13.1.mdx` at line 2, Remove the unused import HostedInstanceSdkVersionWarning from the top of the file since the component is no longer rendered; locate the import statement "import HostedInstanceSdkVersionWarning from \"`@components/molecules/HostedInstanceSdkVersionWarning.astro`\";" and delete it to eliminate the unused symbol and clean up the module imports.docs/ensnode.io/src/components/walkthroughs/quickstart/v1.15.0.mdx (1)
2-2:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winUnused import:
HostedInstanceSdkVersionWarningis no longer rendered.The component is imported but not used in the file after simplification.
♻️ Proposed fix
import { LinkCard, CardGrid, Aside } from "`@astrojs/starlight/components`"; -import HostedInstanceSdkVersionWarning from "`@components/molecules/HostedInstanceSdkVersionWarning.astro`"; import OmnigraphStaticExampleSet from "`@components/organisms/OmnigraphStaticExampleSet.astro`";🤖 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/ensnode.io/src/components/walkthroughs/quickstart/v1.15.0.mdx` at line 2, The import HostedInstanceSdkVersionWarning is unused in the quickstart component; remove the import statement for HostedInstanceSdkVersionWarning from the file so there are no dead imports (search for the symbol HostedInstanceSdkVersionWarning to locate and delete the import line), and run the linter/build to confirm no further references remain.
🤖 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/ensnode.io/src/components/walkthroughs/quickstart/v1.13.1.mdx`:
- Around line 74-84: The GraphQL query DomainByNameQuery is querying domain.name
directly but the schema exposes names under canonical.name, so update the query
passed to graphql(`...`) to select canonical { name { beautified or interpreted
} } (e.g., canonical { name { beautified } } or canonical { name { interpreted }
}) instead of name; keep the owner { address } selection as-is and ensure the
query variable type ($name: InterpretedName!) remains unchanged so editor
typechecking and autocomplete for DomainByNameQuery still work.
- Around line 99-100: Update the JSX to read the new nested field path from the
corrected GraphQL schema: replace references to domain.name with
domain.canonical?.name?.beautified (falling back to "Unnamed Domain" if missing)
while leaving owner access as domain.owner?.address ?? "Unowned"; ensure you
update the display expression where the component currently uses Name:
{domain.name ?? "Unnamed Domain"} to use the canonical.name.beautified path
instead.
In `@docs/ensnode.io/src/content/docs/docs/reference/terminology.mdx`:
- Line 163: Update the Resolvable Name definition to avoid confusing the term
"literal label segments" with the earlier-defined "Literal Label"; replace or
augment that phrase in the Resolvable Name sentence (the text around "Resolvable
Name" and "literal label segments") with one of the suggested clarifications
such as "actual text label segments (normalized or unnormalized)" or "textual
label segments (normalized or unnormalized)", or add a short parenthetical like
"(i.e., not Encoded LabelHashes; normalized or unnormalized)" so readers clearly
understand the distinction from Encoded LabelHashes and the earlier Literal
Label term.
---
Outside diff comments:
In `@docs/ensnode.io/src/components/walkthroughs/quickstart/v1.13.1.mdx`:
- Line 2: Remove the unused import HostedInstanceSdkVersionWarning from the top
of the file since the component is no longer rendered; locate the import
statement "import HostedInstanceSdkVersionWarning from
\"`@components/molecules/HostedInstanceSdkVersionWarning.astro`\";" and delete it
to eliminate the unused symbol and clean up the module imports.
In `@docs/ensnode.io/src/components/walkthroughs/quickstart/v1.15.0.mdx`:
- Line 2: The import HostedInstanceSdkVersionWarning is unused in the quickstart
component; remove the import statement for HostedInstanceSdkVersionWarning from
the file so there are no dead imports (search for the symbol
HostedInstanceSdkVersionWarning to locate and delete the import line), and run
the linter/build to confirm no further references remain.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: bb26b137-1662-4bcf-84ce-a0880601cc2f
📒 Files selected for processing (10)
.prettierrc.json.vscode/extensions.json.vscode/settings.jsondocs/ensnode.io/config/integrations/starlight/sidebar-topics/integrate.tsdocs/ensnode.io/src/components/walkthroughs/quickstart/v1.13.1.mdxdocs/ensnode.io/src/components/walkthroughs/quickstart/v1.15.0.mdxdocs/ensnode.io/src/content/docs/docs/integrate/ensv2-readiness.mdxdocs/ensnode.io/src/content/docs/docs/integrate/omnigraph/concepts.mdxdocs/ensnode.io/src/content/docs/docs/integrate/omnigraph/index.mdxdocs/ensnode.io/src/content/docs/docs/reference/terminology.mdx
- concepts.mdx: domains() takes required where (version inside it) and returns a connection; select via edges.node - concepts.mdx: fix "there is exists" grammar - v1.13.1/v1.15.0 walkthroughs: drop orphaned HostedInstanceSdkVersionWarning import
|
@greptile review |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/ensnode.io/src/content/docs/docs/integrate/omnigraph/concepts.mdx (1)
295-295:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix the malformed example and extra closing parenthesis.
The example shows
domain(by: { name: "" })with an empty string and has an extra closing parenthesis. The empty string doesn't illustrate the point about Encoded LabelHashes, and the extra)is a syntax error.📝 Proposed fix
-ENS Forward Resolution does _not_ support Encoded LabelHashes in names, so while an InterpretedName can be used to traverse the Namegraph (i.e. with `domain(by: { name: "" }))`), if the Canonical Name is not a [ResolvableName](/docs/reference/terminology#resolvable-name), then the records for that name _cannot_ be determined. +ENS Forward Resolution does _not_ support Encoded LabelHashes in names, so while an InterpretedName can be used to traverse the Namegraph (i.e. with `domain(by: { name: "..." })`), if the Canonical Name is not a [ResolvableName](/docs/reference/terminology#resolvable-name), then the records for that name _cannot_ be determined.🤖 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/ensnode.io/src/content/docs/docs/integrate/omnigraph/concepts.mdx` at line 295, The example in the documentation showing the domain query with `domain(by: { name: "" })` is malformed and has an extra closing parenthesis at the end. Fix this by replacing the empty string inside the name parameter with an actual example of an Encoded LabelHash to properly illustrate the point being made about why ENS Forward Resolution does not support Encoded LabelHashes, and remove the extraneous closing parenthesis to correct the syntax error.
🤖 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.
Outside diff comments:
In `@docs/ensnode.io/src/content/docs/docs/integrate/omnigraph/concepts.mdx`:
- Line 295: The example in the documentation showing the domain query with
`domain(by: { name: "" })` is malformed and has an extra closing parenthesis at
the end. Fix this by replacing the empty string inside the name parameter with
an actual example of an Encoded LabelHash to properly illustrate the point being
made about why ENS Forward Resolution does not support Encoded LabelHashes, and
remove the extraneous closing parenthesis to correct the syntax error.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: b21f8842-dbd8-4572-b54c-7b3520ad6ed0
📒 Files selected for processing (3)
docs/ensnode.io/src/components/walkthroughs/quickstart/v1.13.1.mdxdocs/ensnode.io/src/components/walkthroughs/quickstart/v1.15.0.mdxdocs/ensnode.io/src/content/docs/docs/integrate/omnigraph/concepts.mdx
💤 Files with no reviewable changes (2)
- docs/ensnode.io/src/components/walkthroughs/quickstart/v1.13.1.mdx
- docs/ensnode.io/src/components/walkthroughs/quickstart/v1.15.0.mdx
|
@greptile review |
|
@greptile review |
|
@greptile review |
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
# Conflicts: # docs/ensnode.io/config/integrations/starlight/sidebar-topics/integrate.ts # docs/ensnode.io/src/content/docs/docs/integrate/ensv2-readiness.mdx
| # reference a Domain by name | ||
| domain(by: { name: "eth" }) { | ||
| # this is the Registry that "eth" exists within | ||
| registry { id contract { chainId address } } |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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/ensnode.io/src/content/docs/docs/integrate/ensv2-readiness.mdx`:
- Line 35: Update the ENSv2 readiness paragraph that mentions ENSNode's "ENS
Protocol Acceleration" (the sentence beginning "ENSNode also provides **[ENS
Protocol Acceleration]...**") to add a caveat noting that acceleration is
currently gated/disabled in ENSv2-root contexts; change "dramatically reducing
resolution latency for most names" to a qualified statement indicating
acceleration applies to non-root ENSv2 contexts (or "most names outside
ENSv2-root contexts") so readers understand the current limitation.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: be8e130f-0449-4982-bd31-6373d3c8d619
📒 Files selected for processing (5)
docs/ensnode.io/config/integrations/starlight/sidebar-topics/integrate.tsdocs/ensnode.io/src/components/walkthroughs/quickstart/v1.13.1.mdxdocs/ensnode.io/src/content/docs/docs/integrate/ensv2-readiness.mdxdocs/ensnode.io/src/content/docs/docs/integrate/omnigraph/concepts.mdxdocs/ensnode.io/src/content/docs/docs/services/ensrainbow/concepts/creating-files.mdx
lightwalker-eth
left a comment
lightwalker-eth
left a comment
There was a problem hiding this comment.
@shrugs This is a super upgrade to our docs! Nice work! Shared a few suggestions please take the lead on next steps 🫡
|
|
||
| With `enskit`, leverage ENSNode and the Omnigraph to power your React components using `useOmnigraphQuery`. `enskit` comes with built-in type-safety, Omnigraph-specific cache directives, easy infinite pagination, and much much more. | ||
|
|
||
| <HostedInstanceSdkVersionWarning /> |
There was a problem hiding this comment.
@shrugs Good call! Suggest that we wait to merge this PR until we are able to promote the blue environment to production. Should be less than 24-hours now.
Could you please also take the lead for coordinating how we get @sevenzing's PR for adding resolutions merged and deployed in such a way to our blue environment that it can all work there when we activate blue tomorrow.
And then for making it so that we can have a PR-ready to merge as soon as we switch production to blue that will update our docs to:
- Align with the Omnigraph API that will be going live in the blue environment.
- Feature the super amazing addition of resolutions to the ENS Omnigraph API.
@sevenzing Can you and @shrugs Please coordinate on this? For example -- @sevenzing can you please share all the example queries you prepared for your demo today and share those with @shrugs as inspiration to support the docs updates he'll be making now? Thanks!
| const DomainByNameQuery = graphql( | ||
| ` | ||
| // this query is fully typechecked and supports editor autocomplete! | ||
| const DomainByNameQuery = graphql(` |
There was a problem hiding this comment.
Maybe also throw in a "hello world" resolution here too now that we're launching resolutions support?
| ); | ||
| })} | ||
| </ul> | ||
| <p>Name: {domain.canonical?.name.beautified ?? "Unnamed Domain"}</p> |
There was a problem hiding this comment.
Maybe add a comment here highlighting the benefit of getting back the beautified value?
| When ENSv2 launches in **Summer 2026**, the two protocol versions coexist — and the Omnigraph keeps your app working against both, at the same time, with no code changes. Both ENSv1 and ENSv2 Domains are indexed concurrently and exposed through a unified schema. | ||
|
|
||
| Addressing a Domain by name (`domain(by: { name: "vitalik.eth" })`) returns an ENSv2 Domain if the domain has been optionally upgraded by its owner to ENSv2, and returns an ENSv1 Domain otherwise. Set-returning queries (`domains(where: { name: ... })`) return both the ENSv1 and ENSv2 onchain representations of the same domain, unless explicitly filtered with `version: ENSv1` or `version: ENSv2`. | ||
| Ask for a Domain by name (`domain(by: { name: "vitalik.eth" })`) and you get a typed result whether that name lives in ENSv1 or ENSv2 — your code doesn't have to know or care which. |
There was a problem hiding this comment.
| Ask for a Domain by name (`domain(by: { name: "vitalik.eth" })`) and you get a typed result whether that name lives in ENSv1 or ENSv2 — your code doesn't have to know or care which. | |
| Ask for a Domain by name (`domain(by: { name: "vitalik.eth" })`) and you get a typed result whether that name lives in ENSv1 or ENSv2 — your code doesn't have to know which at query time. |
@shrugs My understanding is that devs building on the Omnigraph API will need to care if its ENSv1 or ENSv2 for some queries because don't they need to ensure their logic is fully prepared to handle both cases in the response?
Assuming so, suggest adding some special section about this key idea in the ENS Omnigraph Core Concepts. For example, ENSNode and the Omnigraph API do enable devs to make their apps fully ENSv2 ready even before ENSv2 launches, but to truly achieve that don't these devs need to prepare their apps to handle receiving responses back from the Omnigraph API for both ENSv1 and ENSv2 domains? Otherwise, when ENSv2 launches, if the developer integrated with the Omnigraph API with the assumption that all domains they get back would always be ENSv1 domains then their app will still break when ENSv2 launches because they didn't proactively prepare for getting back ENSv2 domains too. Right?
|
|
||
| A **Namegraph** is the native onchain data model of ENSv2: it represents names not as a flat mapping of namehashes in a Nametable (as in ENSv1), but as a graph of `Registry → Domain → Registry → Domain → …`. This graph may be cyclic, and within the ENSv2 protocol an unbounded number of _disjoint_ (not connected) Namegraphs will exist. Within the unified ENS protocol (v1+v2) there will exist many Namegraphs, at the very least those headed by the ENSv1 Root Registry, Basenames, Lineanames, 3DNS, and the ENSv2 Root Registry. | ||
| - **Multichain in one query** — mainnet `.eth`, Basenames (`.base.eth`), Lineanames (`.linea.eth`), and 3DNS names (`.box`) all in a single unified schema. | ||
| - **Typed, no footguns** — names and labels are normalized for you, so rendering them in a UI is trivial. |
There was a problem hiding this comment.
We can also feature footguns related to resolutions, including the complexities of the params for "raw" resolutions and parsing / validating / interpreting the results for "raw" resolutions.
|
|
||
| **Resolving Records** — If you're exclusively interested in resolving ENS names, you need to ensure that your `resolve` RPC calls go to the new `UniversalResolverV2` contract or risk stale and incorrect results being returned. Depending on your situation, this update may be handled simply by updating `viem` or `wagmi`, but for many apps building on indexed ENS data or with more advanced requirements, additional upgrade actions may be required. | ||
|
|
||
| For many, the simple solution for ENSv2 readiness will be to adopt the ENS Omnigraph API from ENSNode for all their ENS data needs (both ENSv1 and ENSv2). ENSNode also provides **[ENS Protocol Acceleration](/docs/integrate/omnigraph/protocol-acceleration)**, dramatically reducing resolution latency for most names people use. |
There was a problem hiding this comment.
@shrugs Suggest to keep the "... people use" qualifier here. That's because in theory most ENS names are offchain names. And these offchain names cannot currently be accelerated. Therefore for technical accuracy I added this qualifier.
We can note a few details here:
- There are offchain subname issuers who are claiming how they made millions upon millions of ENS subnames, but those names are created via nothing but an API call. Virtually all of them are never actually used. It's inflated metrics.
- We can note how all DNS names are theoretically ENS names too. These outnumber our onchain ENS names significantly, but these are currently rarely "used" in the context of ENS.
|
|
||
| import { CardGrid, LinkCard } from "@astrojs/starlight/components"; | ||
|
|
||
| The [ENS Omnigraph API](/docs/integrate/omnigraph) abstracts away most of ENS's protocol complexity, but a handful of concepts explain _how_ it presents ENSv1 and ENSv2 through a single unified schema. You don't need these to send your first query, only to understand how the Omnigraph represents the state of the ENS protocol. |
There was a problem hiding this comment.
| The [ENS Omnigraph API](/docs/integrate/omnigraph) abstracts away most of ENS's protocol complexity, but a handful of concepts explain _how_ it presents ENSv1 and ENSv2 through a single unified schema. You don't need these to send your first query, only to understand how the Omnigraph represents the state of the ENS protocol. | |
| The [ENS Omnigraph API](/docs/integrate/omnigraph) abstracts away most of the complexity of the ENS protocol. There are still some core concepts that are useful to learn. These concepts will help you understand _how_ the Omnigraph presents ENSv1 and ENSv2 through a single unified schema. You don't need to master these concepts to build your first Omnigraph query, but as you level-up to building more advanced ENS features in your app, these concepts will help you to understand how the Omnigraph represents the state of the ENS protocol. |
|
|
||
| ### InterpretedName with Encoded LabelHash Example | ||
|
|
||
| As noted above, an InterpretedName may contain Labels that are [Encoded LabelHashes](/docs/reference/terminology#encoded-labelhash), meaning that the human-readable Label isn't known or isn't normalizable. The Omnigraph still supports referencing Domains by these InterpretedNames, like so: |
There was a problem hiding this comment.
| As noted above, an InterpretedName may contain Labels that are [Encoded LabelHashes](/docs/reference/terminology#encoded-labelhash), meaning that the human-readable Label isn't known or isn't normalizable. The Omnigraph still supports referencing Domains by these InterpretedNames, like so: | |
| As noted above, an InterpretedName may contain Labels that are [Encoded LabelHashes](/docs/reference/terminology#encoded-labelhash), meaning that the human-readable Label isn't known or isn't normalized. The Omnigraph still supports referencing Domains by these InterpretedNames, like so: |
|
|
||
| ### BeautifiedNames and BeautifiedLabels | ||
|
|
||
| For some labels and names, there exists an [ENSIP-15](https://docs.ens.domains/ensip/15) beautified form, where certain normalized characters are 'beautified' into their _un-normalized_ but prettier forms. |
There was a problem hiding this comment.
| For some labels and names, there exists an [ENSIP-15](https://docs.ens.domains/ensip/15) beautified form, where certain normalized characters are 'beautified' into their _un-normalized_ but prettier forms. | |
| For some labels and names, there exists an [ENSIP-15](https://docs.ens.domains/ensip/15) beautified form, where certain normalized characters are 'beautified' into their _un-normalized_ but _normalizable_ prettier forms. |
|
|
||
| For some labels and names, there exists an [ENSIP-15](https://docs.ens.domains/ensip/15) beautified form, where certain normalized characters are 'beautified' into their _un-normalized_ but prettier forms. | ||
|
|
||
| For example, the InterpretedName `♾.eth` (normalized) would be beautified to `♾️.eth` (un-normalized). All name and label fields in the Omnigraph provide a `beautified` variant which can be used for display. |
There was a problem hiding this comment.
| For example, the InterpretedName `♾.eth` (normalized) would be beautified to `♾️.eth` (un-normalized). All name and label fields in the Omnigraph provide a `beautified` variant which can be used for display. | |
| For example, the InterpretedName `♾.eth` (normalized) would be beautified to `♾️.eth` (un-normalized, but is normalizable back to `♾.eth`). All name and label fields in the Omnigraph provide a `beautified` variant which can be used for display. |
