洪 民憙 (Hong Minhee)

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

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

Instead of using git as a database, what if you used database as a git?

https://nesbitt.io/2026/02/26/git-in-postgres.html

I making auto-translated FEP document for Japanese, trying local models...

@liaizon @julian @rick To be honest, I'm not really waiting for FEP standardization. It's more likely that the task of adding the GTS interaction policy vocabulary to Fedify will be included in the roadmap for the next version. (Or maybe the one after that.) Only after that prerequisite work is done can support for Mastodon-style quote posts be added to Fedify, I think.

@silverpill Ah, I see. In that case, it would be great if canonical permalinks could be decided for the FEP documents first!

@liaizon @rick We have an issue for this!

https://github.com/fedify-dev/fedify/issues/452

There's now a proper rendered web interface for FEPs at https://fediverse.codeberg.page/fep/fep/*/, which is much nicer to read than the raw Markdown source on Codeberg. But the canonical permalink, https://w3id.org/fep/*, still redirects to the Markdown file rather than the rendered page.

Would it make sense to update the w3id.org redirect to point to the rendered version instead? It seems like the better experience for anyone following a FEP link, and arguably what a “permanent” link should resolve to—something human-readable.

I'm not sure who manages the w3id.org/fep/ redirect configuration. (It lives in the perma-id/w3id.org GitHub repo, so it would just be a PR, but I'd want to get community consensus first rather than just send one in unilaterally.)

#fedidev #fep #fediverse #ActivityPub

There's now a proper rendered web interface for FEPs at https://fediverse.codeberg.page/fep/fep/*/, which is much nicer to read than the raw Markdown source on Codeberg. But the canonical permalink, https://w3id.org/fep/*, still redirects to the Markdown file rather than the rendered page.

Would it make sense to update the w3id.org redirect to point to the rendered version instead? It seems like the better experience for anyone following a FEP link, and arguably what a “permanent” link should resolve to—something human-readable.

I'm not sure who manages the w3id.org/fep/ redirect configuration. (It lives in the perma-id/w3id.org GitHub repo, so it would just be a PR, but I'd want to get community consensus first rather than just send one in unilaterally.)

#fedidev #fep #fediverse #ActivityPub

日本かアジア圏でActivityPubとかオープンデータとかシビックテックのカンファレンスやイベントがあればちょっとずつ参加していきたいな。英語もまた話せるように鍛え直さないと…

シビックテックで取り組んでる課題をチームの皆で話してて、データはJSON-LDで記述したほうが良さそうとか、いずれシェア機能が欲しいねとか、コンテンツはオープンデータ化を前提としてデータの帰属は市民や地域コミュニティとしたいね等々を話し合う中で、「なんか…ActivityPub感…」と思った。
ActivityPubをオープンデータの流通・蓄積・活用の際に用いている取り組みとかって、あるのかな？
Open GLAMなどでありそうな気もするけど、どうなんだろ。

AIがバイナリを吐きだすとかの妄言が意味わからないのは、効率の問題もあるけど(バイナリより高級言語のほうが情報のせられる)、開いた状態のものを閉じた状態に戻そうとするからだし、たぶん並列AIに対して関心がもてないのもそこで、AIが理解すればいいだけになると過程全体が閉じてるからだとおもう。

ソフトウェアがソフトなのは、その生産過程が開かれた状態のままだから。これが近代の製品と違う。

成果物と成果物を生成するシステムがある意味交換可能で可視的というのは、現代の特徴かもしれない

Starting with Deno 2.7, you can now use the Temporal API without the --unstable-temporal flag!

https://deno.com/blog/v2.7

@hypolite That last point about oxygen in the room is, I think, the most important thing you've said in this whole exchange—and I find myself largely agreeing with it. The current concentration of resources around a handful of private models is itself what makes the political organizing you'd need for a public alternative so difficult. We agree on the diagnosis more than it might appear.

Where I'd push back, gently, is on the sequencing. “We can't build the structures now, so we wait for the collapse” assumes that the aftermath will be more legible than it probably will be. The people who made billions, as you say, won't go silently—and they'll have a head start on shaping whatever comes next. I'd rather that there be some idea of what “next” should look like, articulated now, even imperfectly, than have that conversation start from scratch in the wreckage.

On the hubris point: I share your discomfort with “built to create God.” But I'd distinguish between the AGI ambitions of specific companies and the underlying technology. The former is what I'd most want to see deflated. What survives that deflation is the open question.

I have archived the apmodel repository. While developing apkit, I encountered the problematic aspects of apmodel, so I plan to redesign it. This does not mean I intend to abandon apkit.

@hypolite The Jevons point is well taken, but I think the assumption that model size and model capability move in lockstep is already starting to break down. Smaller, more specialized models have been closing the gap with frontier models faster than most people expected a couple of years ago. That doesn't settle the question, but it does suggest the trajectory isn't as fixed as the current “bigger is better” trend implies.

On IP: I think that argument assumes the legal and social framework around training data is static. If a public foundation model existed, the question of how its training data was collected would be negotiated very differently—with public accountability, with legislative pressure, with the possibility of opt-in or compensated datasets. The current situation is partly so bad because private actors made unilateral decisions with no one to answer to. That changes when the entity doing the training is public.

But honestly, what strikes me most about your last message is that we may be closer in position than the argument suggests. You're saying rejection is symbolic, but useful as a social signal that could hasten the collapse of the current unsustainable model. I'm not sure I disagree with that. Where we differ, I think, is in what we expect to find in the ruins. You seem to expect something more modest and less harmful to emerge on its own. I'm less confident about that—I think what fills the vacuum depends heavily on what political and social structures we've built in the meantime. Which is, I suppose, exactly why I think the direction of reclamation matters now, even if the specific path is still unclear.

연합우주를 어떻게하면 사람들이 더 자발적으로 다가오고 더 재밌는 컨텐츠로 만들 수 있을까? 라는 고민이 들면서도 한편으로는 니치한 것 자체가 연합우주의 감성이 아닌가 싶은 생각이 들고, 한편으로는 내가 만드는 연합우주 서비스 자체만으로 사람들에게 어필이 되었으면 좋겠고 복잡한 생각이 드는 것이다..

@hypolite You raise fair points, and I don't think I can fully refute them. The Uber analogy is genuinely worrying, and I share your concern about what “profitability” will eventually mean for people who currently depend on LLMs as tools.

That said, I think there's a tension in your argument worth examining. You note that LLMs are still fledgling and heavily subsidized, and I agree. But that same fledgling status means we're also at the beginning of the efficiency curve, not the end. Inference costs have dropped dramatically over the past two years, and experiments like DeepSeek suggest training costs can fall significantly too. “It's expensive now” and “it will always be expensive” are two different claims, and I don't think the first settles the second.

On the redundancy point: the current setup has every major company independently training overlapping foundation models in competition with each other, which is itself an enormous waste. If every software company built its own operating system from scratch instead of sharing one, the cost of software development would be staggering. Public infrastructure like CERN works precisely because the baseline investment is shared, and innovation happens on top of it. I think a similar logic applies here, even if the path there is unclear.

But the question I keep coming back to is: what does rejection actually achieve? If the goal is to limit the harms you describe—the IP violations, the labor displacement, the toll-booth dynamic—it's not obvious to me that individuals and communities blocking scrapers meaningfully slows any of that down. The companies driving this have enough momentum and capital that our refusal mostly affects us. I'm not saying refusal is wrong; I'm genuinely uncertain. I just think the burden of demonstrating impact falls on both sides of this argument, not only on mine.

@Yohei_Zuho @kur0den0010 ありがとうございます！6日（金）にお会いできると嬉しいです。もしよろしければ、私の旅行仲間であるHaze Leeさん（@nebuleto）も一緒に行っても大丈夫でしょうか？（日本語可能です）

3月4日(水)から11日(水)まで東京に滞在します。この機会に日本のフェディバースの皆さんとお会いしたいです。ランチでもディナーでも、お茶やコーヒーでも構いません。私と会ってくださる方はいらっしゃいますか？食事やお茶は私がおごります。私はこの期間中、特に予定がないので、皆さんのご都合に合わせることができます。（ただし、最終日を除きます）

By the way, if you're building a complex CLI app in Node.js, Deno, or Bun, please give Optique a try—I bet you will be satisfied. Curious why? Read this document.

One good thing of my extended sabatical from corporate employment is that while I'm working on #GoActivityPub there's so many things to do, that as soon as something interesting catches my eye, I can go explore it and learn a new thing that can be used, adapted or added to one of the components of the library or its adjacent tooling and applications.

Currently, I'm excited to replace the existing HTML sanitizer for TrustedTypes and setHTML in #ONI as they're finally making its way to Firefox.

#Optique 1.0.0 is shaping up, and three API changes are worth knowing about in advance.

• Runner consolidation: run() from @optique/run now accepts source contexts directly, which makes runWith() and runWithConfig() redundant for most use cases. runWithConfig() is removed outright—no deprecation, since we have a major version to absorb the break. For the typical CLI, run() is now the single entry point.

• Meta command config redesign: help, version, and completion in RunOptions no longer use mode: "command" | "option" | "both". Each now takes independent command and option sub-configs, which makes it possible to give --help a -h alias, hide a meta command from usage lines while keeping it in the help listing, or group the command and option forms differently. String shorthands (help: "both", version: "1.2.3", etc.) still work exactly as before.

• Config-file-relative paths: bindConfig()'s key callback now receives config file metadata as a second argument—configDir and configPath—so you can resolve paths relative to the config file's location rather than the working directory. This matches how tools like the TypeScript compiler handle outDir and similar path options.

More details on the 1.0.0 milestone.

@hypolite Yeah, I’ll admit the licensing idea is “cute.” It was just something that came to mind on the spot. As I wrote in my piece, Acting materialistically in an imperfect world: LLMs as means of production and social relations, I think there are still many other potential ways to reclaim LLMs from private corporations. The point is, the whole act of rejecting LLMs isn't going to do much to help us achieve what we want. I believe the only hope lies in reclaiming the LLMs themselves for the public good.

3月4日(水)から11日(水)まで東京に滞在します。この機会に日本のフェディバースの皆さんとお会いしたいです。ランチでもディナーでも、お茶やコーヒーでも構いません。私と会ってくださる方はいらっしゃいますか？食事やお茶は私がおごります。私はこの期間中、特に予定がないので、皆さんのご都合に合わせることができます。（ただし、最終日を除きます）

@cnx To be honest, I tried using conventional machine translation to properly understand your comment, but it was useless, so I had to use an LLM. I run into this kind of situation often.

My position is that the public should reclaim the LLMs that are currently monopolized by private corporations. On this topic, I would appreciate it if you read my previous article, Histomat of F/OSS: We should reclaim LLMs, not reject them.

@liaizon @hypolite @yhancik

One thing I find a bit disappointing is that the Sanitizer API is [Exposed=Window] only, so there's no way to use it server-side in Node.js or Deno. A simple sanitize(html: string): string method would have been enough to retire a whole category of npm packages. The irony is that sanitizing untrusted HTML is arguably more common on the server—that's where you receive user input, store it, and render it back.

For now, server-side JavaScript still has to rely on DOMPurify (dragging jsdom along with it) or something like sanitize-html, each shipping its own HTML parser that may subtly disagree with how browsers actually parse markup—which is exactly the problem this API was supposed to solve.

https://hacks.mozilla.org/2026/02/goodbye-innerhtml-hello-sethtml-stronger-xss-protection-in-firefox-148/

The Sanitizer API landed in Firefox 148, along with element.setHTML().

This lets you fully configure how HTML strings are cleaned as they're parsed.

https://hacks.mozilla.org/2026/02/goodbye-innerhtml-hello-sethtml-stronger-xss-protection-in-firefox-148/

洪民憙さんのサイトめちゃくちゃ恰好いいな