Media

Highlighter

Highlighter is best read as a Nostr creator surface: part reads app, part writing studio, part highlight network, and part experiment in portable fan communities. Its strongest promise is exit-friendly publishing; its biggest caveats are signer safety, relay behavior and evolving subscription standards.

Media Publishing layer Articles, music, video, live events, reads, clips and media storage.

Media Articles Videos

Media26 min readNostr reads, creator studio, highlights and fan-community publishing around long-form content

Highlighter

The quick readHighlighter is not a generic browser highlighter, not a wallet and not a simple blogging template. It is a Nostr app around long-form reading, highlights, curation and creator/fan publishing. The public site exposes reads, highlights, curations, notifications, signup and a studio area. The repository describes a creator model built around NIP-29 relay-based groups and a recurring-subscription proposal that the README calls NIP-88, while today's canonical NIP-88 page is Polls, so that number must be treated carefully. The codebase uses SvelteKit, NDK, Nostr Tools, Tiptap, nostr-editor, Readability, Turndown and a Highlighter-flavored NDK workspace. Before relying on it for publishing, test long-form posting, drafts, relays, signer flow, imports, media uploads, group membership, zaps/subscription claims and account recovery with a low-risk key.

What Highlighter really is

Highlighter looks simple from the outside: a Nostr site where you can read, highlight and publish longer pieces. Underneath that simple surface is a more ambitious product idea. Highlighter is trying to be a creator/fan layer on Nostr, where long-form writing, highlights, curations, reader attention and creator memberships can travel through standards instead of living only inside one platform account.

That distinction matters for you as a reader or publisher. If you come looking for a browser marker that saves yellow lines on arbitrary websites, the name can mislead you. If you come from the Nostr long-form world, Highlighter is closer to Habla, Primal Reads, YakiHonne and other article clients, but with more emphasis on highlights, curation and creator communities. If you come from Patreon or Substack, it is not trying to recreate a closed subscription database first; it is trying to express creator relationships as Nostr events and relay-scoped groups.

The official repository states the premise unusually clearly. Highlighter should not lock creators into Highlighter, creators should have an exit strategy, and a creator should be able to self-host a Highlighter instance if the hosted service cannot or will not serve them. It also says users should be able to subscribe and consume content on any client that supports the same standards. That is a strong Nostr-native product thesis, not just a web app feature list.

The practical reality is messier, as it always is with young Nostr software. The public site has a reads surface, a highlights area, a curations area and a studio route. The repository has SvelteKit and NDK code, an older relay area, a communities-relay submodule, open issues about publishing and UI behavior, and a README that does not perfectly match the current app tree. The useful reading is therefore balanced: Highlighter is an important long-form and creator experiment, but you should test it like software that is still moving.

The public site surface

The live site at highlighter.com is the reader-facing entry point. A browser check on June 13, 2026 showed navigation for highlights, notifications, studio and signup, plus reads tabs for newest, top, highlighted and curations. The studio route did not open anonymous authoring; it asked the visitor to log in. That is the right first mental model: public reading and discovery are visible, while publishing and creator work live behind a Nostr login.

The reads surface gives Highlighter its media-shelf placement. It is meant for long-form Nostr material and the surrounding social actions that make long-form useful: discovery, attention, highlighting, curation and sharing. A reader is not just consuming a static blog. They are moving through events, authors, relays, highlights and references that other clients may also understand.

That portability is only as good as the event formats and relay availability. If an article is a valid NIP-23 event with useful metadata, other clients can find and render it. If a highlight is a valid NIP-84 event with useful source tags, other clients can reason about the highlight. If a curation or community depends on a relay-specific group policy, the portability story becomes more conditional. Highlighter sits exactly in that tension.

For a normal user, the immediate question is not whether every abstraction is perfect. The immediate question is whether Highlighter helps you read and publish valuable material with less lock-in than a closed platform. The answer is promising but not automatic. You should try it with content you can republish elsewhere, keep your own copy, and verify how the same article or highlight appears in another Nostr client.

Studio is the authoring side

The studio code tells you more than the landing copy. The current `apps/studio` package is a SvelteKit app using Svelte 5, Vite, NDK, NDK Svelte bindings, Dexie caching, nostr-tools, Tiptap, nostr-editor, Readability, Turndown, BlurHash, Unovis and several UI libraries. That stack is not a static marketing site. It is an editor and Nostr app surface with local cache, article events, drafts, imports and publishing checks.

The dashboard route subscribes to published articles, drafts, proposals, scheduled publishing events and deletion events. The visible tabs in the code include Published, Drafts, Proposed and Scheduled. That is an important difference from a tiny note client. Highlighter is trying to support the workflow around long-form material: not just typing a post, but saving, proposing, scheduling, publishing and managing prior work.

The article state code builds NDKArticle events with title, image, summary, tags, content and a `d` tag. Draft code uses NDKDraft and keeps checkpoints. Final checks block obvious publication mistakes such as missing relays, missing title, missing content and missing notes, and warn about missing summary or image. Those checks are ordinary, but they are exactly the ordinary pieces a real writer needs.

You should still treat the studio as a workflow to test, not a promise to trust blind. Open issues include reports about being unable to publish long-form content, buttons breaking while forming a draft, long-form gibberish, settings pages crashing and relay settings problems. Some reports may be old or environment-specific, but they match the risk area: writing tools can look fine until a long draft, a relay edge case or a browser state problem appears.

NIP-23 is the article base

NIP-23 is the main article standard in this story. It defines `kind:30023` as an addressable event for long-form text content, usually articles or blog posts. The content is Markdown, metadata can include title, image, summary and published_at tags, and the `d` tag gives the article an addressable identifier. A long-form client can then link to the article with NIP-19 `naddr` or an `a` tag.

That means a Highlighter article is not just a page in Highlighter's database if the event is published properly. It can be a Nostr event that another NIP-23-aware client may read, reference, reply to or render. This is the main reason Highlighter belongs beside other long-form Nostr projects rather than beside ordinary CMS tools. The public web UI is the surface; the Nostr event is the portable object.

NIP-23 also gives you a practical testing checklist. A good article should have a title, a summary, useful tags, a stable `d` value, a sensible published_at value and relay coverage that makes it discoverable. Edits create replaceable behavior, so clients need to avoid showing stale versions as if they were separate articles. If you publish through Highlighter, open the resulting article in another client and verify that the title, image, summary, tags and body survive.

The standard also says social clients centered on short `kind:1` notes should not be expected to implement NIP-23. That is a useful expectation reset. If a Highlighter article does not look good in every Nostr app, that is not automatically Highlighter's fault. Long-form content needs long-form clients. The portability target is not every timeline; it is clients that choose to support the article standard.

Highlights are a separate object

Highlighter's name points at NIP-84, the Highlights specification. NIP-84 defines `kind:9802` highlight events. The event content is the highlighted portion itself, and the event should tag the source of the highlight. For Nostr-native sources, that can be an `a` or `e` tag. For non-Nostr URLs, it can be an `r` tag. The spec also allows context and original-author tags.

That is a better model than treating highlights as private UI state inside one website. A highlight can become a social annotation: a small object that says this passage mattered, where it came from, who highlighted it, and perhaps what surrounding context matters. Other clients can index, display, quote or discuss it if they understand the same event kind.

Highlighter's value comes from combining those highlights with reading and curation. If you discover articles because people you trust highlighted the strongest lines, the app becomes a filter for long-form attention. That is different from a simple feed sorted by recency. It uses reader judgment as a discovery signal.

The open issue list shows why source tagging deserves scrutiny. One issue asks Highlighter to add URL or `r` tag references to highlights, saying a highlight could be created without a reference to the highlighted URL. Whether that specific behavior still applies everywhere is something to test, but the point is important. A highlight without a durable source reference is much less useful across clients.

Curation is part of the product

Curation is not just a sidebar word here. The Highlighter v2.0 announcement covered curations and zap splits, saying users could create curations of articles and earn zap splits for curation work. The live site also exposes a curations area. That suggests Highlighter sees readers as participants in distribution, not only as consumers.

This is one of the more interesting Nostr-native ideas in the project. Traditional publishing platforms usually reward the original creator, the platform or the advertiser. Nostr can also represent curators, referrers, highlight authors and communities as public actors. If the app can attach value flows to those social discovery paths, a reader who consistently surfaces good work can become part of the creator economy.

The hard part is not the slogan. The hard part is payment truth, event compatibility and user expectations. If a zap split is attached to a highlight, who receives what share? Is the split visible? Which event is being zapped? Does another client show the same context? Can the original author, the highlighter and the curator all be represented without confusing the payer?

For readers, curation should be judged by whether it improves discovery. For creators, it should be judged by whether it sends attention and value without locking the creator into Highlighter. For developers, it should be judged by whether the events are understandable outside one hosted UI.

Groups are the creator layer

The README says Highlighter relies heavily on NIP-29 for content distribution and grouping. It describes a creator signup or tier creation flow where a NIP-29 group is created and the group `h` tag matches the creator pubkey by publishing a `kind:9006` event. That is a specific technical claim and it changes how you should read the product. Creator tiers are not just a Stripe-like account table; they are meant to map to relay-based Nostr groups.

NIP-29 defines relay-based groups. A group identifier is scoped to a relay, and group membership, metadata, admins, roles and moderated event state are represented through events. Normal user-created group events include an `h` tag that identifies the group. The relay is not a passive pipe in this model. It owns important policy and state responsibilities for that group.

That gives Highlighter a path toward portable creator communities, but it also introduces relay dependency. If the group lives on a relay with specific moderation, membership or admin state, other clients need to know that relay and respect the group semantics. If a relay disappears, censors, forks state or fails to expose events consistently, the creator's membership layer can be disrupted.

This is why the repository's self-hosting premise matters. If Highlighter is serious about creator exit, the relay/group story has to be understandable and movable. A creator should know which relay hosts the group, which keys administer it, how members are represented, how paid access is checked, and what happens if the hosted service becomes unavailable.

The NIP-88 numbering caveat

Highlighter's README says NIP-88 provides the infrastructure for recurring subscriptions. That sentence needs careful handling in 2026 because the current public NIPs mirror at `nips.nostr.com/88` shows NIP-88 as Polls, not recurring subscriptions. There is also a `nip88` branch in the NIPs repository with a recurring-subscriptions draft. Highlighter appears to be referencing that older or branch-specific subscription proposal, not the current canonical NIP-88 page.

This is not a small editorial detail. Nostr moves through drafts, branches, merged specs and abandoned ideas. A product can implement or design around a proposal before the number settles. If you write that Highlighter uses current NIP-88 subscriptions without caveat, you will mislead readers who open the official NIP page and find Polls.

The recurring-subscriptions branch is still useful context. It describes tier events, subscribe and unsubscribe events, payment receipts, cadence, relay references, zap splits and verifier keys. That maps closely to Highlighter's creator/fan ambition. It also shows why the idea is difficult: recurring payments on Nostr need coordination among creator tiers, subscriber intent, payment verification, relays and wallet behavior.

For a publisher, the safe sentence is this: Highlighter has pursued recurring creator subscriptions using a Nostr proposal that has been called NIP-88 in its README and related materials, but the accepted or visible numbering around NIP-88 is ambiguous today. Test the actual Highlighter flow and the actual events it emits before assuming broad client compatibility.

Zaps and NWC are adjacent

Highlighter appears in Nostr and NWC ecosystem maps because creator publishing, zaps and recurring payments are part of the same product neighborhood. It should not be described as a wallet. It should also not be described as a general NWC app unless a current Highlighter wallet-connection flow is being verified directly. Its NWC relevance is more careful: Highlighter lives in the creator-payment ecosystem where NIP-57 zaps, wallet automation and subscription receipts matter.

NIP-57 defines zap requests and zap receipts. A client asks a recipient's Lightning endpoint for an invoice, pays it, and a zap receipt can be published as a Nostr event. For Highlighter, zaps can attach value to articles, highlights, curations or creators depending on the flow. That gives payment social context that a plain Lightning invoice does not carry.

The recurring-subscriptions branch also discusses automated payment situations where a subscriber may not be present to sign every zap request. That is where NWC becomes relevant conceptually. Nostr Wallet Connect can let an app talk to a Lightning wallet through Nostr relays with scoped capabilities. A future or adjacent subscription flow may need that kind of automation, budget control and wallet separation.

The reader-facing warning is simple: do not paste a high-value wallet or signer connection into any creator app casually. If Highlighter or a related flow asks for wallet authority, inspect the method permissions, budget, relay, revocation path and spending limits. If all you are doing is reading or highlighting, the app should not need broad payment authority.

Signer safety is central

Highlighter has to sign Nostr events for writing, highlighting, curating and possibly creator membership actions. That makes signer safety central. The login code path inspected for this article accepts `nsec1` private keys and `bunker://` signer URIs. The presence of a bunker path is good because remote signing can keep private keys away from the web app, but the raw nsec path remains a high-risk option.

NIP-46 exists because private keys should be exposed to as few systems as possible. A remote signer or bunker lets an app request signatures without receiving the underlying secret key. That does not make every prompt safe, but it changes the damage model. If the app is compromised, a remote signer can still ask for approval and enforce some boundaries; a pasted nsec can be copied outright.

There is also an open issue asking for Nostr Connect support, specifically mentioning a bunker-style flow. That does not necessarily contradict the code path that already recognizes `bunker://`; it suggests the UX or support story may not be complete for users who expect a polished NIP-46/Nostr Connect login. Treat it as an area to test.

The practical advice is blunt. Use a signer, extension, bunker or low-risk key when testing. Do not paste your main nsec into a site just to try an editor. If you must test a raw-key flow, create a fresh key, publish a disposable article, verify what events are emitted, and then move serious publishing to a safer signer path.

Relays are not a background detail

Highlighter's final publishing checks include a critical error for missing relays. That is not accidental. Long-form publishing, highlights, drafts, groups and subscriptions all depend on relays in different ways. If your relay list is empty or broken, the app cannot reliably publish or find your work.

NIP-23 articles need relays that store and serve addressable long-form events. Highlights need relays that accept and return `kind:9802`. Draft wraps need private relay handling if you rely on NIP-37 style draft storage. NIP-29 groups are even more relay-specific because the group identifier and state are scoped to the relay. A creator community can therefore be only as resilient as its relay choices.

A writer should test relay behavior before publishing important material. Publish a test article, wait, reload, open the article from another browser, open it in another client, query the event through a relay tool if you have one, and confirm that edits replace the prior version rather than creating confusing duplicates. For highlights, test whether the source tag survives and whether another client can follow it back to the article or URL.

Relay dependency is not a failure of Highlighter. It is part of Nostr. The product risk is whether Highlighter makes the dependency legible enough for creators. If a creator pays attention only to the web page and never learns which relays hold the group or article events, the exit strategy becomes theoretical.

Drafts and imports need privacy review

Highlighter's studio code includes draft support and an import flow. Drafts are essential for serious writing, but they deserve more caution than public posts because an unfinished article may contain private notes, quotes, names, links, publication dates or payment details. NIP-37 Draft Wraps defines encrypted draft storage by wrapping unsigned draft events and encrypting them to the signer pubkey with NIP-44. That is the kind of model readers should expect from Nostr-native drafts.

You should verify how a Highlighter draft behaves in your own browser. Is it local only? Is it published as an encrypted draft event? Which relays receive it? Can you restore it on another device? Can you delete it? Does a draft expose title, kind or other metadata even if the body is encrypted? Those details matter when the draft is sensitive.

The import flow inspected in code fetches existing web content through an AllOrigins proxy, then uses Mozilla Readability and Turndown to turn a page into article content. That can be convenient when moving old work into Nostr, but it has privacy and reliability tradeoffs. A third-party proxy can see the URL being requested, parsing can fail, paywalled or authenticated pages will not behave like normal browser pages, and imported formatting can be wrong.

For migration, keep your original files. Import one low-risk article first. Compare headings, quotes, links, images, footnotes and code blocks. Then check the resulting NIP-23 event in another client. The import button can save time, but it should not be your only copy of a piece of writing.

Repository maturity and self-hosting

The repository is public as `pablof7z/highlighter`, with the description `Highlighter.com repo`, topics for nostr, nip-29 and nip-88, and no SPDX license detected in GitHub metadata at the time checked. The README gives self-hosting-style instructions, including cloning with submodules, installing with pnpm, building with Turbo, configuring the web app and running a relay with a private relay identity.

The tree deserves careful reading. The README still describes `apps/web` as the web frontend and `apps/relay` as the NIP-29 relay. The current GitHub API view also shows `apps/studio`, `apps/web`, `apps/old-relay` and a `communities-relay` submodule. That mismatch is not unusual in an evolving monorepo, but it matters if you want to self-host or reuse code. The documentation and the current tree are not perfectly synchronized.

Self-hosting also depends on licensing and operations. If GitHub does not show a clear license, do not assume you can freely copy, modify or deploy the code for commercial use. Check the repository files and ask for clarification if the license remains absent. From an operations point of view, self-hosting a Highlighter-like instance means running the web app, managing environment variables, handling a relay or relay integration, maintaining keys, and keeping dependencies current.

For most readers, this is not a weekend static-site install. For a technically comfortable creator or small community, it could be a credible path if the docs are improved and the relay story is understood. The important thing is that Highlighter's own premise makes self-hosting part of the ethical design, so documentation quality is not a side issue.

Maintainer context

Highlighter is associated with Pablo Fernandez, also known as pablof7z, a major Nostr builder. His public site describes work on NDK, Wikifreedia, TENEX, Agora and other sovereign-technology projects, and lists several merged Nostr Implementation Possibilities including NIP-84 Highlights, NIP-89 Recommended Application Handlers, NIP-90 Data Vending Machines and NIP-60/61 Cashu wallet work. That matters because Highlighter is not an isolated toy from an unknown one-off account.

The strongest maintainer signal is not fame; it is protocol literacy. Highlighter's design keeps pointing back to NIPs, event kinds, relay groups, portable subscriptions and exit paths. The repository uses NDK heavily, and NDK is one of the more important developer kits in the current Nostr ecosystem. That gives the project a high-context foundation.

The caution is capacity. Builders who maintain many protocol projects also have many demands on their time. The open issue list includes user-facing problems that have sat open for months. A project can be architecturally sophisticated and still rough in daily UX. If you are choosing a publishing home, both facts matter.

So the maintainer context should increase your interest, not remove your due diligence. Test the actual product state on the day you plan to use it. Read the open issues. Watch the repository activity. Export your writing. Use safe signing. The best protocol intentions still have to survive ordinary product maintenance.

What to test before using it seriously

Start with a low-risk Nostr key and a small test article. Log in with the safest signer option available to you, preferably not by pasting your main nsec. Configure relays, publish a short article with title, summary, image and tags, then open it from Highlighter, another browser and another NIP-23 client. Confirm that edits behave like edits, not duplicate posts.

Test highlights next. Highlight a Nostr article and a normal web URL if the UI offers both paths. Check whether the highlight event includes a source reference that another client can follow. Try quoting, commenting or zapping the highlight if those actions are available. If a highlight cannot be traced back to the source, treat it as weaker social metadata.

Test drafts, imports and recovery. Create a draft, reload the browser, switch devices if possible, and see whether the draft appears. Import one public URL that you own or control, then compare formatting. Try image upload and removal. Read the browser console if a long draft stops responding. These are boring checks until they save a real essay.

Test the creator layer only with tiny stakes. If tiers, groups, subscriptions or zaps are involved, record which relays, keys, wallet paths and events are used. Confirm what the subscriber sees, what the creator receives, how membership changes, and whether another client can understand the same relationship. Until that works, treat the creator/fan layer as experimental.

When Highlighter is a good fit

Highlighter is a good fit if you want to read and publish long-form Nostr content with a stronger emphasis on highlights, curation and creator relationships than a simple article editor provides. It is especially interesting if you care about standards, exit rights and portable social reading.

It is also a good research target for builders. The project sits at the crossing of NIP-23 articles, NIP-84 highlights, NIP-29 groups, NIP-37 drafts, NIP-46 signing, NIP-57 zaps and recurring-subscription experiments. Even if you do not use Highlighter as your main editor, studying it can teach you how hard a serious Nostr media app has to work.

It is less suitable if you need a conservative publishing system today: guaranteed uptime, polished support, mature subscription billing, clear licensing for reuse, complete docs and predictable editor behavior for a team. For that job, a conventional CMS plus a Nostr publishing bridge may be safer, or another Nostr long-form client may be better depending on your tolerance for rough edges.

For readers, the best use is exploratory. Use Highlighter to discover thoughtful Nostr writing, follow highlights from people you trust, inspect curations and understand how long-form attention can work outside a closed platform. For creators, the best first use is a test article and a small audience experiment, not migrating your entire archive in one sitting.

The reader takeaway

Highlighter is one of the more conceptually important projects in the long-form Nostr shelf because it understands that publishing is not only writing. Publishing also includes discovery, annotations, drafts, source references, communities, payments, membership and an exit path. That is a rich product problem, and Highlighter is trying to solve it with Nostr-shaped pieces.

The article-level promise is clear: NIP-23 gives long-form posts a portable event shape. NIP-84 gives highlights their own social object. NIP-29 gives creator groups a relay-based membership model. NIP-57 and subscription experiments point toward direct creator value. NIP-46 and NIP-37 give safer signing and draft patterns when implemented well.

The caution is just as clear. Standards are evolving, the NIP-88 subscription reference is ambiguous, relay groups are operationally specific, raw nsec login should be avoided for serious keys, and open issues show rough product areas. Use Highlighter with curiosity, but keep copies, use safe signers, test relays and verify events in other clients.

If those checks pass for your use case, Highlighter can be more than another Nostr website. It can be a practical glimpse of a portable creator/fan web where readers, writers and curators are not trapped inside one platform's database. That is worth testing carefully.

Sources worth opening

Start with highlighter.com, the pablof7z/highlighter README and repository tree, the studio package and route code, the open issue list, the NIP-23, NIP-84, NIP-29, NIP-37, NIP-46, NIP-57 and current NIP-88 specs, plus the older recurring-subscriptions branch that Highlighter's README appears to reference.