CraysGrimoire
Grimoire is a web-based Nostr protocol explorer by purrgrammer: a command-palette workspace where REQ queries become reusable spells, layouts become spellbooks and Nostr events become inspectable panels.
A client that behaves like a workbench
Grimoire belongs to the small class of Nostr apps that change your mental model of the protocol. It is not trying to be a friendlier Twitter clone. It is closer to a protocol workbench: a web app where profiles, events, relays, NIPs, zaps, chats, counts, raw JSON and arbitrary event feeds can live side by side in a tiled interface.
The public tagline says it is a Nostr client for magicians. That is cute, but the serious word in the name is not magic. It is method. A grimoire is a book of procedures. This app treats Nostr the same way. Instead of hiding the network behind one main feed, it asks you to write down little procedures for seeing the network: fetch kind 1 notes from these authors, count kind 9735 zap receipts on this relay, open this profile, inspect this event, browse this NIP, watch this hashtag, show this in compact mode, keep this stream open.
The README describes Grimoire as a Nostr protocol explorer and developer tool with a tiling window manager interface. That is the best plain sentence for it. Each window is a small Nostr app: a profile viewer, event feed, NIP viewer, event detail panel or other focused tool. The command palette, opened with a keyboard shortcut, behaves like a little shell for the network. You type commands. Grimoire turns them into panels. The workspace becomes your dashboard.
This matters because Nostr is not one app. It is a pile of event kinds, relay behaviors, address formats and social conventions. Normal users need polished clients. Builders and curious power users also need instruments. Grimoire is an instrument.
Spells are saved queries
The central idea is the spell. In Grimoire, a spell is a reusable Nostr query. The project even includes a draft NIP document for spells, proposing kind:777 events that encode relay query filters as portable, shareable Nostr events. The spell can store a REQ or COUNT command, a human-readable name, topic tags, target relays, relative timestamps and runtime variables.
That sounds abstract until you see an example. A command like req -k 9735 -a $contacts,$me is not just a clever line of text. It is a way to say: show me zap-related events involving my network. Another command might ask for recent kind 1 notes from contacts over the last day, events mentioning your pubkey, NIP-50 search results, addressable events by d tag, or compact rows for a busy relay. Grimoire's req parser supports kinds, authors, event IDs, address pointers, #e, #a, #p, uppercase #P, hashtags, d tags, arbitrary single-letter tags, relative time such as 7d, relay URLs, search terms, follow mode and compact view.
The runtime variables are the clever part. $me resolves to the active user's pubkey. $contacts resolves to the pubkeys in the active user's contact list. That means a shared spell can be personal without hard-coding the original author's identity. If I share a spell for "recent notes from my contacts", you should be able to run the same spell against your contacts. That is the difference between a screenshot of a dashboard and a portable dashboard recipe.
Grimoire also treats spell publishing as a real Nostr action. The publish-spell code builds kind 777 events, signs them with the active account's signer, optionally adds Grimoire's client tag and selects relays for publishing. Local spells are stored with Dexie-backed browser storage, and published spells are marked with their event IDs. This is not just UI poetry. The app tries to make queries themselves into Nostr objects.
Spellbooks turn layouts into objects
A spellbook is the next step up. If a spell is one reusable query, a spellbook is a whole workspace arrangement. The code uses kind:30777 for spellbook events. A spellbook can contain a title, description, slug, content and the layout state needed to recreate a set of panels. When published, Grimoire signs the event and sends it through the same account and relay machinery as other Nostr actions.
That is a subtle but powerful idea. Nostr clients usually let you share content: notes, articles, pictures, zaps, lists. Grimoire lets you share a way of looking. A person can build a dashboard for a subject, a hashtag, a protocol area, a set of people, a relay comparison, an event-kind family or a monitoring workflow. Then that dashboard can become a Nostr event itself.
The interface supports the idea with tiled windows and workspaces. The core state code creates workspaces, inserts windows into a Mosaic layout, moves windows between workspaces, applies layout presets, labels workspaces and tracks active accounts. The component list shows viewers for posts, profiles, relays, events, JSON, NIPs, kinds, counts, chats, Blossom content, wallet state and zaps. It is a small operating environment for Nostr data.
This is why Grimoire feels different from a feed. In a feed, the app decides the shape and you scroll. In Grimoire, the user decides the shape and the network fills it. That makes it harder to learn, but also more honest about what Nostr actually is: a queryable event network, not a single homepage.
The stack under the purple smoke
The implementation is a modern TypeScript web app. The README names React 19, TypeScript, Vite, TailwindCSS, Jotai, Dexie and Applesauce. The package file adds the details: Radix UI components, cmdk for command palette behavior, react-mosaic-component for the tiled window layout, react-router, react-virtuoso for long lists, Tiptap for rich editing pieces, Shiki and react-markdown for rendered documentation and code, FlexSearch, RxJS, nostr-focused Applesauce packages, Blossom client tooling, Nostr Wallet Connect support and media libraries for richer content.
The service layer confirms the ambition. There are modules for accounts, event stores, relay pools, relay selection, relay authentication, relay liveness, relay lists, spell storage, spellbook storage, publish services, Blossom server caches, profile search, emoji search and NWC. The command list goes far beyond req. It includes NIP browsing, kind browsing, manual pages, event opening, profile lookup, chat entry points, zaps, encoding and decoding Nostr bech32 values, and count queries using the relay COUNT verb.
Grimoire also reaches into many NIP-shaped corners. The command docs refer to NIP-05 identifier resolution, NIP-22 comments, NIP-29 relay-based groups, NIP-45 COUNT, NIP-50 search, NIP-53 live activity chat, NIP-57 zaps, NIP-65 relay selection and NIP-89-style handler territory elsewhere in the codebase. You do not need to memorize those numbers to use it, but the numbers explain the app's personality. It is built for people who want to poke the protocol directly.
The live website at grimoire.rocks is a static web app shell with a PWA manifest, custom theme color and bundled assets. That fits the product: no heavy server story is visible from the public app shell. The browser becomes the workstation; Nostr relays provide the data; local browser storage keeps your spells, spellbooks and working state.
What the archive banner means
The important caveat is visible on GitHub: purrgrammer/grimoire was archived by the owner on April 23, 2026 and is now read-only. The repository was created on December 10, 2025, pushed as recently as April 15, 2026, and GitHub still shows public interest around it, but archived means archived. The code is no longer an open issue-and-PR workspace in the normal way.
That changes how this page should talk about it. Grimoire is real. The website exists. The source is public. The MIT license is present. NostrApps lists it as a web app and highlights the spell/spellbook concept. Community traces, including a Stacker News discussion, show people experimenting with it and pointing to the same source repository. But we should not sell it to readers as if it were an actively maintained commercial product with support guarantees.
Read it as a working artifact and a design reference. If you want to depend on it every day, test the live app carefully, check whether your signer flow works, export or preserve anything important, and remember that a browser app can change or disappear even when the code remains readable. If you are building Nostr tooling, Grimoire is still highly valuable because the design ideas are portable: shareable queries, dashboard layouts as events, command-first navigation, NIP documentation inside the client and protocol objects made visible.
Who will actually enjoy it
Grimoire is for people who want Nostr to become an instrument panel. If you only want to follow friends and post notes, you may prefer a normal social client. If you have ever opened a relay inspector, copied an naddr, wondered what a kind number means, compared relays, tracked zaps, watched hashtags, debugged a client, built a bot or tried to understand why an event appears in one place and not another, Grimoire starts to feel natural.
The learning curve is not a defect. It is the price of the interface. The app asks you to think in commands: req, count, open, profile, chat, zap, encode, decode, nip, kind. Once that clicks, the app becomes less like a social feed and more like a Nostr terminal with a visual memory.
There is also a cultural point here. Nostr needs friendly clients, but it also needs strange clients. Strange clients discover what the protocol can do before mainstream clients make it comfortable. Grimoire's magic theme is playful, but the product question underneath is serious: what if users could publish not only posts, but also reusable ways to query and understand the network?
Why Grimoire belongs here
Grimoire deserves a place in the app shelf because it stretches the category. It is not just a content reader. It is not only a developer tool. It is a bridge between a Nostr client, a relay query console, a dashboard builder and a public recipe library for protocol exploration.
That is exactly the kind of app a Nostr atlas should preserve. Some projects will become polished products. Some will become abandoned prototypes. Some will survive as code ideas that other builders quietly absorb. Grimoire may sit anywhere on that spectrum, but the idea is strong enough to write down carefully: queries can be social objects, layouts can be shared, and a protocol client can be an exploratory workspace rather than a single feed.
If you open Grimoire, do it with the right expectation. Do not ask, "Is this the easiest Nostr client?" Ask, "What does this let me see that a normal client hides?" That is where it becomes useful. It gives you a way to turn Nostr from a stream into a set of windows. For some readers, that will be the first time the network feels truly inspectable.
Sources worth opening
These are the sources used to pin Grimoire down: live app, app directory listing, source repository, spell proposal and the code files that show how commands, spells, spellbooks and workspaces are wired.
- Grimoire live app
- purrgrammer/grimoire GitHub repository
- purrgrammer on GitHub
- NostrApps listing for Grimoire
- Grimoire README
- Grimoire package.json
- Grimoire draft NIP for spells
- Grimoire command man pages
- Grimoire command parser
- Grimoire REQ parser
- Grimoire publish spell action
- Grimoire publish spellbook action
- Grimoire spell storage
- Grimoire spellbook storage
- Grimoire workspace logic
- Grimoire relay selection service
- NIP-65 Relay List Metadata
- Stacker News discussion of Grimoire
- 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
