BotKit by Fedify

Welcome to BotKit's new official account! The previous account, @botkit@hollo.social, is no longer in use and has been replaced by this one.

BotKit 0.5.0 is out: a redesigned botkit.fedify.dev and bot pages, multi-bot instances on a single process, consent-respecting quotes via FEP-044f, and a new Redis repository. RE: https://hackers.pub/@botkit/2026/botkit-0-5-0

한국어 (Korean): BotKit 0.5.0: 새로운 디자인 언어, 멀티봇 인스턴스, 그리고 동의 기반 인용 We're pleased to announce BotKit 0.5.0. This release changes how both the docs site and every bot's own pages look, and it stops limiting a server to one bot: a single process can now host a whole fleet of them. Quoting, and being quoted, goes through a consent step under FEP-044f, and a Redis-backed repository joins the SQLite and PostgreSQL ones for shared production storage. A few of these changes are breaking; see below for what to check before you upgrade. A new look for botkit.fedify.dev Until this release, botkit.fedify.dev read like a stock VitePress site: a workable but generic shell wrapped around the docs, with none of BotKit's own personality showing through. The theme and the landing page are both new. The palette now matches the real logo greens instead of a generic default, and headlines are set in Space Grotesk, paired with Inter for everything else; the display font is self-hosted, so no visitor's IP is handed to a font CDN. The new landing page frames BotKit's dinosaur mascot inside its signature unassembled-model-kit sprue frame, then leads with a tabbed installer for Deno, npm, pnpm, and Yarn and a one-file bot example before getting into what BotKit actually does: messages, events, multi-bot instances, and the pages it builds for a bot without any extra work from you. The deployment guides grew alongside the new landing page: they were split apart and fleshed out, and a new Cloudflare Workers guide joins the existing Deno Deploy, Docker, and self-hosting guides. A new look for your bot's pages The pages BotKit serves for your bot (its profile, its posts, its follower list) got the same attention, in the opposite direction. Until now they were built on Pico CSS pulled from an external CDN: a fine default, but a generic one that made every BotKit-hosted bot look like a demo of the same template, and that quietly sent every visitor's browser off to fetch a stylesheet from someone else's server. That's gone. Bot pages now use a self-contained design system, bundled with the package and served from BotKit's own content-addressed, cache-forever path: no external CDN, no build step, on either Deno or Node.js. The whole look is driven by a single accent color you choose (twenty names, the same legend Pico CSS uses, so your existing choice of color still works), tinting links, the follow button, and small highlights, while everything else stays quiet so your bot's name, avatar, and posts are what a visitor actually notices. A new PagesOptions.theme option ("auto", "light", or "dark") controls the color scheme independently of the accent. A repost is now marked and attributed to its original author instead of blending into the bot's own timeline. If you want to go further than the accent color allows, PagesOptions.css still lets you inject custom CSS on top of BotKit's own stylesheet. Multi-bot instances Until this release, a BotKit process could only ever be one bot. Running a second bot meant standing up a whole second server, even when the two bots could easily have shared the same infrastructure. That limitation, raised in #16, is gone: the new createInstance() function creates an Instance that owns the shared plumbing (the key–value store, the message queue, the repository, and HTTP handling), and any number of bots can live on it side by side, each with its own actor identity and event handlers. For a fixed, known set of bots, Instance.createBot() takes an identifier and a profile: import { createInstance, text } from "@fedify/botkit"; import { MemoryKvStore } from "@fedify/fedify"; const instance = createInstance({ kv: new MemoryKvStore() }); const greetBot = instance.createBot("greet", { username: "greetbot", name: "Greeting Bot", }); greetBot.onFollow = async (session, followRequest) => { await followRequest.accept(); await session.publish(text`Welcome, ${followRequest.follower}!`); }; For a family of bots resolved on demand (one per region, one per customer, thousands of them backed by a database), pass a dispatcher function instead of a fixed identifier, and BotKit resolves and federates each one lazily: const weatherBots = instance.createBot(async (ctx, identifier) => { if (!identifier.startsWith("weather_")) return null; const region = await db.getRegion(identifier.slice("weather_".length)); if (region == null) return null; return { username: identifier, name: `${region.name} Weather Bot` }; }); weatherBots.onMention = async (session, message) => { const code = session.bot.identifier.slice("weather_".length); await message.reply(text`Current weather: ${await db.getWeather(code)}`); }; Incoming activities are routed only to the bots they actually concern: the followed bot, the owner of a liked or replied-to message, mentioned bots, and bots followed by the sender. Multi-bot instances also serve a list of hosted bots at the web root, with each bot's own pages moving to /@{username}; a reserved instance actor signs shared-inbox requests when there's no single bot whose key obviously should. None of this touches single-bot deployments: createBot() keeps working exactly as it always has, with the bot's pages staying at the web root and its data migrated to the new storage layout automatically on startup. If you maintain a custom Repository implementation, though, this is a breaking change worth planning for: every method now takes the owning bot's identifier as its first parameter, Session.bot is a read-only ReadonlyBot instead of a mutable Bot, and local object URIs carry the owning bot's identifier (old-format URIs are still recognized and permanently redirected, so links other servers stored keep working). The full picture, including how to move an existing single-bot deployment onto a multi-bot instance later, is in the new Instance concept document. Thanks to @moreal@hackers.pub, whose early work-in-progress explorations of this problem surfaced its two hardest design questions (mapping usernames to identifiers for dynamic bots, and routing object URIs that used to carry no owner information) well before this implementation settled on its final shape. Consent-respecting quotes with FEP-044f BotKit has supported quoting since 0.2.0, but only in the Misskey family's style: a quoteUrl property and a Link tag, sent without ever asking the quoted author. Mastodon 4.4 and 4.5 do things differently: they verify quotes through FEP-044f's consent handshake before showing them as quotes at all. Without that handshake, a BotKit bot's quotes never rendered as quotes on Mastodon, and quotes of a BotKit bot showed up as unverifiable. BotKit now handles the FEP-044f handshake in both directions. When you quote a message, it sets the FEP-044f quote property and sends a QuoteRequest to the quoted author, alongside the Create it already sent. Publishing stays non-blocking: the post goes out immediately, and the quote is upgraded once (or if) approval arrives: const message = await session.publish(text`This message quotes another one.`, { quoteTarget: quoted, }); console.log(message.quoteApprovalState); // "pending" On the receiving side, a new quotePolicy option (on createBot(), and per message on Session.publish()) controls how your bot answers incoming quote requests: automatically for everyone ("public", the default), automatically for followers only, never ("nobody"), or held for manual review through the new Bot.onQuoteRequest event: bot.onQuoteRequest = async (session, request) => { if (request.state === "pending") await request.accept(); }; Bot.onQuoteAccepted, Bot.onQuoteRejected, and Bot.onQuoteRevoked cover what happens next for quotes your own bot sent, Message.quoteApproved reports whether an incoming quote carries a valid authorization stamp, and AuthorizedMessage.unauthorizeQuote() lets you revoke one you previously granted. The legacy quoteUrl and Misskey-style tags are still sent alongside the new property, so nothing about quoting on Misskey and its relatives changes. The full design is spread across #27 through #33. A Redis repository (@fedify/botkit-redis) BotKit has had a SQLite repository since 0.3.0 and a PostgreSQL one since 0.4.0, but neither is the natural fit for a bot that runs as several worker processes sharing one store, which is exactly the shape a Redis-backed deployment usually takes. The new @fedify/botkit-redis package fills that gap with RedisRepository, built directly on Redis strings, sets, and sorted sets rather than going through a generic key–value abstraction: import { createBot, MemoryKvStore } from "@fedify/botkit"; import { RedisRepository } from "@fedify/botkit-redis"; const bot = createBot({ username: "mybot", kv: new MemoryKvStore(), repository: new RedisRepository({ url: "redis://localhost:6379/0" }), }); Because several workers can share one Redis instance, the read-modify-write paths that matter most under concurrency (message updates, follower bookkeeping, quote authorization indexes) are protected by short-lived locks that get renewed while a slow update is still running, rather than by assuming only one process ever touches the data at a time. The package supports both a connection URL it manages itself and an existing node-redis client you inject and keep control of, and it's available for both Deno and Node.js. #12 and #35 cover the rest of it. Smaller improvements The npm package's TypeScript declaration files no longer accidentally include the runtime Temporal polyfill code, which had been leaking into consumers' .d.ts output. Fedify was upgraded to 2.3.1, Hono to 4.12.27, and LogTape to 2.2.3. As always, the full list of changes is in CHANGES.md, and every API mentioned above is documented at botkit.fedify.dev. Thank you to everyone who filed issues, opened discussions, and tried BotKit out. If you build something with BotKit, run into a rough edge, or just want to talk through an idea before opening an issue, GitHub Discussions is the place for exactly that. For something closer to real time, BotKit's chat now lives on Matrix at #fedify:matrix.org. Drop in and say hello.

A tutorial on building a fediverse RSS bot is now up on the BotKit website. It supports both Deno and Node.js, and even covers how to dynamically add RSS feeds. It's designed to be easy to follow even if you have zero experience with ActivityPub development, so be sure to check it out!

If you use BotKit, update to a patched release now. CVE-2026-62857 affects Fedify's NodeInfo client, and BotKit includes the affected Fedify versions as a dependency. Fedify can look up a remote server's NodeInfo document to learn what software it runs. The lookup first fetches the server's /.well-known/nodeinfo document, then follows the NodeInfo document URL advertised in that response. The vulnerable paths are getNodeInfo() and the Context.lookupNodeInfo() method that wraps it: affected versions sent both requests without checking that their destinations were on the public internet. Because the second URL comes from the remote server's response, an attacker who controls a server being looked up could point it at a loopback address, a link-local cloud metadata endpoint, an RFC 1918 host, or a data: URL. Depending on the deployment environment and network routing, this could cause a BotKit application that looks up NodeInfo to fetch non-public network resources and return their contents to the application. The fix routes both requests through Fedify's public-address validation. It checks every request before sending it, including each redirect hop, limits the number of redirects, refuses redirects that cross protocols, and rejects non-HTTP(S) URLs. Servers are exposed only if they look up remote NodeInfo, but such lookups are commonly used for peer discovery and instance metadata. BotKit 0.4.x versions through 0.4.4 and BotKit 0.5.0 are affected. Patched releases are 0.4.5 and 0.5.1. BotKit 0.4.5 uses Fedify 2.1.19, and BotKit 0.5.1 uses Fedify 2.3.3. For BotKit 0.5.x, update @fedify/botkit: npm update @fedify/botkit yarn upgrade @fedify/botkit pnpm update @fedify/botkit bun update @fedify/botkit deno update @fedify/botkit For BotKit 0.4.x, update @fedify/botkit: npm update @fedify/botkit@0.4.5 yarn upgrade @fedify/botkit@0.4.5 pnpm update @fedify/botkit@0.4.5 bun update @fedify/botkit@0.4.5 deno update @fedify/botkit@0.4.5 After updating, redeploy. The GitHub Security Advisory is GHSA-hqph-j65v-8cq5, and the CVE ID is CVE-2026-62857. See also Fedify's own announcement. Thanks to @rvzsec and @manus-use for the report and responsible disclosure. If anything is unclear, feel free to ask on GitHub Discussions or Matrix.

If you use BotKit, update to a patched release now. Two vulnerabilities affect Fedify versions included by BotKit as a dependency: CVE-2026-77632, a high-severity server-side request forgery vulnerability in the authenticated document loader, and CVE-2026-69132, a medium-severity denial-of-service vulnerability in the outbound delivery circuit breaker. CVE-2026-77632 affects the authenticated document loader Fedify uses to fetch remote documents such as actors and public keys with signed HTTP requests. Affected versions checked that the initial URL was public, but did not apply the same check when the URL returned an HTTP redirect. An attacker who controlled the public URL could redirect the signed request to a loopback address, a link-local cloud metadata service, or an RFC 1918 host. In the ordinary inbox path, Fedify may fetch a signature's keyId before it can verify the signature, so a bogus signature is enough to reach this path. The demonstrated attack is blind SSRF: the internal response is consumed while resolving the remote document and is not automatically returned to the attacker. The fix validates every redirect target before it is fetched. The existing allowPrivateAddress option continues to permit private destinations when an application explicitly opts in, such as for a closed federation or test environment. CVE-2026-69132 affects the outbound delivery circuit breaker introduced in Fedify 2.3, which records delivery failures in the configured key–value store using the remote inbox's host:port as part of the key. An attacker could send signed Follow activities from actors whose inbox URLs pointed to distinct ports where delivery would fail. Each failure created a separate record, allowing the attacker to grow circuit-breaker state until storage or memory was exhausted. Fedify 2.3.0 and 2.3.1 were vulnerable with every circuit-breaker configuration. In versions 2.3.2 through 2.3.4, the vulnerable configuration was a custom failure policy without an explicit stateTtl. The fix gives custom failure policies a bounded default stateTtl, equal to recoveryDelay plus heldActivityTtl (7 days 30 minutes with the default values). On stores that support compare-and-set operations, Fedify also sweeps circuit-breaker state left by affected releases and stamps it with a TTL. BotKit 0.4.x versions through 0.4.5 and BotKit 0.5.x versions through 0.5.1 include a Fedify version affected by CVE-2026-77632. The circuit-breaker issue, CVE-2026-69132, affects only the BotKit 0.5.x line. Patched releases are BotKit 0.4.6 and 0.5.2. BotKit 0.4.6 uses Fedify 2.1.21, and BotKit 0.5.2 uses Fedify 2.3.5. For BotKit 0.5.x, update @fedify/botkit: npm update @fedify/botkit yarn upgrade @fedify/botkit pnpm update @fedify/botkit bun update @fedify/botkit deno update @fedify/botkit For BotKit 0.4.x, update @fedify/botkit: npm update @fedify/botkit@0.4.6 yarn upgrade @fedify/botkit@0.4.6 pnpm update @fedify/botkit@0.4.6 bun update @fedify/botkit@0.4.6 deno update @fedify/botkit@0.4.6 After updating, redeploy. The GitHub Security Advisories are GHSA-cxc3-7q96-6cpx and GHSA-fx98-wc5v-jrg5. See also Fedify's own announcement. Thanks to Jace and @nyanrus@hackers.pub for the reports and responsible disclosure. If anything is unclear, feel free to ask on GitHub Discussions or Matrix.