Editorial process

Why we publish this#

The IPFS.NINJA blog exists to help developers make sound content-addressed-storage decisions — which pinning service to use, when a dedicated gateway is worth it, how NFT metadata should actually be pinned, and so on. Every one of those decisions has real cost and lock-in implications. So we take the accuracy of what we publish seriously, and we think you should know exactly how the content on this blog is made.

What sets our content apart#

• Product-verified. Every code sample, API call, and pricing figure is checked against the live IPFS.NINJA platform at draft time. If a claim is untestable against production, it doesn’t ship.
• Written by operators, not marketers. The person reviewing each post also runs the platform day to day, fields the support tickets, and reads the operational signals it emits.
• Comparisons are honest. When we write “IPFS.NINJA vs. Pinata / Filebase / Web3.Storage” we cite their public docs and pricing pages verbatim. Nothing is strawmanned. If they’ve shipped something we haven’t, we say so.
• AI-assisted, human-owned. A named human approves every article before it publishes. AI helps with scale; human judgment gates the ship.

How each article gets made#

1. Brief creation#

Every article starts from a real signal — a support ticket pattern, a Search Console query cluster, or a customer integration question. The brief captures the audience, the promise the article makes, and the search intent it targets.

2. Research + product verification#

We read the primary sources for any claim: the IPFS spec, the go-ipfs / kubo docs, competitors’ current pricing and API docs. Every code snippet is run against the live IPFS.NINJA platform. If something doesn’t work as documented, we file it as a product bug before we ship the article.

3. Drafting#

Most drafts are produced with AI assistance under a content-generation prompt that carries the article brief, the verified facts from step 2, and our voice guide. Drafts land in the repo as a .md file with full frontmatter, ready for review — no marketing template, no separate CMS.

4. Human review#

A named reviewer reads every draft end-to-end. Their job is to catch:

• Any claim that isn’t supported by the primary sources or doesn’t reproduce against the live product
• Comparisons that overstate our position or misrepresent a competitor’s current offering
• Advice that would cost the reader real money if they took it — pricing math, plan selection, migration paths
• Copy that reads like marketing rather than practical engineering

5. Refinement + final read#

The reviewer’s flags come back as revisions, applied by AI against the original draft plus the reviewer’s specific feedback. The reviewer then reads the revision to confirm every flag was addressed — not just acknowledged.

6. Localization#

We translate every ship-ready article into 40 additional locales. Each translation preserves the technical accuracy of the original — code samples aren’t rewritten, only prose is localized. The English article is always canonical; if a translated variant disagrees with English, English wins.

7. Publication + AI disclosure#

Every published article carries a visible AI-content disclosure (bottom of every post) explaining that the article was AI-assisted and human-reviewed. This is a Google helpful-content signal and a promise to the reader that the provenance of what you’re reading is not hidden.

Keeping content fresh#

IPFS and its ecosystem move quickly. Prices change. APIs get deprecated. Best practices evolve. Content that was accurate when it shipped can become misleading a year later.

We run an automated SEO and freshness tracker over the whole corpus every week. It pulls Search Console signals, does a per-page on-page audit, and identifies posts that are ranking for outdated queries or referencing deprecated APIs. The result becomes a work-list of concrete edits — mostly mechanical (fix an outdated price, replace a deprecated endpoint), some human-judged (whether an article needs a substantive rewrite vs. retirement).

Every post carries an Updated: date in the hero, distinct from its original publish date, so you know how fresh the content in front of you actually is.

Our editorial principles#

Product accuracy over speed#

We’d rather ship one accurate, verified article per week than four articles that skim a topic. If a claim can’t be supported against the live product, it doesn’t ship. Full stop.

Named humans review everything#

Every article’s editorial review is done by a specific, named person — see the byline of any post. We don’t publish anonymously and we don’t hide behind institutional voice.

Localization respects the source#

Translations preserve the technical facts of the English original. Locale-specific prose, punctuation, and idiom are adjusted; the underlying claims are not.

Comparisons cite primary sources#

Every competitor claim links to the competitor’s own current docs or pricing page. If a competitor’s offering has changed since we wrote about it, we correct the article — we don’t leave stale comparisons in place.

Practical over clever#

We optimize for whether the article helps a real developer make a real decision — not for how clever the framing is or how novel the take.

Transparent about AI#

Every AI-assisted article says so, at the bottom, in every locale, on every publication. No hedge, no marketing framing.

Our commitment#

If you find something on this blog that’s factually wrong, outdated, or misrepresenting a competitor’s product, we want to know. Reach out via hello@ipfs.ninja. We correct articles openly — every substantive edit bumps the Updated: date and preserves an audit trail in Git history.

Trust is the whole point of writing about content-addressed storage in the first place. We hold ourselves to the same standard.