NIP-LINK: Web-to-Nostr Entity Link

Abstract#

This NIP defines a standard mechanism for traditional HTTP web pages to advertise their corresponding Nostr entity (such as a NIP-23 long-form article or a standard note) using the standard HTML <link> element and NIP-21 URIs.

Motivation#

Many publishers maintain traditional web infrastructure (static site generators like Hugo, CMS platforms like WordPress, or traditional news portals) while simultaneously publishing content to the Nostr network.

Currently, a user visiting a traditional URL (e.g., [https://blog.example.com/my-article](https://blog.example.com/my-article)) has no automated way to know that the content they are reading is also a native Nostr event. By providing a standardized discovery mechanism, browser extensions, specialized web browsers, and Nostr clients can automatically detect the underlying Nostr entity.

This enables seamless bridges between the legacy web and Nostr, allowing tools to:

• Overlay Nostr comments directly on a legacy web page.
• Display a Zap button in the browser toolbar for the current article.
• Offer a "Read in Nostr Client" redirect.
• Quote the article using its nevent or naddr rather than a fragile HTTP URL.

Specification#

Web publishers MUST use the HTML <link> element located within the <head> of the HTML document to specify the corresponding Nostr entity.

Attributes#

1. rel: MUST include the value alternate.
2. href: MUST contain a valid NIP-21 URI representing the corresponding Nostr entity (e.g., nostr:<bech32-entity>).

• Typically, this will be an naddr (for parameterized replaceable events like NIP-23 articles) or an nevent / note.

Examples#

Example 1: Linking a web page to a Long-Form Content event (NIP-23)

<!DOCTYPE html>
<html>
<head>
    <title>My Awesome Article</title>
    <link rel="alternate" href="nostr:naddr1qqqqqq..." />
</head>
<body>...</body>
</html>

Example 2: Linking a web page to a standard Note

<!DOCTYPE html>
<html>
<head>
    <title>A quick thought</title>
    <link rel="alternate" href="nostr:nevent1qqqqqq..." />
</head>
<body>...</body>
</html>

Implementation Guidelines#

For Publishers (Static Site Generators & CMS)#

Publishers generating HTML from Nostr events should inject this tag programmatically. For platforms like Hugo or WordPress, plugins can be created to map the generated page's metadata to the NIP-21 URI and render the <link> tag in the header template.

For Consumers (Browser Extensions & Web Clients)#

Clients seeking to discover a Nostr entity for the current web page SHOULD parse the document <head> for a link tag matching the NIP-21 scheme.

A standard JavaScript implementation for discovery:

// Find the first link tag with rel="alternate" and a nostr: href
const linkTag = document.querySelector('link[rel~="alternate"][href^="nostr:"]');

if (linkTag) {
    const nostrUri = linkTag.getAttribute('href');
    const bech32 = nostrUri.replace('nostr:', '');
    
    // Proceed to decode the bech32 string and fetch the event/comments
    console.log("Found Nostr entity for this page:", bech32);
}

Note: The CSS selector rel~="alternate" correctly handles cases where multiple rel values are provided (e.g., rel="alternate nostr"), though only alternate is strictly required.

Security and Trust Considerations#

This mechanism establishes a one-way claim from the web page to the Nostr network.

Any webmaster can add a <link> tag pointing to any Nostr event, even ones they do not own (e.g., a scam blog pointing to a prominent developer's naddr to farm engagement).

Clients MUST NOT assume that the HTTP domain owns the Nostr event based solely on this HTML tag. If a client intends to display a verification badge or definitively link the author of the event to the domain, the client MUST verify the event's author against NIP-05 using the domain where the HTML is hosted, or rely on other cryptographic proofs natively embedded in the Nostr event itself (such as the r tag or NIP-39 external identity claims).

For the purposes of simply loading comments or allowing a user to Zap the content they are currently viewing, this one-way claim is generally sufficient and mirrors existing web syndication trust models.