Hello! I'm Hong Minhee (洪 民憙), an open source software engineer in my late 30s, living in Seoul, Korea. I'm bisexual and non-binary (they/them), and an enthusiastic advocate of free/open source software and the fediverse.

I work full-time on @fedify, an ActivityPub server framework in TypeScript, funded by @sovtechfund. I'm also the creator of @hollo, a single-user ActivityPub microblog; @botkit, an ActivityPub bot framework; Hackers' Pub, a fediverse platform for software developers; and LogTape, a logging library for JavaScript and TypeScript.

I have a long interest in East Asian languages (CJK) and Unicode. I post mostly in English here, though occasionally in Japanese or in mixed-script Korean (國漢文混用體), a traditional writing style that interleaves Chinese characters with the native Korean alphabet. Wanting to write in that style was actually one of the reasons I joined the fediverse. Feel free to talk to me in English, Korean, Japanese, or even Literary Chinese!

#introduction

はじめまして！ソウル在住の30代後半のオープンソースソフトウェアエンジニア、洪 民憙（ホン・ミンヒ）と申します。バイセクシュアル（bisexual）・ノンバイナリー（non-binary）で、自由・オープンソースソフトウェア（F/OSS）とフェディバース（fediverse）の熱烈な支持者です。

STF（@sovtechfund）の支援を受け、TypeScript用ActivityPubサーバーフレームワーク「@fedify」の開発に専念しています。他にも、おひとり様向けのActivityPubマイクロブログ「@hollo」、ActivityPubボットフレームワーク「@botkit」、ソフトウェア開発者向けフェディバースプラットフォームHackers' Pub、JavaScript・TypeScript用ロギングライブラリLogTapeなどの制作者でもあります。

東アジア言語（いわゆるCJK）とUnicodeにも興味があります。このアカウントでは主に英語で投稿していますが、時々日本語や国漢文混用体（漢字ハングル混じり文）の韓国語でも書いています。実はこの文体で書きたくてフェディバースを始めた、という経緯もあります。日本語、英語、韓国語、漢文でも気軽に話しかけてください！

#自己紹介

安寧(안녕)하세요! 저는 서울에 살고 있는 30代(대) 後半(후반)의 오픈 소스 소프트웨어 엔지니어 洪民憙(홍민희)입니다. 兩性愛者(양성애자)(bisexual)이자 논바이너리(non-binary)이며, 自由(자유)·오픈 소스 소프트웨어(F/OSS)와 聯合宇宙(연합우주)(fediverse)의 熱烈(열렬)한 支持者(지지자)이기도 합니다.

STF(@sovtechfund)의 支援(지원)을 받아 TypeScript用(용) ActivityPub 서버 프레임워크 @fedify 開發(개발)에 專業(전업)으로 任(임)하고 있습니다. 그 外(외)에도 싱글 유저用(용) ActivityPub 마이크로블로그 @hollo, ActivityPub 봇 프레임워크 @botkit, 소프트웨어 開發者(개발자)를 위한 聯合宇宙(연합우주) 플랫폼 Hackers' Pub, JavaScript·TypeScript用(용) 로깅 라이브러리 LogTape 等(등)의 製作者(제작자)이기도 합니다.

東(동)아시아 言語(언어)(이른바 CJK)와 Unicode에도 關心(관심)이 많습니다. 이 計定(계정)에서는 主(주)로 英語(영어)로 포스팅하지만, 때때로 日本語(일본어)나 國漢文混用體(국한문 혼용체) 韓國語(한국어)로도 씁니다. 聯合宇宙(연합우주)에 오게 된 動機(동기) 中(중) 하나가 바로 國漢文混用體(국한문 혼용체)로 글을 쓰고 싶었기 때문이기도 하고요. 韓國語(한국어), 英語(영어), 日本語(일본어), 아니면 漢文(한문)으로도 말을 걸어주세요!

#툿친소 #연친소 #별친소 #자기소개

By the way, I'm flying from Seoul to Brussels tomorrow to attend FOSDEM 2026. It's my first trip to Europe, so I'm both excited and nervous.

@ntek 良いアイデアですね。課題トラッカーにイシューとして作成していただけますか？

If people who speak a different native language than you make the effort to speak to you in yours, that's a privilege.

@hongminhee FWIW, I think EVE Online still uses its stackless Python fork (which supports goroutine-like tasks/fibers) for gameplay scripting.

This brings back memories. Before Python had async/await, before asyncio became standard, I was happily writing concurrent code with gevent. I actually preferred it.

The reason was simple: no function color problem. With async/await, you split the world into two kinds of functions—ones that block by default and ones that don't. You have to mark the latter with async and remember to await them. With gevent, everything just blocks by default, and you spawn when you need concurrency. It's the same mental model as multithreading, just lighter. Project Loom in Java does something similar, though the technical details differ.

I sometimes wonder what Python would look like if it had embraced gevent-style coroutines in CPython instead of adding async/await. Or if Stackless Python had been accepted upstream. Maybe async programming would be more approachable today.

The explicit await keyword gives you visibility into where context switches can happen, sure. But in practice, I/O points are obvious even without the keyword—you're reading from a socket, querying a database, making an HTTP request. The explicitness doesn't really prevent race conditions or timing bugs. Meanwhile, function colors infect everything. One async library forces your entire call stack to be async. You end up maintaining both sync and async versions of the same code, or the ecosystem just splits in two.

With gevent, there's no such problem. You just call functions. Spawn them if you want concurrency, call them normally if you don't. Go's goroutines and Project Loom are popular for good reasons—they make concurrency accessible without the cognitive overhead.

Python's choice is history now, and there's no going back. But looking at how things turned out, I can't help but think the more practical path was right there, and we walked past it.

사상(메시지)가 없는 작품은 없습니다. 어떤 작품이 아무런 사상이나 의도가 없어 보인다면 기존의 지배적인 질서에 너무나 완벽하게 순응하고 있기 때문입니다. 단지 사유를 멈추게 하는 그런 사상과. 사유를 시작하게 하는 사상이 있고 보통 후자를 메시지(사상)가 있다고 말할 뿐이죠. 작품에 사상이 없어야 한다 라는 주장은 사실 '지배적인 사상에 저항하지 마라' 라는 강력한 이데올로기(사상)적 명령입니다.

This brings back memories. Before Python had async/await, before asyncio became standard, I was happily writing concurrent code with gevent. I actually preferred it.

The reason was simple: no function color problem. With async/await, you split the world into two kinds of functions—ones that block by default and ones that don't. You have to mark the latter with async and remember to await them. With gevent, everything just blocks by default, and you spawn when you need concurrency. It's the same mental model as multithreading, just lighter. Project Loom in Java does something similar, though the technical details differ.

I sometimes wonder what Python would look like if it had embraced gevent-style coroutines in CPython instead of adding async/await. Or if Stackless Python had been accepted upstream. Maybe async programming would be more approachable today.

The explicit await keyword gives you visibility into where context switches can happen, sure. But in practice, I/O points are obvious even without the keyword—you're reading from a socket, querying a database, making an HTTP request. The explicitness doesn't really prevent race conditions or timing bugs. Meanwhile, function colors infect everything. One async library forces your entire call stack to be async. You end up maintaining both sync and async versions of the same code, or the ecosystem just splits in two.

With gevent, there's no such problem. You just call functions. Spawn them if you want concurrency, call them normally if you don't. Go's goroutines and Project Loom are popular for good reasons—they make concurrency accessible without the cognitive overhead.

Python's choice is history now, and there's no going back. But looking at how things turned out, I can't help but think the more practical path was right there, and we walked past it.

Did you know you can get similar concurrency as asyncio/ASGI in Flask, by using gevent? It's been possible as long as Flask has existed! Turns out we never documented it, so how would anyone have known? Fixed that https://flask.palletsprojects.com/en/stable/gevent/ #Python #Flask #gevent

Idea: "The unbillionaires list", to promote contributors to the common.

A collaborative website that lists people who created something useful to millions but purposedly choose to put in in the common and didn’t earn money directly from it (or not as much as expected)

Besides those listed in https://ploum.net/2026-01-22-why-no-european-google.html

I would add Henri Dunant (Red Cross, he died in great poverty), Didier Pittet (who invented the hydroalcoolic gel we now use everyday).

@kai In Korea, we traditionally don't provide any slippers. However, some households do so nowadays.

After months of struggling with the “zombie post” issue on Hackers' Pub—where deleted posts wouldn't disappear from remote servers—I had a sudden hypothesis today. As I dug into it, I realized it's a structural issue with Fedify's MessageQueue system: Create(Note) and Delete(Note) activities can be delivered out of order, causing remote instances to receive Delete(Note) before Create(Note).

The fix will likely require API changes, so this will probably need to wait for #Fedify 2.0.0.

#ActivityPub #fedidev

A hand picked list of fediverse events put together by @liaizon, if you want an event added to this list please reply to this post, or you can DM me.

UPCOMING EVENTS:

April 28th–30th, online

• FediForum Spring 2026 by @fediforum

April 29th, Montréal, CA

• Fediverse Night at @foulab

May 4th, Berlin, DE

• Fediverse Stammtisch at @cbase

May 4th, Hamburg, DE

• 2MR - The festival of great examples at Bucerius Law School

May 27, Montréal, CA

• Fediverse Night at @foulab

July 8th–12th, Germany

• DWeb Camp 2026 by @dweb

August 4th–9th, Gedelitz, Germany

• FediCamp 2026

Aug 6th–9th, Vancouver, CA

• FediCon @ FOSSY

Aug 8th–9th, Taipei, TW

• Fediverse & Social Web track at @COSCUP

September 11th to 13th, Berlin, DE

• Berlin FediDay 2026 by @berlinfediday

COMPLETED EVENTS:

Jan 26th, online

• Fediverse-Sprechstunde (in German)

Jan 31st, Brussels

• FOSDEM: Fediverse Integration into (EU) Public Administration

• FOSDEM: Social Web Devroom (25 presentations)

February 1st, Berlin

• Digital Independence Day: Punk Tour of the Fediverse (in German/English)

February 1st, Brussels

• FOSDEM: Shaping the Future of Events and Calendars in the Fediverse
• FOSDEM: The Fediverse and the EU's DSA: solving the challenges of modern social media?

February 3rd, Berlin

• BERLIN FEDERATED NETWORK EXPLORATION CIRCLE: Fedify

February 4th + 5th, London

• Protocols for Publishers

February 6th, online

• David Revoy on Fireside Fedi
• Fresh Friday on TIBtv
• NHAM Sound Table

February 7th and 8th, online

• Piefed Hackathon

February 11th, Edmonton

• Move Slowly and Build Bridges by Robert W. Gehl book launch and panel

February 11th, online

• Hubzilla Workshop

February 14th, Amsterdam

• <3 Free Software Day: Bonfire presentation

February 15th, Murcia

• Fedifiesta

February 17th, Seattle

• dwebber workshop at INTDEV

February 22nd, Vancouver

• FediCollective: Co-Creating the Web

February 24th, Montreal

• FediMTL: digital sovereignty and the social web

February 24th, Berlin

• ATProto Meetup

February 25th, Montreal

• Faulab Fediverse Night

February 28th, Alicante

• 2a FEDIFESTA

February 28th, Raleigh

• Raleigh Fediverse Meet Up!

February 28th, Cardiff

• Tŵt app launch

February 28th, Rome

• Quinta Assemblea di Puntarella.party - A/Social indipendente de Roma

March 2nd, online

• Growing the Open Social Web: An Online FediForum Un-Workshop

March 1st, Lisbon

• Cooperativa Rizoma: Digital Independence Day

March 1st, Bielefeld

• DI.DAY: Wir machen unsere sozialen Medien selber

March 5th, online

• W3C Forum/Threaded Discussions Task Force Meeting

March 19th + 20th, Amsterdam

• Nodes on a Web: The Fediverse in/for Public Institutions

March 25, Montréal, CA

• Fediverse Night at @foulab

March 28th, Seoul, KR

• Fedidev KR 스프린트 세 번째 모임 by @fedidevkr

Fedify로 ActivityPub 객체 룩업해서 한 페이지로 만드는거 만들어봤는데 생각해보면 그냥 Mastodon처럼 글자 제한이 작은 쪽만 문제라서 Mastodon API 써서 하는게 좋았겠다는 생각이 들고 그리고 이미 그런 구현체는 있었다 (당연). 번역해서 보려고 모 서비스에 넘기려던 글은 타임아웃에 걸리는지 안 넘어가지는데 내일 마저 봐야지..

https://ap-thread-reader.fly.dev/

@ianthetechie Yeah, I need to be exposed to English-speaking environments more!

In cultures like Korea and Japan, taking off your shoes at home is a long-standing tradition. I'm curious about how this practice varies across different regions and households in the fediverse.

How does your household handle shoes indoors?

@steve @liaizon Yeah, I'm going to FOSDEM 2026 as well!

I want to become fluent in English. Not reading and writing, but speaking.

I'll hopefully be here:

On February 3rd (very soon!) I am hosting another [BERLIN FEDERATED NETWORK EXPLORATION CIRCLE] at @offline. It's a chance to meet and talk with people who are interested in the #fediverse & networking & exploration & circ---you get the idea.

We have the pleasure of having @hongminhee who will give a presentation about @fedify "an opinionated #ActivityPub framework for TypeScript that handles the protocol plumbing"

It is an open free event and everyone is welcome!

After deep thinking, I've designed a satisfying solution and broke it down into 4 issues:

• Annotations system (#83): Low-level primitive that allows passing runtime context to parsers via parse() options

• SourceContext interface (#85): High-level system for composing multiple data sources (env, config, etc.) with clear priority ordering via runWith()

• @optique/config (#84): Configuration file support with Standard Schema validation (Zod, Valibot, etc.)

• @optique/env (#86): Environment variables support with automatic type conversion

The key insight: use a two-pass parsing approach where the first pass extracts the config file path, then the second pass runs with config data injected as annotations. All sources can be composed together with runWith([envContext, configContext]) for automatic priority handling: CLI > environment variables > configuration file > default values.

My wife picked up a zine that is advertising the fediverse.

Would it be a good idea to add a feature for handling configuration files to Optique? 🤔

Hollo 0.7.0: Advanced search, faster notifications, and improved client compatibility

It's been a while since our last release, and we're excited to finally share Hollo 0.7.0 with you. This release brings a lot of improvements that we've been working on over the past months—from powerful new search capabilities to significant performance gains that should make your daily Hollo experience noticeably snappier.

Let's dive into what's new.

Highlights

Search gets a major upgrade

One of the most requested features has been better search, and we're happy to deliver. Hollo now supports Mastodon-compatible search operators, so you can finally filter your searches the way you've always wanted:

• has:media/has:poll — Find posts with attachments or polls
• is:reply/is:sensitive — Filter by post type
• language:xx — Search in a specific language
• from:username — Find posts from a specific person
• mentions:username — Find posts mentioning someone
• before:YYYY-MM-DD/after:YYYY-MM-DD — Search within a date range
• Combine them with - for negation, OR for alternatives, and parentheses for grouping

For example, (from:alice OR from:bob) has:poll -is:reply will find polls from Alice or Bob that aren't replies.

We've also made search much faster. URL and handle searches that used to take 8–10 seconds now complete in about 1.4 seconds—an 85% improvement.

Notifications are faster than ever

We completely rebuilt how notifications work under the hood. Instead of computing notifications on every request, Hollo now stores them as they happen. The result? About 24% faster notification loading (down from 2.5s to 1.9s).

On top of that, we've implemented Mastodon's v2 grouped notifications API, which groups similar notifications together server-side. This means less work for your client app and a cleaner notification experience.

Everything loads faster with compression

All API responses are now compressed, reducing their size by 70–92%. Some real numbers: notification responses dropped from 767KB to 58KB, and home timeline responses went from 91KB to 14KB. You'll notice faster load times, especially on slower connections.

Quote notifications

When someone quotes your post, you'll now get a notification about it. And if the original author edits a post you've quoted, you'll be notified too. These are the new quote and quoted_update notification types from Mastodon 4.5.0.

Background import processing

Importing your data (follows, lists, muted/blocked accounts, bookmarks) used to block the entire request until it finished. Now imports run in the background, and you can watch the progress in real-time. Much better for large imports. Thanks to Juyoung Jung for implementing this in #295.

Other improvements

• Upgraded Fedify to 1.10.0.
• Instance API responses now include proper thumbnails, actual stats, and correct values for max_featured_tags and max_pinned_statuses. Thanks to Juyoung Jung for this improvement in #296.
• The notifications API now includes a prev link in pagination headers, which was tracked in #312.
• Replaced the deprecated fluent-ffmpeg package with direct ffmpeg calls. If video thumbnail generation fails, you'll get a default image instead of an error. Thanks to Peter Jeschke for this fix in #333.

Bug fixes

• Emelia Smith fixed an issue where POST /api/v1/statuses and PUT /api/v1/statuses/:id were rejecting FormData requests in #171.
• Fixed log files writing multiple JSON objects on a single line, as reported in #174.
• Lee ByeongJun fixed POST /api/v1/statuses rejecting null values in optional fields in #179.
• Juyoung Jung fixed OAuth token endpoint issues with clients that send credentials in both the header and body in #296.
• Fixed OAuth token endpoint failing to parse requests from clients that don't send a Content-Type header.
• Peter Jeschke fixed notification endpoints returning 500 errors for unknown notification types in #334.
• Fixed /api/v2/search not respecting the limit parameter, as reported in #210.

Upgrading

Docker

Pull the latest image and restart your container:

docker pull ghcr.io/fedify-dev/hollo:0.7.0
docker compose up -d

Railway

Go to your Railway dashboard, select your Hollo service, and click Redeploy from the deployments menu.

Manual installation

Pull the latest code and reinstall dependencies:

git pull origin stable
pnpm install
pnpm run prod

Thank you to our contributors

This release wouldn't have been possible without the contributions from our community. A big thank you to Emelia Smith (@thisismissem), Juyoung Jung (@quadr), Lee ByeongJun (@joonnot), and Peter Jeschke (@peter@jeschke.dev) for their pull requests and bug reports. We really appreciate your help in making Hollo better!

We've published an AI usage policy for the Fedify project, inspired by Ghostty's approach.

TL;DR: AI tools are welcome, but contributions must disclose AI usage, be tied to accepted issues, and be human-verified. Maintainers are exempt.

https://github.com/fedify-dev/fedify/blob/main/AI_POLICY.md

ioriとFedify

ioriがActivityPubをサポートできているのは、間違いなくFedifyのおかげである。

自分でActivityPubの仕様を一から実装しようとしたことはこれまでに何度もあるが、以下の問題にぶつかり、いつも挫折してきた。

• データモデリングの対象が広範囲に及ぶ
  • Vocabularyが多岐にわたる
  • オブジェクトタイプやアクタータイプが多い
• ネットワーク通信の仕様が複雑
  • HTTPシグネチャチャの実装
  • JSON-LDのコンテキスト解決

私が本当に提供したいのはナレッジ管理サービスであり、ActivityPubの実装ではない。Fedifyはこれらの複雑さを抽象化し、開発者がビジネスロジックに集中できるようにしてくれる。

Ghostty has a really well-balanced AI usage policy. It doesn't ban AI tools outright, but it sets clear boundaries to prevent the common problems we're seeing in open source contributions these days.

What stands out is that it's not about being anti-AI. The policy explicitly says the maintainers use AI themselves. The rules are there because too many people treat AI as a magic button that lets them contribute without actually understanding or testing what they're submitting. The requirement that AI-generated PRs must be for accepted issues only, fully tested by humans, and properly disclosed feels like basic respect for maintainers' time.

I'm thinking of adopting something similar for my projects, even though they're not at Ghostty's scale yet. Better to set expectations early.

@julian @reiver Yes, true. Fedify can represent multiple keys for an actor, and indeed Hollo and Hackers' Pub do so!

@reiver From personal experience, at the very least anything based on @fedify can represent multiple keys for an actor.

FEP-521a has a list of implementations: https://codeberg.org/fediverse/fep/src/branch/main/fep/521a/fep-521a.md#implementations

On changing keys, I used to think this was impossible, but then I saw Claire mention that Mastodon will simply accept a changed key as long as the valid updated actor can be fetched from its canonical URI. So I guess that might work straightforwardly?

Ghostty has a really well-balanced AI usage policy. It doesn't ban AI tools outright, but it sets clear boundaries to prevent the common problems we're seeing in open source contributions these days.

What stands out is that it's not about being anti-AI. The policy explicitly says the maintainers use AI themselves. The rules are there because too many people treat AI as a magic button that lets them contribute without actually understanding or testing what they're submitting. The requirement that AI-generated PRs must be for accepted issues only, fully tested by humans, and properly disclosed feels like basic respect for maintainers' time.

I'm thinking of adopting something similar for my projects, even though they're not at Ghostty's scale yet. Better to set expectations early.

來日(내일) 늦잠 자면 안 되는데, 아직 자고 싶지 않다…