CraysLantern
Lantern is fiatjaf's Nostr annotation extension, forked from Hypothesis to publish highlights, bookmarks, page notes and PDF annotations as portable Nostr events.
A margin for the open web
Lantern is for the reader who wants to write in the margins without handing the margins to a platform. That sounds old-fashioned in the best way. You read an essay, a spec, a PDF, a forum post, a research paper. Something matters. You highlight it. You leave a note. Maybe someone else replies. The question is: where does that margin live after the page is closed?
In most annotation tools, the answer is a company database. Lantern tries a different answer. It is a browser extension that publishes page notes, annotations, bookmarks and highlights to Nostr. NostrApps describes it as a tool for collaboratively annotating, highlighting and bookmarking web pages and PDF documents on Nostr. The Chrome Web Store says the same thing, then adds the important technical trail: Lantern is a fork of Hypothesis, URLs are normalized, highlights follow NIP-84, replies and annotations follow NIP-22, relay-list publishing uses NIP-65, custom annotation groups use NIP-51 relay sets, and login can happen with either a pasted nsec or a NIP-46 bunker.
The project is associated with fiatjaf. The Chrome Web Store listing is offered by fiatjaf, and fiatjaf's own tools page lists Lantern as a web annotator and highlighter forked from hypothes.is, with links to installation and source code. As of the store listing checked for this work, Lantern was published as a Chrome extension, version 0.3.3, updated October 22, 2025, with source code pointed to `git.fiatjaf.com/lantern`. That source link now opens through GitWorkshop, a decentralized Git interface over Nostr, which is thematically perfect and a little inconvenient for old-school repository inspection.
Why Hypothesis matters here
The Hypothesis lineage is not a footnote. Hypothesis is one of the best-known social annotation systems on the web. Its pitch is simple: highlight and comment directly over web content, turn annotations into discussion and let readers collaborate over the text itself. It is especially common in education, where teachers want students to respond to a reading in the reading, not in a separate discussion board that feels detached from the sentence under debate.
Lantern borrows that interface idea and moves the storage question into Nostr. That matters because annotation is intimate. A highlight is not just a bookmark. It is a small record of attention. A margin note is not just a comment. It is a private or public trace of how you met an idea. If those traces are locked into one service, the reader's intellectual map is locked there too. If they become Nostr events, other clients can theoretically discover them, render them, reply to them, index them or move them into a different reading workflow.
There is also a cultural difference. Hypothesis is an annotation platform. Lantern wants to make annotation part of the open Nostr graph. That means your highlights can sit closer to your public identity, your relay choices and your broader network of notes. It also means the tool inherits all the usual Nostr mess: relays can differ, clients may not render every event kind, and discoverability depends on standards being implemented by more than one app. Lantern is valuable precisely because it pushes that problem into a concrete use case.
The event shape under the highlight
The most important Lantern feature is not that you can highlight text. Many tools can do that. The important part is what the highlight becomes. NIP-84 defines a highlight event, `kind:9802`, for content a user finds valuable. The content of the event is the highlighted text when text exists. It can tag the source with a URL, and the NIP explicitly encourages clients to clean obvious tracking junk from URLs. It can also carry context around the highlighted portion and attribution tags for original authors.
That maps neatly onto Lantern's promise. A highlight of an article can become a Nostr object with the selected quote, the source URL and enough surrounding context to be useful elsewhere. A quote highlight can behave more like a quote repost, avoiding the ugly pattern where a highlight and a separate note appear as two unrelated posts. This is the kind of detail that separates a real Nostr annotation tool from a browser extension that merely posts a link to your timeline.
NIP-22 is the other half of the margin. It is used for comments, replies and annotations. Lantern's store text says it follows NIP-22 for replies, annotations and page notes. That means the note you leave on the page is not just free-floating prose; it has a standard event shape that can point back to the thing being discussed. In a mature ecosystem, that would let a reader see conversations attached to a URL even when the conversation did not happen on the original website.
This is where Lantern becomes genuinely exciting. The ordinary web treats the page and the conversation as separate. The article lives here, the replies live in a comment system, the quote lives on a social network, the bookmark lives in a browser account, the classroom discussion lives in an LMS. Lantern tries to attach the reader's reaction to the object being read while still using open Nostr events. It is small, but the idea is large.
Login, relays and URL discipline
Lantern supports two login paths in the public description: pasted nsec or NIP-46 bunker. That choice deserves care. Pasting an nsec into any browser extension is a serious act. NIP-46 is more interesting because it lets a client talk to a remote signer or bunker instead of holding the key directly. For a tool that lives on arbitrary web pages and PDFs, a signer-aware path is the one experienced Nostr users will notice first.
The relay story is also deliberate. Lantern uses NIP-65 relay lists for publishing in the common case. NIP-65 is the relay-list metadata mechanism that lets an account state where it reads and writes. For custom groups of annotations, Lantern uses NIP-51 relay sets. That means the extension is not only publishing into a vague cloud of relays. It is trying to use the user's normal relay information when appropriate and separate relay groups when the annotation context calls for it.
URL normalization may sound like housekeeping, but for annotation it is survival. The same article can appear with tracking parameters, fragments, referral codes, uppercase/lowercase differences or alternate forms. If every reader annotates a slightly different URL, the shared margin fragments. The Chrome Web Store and NostrApps both call out URL normalization because it is one of the unglamorous requirements that makes collaborative annotation possible. A highlight has to know what page it belongs to.
The Chrome Web Store listing also states that the developer disclosed no data collection or use. That is useful, but it is not a substitute for judgment. Browser extensions can see powerful context depending on permissions and implementation. Lantern's job requires it to interact with web pages and PDFs. The right question is not only, "Does it collect data?" The right question is, "Do I understand what I am asking this extension to watch, sign and publish?"
Who should install it
Lantern is for people who read actively. If your Nostr life is mostly short posts and replies, you may not need it. If you spend time in specs, essays, documentation, PDFs, academic papers, legal texts, manuals, source pages or long posts, Lantern is exactly the kind of weird useful tool that makes Nostr feel bigger than a timeline.
It is especially interesting for research groups, teachers, open-source maintainers, protocol people and newsletter readers. Imagine a NIP discussion where highlights of the spec become public Nostr events. Imagine a reading group where everyone annotates the same essay without joining a private SaaS workspace. Imagine a project maintainer leaving notes on documentation that can be surfaced by a Nostr-aware client later. Lantern is not the whole answer, but it makes the shape visible.
The caution is interoperability. Lantern can publish according to the standards it names, but other clients have to care. A beautiful highlight event is more useful when clients render it well, relays keep it reachable and search/indexing tools know how to find it. That does not make Lantern weak. It makes it early. Annotation on Nostr is exactly the sort of feature that needs one stubborn implementation before the rest of the ecosystem notices what it is missing.
The best way to judge Lantern is to perform one real reading action. Install it, log in with a low-risk key or a NIP-46 signer, highlight a sentence on a page you care about, publish it, then see where the event can be found. Does the URL look clean? Does the highlight carry the right text? Can another Nostr tool understand it? If yes, you have not merely saved a quote. You have put a small lamp in the margin of the open web.
Sources worth opening
This article keeps claims close to the public project trail. Start with these pages when you want to verify the product yourself.
- Lantern on the Chrome Web Store
- NostrApps listing for Lantern
- fiatjaf tools page listing Lantern
- Lantern source code via git.fiatjaf.com
- Hypothesis social annotation background
- Hypothesis web annotation client source
- NIP-84 Highlights
- NIP-22 comments and annotations
- NIP-65 relay list metadata
- NIP-51 lists and relay sets
- NIP-46 remote signing
- NIP-25 reactions
- NIP-27 text note references
- Nostr protocol NIPs repository
- NIP-01 basic protocol flow
- NIP-05 DNS identifiers
- NIP-07 browser signer capability
- NIP-10 text note threading
- NIP-11 relay information document
- NIP-19 bech32 encoded entities
- NIP-44 versioned encryption
- NIP-56 reporting
- NIP-57 lightning zaps
- NIP-89 recommended application handlers
- NIP-94 file metadata
