CraysPrimal Studio
Primal Studio is not a prettier posting box. It is Primal's attempt to give serious Nostr publishers a desk: write, import, store media, schedule, review with a team and read the network back through analytics.
The CMS problem Nostr had to meet
Nostr began with a brutal little idea: keys sign events, relays move them, clients show them. That is enough to create a social network without a single king database. It is not enough to run a serious publishing room. The moment you move from "I posted a note" to "we publish essays every week, reuse media, schedule launches, import an old archive, review drafts and measure what landed", you are no longer asking for a client. You are asking for a content management system.
Primal Studio is Primal's answer to that problem. The official site introduces it as "a professional publishing suite for Nostr" for creators, teams and companies. That sentence matters because it places the product in a different drawer from Primal's main reader app. Primal is the feed, wallet, Reads surface and discovery client. Studio is the back office. It is where you prepare the thing before the network sees it.
This is an important category for Nostr. A protocol can let you publish without permission, but it does not automatically give you the boring professional comforts that make publishing sustainable. Someone still has to handle drafts. Someone still has to make image upload sane. Someone still has to show a writer how a long article will look on desktop and mobile. Someone still has to answer the editor who asks, at 23:40, whether tomorrow's piece is approved or still in review.
That is the useful way to read Studio. Not as a proof that Nostr has become mature overnight. Not as a magic replacement for every newsletter, blog or CMS. Read it as Primal building a serious creator desk on top of the network. If you only want to write a note and vanish, it may feel too heavy. If you have an archive, a publishing calendar or a team, the heaviness is the point.
There is also a tradeoff baked into the category. A CMS always adds a product layer. On Nostr, that product layer can be honest and useful, but it does not become protocol just because it publishes to protocol. Studio's strongest parts are the signed articles and notes, the Blossom media trail and the way it surfaces relay-published content. Its Primal-specific parts are the scheduler service, license checks, analytics index, team workflows and hosted media defaults. A grown-up reader can like the product and still keep those layers separate in their head.
The editor is the first promise
The first promise of Primal Studio is not a button. It is a calmer writing environment than a feed composer. The official page calls out professional-grade editors, rich formatting, a dedicated code view and real-time previews for desktop and mobile layouts. That is a very different promise from the normal Nostr client promise of "type, sign, broadcast." It says: you can prepare a real piece here and see what you are about to publish.
The public code supports that promise. The article editor uses TipTap, SolidJS and a Markdown transform rather than a plain textarea. The dependencies include TipTap extensions for bubble menus, code blocks, file handling, images, links, mentions, tables, table rows and underline. The editor also has Nostr-specific mention extensions for profiles, events and addressable articles: nprofile, nevent and naddr are not decorative details. They are how a writer can point at people, notes and long-form material without turning every reference into a dead paste of text.
For long-form work, Studio writes Nostr long-form content as kind 30023, the kind described by NIP-23. For ordinary notes, it writes kind 1. For drafts, the Studio code uses kind 31234. That means the article editor is not merely exporting HTML into a Primal database. It is preparing Nostr event shapes. The `sendArticle` path creates an event with `kind: Kind.LongForm`, the article content, tags and a `published_at` timestamp. The `sendNote` path creates a kind 1 event and tags it with `client`, `Primal Studio`.
The detail I like here is that the product seems to understand that writers need two modes at once. A writer wants the visual view because formatting by code is tiring. The same writer wants a code or Markdown view because serious publishing often needs exact control. Studio exposes both sides. That is not glamorous, but it is the sort of unglamorous feature that decides whether a tool becomes part of someone's weekly rhythm.
The note editor is also more than the little field you expect from a social app. It has rich/text modes, media uploads, user mentions, note mentions, article mentions, emoji history and scheduled publishing. It can attach images and video through the uploader. It can store an emergency draft locally while you work. It can turn references in the content into tags. That tells you Studio is not treating notes as a side feature. It treats notes and articles as two surfaces of the same creator operation.
Still, the writer's test is simple. Write a small article, publish it, then open it outside Studio. If another Nostr client that understands NIP-23 can read the event, you are looking at protocol value. If the article only feels alive inside Primal's own reading surfaces, you are looking at product value. Both can matter. You just want to know which one you are using.
Media is where ownership gets expensive
Text is cheap. Media is where the Nostr dream starts sweating. A relay can pass events around, but images, videos, audio and large files need storage, bandwidth, previews, metadata and failure handling. Every creator who says "I own my audience" eventually has to ask a less poetic question: where do the files actually live?
Primal Studio answers with a media library and Blossom. The official page says Studio lets you organize Nostr media uploads in one place, gives 100 GB of media storage on Primal's Blossom media server and lets you mirror content or manage any number of third-party Blossom servers. That is a serious feature. It means Studio is not simply asking you to paste image URLs from elsewhere. It is trying to make media storage part of the publishing workflow.
The code trail is specific. Studio has a default `primalBlossom` server at `https://blossom.primal.net`. It reads and updates the user's Blossom server list through a Nostr event kind 10063, with `server` tags. The relay API file has a `sendBlossomEvent` function that publishes a Blossom server list. The uploader uses `blossom-client-sdk`, creates upload authorization through a signed Nostr event, calculates the file's SHA-256 hash, sends `X-SHA-256`, `Authorization`, `Content-Type` and `X-Content-Length` headers, then tries the server's `media` or `upload` endpoint. It also has a mirroring path that takes additional Blossom servers from the account store and mirrors the blob.
That is much better than a vague promise of "decentralized media." It gives the creator a concrete object to inspect: the file URL, the hash, the primary server, the mirror servers and the event that advertises server preferences. Blossom is not a Nostr relay. It is a companion pattern for blobs, built around signed authorization and simple media server behavior. Studio's use of it shows how Nostr apps can avoid pretending that every image belongs inside a relay event.
Here is the practical caution. A 100 GB included media library is convenient because Primal is hosting a strong default. It is also a dependency. If your media is only on Primal's Blossom server, Primal is part of your publishing stack. If you add third-party Blossom servers and mirror files, the stack becomes more resilient. The reader should not moralize this. Hosted storage is useful. But if you are publishing work you care about, open the media settings, look at the server list and decide whether one server is enough for you.
The pricing page makes the media promise part of paid Studio, not a tiny free trial footnote. When checked, the Studio landing page showed Primal Pro at 69 USD per month, billed annually at 749 USD, with one user, Studio access, Legend status on Primal, 100 GB media storage and a 10 GB max file size. Primal Team showed 49 USD per user per month, billed annually at 2,695 USD for five users, with Studio, Legend status, 100 GB storage and 10 GB max file size for each user. Prices can change, so treat those numbers as a current product signal, not eternal protocol law.
Imports, scheduling and teams
The most revealing Studio feature may be importing. Primal's own feature language names this stretch of the product Content Imports, Smart Scheduling, Team Collaboration and Content Analytics. Primal's page says you can bring work from Substack, WordPress, Medium, Ghost or any RSS-enabled platform, and that imported content lands in a Primal Studio inbox ready to publish or refine. That is exactly the bridge Nostr needs if it wants established writers, not only early adopters. A creator with five years of essays does not want to start from a blank feed. They want a migration path.
The code has a settings list for `content_imports` and an `rss_feed_url` payload. It also has an inbox permission path, which matters for teams. Imports do not magically make old writing sovereign the moment you connect a feed. The useful moment comes when a piece is reviewed, turned into a Nostr event, signed and published. Studio's inbox language is therefore honest: it is a staging room. Your old archive comes in, then you decide what belongs on Nostr.
Scheduling is the next professional feature. The official site calls it Smart Scheduling and says you can create, sign and schedule content in advance while Primal's system handles the rest. The code has operations named `import_scheduled`, `replace_scheduled`, `get_scheduled` and `delete_scheduled`. For articles, `scheduleArticle` signs a long-form event with the future publish time, then sends it to Studio's scheduled import path. For notes, `scheduleNote` does the same with a kind 1 event.
This is one of those places where product convenience and protocol purity do not line up neatly. Relays do not wake up in the future and publish your content because you whispered a date at them. Some service has to remember the scheduled event and broadcast it later. Studio appears to make that comfortable: sign now, schedule now, let Primal handle the timing. That is useful. It is also a hosted promise. If scheduling is mission-critical for you, test it before you depend on it for a launch.
The team workflow is even more interesting because it changes who gets to sign. The public page says content creators can propose drafts while designated users review, sign and publish. In the code, `ReadsProposeDialog` literally says "Prepare the article and send to another Nostr user to publish under their name." `ReadsApproveDialog` parses proposed drafts, reviews the article, then either sends or schedules it. Draft paths use encryption through `encrypt44`, attach kind tags for long-form or text, and can include a recipient public key. In plain English: one person can prepare the work, another person can become the publisher of record.
That is not a small feature for companies, magazines, creator teams or projects with brand accounts. It means a junior contributor can prepare a post without holding the publishing key. It means a founder can approve a release without rewriting the whole thing in a chat window. It means an organization can have a Nostr presence without passing one private key around like a cursed office password. The human workflow is the actual product here.
The caution, again, is to understand where trust lives. If you are using team approval, ask who can draft, who can approve, who can sign, where drafts live and what happens when someone leaves the team. Nostr gives you cryptographic authorship at the event level. Studio gives you workflow around that authorship. Those are complementary, not identical.
Analytics are Primal's readable network
Analytics is where Primal's personality shows most clearly. The official Studio page says Primal indexes the full network to deliver engagement scores, sentiment analysis and sats zapped for every note and published item. That is very Primal: the company has always treated Nostr not only as a set of relays, but as a network that needs indexing, scoring, search and readable context.
Studio turns that into a creator dashboard. The home stats component tracks replies, reposts, reactions, bookmarks, quotes, mentions, zaps received, zaps sent and sats deltas. The event stats component shows zaps, sats, replies, likes, reposts, bookmarks, quotes, sentiment and a score. The Studio API file has operations such as `home_totals`, `home_graph`, `home_top_articles`, `home_top_notes`, `feed`, `feed_totals`, `scoring` and `media_files_usage`. That is not just a like counter bolted onto a post composer. It is an analytics product built around Primal's view of the network.
For creators, this can be genuinely useful. Nostr often feels wonderfully raw but also unreadable. Relays do not hand you a polished dashboard of what worked. Different clients may show different slices. Zaps are money-like signals, but a creator still needs to see them alongside replies, reposts and attention. Studio gives the publisher one surface where those signals sit together.
The important caveat is that analytics are an interpretation layer. Your signed note is a Nostr event. Your score is Primal's score. Your sentiment read is Primal's analysis. Your full-network engagement view depends on what Primal indexed, how it weighted the signals and how it resolves the messy reality of relays. That does not make it bad. It makes it a product. Treat it like you would treat good analytics anywhere else: useful, directional and never the same thing as reality itself.
This distinction matters because creators can become obedient to dashboards. If Studio tells you a post scored badly, do not let that be the only sentence in the room. Open replies. Look at who zapped. Look at whether the work reached the right small audience rather than the largest possible audience. Nostr's promise is not that every creator becomes a growth spreadsheet. Studio is best when it makes the network legible without replacing judgment.
The product trail and the stack
The public project trail is clear enough. Primal Studio lives at `studio.primal.net` and the public web client is in `PrimalHQ/primal-studio-web` on GitHub. The repository is MIT licensed, written mostly in TypeScript with SCSS, and its README is plain: "Web client for the Primal Studio." GitHub showed 267 commits on the repository page when checked. The repo was created in May 2025 and the public metadata showed it pushed in April 2026. That makes Studio a real Primal codebase, not just a landing page and a promise.
The stack is modern but not mysterious. The package is still named `vite-template-solid`, which is a funny little fossil of its starting point, but the dependencies tell the real story: Vite 6, SolidJS 1.9, TypeScript 5.7, Sass, Kobalte components, TipTap, `solid-tiptap`, `nostr-tools 2.10.4`, `blossom-client-sdk 4.0.0`, Chart.js, `solid-chartjs`, DOMPurify, IndexedDB through `idb`, UUIDs and a remark/rehype/unified toolchain for Markdown and HTML conversion. That is exactly the stack you would expect for a serious browser-based editor that has to write, transform, preview, sanitize, upload and graph.
The Nostr integration is also visible in the constants. The app defines kind 1 for text, kind 30023 for long-form, kind 31234 for drafts, kind 10063 for Blossom server lists, and Primal-specific high-number cache events for media info, uploads, Studio note stats, Studio media usage and license status. It also signs Studio cache operations before asking Primal's cache API for totals, graphs, feeds, settings, scheduled events and license state. In other words, Studio is a hybrid: Nostr events for publishable content, Primal cache operations for the heavy product layer.
That hybrid is the honest architecture of many serious Nostr products. Pure protocol gives you the public artifact. Product infrastructure gives you speed, search, dashboards, coordination, import pipelines and paid features. The question is not whether Primal Studio is pure. It is not. The question is whether the boundary is understandable and whether the output you care about can survive outside the product.
Who is behind it? Primal. More specifically, the public trail points to the PrimalHQ GitHub organization and Primal's own domains. This page should not invent extra mythology where the source trail does not require it. The relevant fact is that Studio belongs to the same product family as Primal, Primal Reads, Primal Wallet and Primal's broader indexed view of Nostr. That matters because Studio is not an independent neutral CMS that merely happens to publish Nostr events. It is Primal's creator layer.
What you should test before you build on it
If Primal Studio fits your life, you will know quickly. You have a writing schedule. You care about how articles look. You have media you reuse. You are tired of pasting images into random uploaders. You want to move old posts from a newsletter or blog. You want someone else to draft without giving them the publishing key. You want to know which articles brought replies, zaps and real attention. For that person, Studio is not overbuilt. It is finally the right size.
If you are only exploring Nostr, start elsewhere. Use a normal client, post a note, follow people, try a signer, make a zap, read a long-form post. Studio makes the most sense after Nostr has become a place where you publish intentionally. It is not the first rung of the ladder. It is the desk you buy when you already know you are going to sit down every week.
Before you build your workflow around it, run a small audit. Publish one short note and one short long-form article. Open both in another client. Look at the tags. Check whether the article appears as a kind 30023 event. Upload one image, then inspect the media URL and your Blossom server settings. Add a second Blossom server if you care about redundancy and confirm mirroring does what you expect. Schedule a harmless post for tomorrow and see exactly how it behaves. Invite a collaborator only after you understand who signs what.
Then look at the analytics with the right attitude. Use them to learn, not to become obedient. A small audience that responds deeply can matter more than a large number in a dashboard. Nostr is good at restoring strange, specific publics. A publisher's job is not only to maximize reach. It is to keep faith with the people who actually came to read.
That is why Primal Studio is one of the more consequential apps in this shelf. It does not merely ask whether Nostr can host another social feed. It asks whether Nostr can support professional publishing without giving up the signed, portable artifact underneath. The answer is not finished. Studio is one serious attempt at it: useful, Primal-shaped, technically legible, commercially hosted and worth testing with clear eyes.
Sources worth opening
This article stays close to the official page, the public Primal Studio web client and the protocol pieces the product relies on.
- Primal Studio official site
- Primal main site
- PrimalHQ/primal-studio-web repository
- Primal Studio package.json
- Landing page feature copy
- Primal Pro pricing card
- Primal Team pricing card
- Primal Studio event-kind constants
- Publishing, scheduling and draft API code
- Studio cache operations and analytics API code
- Account store and Blossom server handling
- Relay and Blossom server event publishing
- Blossom uploader component
- Upload utility and mirroring logic
- Article editor implementation
- Note editor implementation
- Article proposal workflow
- Article approval workflow
- Home analytics stats component
- Per-event stats component
- NIP-23 long-form content
- NIP-01 basic Nostr event model
- Blossom protocol repository
- NostrApps listing for Primal Studio
- NIP-25 reactions
