CraysMAKIMONO
MAKIMONO is for the moment when a note is too small. It gives you a Markdown editor, the fields a NIP-23 article needs, and a direct path from draft to a signed long-form Nostr event.
A writing room, not a publishing empire
MAKIMONO is easy to underestimate because it does not arrive dressed like a media platform. The official page is almost blunt: a title, a GitHub icon, a NIP-23 link, an identifier, title, summary, image field, editor area, preview and publish button. NostrApps calls it a barebones app for publishing long-form articles. That description is true, but it undersells the point. MAKIMONO is not trying to become your newsletter company, your CMS, your analytics suite or your writer brand. It is trying to turn a piece of Markdown into a real Nostr long-form event.
That makes it one of the cleanest app ideas in the Nostr shelf. When you write a normal short note, you are usually dealing with kind 1. When you write a longer essay, guide, announcement or blog post, NIP-23 gives you kind:30023: addressable long-form content with Markdown in the event content and article metadata in tags. MAKIMONO is the small room where those fields become visible. You do not have to remember the whole event shape by hand. The app puts the pieces in front of you.
The project is connected to the same Japanese builder trail as lumilumi. The official app links to TsukemonoGit/longFormEditor; GitHub shows a public TypeScript repository created in May 2025, with TsukemonoGit as the visible contributor. The README describes it as a lightweight long-form content editor with editing functionality for articles, NIP-19 embedding and custom emoji integration. There is also a small credit in Japanese for the icon, attributed to ikanoasi10.
One detail is worth being honest about: GitHub did not detect a license for the repository at the time this page was researched. The source is public and inspectable, but "public source" and "clearly licensed open source" are not the same sentence. For readers, that mainly matters if you want to reuse or fork code. For writers, the more immediate question is how it signs and publishes your article.
The shape of a NIP-23 article
NIP-23 is the standard MAKIMONO is built around. It defines kind:30023 as addressable long-form content, generally articles or blog posts. The content field is Markdown. Metadata such as title, summary, image, tags and first publication time can be added as event tags. The article is editable because the event includes a d tag identifier; newer versions with the same address can replace older ones when relays and clients handle addressable events correctly.
MAKIMONO maps that directly into the UI. The editor has an identifier, a title field, a summary field and an image URL field. When publishing, the code builds article tags for d, title, summary, image and published_at, then creates an event with kind: 30023. That sounds technical, but it is exactly the bridge a writer needs. You write prose; the app turns it into the event shape other Nostr software can find.
The identifier deserves special attention. A title can change. A summary can change. The article image can change. The identifier is the durable address part of the long-form event. If you are writing seriously, do not treat it like a random afterthought. Pick something stable enough to survive edits. The code uses the current timestamp as a default when no identifier is present, which is convenient for quick drafts, but a human-readable identifier is often better for work you expect to maintain.
Once an article exists, MAKIMONO derives an naddr from the identifier, kind and pubkey. That is important because naddr is the portable pointer to an addressable Nostr object. MAKIMONO also gives buttons to open the article in njump and in lumilumi. In other words, the page is not just a publish form. It is built around the idea that a finished article can move across the network.
The editor has protocol hands
The editor component is powered by Bytemd and CodeMirror, with GitHub-flavored Markdown support. That is the visible writing layer. Underneath it, MAKIMONO does a handful of Nostr-specific jobs that ordinary Markdown editors do not do. It processes Nostr references, custom emojis, hashtags and links before publishing. It adds the resulting tags to the event. It can mark content as sensitive with a content-warning tag, matching the NIP-36 idea of warning labels. It can attach app information through a NIP-89-style client tag.
The Nostr reference support is the feature that makes the editor feel native to this network. The README says the app supports embedding Nostr IDs via NIP-19, and the plugin code recognizes identifiers such as npub, nprofile, naddr, nevent and note. In the editor, there is an action for inserting a Nostr ID reference. In the viewer, those references are turned into richer Nostr reference components. For a writer, that means you can weave profiles, notes and articles into long-form text without flattening everything into plain external links.
Custom emoji support is another very Nostr-ish choice. In a normal publishing tool, emoji are just characters. On Nostr, custom emoji can be event-tagged resources, part of a culture that moves between clients. MAKIMONO pulls that into the writing flow rather than pretending long-form publishing has to be sober and isolated from the rest of the network.
The image story is also more ambitious than the NostrApps summary suggests. MAKIMONO includes a NIP-96 image upload plugin with server choices such as nostrcheck.me, nostr.build, void.cat, files.sovbit.host, nostpic.com and yabu.me. The plugin inserts Markdown image syntax after upload. That matters because long-form articles need cover images and inline images, but Nostr itself is not a file host. A writer still has to think about where media lives. MAKIMONO at least brings that problem into the editor rather than leaving you to copy URLs from somewhere else.
What the smallness does well
There is a good kind of smallness in MAKIMONO. The interface does not ask you to pick a publication template, configure monetization, design a landing page or join a platform audience. It asks for the information a NIP-23 article actually needs and gives you a Markdown writing surface. That makes the protocol visible in a way that can teach you while you use it.
The sidebar lists articles associated with the active user and lets you create a new one or load an existing one. Loading an existing article fills the editor from the event: content, title, summary, image, published_at and identifier. If the loaded article is not yours, the publish button becomes a not-authorized state. That is the right kind of friction. Nostr articles are signed by keys; editing should belong to the signing identity, not to whoever happens to open the page.
Deletion is handled as a Nostr event too. MAKIMONO builds a kind 5 deletion event with tags pointing to the article event and address. That does not magically erase every copy from every relay, and that deserves to be said plainly. Nostr deletion is a request that compliant software can honor, not a platform database delete. Still, it is better for the editor to expose the deletion path than to pretend long-form posts only move in one direction.
The success and failure messages also show the network reality. Publishing reports successful relays and failed relays. That little detail matters more than most users realize. On Nostr, "published" is not a single server transaction. It is a set of relay outcomes. A good publishing tool should make that visible enough that writers learn to care where their work actually landed.
The checks before you write seriously
MAKIMONO is promising precisely because it is narrow. But narrow tools deserve practical testing before you trust them with serious work. Use a signer you understand. Try a small article first. Publish it, copy the naddr, open it in njump, open it in lumilumi, then check whether another NIP-23-capable client can read it. Edit the article and see how old versions behave across your relays. Upload an image and ask where that file actually lives.
Pay attention to drafts. NIP-23 used to mention kind:30024 for encrypted drafts, but the NIP now points elsewhere for preferred draft handling. MAKIMONO's visible flow is publish-and-edit, not a full private drafting system. That is fine if you know it. It is risky if you assume every text you type is locally safe, encrypted, backed up and recoverable. Serious writing still deserves your own local copy until the workflow has proved itself.
Also watch the license question if you are a builder. The repo is public and small enough to read, which is excellent for trust. But because GitHub does not report a license, reuse terms are not as clear as they would be for a MIT-licensed project. That does not reduce MAKIMONO's usefulness as a writing tool. It only means readers should not lazily call it "open source" in the legal sense without checking.
The final judgment is simple: MAKIMONO is not a grand publishing system. It is a focused Nostr writing instrument. If you want to learn how long-form Nostr articles are shaped, or you want a direct editor for kind:30023 posts, it is worth opening. Its best quality is that it does not hide the network from you. It lets you see the address, the metadata, the signer, the relays and the handoff to other clients. For Nostr writing, that is not barebones in the weak sense. It is barebones in the useful sense: you can see the bones.
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.
- Official project
- NostrApps listing
- GitHub repository
- Project README
- Package file
- Editor component
- NIP-96 image upload plugin
- English UI labels
- NIP-23 long-form content
- NIP-19 bech32 entities
- NIP-36 sensitive content
- NIP-89 application handlers
- 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-44 versioned encryption
- NIP-46 remote signing
- NIP-51 lists and mute lists
- NIP-56 reporting
- NIP-57 lightning zaps
