Now that #codeberg has manifested their anti-AI view with a 70% in favor vote (https://codeberg.org/Codeberg/org/pulls/1253), we're happy to welcome (once again) all the people which have to/want to move their repositories off Codeberg but still want to stay on a Forgejo-based instance.
Bonus: on top you'll get better uptime, faster site responses and faster CI runners - all for free :)
tl;dr: after this ToU change, keeping AI-generated code on Codeberg would violate these and repositories will be in danger of deletion.
Now that #codeberg has manifested their anti-AI view with a 70% in favor vote (https://codeberg.org/Codeberg/org/pulls/1253), we're happy to welcome (once again) all the people which have to/want to move their repositories off Codeberg but still want to stay on a Forgejo-based instance.
Bonus: on top you'll get better uptime, faster site responses and faster CI runners - all for free :)
tl;dr: after this ToU change, keeping AI-generated code on Codeberg would violate these and repositories will be in danger of deletion.
Ghostty and libghostty are now on Zig 0.16! This was done by a [paid!] contributor over a few weeks. Through this process, the Ghostty non-profit also paid for hours to contribute over a dozen patches upstream to Zig, translate-c, and arocc which help the entire ecosystem. Really amazing work (not by me!) and happy to be upgraded. :)
Culture change is hard. Sooooo many people got here "first" and think their claim is the only correct one. Has always been thus ...
One thing I can think of is remind people that r/fediverse is not exactly the place where "the fediverse" is developed, managed, or happening.
Then follow this dev and see what is up! I care much more that the software and the instance are acting like decent neighbours than I do about the infra its hosted on.
LLVM21 is a stinker and has worse codegen in general, and a bug forced disabled loop auto-vectorization. Turned out to be a blessing: we clearly identified areas we were over-reliant on implicit compiler optimizations and were able to explicitly restructure our code to what we really wanted.
The result is that we now have clean generic SIMD subroutines in places we previously relied on auto-vectorization. And we did it better and as a result produced faster code (see below). Pure ASCII throughput improved more than 20% (30% on Linux) which is insane and is purely because we wrote better SIMD than an auto-vectorizer can. Lit.
We also found it stopped inlining automatically in certain places which destroyed some benchmarks based on real world corpuses. As a result, we now explicitly inline those backed by benchmarks. Wonderful.
"Exotic"-sized integers (e.g. u13) also cause poor LLVM codegen and some performance pitfalls were fixed by adding padding to power-of-two sizes. I know Zig is working on a sema fix for this to avoid LLVM ever seeing these.
Note when I said "in general" above I mean that this was consistently across macOS aarch64, Linux aarch64, and Linux x86_64. Just across the board bad codegen.
Some things slowed down more than can be attributed to noise. I'm looking into that now but they're minor benchmarks. The important ones are parity or better.
Yeah, I'm noticing that more and more. Nothing is able to pass the purity tests. Nobody is good enough. So, doing ANYTHING means we're going to berate you for it.
I try to avoid going straight to the conspiracy theories, but it makes a lot of sense. No better way to discredit something than "false flag"
@benpate i can think of worse companies to host with tbh. Funnily enough these same people probably don't get that a significant portion of the fediverse is actually behind cloudflare's CDNs.
I think these "do as I say" holier than thou types are the bane of the decentralised web. Like, if I wanted to drive people away from open social projects, that's exactly how I'd do it: hire a small group of people to consistently be assholes to other's. It's like 101 from the CIA field guide to sabotage 🚩
the new hackers' pub is looking really nice. seeing that botkit now supports FEP-044f I wonder if that means full QP support will soon arrive here and Hollo
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<void>({ 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:
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, 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:
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.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.
I didn't know that the fediverse community drawing app https://oeee.cafe had an app in the google play store, nor that my compliment to the chicken made the cut to be in a featured screenshot lol
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.
If you run Hollo, update to a patched release now. CVE-2026-62857 affects Fedify's NodeInfo client, which Hollo uses to identify the software running on remote ActivityPub servers.
A NodeInfo lookup starts by fetching a remote server's /.well-known/nodeinfo document, then follows the NodeInfo document URL advertised in that response. The vulnerable getNodeInfo() path fetched both URLs without validating that they resolved to public network destinations. Because the second URL comes directly from a response controlled by the remote server, it could point to a loopback address, a link-local cloud metadata endpoint, an RFC 1918 private address, or even a data: URL.
An attacker who controls a remote server that Hollo discovers could therefore make the Hollo instance initiate requests to non-public network destinations, depending on the deployment environment and network routing.
The fix applies Fedify's public-address validation to both NodeInfo requests and every redirect hop. It also caps redirects, refuses cross-protocol redirects, and rejects non-HTTP(S) URLs. As a result, NodeInfo lookups for private or intranet addresses are now refused.
All Hollo versions in the supported 0.8.x and 0.9.x release lines up to and including 0.8.8 and 0.9.8 are affected. Patched releases are 0.8.9 for the 0.8.x series and 0.9.9 for the 0.9.x series.
Hollo 0.7.x is also affected. It and earlier release lines are no longer supported under the Hollo security policy. Upgrade to a supported release series rather than remaining on an older version.
If you use Fedify, update to a patched release now. CVE-2026-62857 affects Fedify's NodeInfo client. An attacker who runs any instance your server looks up could cause that server to fetch non-public network destinations and return their contents to your application, depending on the deployment environment and network routing.
Fedify can look up a remote instance's NodeInfo document to learn what software it runs. The lookup happens in two steps: it fetches the instance's /.well-known/nodeinfo document, then follows the NodeInfo document URL that response advertises. The vulnerable path is getNodeInfo(), along with the Context.lookupNodeInfo() method that wraps it: affected versions sent both requests without validating the destination against public-network expectations. Because that second URL comes straight out of the remote server's response body, the instance being looked up fully controls it, and could point it at a loopback address, a link-local metadata endpoint, an RFC 1918 host, or a data: URL. Servers are exposed only if they look up NodeInfo, but that lookup is routine for peer discovery and instance metadata.
The fix routes both requests through the same public-address validation Fedify already applied to WebFinger lookups and remote document loading. Every request is now checked before it is sent, including each redirect hop, so a public URL cannot bounce a request to an internal address. Redirects are followed with a cap and are refused if they cross protocols, and non-HTTP(S) URLs such as data: are rejected outright.
These are patch releases, so they tighten behavior without adding new API. If you deliberately look up NodeInfo on a private or intranet address, such as in a closed federation or a test environment, these releases will now refuse it. An allowPrivateAddress opt-out is coming in 2.4.0.
@felipe my take is that the problems and inconsistencies in the YAML spec are bad, but are also things which should be trivially solved by a linter. I think the real reason people mostly don’t like YAML is that it makes it cheap and easy to accidentally build a programming language, and any programming language created by accident is almost certainly going to be shit.
So I guess I’m YAML-neutral. I don’t like TOML or JSON much better.
It's a shame I can't make it to both @COSCUP 2026, which features the Fediverse & Social Web track, and FOSSY 2026, where FediCon is being held, since they're both happening around the same time in early August this year. I really hope to attend both next year.
