Nostr posts, signed in-house.
A publisher that owns its own signatures.
Nostr is the one network in this family where the interesting part is cryptography rather than product surface. An event is not accepted because you authenticated; it is accepted because it carries a valid signature over its own contents. That makes the question “who signs?” the whole question. Bloom answers it by signing in-house: BIP-340 Schnorr signatures produced inside Bloom and verified three separate ways against the official test vectors, then published over Bloom’s own WebSocket connection rather than handed to an external signing service to do on your behalf.
No third-party signer
The common shortcut is to delegate signing to somebody else’s service. Bloom does not: the signature is produced in-house, which means your key is not circulating through an intermediary whose logging, retention and incident history you cannot inspect. For a protocol where the key is the identity, that is the difference between publishing and lending out your name.
Verified three ways, deliberately
A signing implementation that is wrong is worse than one that is missing, because it fails silently and publicly. Bloom’s BIP-340 implementation is checked three separate ways against the official test vectors, so the correctness claim rests on the specification’s own fixtures rather than on the code having been read carefully.
Two thousand characters, and no thread.
Bloom enforces a 2,000-character ceiling on Nostr. That is nearly seven times what Bluesky allows and four times Mastodon, but well under the 5,000 that Lemmy, Mbin, dev.to and Tumblr accept. It puts Nostr in the middle of the range, which in practice means a Nostr post is long enough to be a complete thought and short enough that a genuinely long piece belongs somewhere else and should link back.
Native threading exists on three of Bloom’s eighteen networks — Bluesky, Mastodon and Telegram — and Nostr is not one of them, so Bloom does not offer a Nostr thread it cannot publish as a real chain. Carousels are available on two networks and Nostr is not one of those either. Both absences are declared at compose time rather than discovered at the slot, which is the same rule that governs every other shape: a false success is the worst failure mode available to a publishing tool. The eighteen-row limit table is on the coverage page.
A pasted credential, kept encrypted.
Nostr is one of the nine Bloom networks linked with a credential you paste rather than an OAuth redirect — there is no OAuth provider to redirect to on this protocol at all. Bloom stores what you give it under AES-256-GCM with a scrypt-derived key, and uses it to sign events at publish time inside Bloom rather than forwarding it anywhere.
Key custody is the product question
On most networks the credential is a revocable token issued by a company. On Nostr it is the identity itself, which raises the stakes of every design decision around it. Bloom signs in-house and encrypts at rest; those two facts are the entire answer, and they are stated rather than implied.
Roles still gate the connection
Five workspace roles are checked against eight actions, and connecting an account is one of them. An editor can draft Nostr events without holding the credential that signs them — which is the separation that makes a shared workspace tolerable on a protocol with no revocation story.
Its own throughput budget
The rate governor is per connected account, with a maxPerDay ceiling and a minIntervalMinutes gap. Relays vary in what they tolerate, so a Nostr account’s budget is set independently of every other account in the workspace.
Nostr publishes. It does not report.
This is the part most tools would leave out. Bloom reads engagement from ten of its eighteen networks and Nostr is not among them, because engagement on Nostr requires maintaining relay subscriptions rather than making a request — a fundamentally different shape of work from polling an API. Nostr also returns no conversations: it is one of eleven networks for which Bloom registers no inbox source at all. Neither gap is shown as a zero, because a zero looks like failure and this is absence.
There is a practical consequence worth planning around. Because Nostr posts are not sampled, they contribute nothing to the twenty-four-arm learner that shapes later plans, and they will not appear in an engagement comparison next to Mastodon or Bluesky. What Nostr posts can still carry is a Bloom short link — an eight-character code from a 32-character ambiguity-free alphabet, with per-platform UTM parameters — so clicks, conversions and leads from a Nostr post remain attributable even though likes and replies are not.
Scheduling a protocol with no undo.
Nostr events propagate across relays and there is no support queue to call. That makes the guards in front of publishing more important here than almost anywhere else: the thing you most want is not to publish twice, not to publish late, and not to publish forty times at once after an outage.
A 30-day duplicate window
The same content will not be published to the same Nostr account twice inside 30 days, so re-running a plan or importing an idea a second time does not put a near-duplicate event on relays that will keep both.
Stale posts are skipped
Anything more than 24 hours past its slot is skipped rather than published late, and catch-up is capped at ten posts per five-minute tick. Lateness is treated as a failure state, not an inconvenience to be worked through.
Five attempts, then a visible failure
If a publish fails, Bloom retries up to five times with backoff doubling from 60 seconds — one, two, four and eight minutes in practice — then stops and reports it. A stuck publish is reclaimed by a reaper after 15 minutes.
Nostr inside a wider schedule.
Almost nobody posts only to Nostr, and nothing about Bloom asks you to. The same idea can go out at 2,000 characters here, 3,000 on Misskey and 300 on Bluesky, from one compose box and one weekly queue. For the full eighteen-network picture see the coverage matrix; for how the plan-to-lead loop closes, see the Bloom overview.
Nostr questions, answered plainly.
Can Bloom schedule Nostr posts?
Who signs a Nostr event published by Bloom?
Does Bloom read Nostr engagement?
What is Bloom's Nostr character limit?
Can I still attribute leads from a Nostr post?
Publish to Nostr on a schedule.
Bloom runs on its own application and its own sign-in — an Autocloz account is not required. Connect a Nostr key, write once, and let the queue publish signed NIP-01 events alongside the other seventeen networks.