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

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

@Gargron @liaizon That might be the case for European languages. But for distant language pairs like English → Korean, LLM-based translation is necessary. This is especially true for deep discussions like in @tante's writing.

「@tante's decision to block LLM scrapers is consistent with his own logic, but it ended up reinforcing the asymmetry between readers who are fluent in English and those who are not. This is not just an irony. The asymmetry operates across the whole of technology discourse. Whose viewpoint is set as the default? What social relations produced that default?」
- @hongminhee
https://writings.hongminhee.org/2026/02/acting-materialistically-in-an-imperfect-world

https://writings.hongminhee.org/2026/01/histomat-foss-llm/index.ja.html

労働が非人間的になるのは「疎外」と呼ばれるけど、先日洪民憙さんの記事を読んだばかりだった。

Marxは『資本論』第一巻で、イギリスのラッダイト運動をこう評した。

労働者が機械そのものと機械の資本主義的利用とを区別し、したがって物質的生産手段そのものではなく、その社会的搾取形態を攻撃することを学ぶまでには、時間と経験が必要だった。

機織り機を打ち壊した労働者たちの怒りは正当だった。方向が間違っていただけだ。問題は機械ではなく、機械をめぐる資本主義的社会関係だった——機械が労働時間を短縮するどころか延長し、労働者を解放するどころか機械の付属物にしてしまうのは、機械の本性ではなく、機械を配置する方式の問題だった。Marxは彼らを嘲笑したのではなく、闘争が成熟していく過程を叙述したのだ。

https://writings.hongminhee.org/2026/02/acting-materialistically-in-an-imperfect-world/

F/OSSの唯物史観——LLMを拒絶するのではなく、取り戻すべきだ — 洪民憙雑記
https://writings.hongminhee.org/2026/01/histomat-foss-llm/

🚀 New libraries for @graphql on Vapor and Hummingbird dropped!

Expose GraphQL APIs with just one line of code:
routeBuilder.graphql(schema: schema) { ... }

✅ Full spec compliance
✅ WebSocket subscriptions
✅ Built-in GraphiQL IDE

Check them out 👇
https://forums.swift.org/t/introducing-graphql-vapor-hummingbird-packages/84758

Fedify로 어디까지 할 수 있나 프로덕션에서 실험하는 사람이 돼

미스키에서도, 마스토돈에서도, 해커스펍에서도 호환이 되는 밋업 플랫폼 만들고 있는데 관심있으신분

@julian That's a fair point; honestly, right now there's no reliable way to know. If a server supports both RFC 9421 and draft cavage, and you lead with cavage, you can't infer anything about its RFC 9421 support from a successful response.

The workaround I applied is intentionally temporary, just to keep things working while Bonfire instances catch up with the fix. Once they do, I'll revert firstKnock back to RFC 9421.

The longer-term answer to your question might be FEP-844e, which proposes a capability discovery mechanism—servers could explicitly advertise which specifications they implement (including RFC 9421) via an Application object. That would make the guesswork unnecessary. It's still a draft, but worth keeping an eye on.

@elena Thanks! 🥰

A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent a follow request—but the Accept never came back, even though they hadn't enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.

I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.

This matters because Fedify implements a double-knocking mechanism—if a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.

I filed two issues on the Bonfire #ActivityPub repo—one requesting RFC 9421 support, and one about returning 401 on invalid signatures. For the latter, I also sent a PR, which got merged pretty quickly: bonfire-networks/activity_pub#9.

That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.

One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as “supports RFC 9421”—because they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.

After all that, the mutual follow went through and my DM reply landed. Worth it.

#fedidev #fediverse #Hollo #HackersPub

The recent Hollo 0.7.3 and 0.7.4 updates have improved interoperability with #Bonfire. The issue where sending/receiving DMs or mutual following with Bonfire wasn't working properly has been resolved.

@box464 Thank you! I've got an account on the indieweb.studio instance for now, but I'll ask you if I need another one later!

@fedicat Oh, didn't know that. Thank you!

Hi #fediverse and #ActivityPub developers!

I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.

Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!

#fedidev #BonfireNetworks

"問いはF/OSSコードに対するLLM訓練がある抽象的意味で倫理的かではない。どのような条件で倫理的かだ。答えはF/OSSがこれまで示してきた答えと同じだと信じる。我々が付与する自由が保存され伝達されるとき、改善がコモンズに戻るとき、知識が自由に留まるとき、倫理的なのだ。"

まさに「これが唯物史観だ」という文章。

F/OSSの唯物史観——LLMを拒絶するのではなく、取り戻すべきだ — 洪民憙雑記
https://writings.hongminhee.org/2026/01/histomat-foss-llm/index.ja.html

日本のIT系はこういう主張する人をあんまり見たことないのはおろか、日本の左派からも、こんな硬派なマルクス主義的主張はほとんど見ない気がする。

いやていうか生産手段のコモン化ってもともとマルクス主義のテーゼだよな

洪民憙さんのこの記事、ブーストしてたが読んでなかった。

めちゃくちゃおもしろかった。 https://writings.hongminhee.org/2026/01/histomat-foss-llm/

ベンヤミンが、映画技術が少数の権力に寡占されていることに対して、市民による再領有を要求したことを思いだしながら読んだ(「複製技術時代の芸術」)。ベンヤミンが生きているころに、まだ技術の再領有は実践的にはかなり困難だったとおもう(というか方法論もなにもなかった)けど、いま同じ問題が実践的に解決可能な課題として問われているのだなと思う。

https://writings.hongminhee.org/2026/01/histomat-foss-llm/index.ja.html

>私は自分のコードがLLM訓練に使われることを望んでいる。望んでいないのは、その訓練によってAI企業の私有財産となるプロプライエタリなモデルが作られることだ。

とてもいい文章だった。
まぁ、自分はフルスクラッチで良いOSSを作れるような技術力はなく、LLMにおんぶにだっこ状態なので、あんまり何かを言う権利は無いけど。

今のOSS、詳しくは知らんけど、多くの人は本業があって、その稼ぎでご飯を食べながらcontributeして成立していると思っているので、じゃあ仮にLLMのモデル公開まで含めたライセンシングになったとき、そのLLMのコストは持続可能な形でどこから出るべきなんだろうか？と思った(オープンなLLMモデルも、戦略としてオープンにしてるけど、かなりの額の赤字を垂れ流してると思うので)。

Instead of trying to prevent LLM training on our code, we should be demanding that the models themselves be freed.

I want my code to be used for LLM training. What I don't want is for that training to produce proprietary models that become the exclusive property of AI corporations. The problem isn't the technology or even the training process itself. The problem is the enclosure of the commons, the privatization of collective knowledge, the one-way flow of value from the many to the few.

This isn't a new problem. It's the same problem FLOSS has always fought, just wearing new clothes.

https://writings.hongminhee.org/2026/01/histomat-foss-llm/

@stefan Thanks!

@smallcircles Okay, we'll look into the list, and send pull requests!

The really cool thing about this new architecture is that it can enable Client to Server architecture for AP with fedify (maybe vocab packages could be used in the browser too!)

@david_megginson @ben

Btw, just found the v2 release announcement of @fedify and that is a prime example on how, on the grassroots environment end of the spectrum we can maneuvre into better territory.

Kudos to the #fedify developers. Handing people tools they need to focus on solutions, and build without getting thrown into deep on-the-wire impl detail reeds to worry about.

That is the positive side of the equation. There's not only a big uptick in interest for the #SocialAPI i.e. #ActivityPub client-to-server, which offers new opportunity to correct course. But also are there more #FOSS projects focused on robust tool and library support for the 'Solution developer' stakeholder.

In the revamp of the delightful commons initiative, made possible with support of @nlnet I emphasized all these projects, while I de-emphasized the apps that are already doing good for themself, but contribute to further divergence from open standards.

https://delightful.coding.social

https://hollo.social/@fedify/019c8521-92ef-7d5f-be4d-c50eae575742

"Fedify 2.0.0 está aqui!

Esta é a maior atualização da história do Fedify. Destaques:

**Arquitetura modular** – O pacote monolítico `@fedify/fedify` foi dividido em pacotes independentes e focados: `@fedify/vocab`, `@fedify/vocab-runtime`, `@fedify/vocab-tools`, `@fedify/webfinger` e outros. Pacotes menores, imports mais limpos e a possibilidade de estender o ActivityPub com tipos de vocabulário personalizados.

**Painel de depuração em tempo real** – O novo pacote `@fedify/debugger` oferece um dashboard ao vivo em `/__debug__/` que mostra todo o tráfego de federação: traces, detalhes das atividades, verificação de assinaturas e logs correlacionados. Basta envolver seu objeto `Federation` e pronto.

**Suporte a relay do ActivityPub** – Suporte nativo a relays via `@fedify/relay` e o comando CLI `fedify relay`. Compatível com os protocolos Mastodon-style e LitePub-style (FEP-ae0c).

**Entrega ordenada de mensagens** – A nova opção `orderingKey` resolve o problema do "post zumbi", quando um `Delete` chega antes do seu `Create`. Atividades com a mesma chave são entregues garantidamente na ordem FIFO.

**Tratamento de falhas permanentes** – `setOutboxPermanentFailureHandler()` permite reagir quando uma inbox remota retorna 404 ou 410, possibilitando limpar seguidores inacessíveis em vez de tentar reenviar indefinidamente.

Outras novidades incluem negociação de conteúdo no nível do middleware, `@fedify/lint` para regras compartilhadas de linting, `@fedify/create` para scaffolding rápido de projetos, arquivos de configuração para a CLI, suporte nativo à CLI em Node.js/Bun e diversos fixes de bugs.

Esta versão conta com contribuições significativas de participantes do OSSCA da Coreia. Agradecemos imensamente a todos envolvidos!

Trata-se de uma release major com breaking changes. Consulte o guia de migração antes de atualizar.

Notas completas da release: https://github.com/fedify-dev/fedify/discussions/580

#Fedify #ActivityPub #fediverso #fedidev #TypeScript"

@fediverse @tecnologia @academicos @internet (pode seguir para acompanhar os assuntos ou marcar para amplificar a postagem até no #lemmy tb)

@fedify https://hollo.social/@fedify/019c8521-92ef-7d5f-be4d-c50eae575742

Fedify 2.0.0をリリースしました！

Fedify史上最大のリリースです。主な変更点をご紹介します：

• モジュラーアーキテクチャ — これまでのモノリシックな@fedify/fedifyパッケージを、@fedify/vocab、@fedify/vocab-runtime、@fedify/vocab-tools、@fedify/webfingerなど、独立したパッケージに分割しました。バンドルサイズの削減、インポートの整理に加え、カスタム語彙型によるActivityPubの拡張も可能になりました。
• リアルタイムデバッグダッシュボード — 新しい@fedify/debuggerパッケージにより、/__debug__/パスにライブダッシュボードを表示できます。連合トラフィックのトレース、アクティビティの詳細、署名検証、ログまで一目で確認できます。既存のFederationオブジェクトをラップするだけで使えます。
• ActivityPubリレーサポート — @fedify/relayパッケージとfedify relayCLIコマンドで、リレーサーバーをすぐに立ち上げることができます。Mastodon方式とLitePub方式の両方に対応しています（FEP-ae0c）。
• 順序保証メッセージ配信 — 新しいorderingKeyオプションにより、「ゾンビ投稿」問題を解決しました。DeleteがCreateより先に到着してしまう問題がなくなります。同じキーを共有するアクティビティはFIFO順序が保証されます。
• 永続的な配信失敗の処理 — setOutboxPermanentFailureHandler()で、リモートのインボックスが404や410を返した際に対応できるようになりました。到達不能なフォロワーの整理などが可能です。

その他にも、ミドルウェアレベルでのコンテンツネゴシエーション、@fedify/lint、@fedify/create、CLI設定ファイル、ネイティブNode.js/Bun CLIサポート、多数のバグ修正などが含まれています。

今回のリリースには、韓国のOSSCA（オープンソースコントリビューションアカデミー）参加者の皆さんからの多大な貢献が含まれています。ご協力いただいた全ての方に感謝いたします！

破壊的変更を含むメジャーリリースです。アップグレード前にマイグレーションガイドを必ずご確認ください。

リリースノート全文: https://github.com/fedify-dev/fedify/discussions/580

#Fedify #ActivityPub #fediverse #fedidev #TypeScript

Fedify 2.0.0을 릴리스했습니다!

Fedify 역사상 가장 큰 릴리스입니다. 주요 변경 사항을 소개합니다:

• 모듈형 아키텍처 — 기존의 단일 @fedify/fedify 패키지를 @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger 등 독립적인 패키지들로 분리했습니다. 번들 크기가 줄어들고, 임포트가 깔끔해지며, 커스텀 어휘 타입으로 ActivityPub을 확장할 수도 있습니다.
• 실시간 디버그 대시보드 — 새로운 @fedify/debugger 패키지로 /__debug__/ 경로에 라이브 대시보드를 띄울 수 있습니다. 연합 트래픽의 트레이스, 액티비티 상세, 서명 검증, 로그까지 한눈에 확인할 수 있습니다. 기존 Federation 객체를 감싸기만 하면 됩니다.
• ActivityPub 릴레이 지원 — @fedify/relay 패키지와 fedify relay CLI 명령어로 릴레이 서버를 바로 띄울 수 있습니다. Mastodon 방식과 LitePub 방식 모두 지원합니다(FEP-ae0c).
• 순서 보장 메시지 전달 — 새로운 orderingKey 옵션으로 “좀비 포스트” 문제를 해결합니다. Delete가 Create보다 먼저 도착하는 문제가 더 이상 발생하지 않습니다. 같은 키를 공유하는 액티비티는 FIFO 순서가 보장됩니다.
• 영구 전달 실패 처리 — setOutboxPermanentFailureHandler()로 원격 인박스가 404나 410을 반환할 때 대응할 수 있습니다. 도달 불가능한 팔로워를 정리하는 등의 처리가 가능합니다.

이 외에도 미들웨어 수준의 콘텐츠 협상, @fedify/lint, @fedify/create, CLI 설정 파일, 네이티브 Node.js/Bun CLI 지원, 다수의 버그 수정 등이 포함되어 있습니다.

이번 릴리스에는 한국 OSSCA (오픈소스 컨트리뷰션 아카데미) 참가자분들의 큰 기여가 담겨 있습니다. 참여해 주신 모든 분께 감사드립니다!

브레이킹 체인지가 포함된 메이저 릴리스입니다. 업그레이드 전에 마이그레이션 가이드를 꼭 확인해 주세요.

전체 릴리스 노트: https://github.com/fedify-dev/fedify/discussions/580

#Fedify #ActivityPub #fediverse #fedidev #TypeScript

Fedify 2.0.0 is here!

This is the biggest release in Fedify's history. Here are the highlights:

• Modular architecture — The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
• Real-time debug dashboard — The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
• ActivityPub relay support — First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
• Ordered message delivery — The new orderingKey option solves the “zombie post” problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
• Permanent failure handling — setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.

Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.

This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!

This is a major release with breaking changes—please check the migration guide before upgrading.

Full release notes: https://github.com/fedify-dev/fedify/discussions/580

#Fedify #ActivityPub #fediverse #fedidev #TypeScript