洪 民憙 (Hong Minhee) :nonbinary:'s avatar

洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

1,099 following1,872 followers

An intersectionalist, feminist, and socialist living in Seoul (UTC+09:00). @tokolovesme's spouse. Who's behind @fedify, @hollo, and @botkit. Write some free software in , , , & . They/them.

서울에 사는 交叉女性主義者이자 社會主義者. 金剛兔(@tokolovesme)의 配偶者. @fedify, @hollo, @botkit 메인테이너. , , , 等으로 自由 소프트웨어 만듦.

()

Website

https://hongminhee.org/

GitHub

https://github.com/dahlia

Blog

https://writings.hongminhee.org/

Hackers' Pub

https://hackers.pub/@hongminhee

BotKit by Fedify
@botkit@hackers.pub

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.

matrix.to

You're invited to talk on Matrix

You're invited to talk on Matrix

Hollo :hollo:
@hollo@hollo.social

Hollo security updates: 0.8.9 and 0.9.9

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.

For full technical details of the underlying vulnerability, see the Fedify security advisory and the Fedify security announcement.

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.

For 0.8.x deployments, update to 0.8.9:

docker pull ghcr.io/fedify-dev/hollo:0.8.9

For 0.9.x deployments, update to 0.9.9:

docker pull ghcr.io/fedify-dev/hollo:0.9.9

After pulling the new image, restart your Hollo container. If you deploy from source, pull the corresponding release tag and restart.

Thanks to @rvzsec and @manus-use for the report and responsible disclosure to the Fedify project.

If anything is unclear, ask below.

github.com

manus-use - Overview

Cybersecurity Researcher | Sharing practical InfoSec knowledge - manus-use

Fedify
@fedify@hackers.pub

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.

Current patched releases are 1.9.13, 1.10.12, 2.0.22, 2.1.18, 2.2.7, and 2.3.2. The GitHub Security Advisory is GHSA-hqph-j65v-8cq5, and the CVE ID is CVE-2026-62857.

Update @fedify/fedify:

npm  update  @fedify/fedify
yarn upgrade @fedify/fedify
pnpm update  @fedify/fedify
bun  update  @fedify/fedify
deno update  @fedify/fedify

After updating, redeploy. If you run other Fedify-based servers, update those too.

Thanks to @rvzsec and @manus-use for the report and responsible disclosure.

If anything is unclear, ask below.

github.com

manus-use - Overview

Cybersecurity Researcher | Sharing practical InfoSec knowledge - manus-use

jnkrtech
@jnkrtech@treehouse.systems · Reply to skategoat 🐐 🇵🇸

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

Chee Aun 🤔
@cheeaun@mastodon.social

👀 new 3rd-party Mastodon/fediverse client

🤔 can't find the English translation. Even the browser's built-in translator is failing maybe due to its usage of Flutter.

でもでも@自宅鯖
@d@mastodon.demo2.jp

私が開発しているMastodonクライアントアプリの紹介ページを作成しました！
これまでごく一部の人に試してもらっていましたが、より広く公開しようと思います。
現在まだテスト版ですが、使っていただけると嬉しいです。（ぜひ拡散おねがいします）

demo2.jp/kurage/

demo2.jp

Kurage — Fediverse の海を、自由に漂う。

マルチプラットフォーム対応の Mastodon クライアント。複数アカウントの統合タイムライン・ストリーミング・豊富な投稿オプション。

でもでも@自宅鯖
@d@mastodon.demo2.jp

私が開発しているMastodonクライアントアプリの紹介ページを作成しました！
これまでごく一部の人に試してもらっていましたが、より広く公開しようと思います。
現在まだテスト版ですが、使っていただけると嬉しいです。（ぜひ拡散おねがいします）

demo2.jp/kurage/

demo2.jp

Kurage — Fediverse の海を、自由に漂う。

マルチプラットフォーム対応の Mastodon クライアント。複数アカウントの統合タイムライン・ストリーミング・豊富な投稿オプション。

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:

ブログ『洪民憙雑記』をPHPからAstro + Netlifyに移行して、ついでにFedifyでActivityPubに対応させた話を文章にまとめた。

https://writings.hongminhee.org/2026/07/fedified-blog/

writings.hongminhee.org

I added ActivityPub to this blog

I built this blog with Jikji, a static site generator I wrote myself, almost five years ago. Back then I barely knew TypeScript or modern web tooling, and I'd…

洪民憙 (Hong Minhee)
@hongminhee@writings.hongminhee.org
I built this blog with Jikji, a static site generator I wrote myself, almost five years ago. Back then I barely knew TypeScript or modern web tooling, and I'd…

I added ActivityPub to this blog

I built this blog with Jikji, a static site generator I wrote myself, almost five years ago. Back then I barely knew TypeScript or modern web tooling, and I'd never implemented ActivityPub. TypeScript and modern web tooling are second nature to me now, and ActivityPub has become central to my work. I maintain Fedify, for whatever that's worth, and it bothered me that my own blog wasn't federated. So I fixed that.

The old stack: Jikji and PHP

This blog used to run on Jikji, a static site generator I wrote myself in Deno. Calling it a static site generator is a bit of a stretch, though. Like old Movable Type installations, it didn't just produce HTML; it generated a bit of PHP too. That PHP existed almost entirely for HTTP content negotiation: it read the browser's Accept-Language header and chose among Korean mixed script, hangul-only Korean, English, and Japanese. That's all it did.

I first considered adding a thin ActivityPub implementation directly in PHP, since I was already using it. But I wasn't really writing that PHP by hand; Jikji generated it for me, and I had no interest in hand-coding PHP myself. Federating meant delivering a Create(Article) activity to followers whenever a new post went up, which meant I'd need something like a message queue. Bolting a message queue onto Jikji's generated PHP felt, to me at least, like more complexity than it was worth maintaining. And honestly, with Fedify already around, I had no desire to implement ActivityPub from scratch again.

So I ripped out PHP entirely and decided to bring in Fedify instead.

The new stack: Astro and Netlify

The first decision was to drop Jikji and PHP for Astro, a JavaScript framework built for static-content-heavy sites. I chose Astro largely because it already had a @fedify/astro integration.

I reused as much of the existing CSS and HTML as I could. I'm happy with the current design, and redoing it alongside everything else felt like scope creep waiting to happen. Permalinks stayed exactly as they were. I wanted to replace the stack underneath without visitors noticing anything had changed at all.

For hosting, I went back and forth between Cloudflare Workers and Netlify, and settled on Netlify partly because Fedify had never run there before, and this seemed like a good excuse to add that support. I've hosted static sites on Netlify plenty of times, but this was my first time pairing it with edge functions. The idea of a mostly static site with a few dynamic slices reminded me of the late-nineties web, when a site was static HTML except for whatever lived in /cgi-bin/.

Publishing used to mean committing a Markdown file to Git, pushing, letting GitHub Actions build the static site, and deploying it over SFTP. Now GitHub Actions is out of the build pipeline entirely, since Netlify builds the site itself. It ended up simpler overall.

I'm happy with Astro, and the migration went smoothly. It beats Jikji, which I'd barely touched since building it five years ago. Jikji is now archived; there's no reason left for me to keep maintaining it.

Fitting Fedify into Astro

Updating @fedify/astro

Once I actually tried to add Fedify to Astro, I ran into a problem: @fedify/astro didn't support Astro 7, the current version. The Astro APIs it relied on hadn't changed much internally, but the package's declared compatibility range, and its tests, only went up to Astro 5. So before I could federate the blog, I had to fix @fedify/astro first.

That meant more than widening a version range. The existing tests built a fake Astro context and called the middleware directly, which couldn't catch problems with Vite's SSR configuration, compatibility across adapters, or request routing on a built server. So I wrote new compatibility tests that pack @fedify/astro for real, install it into a small Astro app, build and start the app, and send real HTTP requests to it.

Those tests check, across Astro 5, 6, and 7, that HTML requests reach Astro's pages, that ActivityPub and WebFinger requests are handled by Fedify, and that Astro's 404 Not Found still applies to everything else. For Astro 7 specifically, I also run the tests against Deno and Bun, not just the Node.js adapter.

That work has already been merged upstream and will ship in Fedify 2.4.0.

Static pages, dynamic endpoints

The Astro project as a whole builds with server output, but the existing blog pages are still prerendered, same as before. WebFinger, the actor, the inbox and outbox, the followers collection, and ActivityPub objects are the exceptions: Fedify handles those dynamically, per request. The middleware @fedify/astro provides looks at a request's URL and Accept header and only intercepts what Fedify is meant to handle. The same URL can return the existing Astro page for an HTML request and a Fedify-built object for an ActivityPub one.

What visitors see is still, for all practical purposes, a static site. Nearly all the new dynamic surface lives somewhere only other fediverse servers ever touch. That's the CGI comparison again.

Person and Article

Adding ActivityPub also meant deciding what counts as an actor here, and what counts as an object. I gave the blog's actor a Person type. Publishing itself is automated, but the actor represents me, the person writing these posts, not a piece of software or a service. So the handle is @hongminhee@writings.hongminhee.org, and the actor's web URL points at the blog.

Each post gets an Article. It has a title and a body, and it lives at its own permalink as a long-form document, which fits Article better than Note. Most major ActivityPub implementations support Article these days, Mastodon included. Human-facing permalinks stayed put; ActivityPub objects got their own URIs instead, shaped like /ap/articles/{year}/{month}/{slug}. Article's url points back at the original permalink, so the object's identity and the web page people actually read stay separate.

Multiple languages took more thought. Representing each language as its own Article would scatter likes and shares for the same post across several objects. So I merged the Korean mixed script, hangul-only Korean, English, and Japanese versions under a single Article, all sharing one permalink. Title, summary, and body each carry language-tagged values for every version, which serialize to JSON-LD as nameMap, summaryMap, and contentMap. For implementations that don't handle per-language values, name, summary, and content also carry a default: English if there's an English version, Korean mixed script otherwise. Each language's HTML page also gets a Link on Article's url, tagged with hreflang.

That way, a receiving server that understands multiple languages can pick a title and body matching the reader's language, and one that doesn't can still fall back to the default. In practice, though, I know of hardly any ActivityPub implementation that renders these multilingual values properly yet. There's an open issue for it on Mastodon's tracker, and a similar proposal on Hackers' Pub's, but neither has a timeline. Some of that is probably a UI design problem as much as anything else.

Running Fedify on Netlify

Unlike serving plain static files, an ActivityPub server needs some state that outlives any single deploy. The actor's signing key can't rotate on every deploy. The followers list can't disappear on the next one either. Both live in Netlify Database.

Incoming and outgoing activities go through a message queue built on Async Workloads. Delivery can be slow or fail outright depending on the receiving server, so it can't all happen inside the function handling the HTTP request. Queuing it separates accepting a request from actually delivering it, and failed deliveries can be retried later. Fedify already abstracts this, with pluggable backend adapters, but there wasn't yet an adapter for Netlify's Async Workloads. So I wrote the @fedify/netlify package, which uses Async Workloads as the queue and keeps delivery-order state in Netlify Database.

Announcing new posts to the fediverse turned out to be a separate problem. A static site finishing its build doesn't tell a running ActivityPub server anything about which posts changed. So on every successful production deploy, I diff the current post list against the previous deploy's. New posts get a Create(Article); edited ones, whether the content or just the timestamp changed, get an Update(Article); removed ones get a Delete(Article). All of it goes out to followers. Retries reuse the same activity ID for the same change, and deploy ordering is checked so that an older deploy syncing late can't undo a newer one.

Netlify's deploy previews and branch deploys have federation turned off entirely. Otherwise every preview would spin up an actor claiming to be this same blog, and a test deploy could end up sending activities to real followers. Locally, I develop against an in-memory store and queue; production is the only place using the persistent database and queue.

Fedify now runs on Netlify Functions, alongside Deno Deploy and Cloudflare Workers, on top of its usual support for Node.js, Deno, and Bun.

Wrapping up

None of this gives the blog a timeline, a reply box, or any other social feature. Writing and reading still work the way they always did, and the permalinks and design are basically untouched. What changed is that the blog, and every post on it, now has a name and address the fediverse understands. Follow @hongminhee@writings.hongminhee.org to get new posts, or look up a post's ActivityPub object URI to find the original.

I've maintained Fedify long enough to show other developers how to implement ActivityPub, and I dogfooded it plenty while building Hollo and Hackers' Pub. But this was the first time I'd added it to a site that was already live, and static at that. Along the way I got a compatibility test suite for the Astro integration, Netlify support, and a handful of deployment and operational problems that no amount of reading docs or unit tests would have surfaced. It turns out Fedify isn't just for building new social networks from scratch; it works just as well for bringing an existing site into the fediverse without changing how it looks.

hackers.pub

Hackers' Pub: Local timeline

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

Wrote up the story of moving my blog, Hong Minhee on Things (洪民憙雜記), off PHP and onto Astro + Netlify, and adding ActivityPub support along the way with Fedify.

https://writings.hongminhee.org/2026/07/fedified-blog/

writings.hongminhee.org

I added ActivityPub to this blog

I built this blog with Jikji, a static site generator I wrote myself, almost five years ago. Back then I barely knew TypeScript or modern web tooling, and I'd…

洪民憙 (Hong Minhee)
@hongminhee@writings.hongminhee.org
I built this blog with Jikji, a static site generator I wrote myself, almost five years ago. Back then I barely knew TypeScript or modern web tooling, and I'd…

I added ActivityPub to this blog

I built this blog with Jikji, a static site generator I wrote myself, almost five years ago. Back then I barely knew TypeScript or modern web tooling, and I'd never implemented ActivityPub. TypeScript and modern web tooling are second nature to me now, and ActivityPub has become central to my work. I maintain Fedify, for whatever that's worth, and it bothered me that my own blog wasn't federated. So I fixed that.

The old stack: Jikji and PHP

This blog used to run on Jikji, a static site generator I wrote myself in Deno. Calling it a static site generator is a bit of a stretch, though. Like old Movable Type installations, it didn't just produce HTML; it generated a bit of PHP too. That PHP existed almost entirely for HTTP content negotiation: it read the browser's Accept-Language header and chose among Korean mixed script, hangul-only Korean, English, and Japanese. That's all it did.

I first considered adding a thin ActivityPub implementation directly in PHP, since I was already using it. But I wasn't really writing that PHP by hand; Jikji generated it for me, and I had no interest in hand-coding PHP myself. Federating meant delivering a Create(Article) activity to followers whenever a new post went up, which meant I'd need something like a message queue. Bolting a message queue onto Jikji's generated PHP felt, to me at least, like more complexity than it was worth maintaining. And honestly, with Fedify already around, I had no desire to implement ActivityPub from scratch again.

So I ripped out PHP entirely and decided to bring in Fedify instead.

The new stack: Astro and Netlify

The first decision was to drop Jikji and PHP for Astro, a JavaScript framework built for static-content-heavy sites. I chose Astro largely because it already had a @fedify/astro integration.

I reused as much of the existing CSS and HTML as I could. I'm happy with the current design, and redoing it alongside everything else felt like scope creep waiting to happen. Permalinks stayed exactly as they were. I wanted to replace the stack underneath without visitors noticing anything had changed at all.

For hosting, I went back and forth between Cloudflare Workers and Netlify, and settled on Netlify partly because Fedify had never run there before, and this seemed like a good excuse to add that support. I've hosted static sites on Netlify plenty of times, but this was my first time pairing it with edge functions. The idea of a mostly static site with a few dynamic slices reminded me of the late-nineties web, when a site was static HTML except for whatever lived in /cgi-bin/.

Publishing used to mean committing a Markdown file to Git, pushing, letting GitHub Actions build the static site, and deploying it over SFTP. Now GitHub Actions is out of the build pipeline entirely, since Netlify builds the site itself. It ended up simpler overall.

I'm happy with Astro, and the migration went smoothly. It beats Jikji, which I'd barely touched since building it five years ago. Jikji is now archived; there's no reason left for me to keep maintaining it.

Fitting Fedify into Astro

Updating @fedify/astro

Once I actually tried to add Fedify to Astro, I ran into a problem: @fedify/astro didn't support Astro 7, the current version. The Astro APIs it relied on hadn't changed much internally, but the package's declared compatibility range, and its tests, only went up to Astro 5. So before I could federate the blog, I had to fix @fedify/astro first.

That meant more than widening a version range. The existing tests built a fake Astro context and called the middleware directly, which couldn't catch problems with Vite's SSR configuration, compatibility across adapters, or request routing on a built server. So I wrote new compatibility tests that pack @fedify/astro for real, install it into a small Astro app, build and start the app, and send real HTTP requests to it.

Those tests check, across Astro 5, 6, and 7, that HTML requests reach Astro's pages, that ActivityPub and WebFinger requests are handled by Fedify, and that Astro's 404 Not Found still applies to everything else. For Astro 7 specifically, I also run the tests against Deno and Bun, not just the Node.js adapter.

That work has already been merged upstream and will ship in Fedify 2.4.0.

Static pages, dynamic endpoints

The Astro project as a whole builds with server output, but the existing blog pages are still prerendered, same as before. WebFinger, the actor, the inbox and outbox, the followers collection, and ActivityPub objects are the exceptions: Fedify handles those dynamically, per request. The middleware @fedify/astro provides looks at a request's URL and Accept header and only intercepts what Fedify is meant to handle. The same URL can return the existing Astro page for an HTML request and a Fedify-built object for an ActivityPub one.

What visitors see is still, for all practical purposes, a static site. Nearly all the new dynamic surface lives somewhere only other fediverse servers ever touch. That's the CGI comparison again.

Person and Article

Adding ActivityPub also meant deciding what counts as an actor here, and what counts as an object. I gave the blog's actor a Person type. Publishing itself is automated, but the actor represents me, the person writing these posts, not a piece of software or a service. So the handle is @hongminhee@writings.hongminhee.org, and the actor's web URL points at the blog.

Each post gets an Article. It has a title and a body, and it lives at its own permalink as a long-form document, which fits Article better than Note. Most major ActivityPub implementations support Article these days, Mastodon included. Human-facing permalinks stayed put; ActivityPub objects got their own URIs instead, shaped like /ap/articles/{year}/{month}/{slug}. Article's url points back at the original permalink, so the object's identity and the web page people actually read stay separate.

Multiple languages took more thought. Representing each language as its own Article would scatter likes and shares for the same post across several objects. So I merged the Korean mixed script, hangul-only Korean, English, and Japanese versions under a single Article, all sharing one permalink. Title, summary, and body each carry language-tagged values for every version, which serialize to JSON-LD as nameMap, summaryMap, and contentMap. For implementations that don't handle per-language values, name, summary, and content also carry a default: English if there's an English version, Korean mixed script otherwise. Each language's HTML page also gets a Link on Article's url, tagged with hreflang.

That way, a receiving server that understands multiple languages can pick a title and body matching the reader's language, and one that doesn't can still fall back to the default. In practice, though, I know of hardly any ActivityPub implementation that renders these multilingual values properly yet. There's an open issue for it on Mastodon's tracker, and a similar proposal on Hackers' Pub's, but neither has a timeline. Some of that is probably a UI design problem as much as anything else.

Running Fedify on Netlify

Unlike serving plain static files, an ActivityPub server needs some state that outlives any single deploy. The actor's signing key can't rotate on every deploy. The followers list can't disappear on the next one either. Both live in Netlify Database.

Incoming and outgoing activities go through a message queue built on Async Workloads. Delivery can be slow or fail outright depending on the receiving server, so it can't all happen inside the function handling the HTTP request. Queuing it separates accepting a request from actually delivering it, and failed deliveries can be retried later. Fedify already abstracts this, with pluggable backend adapters, but there wasn't yet an adapter for Netlify's Async Workloads. So I wrote the @fedify/netlify package, which uses Async Workloads as the queue and keeps delivery-order state in Netlify Database.

Announcing new posts to the fediverse turned out to be a separate problem. A static site finishing its build doesn't tell a running ActivityPub server anything about which posts changed. So on every successful production deploy, I diff the current post list against the previous deploy's. New posts get a Create(Article); edited ones, whether the content or just the timestamp changed, get an Update(Article); removed ones get a Delete(Article). All of it goes out to followers. Retries reuse the same activity ID for the same change, and deploy ordering is checked so that an older deploy syncing late can't undo a newer one.

Netlify's deploy previews and branch deploys have federation turned off entirely. Otherwise every preview would spin up an actor claiming to be this same blog, and a test deploy could end up sending activities to real followers. Locally, I develop against an in-memory store and queue; production is the only place using the persistent database and queue.

Fedify now runs on Netlify Functions, alongside Deno Deploy and Cloudflare Workers, on top of its usual support for Node.js, Deno, and Bun.

Wrapping up

None of this gives the blog a timeline, a reply box, or any other social feature. Writing and reading still work the way they always did, and the permalinks and design are basically untouched. What changed is that the blog, and every post on it, now has a name and address the fediverse understands. Follow @hongminhee@writings.hongminhee.org to get new posts, or look up a post's ActivityPub object URI to find the original.

I've maintained Fedify long enough to show other developers how to implement ActivityPub, and I dogfooded it plenty while building Hollo and Hackers' Pub. But this was the first time I'd added it to a site that was already live, and static at that. Along the way I got a compatibility test suite for the Astro integration, Netlify support, and a handful of deployment and operational problems that no amount of reading docs or unit tests would have surfaced. It turns out Fedify isn't just for building new social networks from scratch; it works just as well for bringing an existing site into the fediverse without changing how it looks.

hackers.pub

Hackers' Pub: Local timeline

kopper :colon_three:
@kopper@not-brain.d.on-t.work · Reply to kopper :colon_three:
one interesting thing with sqlite is its main downside (1 concurrent writer max) can be alleviated if you partition your database, which in something like postgres is only needed if you Scale Massively. like, the bluesky pds software uses sqlite, but partitions it so each user has their own sqlite file, with the expectation that one user won't ever write fast enough for sqlite to be the bottleneck.

this has an interesting interaction with tools like ORMs that aim to be portable among database systems, because they are flat out not built for it and lead you to having One Sqlite For Everything, and can even make doing the correct thing harder by assuming you'll not really live dis/connect to databases all too often. i imagine this is why stuff like nextcloud or gotosocial or forgejo on sqlite is such a slog. you really have to build for sqlite if you want to use sqlite and can't Just have it be Another Option
洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

Sharing my post from last November once again today. As I continue to navigate this journey of self-discovery, celebrating my very first International Non-Binary People's Day feels quietly meaningful. Claiming my own space and identity is still a work in progress, but I am deeply grateful for the quiet support and honest conversations that have brought me here. Wishing peace and warmth to everyone celebrating today. 💜💛

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

Growing up, I never quite fit into the typical mold of masculinity. My name, Minhee, doesn't help either—it carries a fairly feminine connotation in Korean, which only made it harder to feel any strong sense of male identity.

For the longest time, society categorized me as male, and I didn't really push back against that label. I just went along with it.

But over time, I've realized something important: I don't just lack the traits society expects from men—I have zero interest in pursuing what people call “masculine values.” Sometimes I find myself actively rejecting them.

Things really clicked after I met my spouse, Lisa (@tokolovesme). Through our deep, honest conversations, I finally found words for something I'd felt all along: I'm fundamentally different from a typical cisgender, heterosexual man.

I have come to identify as non-binary and bisexual.

After introducing myself as a man for my entire life, claiming this identity—actually saying “I am non-binary”—still feels new and awkward. But I'm starting to share this truth with the people close to me, one conversation at a time.

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

Growing up, I never quite fit into the typical mold of masculinity. My name, Minhee, doesn't help either—it carries a fairly feminine connotation in Korean, which only made it harder to feel any strong sense of male identity.

For the longest time, society categorized me as male, and I didn't really push back against that label. I just went along with it.

But over time, I've realized something important: I don't just lack the traits society expects from men—I have zero interest in pursuing what people call “masculine values.” Sometimes I find myself actively rejecting them.

Things really clicked after I met my spouse, Lisa (@tokolovesme). Through our deep, honest conversations, I finally found words for something I'd felt all along: I'm fundamentally different from a typical cisgender, heterosexual man.

I have come to identify as non-binary and bisexual.

After introducing myself as a man for my entire life, claiming this identity—actually saying “I am non-binary”—still feels new and awkward. But I'm starting to share this truth with the people close to me, one conversation at a time.

Evan Prodromou
@evan@cosocial.ca

Hurting people around you and being forgiven is one way to prove that you are loved, but it's not the only way.

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social · Reply to Sashin

@sashin I mainly work on my F/OSS projects. I need a web browser to check issues, PRs, and related materials, and I use Zed and Ghostty for coding. Zed actually has a built-in terminal, but I find built-in editor terminals to be too cramped, so I don't really use them. I usually assign one project per workspace, but sometimes I'll assign two or more different issues from the same project to separate workspaces.

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

I use Fedora Linux as my primary operating system, and I absolutely love GNOME's workspaces. I typically create a workspace for each specific task, assigning a Ghostty, Zed, and Firefox window to each one accordingly. This is because I want to focus on just one task within each workspace. Even after submitting a pull request, I don't close the workspace until it's been reviewed and successfully merged. This way, I'm currently maintaining a total of 8 workspaces.

help.gnome.org

What is a workspace, and how will it help me?

wakest ⁂
@liaizon@wake.st

Cool to see Fedify, Mitra and the FEP processes get some time on stage at the Open Social track at from Sefano and Zach

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social · Reply to fedicat

@fedicat Yeah, the quote post collision was a clear example. Whether it's deliberate or just indifference, the Mastodon team doesn't seem to treat the API as a shared surface that evolves across implementations. Hard to build on top of that.

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social · Reply to fedicat

@fedicat That's fair. I know other platforms extend the Mastodon API, but I've been reluctant to do the same. It doesn't feel like a surface that's meant to be extended, and I'd rather not pile more non-standard behavior on top of an API that's already a moving target.

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social · Reply to Dawn Ahukanna

@dahukanna I'm not sure I'm following the storage question. Could you say more about what you mean by runtime data here?

On the second point: the Mastodon API and ActivityPub are completely different in design. They're separate specifications: the Mastodon API is a REST API, ActivityPub is an entirely different protocol. The two look nothing alike, so I'm not sure what “Mastodon instance API that implements ActivityPub” refers to.