CraysNostree
Nostree is a small, stubbornly useful Nostr app: make link lists, publish them as signed events, give them readable slugs, style your page and let another client inspect the proof behind the pretty button.
The personal page that does not belong to a platform
You already know the ordinary version of this product. A creator has too many places to point people: writing, video, store, podcast, donations, calendar, community, maybe a single post that matters this week. So they make one public page, put the links in order and use it as the front door to the rest of their work.
Nostree takes that familiar shape and moves the ownership line. A normal link-in-bio service gives you a neat page, but the page belongs to the service. Nostree asks a more interesting question: what if the list itself is a Nostr object, signed by your key, discoverable through relays and addressable from more than one URL style?
That is why the app is worth a serious page. NostrApps gives the short description, "List and link aggregator", and calls out create link lists, multiple lists and theming. Those words are correct, but too small. The real product is a presentation card for a Nostr identity. It lets you collect links, show them under your profile, edit or delete them, fork another person's list, group them by slug and hashtag, and share the result either as a readable page or as a Nostr address pointer.
No Bullshit Bitcoin caught the same idea early in the v0.1.2 release: Nostree was already described as a Linktree-style Nostr client for creating and managing lists of links, with the longer ambition of showing notes, articles and other public identity material. That phrase, "presentation card", is the right mental model. Nostree is not trying to replace Damus, Amethyst or Primal. It is trying to make the public front page of a Nostr person portable.
Who built it and why that matters
The public source trail points to gzuuus, whose GitHub profile lists the Nostr pubkey npub1gzuushllat7pet0ccv9yuhygvc8ldeyhrgxuwg744dn5khnpk3gs3ea5ds. NostrApps also attributes the app to that same npub, and the live project name in the repository is gzuuus/linktr-nostr. This is useful because it ties the app to a builder identity, a code repository and a Nostr identity rather than to a vague brand shell.
The repository was created on July 11, 2023. As checked on June 6, 2026, GitHub reports it as public, GPL-3.0 licensed, primarily Svelte, with TypeScript close behind, plus 53 stars, 9 forks and 9 open issues. The repo description says it is "A Nostr-based application to create, manage and discover link lists, show notes and other stuff." That is still the best one-line description, because it keeps the app in the social-publishing world instead of reducing it to a bookmark manager.
The README gives the philosophy in plainer terms: Nostree is free to use, the data is owned by you and the relays, and the data is signed by you. It says the app does not need email, phone numbers or personal data. It also says the project was founded by OpenSats and encourages pull requests and collaboration. You should read that as part of the product, not as decoration. In a Nostr app, funding model, license, signer behavior and relay assumptions are not side notes. They shape whether the tool feels like open infrastructure or another rented account.
There is also a small design story in the release history. The v0.1.5 release thanks OpenSats, Niel Liesmons, karnage and other people who gave feedback, sats or proposals. That matters because Nostree is the kind of tool where the interface can quietly make or break the whole promise. A link page is supposed to feel simple. Underneath it, Nostree is doing event construction, relay fetching, NIP-05 checks, signer negotiation, naddr links, slug routing and theme publishing. If that complexity leaks into the page too much, the page stops being useful.
The list is the event
The central technical fact is wonderfully concrete: Nostree's list kind is 30003. In the code it is named kindLinks. When you create a list, Nostree builds a Nostr event with tags for the title, description, a replaceable d identifier, the namespace me.nostree.ontology, the app label nostree, one or more slug labels, the actual links and any hashtags.
Each link becomes an r tag with the URL and the button label. That means the thing you see on the page, a clean stack of buttons, is backed by a small public data structure. The title is not a mystery field. The link label is not trapped in a private table. The slug is not magic. You can inspect it, copy the naddr, open it elsewhere and ask whether another Nostr-aware tool can understand the pieces.
The valid link prefixes tell you what Nostree thinks a link page can be. It accepts normal web URLs, but also nostr:, mailto:, tel:, magnet:, ssh://, irc:// and a few more. That is a very Nostr-flavored detail. A creator's front page is not only a marketing page. It can point to a note, a profile, a project, a mailing address, a file pointer, a chat channel, a torrent or a public resource.
When a rendered link starts with nostr:, Nostree sends it through https://njump.me. That is a sensible bridge for readers who do not have native Nostr URL handling set up. It keeps the link useful in an ordinary browser while preserving the Nostr reference underneath.
The app also has two sharing styles. A readable page can look like nostree.me/user/slug. A unique event address can go through the /a/ route using an encoded naddr. The v0.1.2 notes explain why both exist: slugs are memorable, while naddr links point to a specific addressable event. You use the slug when you want a human link. You use the naddr when you want the exact Nostr object.
Slugs, hashtags and being found
A link page without a memorable address is half a product. Nostree handles that by storing slug-like labels in l tags and by using valid NIP-05 identifiers when it can. The result is a friendlier page URL when the user's Nostr address can be verified, and a more mechanical npub route when it cannot. That distinction is worth noticing. Nostree is not only storing your links; it is negotiating how your identity should be presented to a normal human reader.
The code filters lists by #l and the nostree label. Other labels become visible list slugs. Hashtags are stored as t tags and exposed through list browsing and explore behavior. In practice, that lets one person maintain more than one public list: projects, writing, music, favorite relays, references for a workshop, a reading shelf, a merchant page, a small personal directory.
Forking is one of the more interesting touches. If you view somebody else's list while logged in, the app can treat your edit as a fork. It stores a pointer back to the original with p and a tags. That makes a link list behave less like a static profile page and more like a public object that can be copied, adapted and credited. For curators, educators and builders, that is a genuinely useful habit: take a good resource list, make your own version, keep the lineage visible.
Release v0.1.5 added templates, a better share modal and search improvements, including profile and hashtag search. Release v0.1.5.3 focused on NIP-51 compatibility, NDK updates, NDK-Svelte, local profile caching and the migration path for old lists. That release note is especially revealing: Nostree had to treat old list formats carefully, keep them readable and move users to a newer standard without pretending migrations are invisible. Good Nostr apps will have this problem again and again. Standards move, and real users keep old events.
Themes as public style
Theming can sound like surface polish until you look at how Nostree does it. The app ships with named themes, but the more interesting part is that a user's selected or custom theme can be published as a Nostr event. In code, the replaceable CSS asset uses kind 35393, a d identifier, the namespace nostree-theme, a theme label and CSS content.
That means the style of the page can also become part of the public Nostr-shaped identity layer. It is not just "pick a color in the app." The app can fetch a user's CSS asset, apply it to the page and remember the last selected theme locally. The v0.1.5 release describes the theme system as the headline change, alongside the migration to Tailwind CSS and Skeleton UI components. The package file backs that up: Nostree uses SvelteKit, Vite, Tailwind CSS, Skeleton, @nostr-dev-kit/ndk, @nostr-dev-kit/ndk-svelte, nostr-tools, Dexie, markdown/link parsing helpers and QR generation.
That stack says a lot about the project. It is not a static HTML toy, and it is not a giant social client either. It is a SvelteKit app with a Nostr data model, local caching, signer support and enough UI system work to make small public pages feel intentional. For readers, the result should feel ordinary: a page, a profile, a stack of links. For builders, the interesting part is how much of that ordinariness is constructed from signed events.
Signing without handing over the key
Nostree gives you two main login paths. The first is a NIP-07 browser extension. That is the familiar Nostr web pattern: the site asks a signer to sign events, and the private key stays in the signer rather than inside the app. The second path is Nostr address or connection string login through NIP-46 remote signing. The code handles NIP-05 addresses, bunker-style connection strings and a special relay case for @nsec.app.
Nsec.app's own guide confirms that flow in user terms: copy your name@nsec.app username, choose login with Nostr address in Nostree, paste it, then confirm the connection in the Nsec.app popup. That is exactly the kind of signer path a web app should support if it wants people to publish without casually pasting private keys into forms.
The default relay set is also visible in the provider code: wss://purplepag.es, wss://relay.damus.io, wss://relay.nostr.net and wss://nos.lol, with outbox behavior enabled through purplepag.es. This matters because a link page is only as portable as the event discovery behind it. If your list publishes cleanly but nobody can find it, the page has failed in a boring way.
There is one detail you should watch with clear eyes: Nostree can remember login state locally and stores a local signer value for the NIP-46 flow. That is not automatically bad; NIP-46 needs a local key pair to authenticate the remote signer relationship. But it is exactly the sort of behavior a serious user should understand. The right question is not "is there local storage?" The right question is what is stored, what can sign, what can be revoked and whether your remote signer shows you the events before approval.
How I would test it
If you want to know whether Nostree belongs in your own workflow, do not start with the brand promise. Start with one throwaway list. Use a signer, publish three links and include at least one nostr: reference, one ordinary web link and one tag that would make sense to another person. Then open the page from a second browser where you are not logged in.
Next, copy both forms of the address: the readable slug page and the naddr link. Open the naddr through a neutral Nostr viewer such as njump. Check whether the title, links, tags and author line still make sense when Nostree is no longer the only interface in front of you. That is the whole point of using Nostr for this object.
Then test the uncomfortable cases. Change a slug. Edit a link. Fork your own list from another account. Publish a theme. Log out and come back. Try the Nsec.app path if you use remote signing. If you care about permanence, inspect which relays received the event and whether your other clients can find it. Nostree is strongest when it turns the link page into a portable public record. The test is whether that record remains legible outside the first pretty screen.
My honest read: Nostree is one of those small apps that explains Nostr better than a diagram does. It takes a thing everyone understands, the personal link page, and shows what changes when the page is signed, addressable, forkable, themable and attached to a key. You do not have to use it for every profile. But if you build for creators, communities, venues, writers, musicians or open-source projects, Nostree is a good reminder that the boring front door of a person's web presence can be protocol-shaped too.
Sources worth opening
This article keeps claims close to the public project trail, source code and release history. Start here when you want to verify the details yourself.
- Nostree official site
- NostrApps listing for Nostree
- gzuuus/linktr-nostr GitHub repository
- Nostree README
- Nostree package.json
- Nostree signer and relay provider code
- Nostree list creation component
- Nostree helper functions and tag parsing
- Nostree event rendering and fork behavior
- Nostree theme publishing component
- Nostree v0.1.6 release
- Nostree v0.1.5.3 release
- Nostree v0.1.5 release
- No Bullshit Bitcoin on Nostree v0.1.2
- SvelteThemes mirror of Linktr Nostr
- Nsec.app guide for Nostree login
- gzuuus on GitHub
- NIP-51 lists
- 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
