洪 民憙 (Hong Minhee)

Having some nice ActivityPub design/implementation conversations with @hongminhee in the @fedify Matrix chat at #fedify:matrix.org

And if it sometimes boils down to an exchange of 😮‍💨 and 😞, then maybe that's what we need that day, and 💪 can be for tomorrow.

As an example, I've already put together a curated list for Django developers(https://social.silicon.moe/collections/116839954192203195), as well as a broader one for general developers (https://social.silicon.moe/collections/116837709178617613) (including the Lobsters account)

I'd love to see a coordinated campaign across some of the more active instances — recommending well-known and influential accounts to follow. I'm especially trying to curate lists for Fosstodon and Hachyderm, but doing this alone is tough. Would anyone be interested in collaborating?

Mastodon 4.6 has just been released, introducing a new "Collections" feature. Like Bluesky's Starter Packs, this lets us curate and recommend accounts to newcomers on the fediverse, so they don't land on an empty, lifeless timeline when they first join.

Sometimes, while designing some hypothetical fediverse software, I run into this feeling

setting aside ActivityPub spec compatibility itself, there are these frustrating moments where I hit preconditions like 'this won't work because of which FEPs (e.g. Activity Intents) other fediverse software happens to support' and it just kills the momentum.

@bitbraindev They say they have their reasons.

One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.

AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.

I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.

#ATProto #ATProtocol #fedidev

Requested a #CVE ID through a #GitHub Security Advisory on June 27 and still nothing, almost two weeks now. GitHub's docs say it usually takes up to three days.

Anyone else seeing longer waits from the GitHub CNA lately, or is this just me? Curious whether it's a general slowdown or something specific to my request.

#FOSS #InfoSec #GHSA

@Profpatsch Oh, the quote seems still pending. I'm quoting it: https://tldr.nettime.org/@tante/116880003584050912.

BotKit: Standalone ActivityPub bots in TypeScript by @hongminhee https://lobste.rs/s/tbs5t3 #javascript #web
https://botkit.fedify.dev/

Just dropped a new BotKit release, and BotKit now can host multiple bots per instance! Also we have a new beautiful website as well: botkit.fedify.dev.

📣 The moment is here. 📣

TypeScript 7 is officially released! 7️⃣

https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

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.

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:

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, 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.

I'm concerned about this, though maybe I'm missing some context. A maintainer saying “I don't want AI-assisted patches in this project” seems fair enough. A forge-wide ban feels like a different thing. Code usually doesn't tell you how it was written, so a rule like this may mostly teach people not to disclose AI use rather than not to use it. Honest disclosure gets punished, concealment doesn't. That seems like the opposite of what the policy wants.

New @botkit release will be shipped soon. Stay tuned!

the fediverse right now

https://fediverse.info (stats by https://fedidb.com)

This week, we cover the writing layer of the fediverse: Ghost, WriteFreely, Micro.blog, Plume, WordPress, and Flipboard. Text was ActivityPub's first real workload, but these platforms didn't all arrive at federation the same way.

Ghost: a UK non-profit that funds Fedify (by @hongminhee) the framework its federation is built on. it's a publisher and a fediverse client at once, with an inbox as well as an outbox. Our newsletter is also powered by it, so @index is followable from any Mastodon app right now.

WriteFreely: one primary maintainer, Matt Baer (@matt), roughly 1,400 of 1,900+ commits, going since 2015. Funded by his own hosted product, Write.as.

Micro.blog: a Kickstarter By Manton Reese (@manton) that funded the platform before it had a single user. POSSE, native ActivityPub, and native Bluesky, no bridge.

Plume: a simple platform that also supported collaborative multi-author blogs. But no longer actively developed - it recommends WriteFreely and WordPress instead of itself.

WordPress: built-in ActivityPub (using plugin by Matthias Pfefferle - @pfefferle) plus a native AT Protocol plugin and real moderation tooling.

Flipboard: curating other people's writing rather than hosting its own.

Part 3 of the "Fediverse Beyond Mastodon" series.

https://federatedmind.com/the-written-fediverse/?utm_source=mastodon&utm_medium=social&utm_campaign=fediverse-beyond-mastodon-3

#Fediverse #ActivityPub #Ghost #WriteFreely #MicroBlog #WordPress #OpenWeb #Blogging

The new https://fediverse.info is now live 🥳

it's a lot better than before, much more useful, take a look!

Back in time I used to make a stupid little font called Unison. It was a bitmap-vector hybrid font defined by text-based font description files which then get compiled by Python script. During the development of Unison, I had so frustrating bug that I had to write this comment in addition to its workaround:

def custom_sort_key((name, _)):
    # what, the, real, fuck.
    # it seems that Uniscribe has some bug with Hangul and possibly more scripts:
    # some characters, when they are located in specific glyph indices, are correctly
    # mapped via ScriptGetCMap but considered to be missing via ScriptShape.
    # combined with SSA_FALLBACK it causes the wrong *and* inconsistent fallback behavior.
    # given that the range of those indices abruptly end with 2^n boundaries,
    # I strongly suspect that this is something to do with the internal lookup mechanism.
    # for now, reorder problematic scripts to (empirically) avoid the problem... *sigh*
    if not name.startswith('uni'): return (2, name)
    try: c = int(name[3:], 16)
    except ValueError: return (2, name)
    return (0 if 0x1100 <= c <= 0x11ff or 0x3130 <= c <= 0x318f or
                 0xa960 <= c <= 0xa97f or 0xac00 <= c <= 0xd7ff else 1, c)

Uniscribe isn't exactly a household name so here's a brief description. It's an internal name for Windows' font rendering---or more accurately, shaping---system. OpenType fonts consist of a list of zero-numbered glyphs and a character mapping (cmap) from a character code, typically Unicode, to the glyph index. The problem was that Uniscribe correctly found a glyph from the cmap but failed to actually make use of that glyph. It is easy to demonstrate with Windows Notepad; you can configure its font, but it will use a fallback system font if the glyph doesn't exist in the specified font. When the problematic character was typed in, every non-space character before that character would suddenly switch to the fallback font!

For a long time the bug was thought to be Windows' because of its peculiar behavior over the problematic glyph indices. The bug starts to appear around the glyph index 1200 and persists right until the glyph index 2048 at which the bug suddenly disappears. Also I found a workaround to relocate problematic glyphs to lower glyph indices. 2048 = 2^11, what a suspicious number. My gut reaction was that it should be something to do with binary search, as OpenType's cmap contains related fields, but my compiler internally used fontTools for font creation and they should have been automatically calculated. So the culprit must have been Windows instead.

As there was a workaround I had no reason to continue at this point, so I documented this weird behavior and moved on. Fast forward to today: after 11 busy years, LLM has completely transformed how we do programming and I realized that LLM should be able to solve this 11-year-old mystery. You know, in this agentic era any little idea is worthy to execute. So I asked and got some additional infos:

• The bug was traced back to GetCharacterPlacementW, which is a GDI function. Note that GDI is a part of Windows kernel (due to the performance concern) so I ended up with kernel debugging! Dang it!

• Workaround turned out to be incomplete, as it only moved problematic glyph indices from here to there.

• More precisely, problematic glyph indices were two ranges: [1216, 1664) and [1792, 2048). Every single end point here are multiples of 64. So a hypothesis was set up: there must have been some list of 64-entry bitmaps, and for some reason they were partially initialized. A partially initialized bitmap causes other glyphs in that bitmap to fail, hence this behavior.

• I was able to (finally) confirm that fonts had the correct cmap and correct metadata. For example, there are fields called ulUnicodeRange1--4 which are bitmaps for script coverage. Unison had these fields incorrect set but fixing them or setting every single bit didn't help much.

And you can easily imagine my struggle with Claude because of the kernel debugging---oh, you must be doing cybersecurity so I'll block you, thank you so much. After two blocks I gave up with Claude and let Codex to finish the investigation. Codex too struggled, but this time it was able to infer the following from Claude's investigation notes:

Connecting the existing experiment results with the kernel path surfaces one strong pattern. Every failing page contains at least one glyph with 4 or more top-level composite components, while adjacent OK pages top out at 3. Page-mate victims such as AC00-AC27 are also explained this way: they fail not because of their own glyphs, but because a 4+ component glyph lives in the same 64-glyph page.

In simple words, the bug manifests itself when the number of subglyphs in composite glyphs is too high.

And it went to rewrite the font with fontTools until it concluded that:

I found the decisive difference. A/B use up to 8 top-level components in actual composite glyphs, but maxp.maxComponentElements == 0; I has the same glyf size, but maxp.maxComponentElements == 8. That explains why I stays OK even with 4+ component pages. So the general workaround is not Hangul-specific: it is to make the composite limit values in maxp match the actual glyph data.

Was it all about the buggy font?

maxp is an OpenType font header containing various maximums and minimums to aid implementations. It is not exactly metadata, but it is easily derivable from other font data and fontTools must have correctly set them automatically. At this point I looked maxp.maxComponentElements up from fontTools' issue tracker and voilà, old versions of fontTools somehow forgot to set that exact field!!!! So Windows wasn't a culprit; all it did wrong was the over-reliance on incorrect maxp values.

So, yeah, that was my hunt towards 11-year-old bug that traced back to another bug only found in 2019. Bittersweet, eh? At least it wasn't my fault, nor Windows' fault. That should be enough.

Ah, as for what's going on Unison today...

It might be a kind of Stockholm syndrome, but I often get the urge to code in programming languages that tormented me in the past, like PHP or C#.

i wonder what other entry-level software engineers study or build in their spare time. i'm building Feder

The official account for the BotKit project is moving to @botkit. This account will be replaced by the new one. Followers should automatically follow the new account unless any issues occur.

Fedify keeps growing a family of sibling projects, each one solving a different piece of what it takes to build on ActivityPub.

Hollo is a single-user microblogging server built on Fedify. It has a Mastodon-compatible API, CommonMark support, and quotes in both Mastodon and Misskey style.

BotKit is a framework for building standalone ActivityPub bots, no Mastodon or Misskey account required behind it. A complete bot fits in a single TypeScript file.

Two more are still incubating. DrFed is a web-based platform for inspecting ActivityPub objects and activities and tracing where federation breaks down. Feder is a lightweight ActivityPub server framework in Rust, a sibling to Fedify for those working outside the TypeScript ecosystem.

All of them live under the @fedify-dev organization on GitHub.

Great post, I suggest to anyone interested in the ActivityPub spec and technical architecture to read it. I had no idea the tool echosystem had this many problems, and Fedify handles a lot of them for you!
#activitypub
https://hackers.pub/@fedify/2026/why-activitypub-is-hard

@fedify Awesome work for the fediverse! The fact that so many servers behave in non-compatible ways seems to suggest the spec has problems, right? Some examples are frustrating to read, I can't imagine building around them without such framework.

@fedify This sounds like an amazing piece of software! Far outside my wheelhouse, but I can imagine this makes it far easier to create new services for the Fediverse!

Probably has already been looked at by many in the #fediverse, but I just saw it. Nice read but mostly out of my wheelhouse.
https://hackers.pub/@fedify/2026/why-activitypub-is-hard

I know it's healthy not to take criticism of my work personally, but sometimes the criticism I get about my work still hurts quite a bit.