How to Schedule Nostr Posts: Why the Protocol Can't Do It and What Actually Works

Short answer: no, Nostr does not have a scheduled-publish button anywhere in the protocol, and there is no company you could email to request one. Long answer: that is not an oversight, it is the entire design, and once you see why, scheduling Nostr notes stops being confusing and turns into a fairly simple mechanical problem.

What makes Nostr different (events, relays, keys)

Every other platform in this series has a company behind it: a server that owns your account, checks your password, and stores your posts. Nostr has none of that.

Your identity is a keypair. The public half (your npub) is your identity everywhere on the network. The private half (your nsec) is the only thing that proves a note came from you, and there is no password reset, no support ticket, and no "forgot my account" flow if you lose it.

A post is called a note, and a note is really just a signed JSON object called an event. Per NIP-01, the spec that defines the base protocol, an event's content field is an arbitrary string. There is no character limit written into the protocol itself. Clients impose their own soft limits for display, but the wire format does not care if your note is 20 characters or 20,000.

Signing uses secp256k1 Schnorr signatures, the same curve family as Bitcoin. There is no OAuth, no client secret, no API key you request from a developer portal. You sign locally with your private key, and any relay or client can verify the signature came from your public key without ever seeing the private one.

Once a note is signed, you send it as ["EVENT", <signed-event>] over a plain WebSocket connection to whichever relays you choose. A relay is just a server that stores events and forwards them to anyone who asks. There is no single central API endpoint for "Nostr." Your note only exists on the relays you pushed it to, and only for as long as those relays choose to keep it.

Why native scheduling can't exist at protocol level

Scheduling requires something to hold your draft, wake up at the right time, and publish it on your behalf. On every centralized platform, that something is the platform's own server, because the server already owns your session and your content.

Nostr has no equivalent. There is no account server sitting between you and the network. Your client (whatever app you're using to read and write notes) is not running a background job for you when it's closed, and no relay is authorized to generate a signature on your behalf, because a relay only stores and rebroadcasts events, it never holds your key.

This is genuinely an open question at the protocol level. Nostr Implementation Possibilities (NIPs) are the community's spec proposals, and there is a long-running discussion, NIPs issue #587, about whether scheduling deserves a standard event type at all. Nothing has been ratified. Until it is, scheduling a note is entirely the responsibility of whatever client-side tool you choose, not the protocol.

What you need

• Your keypair, or more safely, a signer that holds it for you (more on this below).
• A signing method: a browser extension implementing NIP-07, or a remote signer implementing NIP-46.
• A list of relays you actually publish to. Most people use somewhere between three and eight.
• Something that stays online at the moment you want a note to go out, since your own laptop being closed at 9am does not stop the clock.

That last point is the whole problem scheduling has to solve, and it's worth being precise about it.

The safe way to let a tool post for you (NIP-07 / NIP-46, never paste your nsec)

If you search for "Nostr scheduler," you will eventually find a tool that just asks you to paste your nsec into a text box. Do not do this. There is no revocation mechanism for a Nostr private key the way there is for an OAuth token. If a private key leaks, every note ever signed by that key is permanently and unfixably attributable to it, and there is no way to rotate it without abandoning your identity and rebuilding your follower graph from zero.

The protocol gives you two better patterns:

NIP-07 is for browser-based signing. A browser extension (Alby and nos2x are the common ones) holds your key. Any web app calls window.nostr.signEvent(event), the extension pops up a confirmation, and the raw key never leaves the extension's storage. The web app only ever sees a finished, signed event.

NIP-46, sometimes called "remote signing" or "bunker," goes further. Your key lives on a separate signer app, often on your phone, and never touches the device or service doing the scheduling at all. The scheduler sends a signing request over an encrypted relay-based channel, your signer approves it, and only the signed event comes back. This is the pattern any tool that publishes on a delay should be built on, because it means the tool itself is never holding something that can impersonate you forever.

Scheduling workflow with an always-online publisher (the TimeToPost model)

Here is the part that trips people up: you cannot just pre-sign a note for tomorrow and let it sit. A signed event's timestamp is part of what got signed, and relays are free to reject events whose created_at looks stale or implausibly far in the future when they finally receive it. So the "sign it now, fire it later" approach doesn't hold up cleanly across a real delay window.

What actually works is holding the draft, not a pre-signed event, and doing the signing at the moment of publish. That's the model we use in TimeToPost's calendar: you write the note and set the time like you would for any other platform, and at the scheduled minute, an always-online publisher requests a signature through your connected NIP-46 signer and pushes the resulting event to your chosen relay set over the same ["EVENT", ...] frame any client would use. Nothing about the note differs from one you'd have posted by hand, it's just fired by a service that doesn't sleep instead of a laptop that does.

Because this only requires a signer connection and a relay list, it sits fine alongside the rest of a posting calendar. If you're already mapping out send times across other platforms, our best-time-to-post breakdown is worth a read before you lock in a Nostr cadence, since a federated, algorithm-free timeline behaves differently from a ranked feed.

Limits: none in protocol, per-relay rate limits

The honest answer here is that Nostr's protocol-level limits are close to nonexistent, and the real limits come entirely from the relays you use:

• Character count: none, per NIP-01. content is an arbitrary string. Whatever cap you hit will be a client's display choice or a specific relay's storage policy, not a network-wide rule.
• Posting frequency: not defined in the base protocol at all. There is no equivalent of "250 posts per 24 hours."
• Relay-level rate limiting: optional and relay-operated. A relay that wants to throttle you will typically reject your event and return a message starting with the "rate-limited:" prefix, a convention documented in NIP-01's command results, but whether any given relay enforces this, and how aggressively, is entirely up to that relay's operator.

In practice this means your effective limits are whatever the specific relays in your list decide, which is one more reason to publish to more than one relay rather than relying on a single point of failure.

FAQ

Is there a character limit on Nostr notes? No, not in the protocol. NIP-01 defines content as an arbitrary string with no length field. Any limit you hit comes from a specific client's UI or a specific relay's own policy, not from Nostr itself.

Is it safe to give a scheduler my private key? Not your raw nsec, no. The safe pattern is NIP-46 remote signing, where your key stays on a separate signer and the scheduler only ever receives a finished, signed event back. Never use a tool that asks you to paste your private key into a form.

Which relays should I publish to? There's no official list, and the brief has to hedge here: relay reliability and rate-limiting policy vary operator to operator, so most active users publish to a handful of relays at once (commonly cited as three to eight) rather than trusting any single one to stay up.

Can I schedule images or video? A Nostr note's content is text. Media isn't uploaded to a relay the way it would be to Instagram or TikTok, it's hosted externally and referenced by URL inside the note. Scheduling that note works the same way as scheduling a text-only one, since the signing and publishing mechanics don't change based on what the text links to.

If you're running a posting calendar across platforms that do offer native or API scheduling, TimeToPost's scheduler can hold your Nostr drafts on the same calendar as everything else, even while the underlying publish step stays protocol-native and signer-controlled the whole way through.