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

洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

1,096 following1,904 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 메인테이너. , , , 等으로 自由 소프트웨어 만듦.

()

Pinned

@hongminhee@hollo.social

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!

en.wikipedia.org

Korean mixed script - Wikipedia

Pinned

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

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

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

speakerdeck.com

国漢文混用体からHolloまで

本発表では、韓国語の「国漢文混用体」(漢字ハングル混じり文)を自分のフェディバース投稿に実装したいという小さな目標から始まった旅路を共有します。 この目標を達成するために、ActivityPubのJSON-LDの複雑さやHTTP Signatures、WebFingerなどの仕様を理解する必要性に…

Pinned

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

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

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

logtape.org

LogTape

Unobtrusive logging library with zero dependencies—library-first design for Deno, Node.js, Bun, browsers, and edge functions

@hongminhee@hollo.social
@hongminhee@hollo.social

I've opened a proposal for to support configuration from plain objects, making it possible to load configs from JSON/YAML/TOML files.

The idea is similar to Python's logging.config.dictConfig()—you'd be able to configure sinks, formatters, and loggers declaratively, making it easier to manage different configs for dev/staging/prod without touching code.

Would love to hear your thoughts, especially if you've worked with similar patterns in other ecosystems.

https://github.com/dahlia/logtape/issues/117

github.com

Support configuration from plain objects · Issue #117 · dahlia/logtape

Summary Add a new @logtape/config package that provides configureFromObject() function to configure LogTape from plain JavaScript objects loaded from JSON, YAML, TOML, or other configuration format...

@kiq@fedibird.com
@bori@baram.me · Reply to 김보리

공개 서버를 운영하다가 닫게 된 것에는 당연히 충분한 고민이 있기는 하니 닫게 된 곡절에 대해서 따지기도 힘들고 이미 정착해 있는 사람들 입장에서는 평소에는 안 들어올때만 트위터 터졌을 때만 찾는 게 꽤나 얄밉기도 하고 운영 종료 통지를 회원 한 사람 한 사람 집에 찾아가서 통보를 할 수도 없고 … 이렇게 할 거면 조금 더 책임감 있게 공개 인스턴스를 개설해야 하는 더 아닌가 싶으면서도 그런 책임감이나 자금이 크나큰 진입 장벽으로 작동하게 되면 가벼운 이야기는 할 수 없는 공간이 될테고 …. 그런 복잡한 문제가 있단 말이죠….

@bori@baram.me

페디버스에서 그럭저럭 큰 인스턴스가 문을 닫는 건 정말… 안타까운 일이긴 한데 물론 당연히 운영측의 고민이 없지는 않았겠지만 오랫동안 자리를 비운 사람들이 생각나서 돌아올 곳이 없어지면 굉장히 … 돌이킬 수 없는 미움을 사게 되겠다는 생각은 늘 하게 되는 것 같아요.

@hongminhee@hollo.social

This is actually taking so long.

A Windows computer screen displaying the “Reset this PC” interface with a purple background. The message reads “Getting things ready. This won't take long” with a loading hourglass icon. A “Cancel” button is visible in the bottom right corner.
ALT text

A Windows computer screen displaying the “Reset this PC” interface with a purple background. The message reads “Getting things ready. This won't take long” with a loading hourglass icon. A “Cancel” button is visible in the bottom right corner.

Upyo 0.4.0をリリースしました。UpyoはNode.js、Deno、Bunなど複数のランタイムで動作するメール送信ライブラリです。

今回の主な変更点:

  • JMAPトランスポートの追加
  • SMTPでのDKIM署名対応
  • メッセージレベルの冪等性キー

https://zenn.dev/hongminhee/articles/c1a304e92c6efa

zenn.dev

Upyo 0.4.0: モダンなプロトコルへの対応とメール認証機能の強化

@hongminhee@hollo.social

Upyo 0.4.0 released. Upyo is an email sending library for Node.js, Deno, Bun, and edge functions. New in this version:

  • JMAP transport for modern email servers
  • DKIM signing support in SMTP transport
  • Message-level idempotency keys for reliable retries

https://github.com/dahlia/upyo/discussions/21

github.com

Upyo 0.4.0: Modern protocols and email authentication · dahlia/upyo · Discussion #21

Upyo is a cross-runtime email library for JavaScript that provides a unified API for sending emails across Node.js, Deno, Bun, and edge functions. It supports multiple transports including SMTP, Ma...

@kroisse@hackers.pub

크리스마스는 새 프로그래밍 언어를 공개하기에 좋은 날이죠. 아직 미완성이지만 요즘 작업하고 있던 프로젝트를 소개합니다. https://github.com/Kroisse/tribute

순수 함수형이고, 모나드는 없고, 소유권도 없고, 타입클래스나 트레잇도 없습니다. 물론 객체 시스템도 없고요. 대신 제네릭과 대수적 효과를 넣을 예정입니다. ad-hoc polymorphism을 배제하고 어디까지 갈 수 있는지 시험해보려는 게 목적 중 하나인데 생각보다 할만할 것 같아요.

그리고 매우 vibe-coded되어 있습니다. Claude Code와 Codex가 없었으면 엄두도 못 냈을 듯.

문법적으로는 Rust와 Gleam에, 의미론적으로는 Gleam과 Unison에 영감을 많이 받았습니다. 사실 Gleam과 Unison 둘 다 네이티브 바이너리로 컴파일을 아직 못 하고 있어서 시작한 프로젝트이기도 합니다. 하지만 정작 Tribute도 첫 타겟은 네이티브가 아니라 WebAssembly 3.0입니다. GC 구현을 만들기 귀찮았거든요.

github.com

GitHub - Kroisse/tribute: This is not the greatest language in the world, no. This is just a tribute.

This is not the greatest language in the world, no. This is just a tribute. - Kroisse/tribute

@moreal@hackers.pub · Reply to Lee Dogeon
@mariusor@metalhead.club

I don't know if people are aware of this Firefox addon that brings discoverability for personal websites that have identity confirmation links to Mastodon profiles: StreetPass for Mastodon.

It's pretty good, it allowed me to find quite a number of people based on incidentally reading their blogs.

addons.mozilla.org/en-US/firef

addons.mozilla.org

StreetPass for Mastodon – Get this Extension for 🦊 Firefox (en-US)

Download StreetPass for Mastodon for Firefox. Find your people on Mastodon

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a framework for building servers that participate in the . It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

  • activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
  • activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
  • activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

  • activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
  • activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

  • MemoryKvStore — filters in-memory keys by prefix
  • SqliteKvStore — uses LIKE query with JSON key pattern
  • PostgresKvStore — uses array slice comparison
  • RedisKvStore — uses SCAN with pattern matching and key deserialization
  • DenoKvStore — delegates to Deno KV's built-in list() API
  • WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

github.com

fedify/CHANGES.md at main · fedify-dev/fedify

ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.

@hongminhee@hollo.social
@hongminhee@hollo.social · Reply to jnkrtech

@jnkrtech Good question! The main reason is composability at the combinator level.

With bifurcated APIs, combining sync and async parsers becomes awkward:

const syncParser = flag("--verbose");
const asyncParser = option("--branch").suggestAsync(getBranches);

// How do you combine these?
object({ verbose: syncParser, branch: asyncParser })  // Type mismatch
objectAsync({ verbose: toAsync(syncParser), branch: asyncParser })  // Explicit conversion needed

This pushes complexity onto users—they have to track which parsers are sync vs async and manually convert at composition boundaries.

With the unified approach (explicit mode parameter with default), the library handles mode propagation automatically:

const combined = object({ verbose: syncParser, branch: asyncParser });
// → Parser<"async", …> inferred automatically

Users only decide sync/async at the leaf parser level; combinators figure out the rest.

I agree the yargs-style “everything is both” can hurt IntelliSense. But with explicit mode parameter (Parser<M extends Mode, T, S>), the types stay predictable—you always know if a parser is "sync" or "async". The conditional type complexity lives inside the library, not in user-facing types.

On a related note, if you learn better by building things, @fedify has a step-by-step tutorial where you create a federated microblog from scratch—implementing actors, inbox/outbox, following, and posts along the way:

https://fedify.dev/tutorial/microblog

fedify.dev

Creating your own federated microblog | Fedify

In this tutorial, we will build a small microblog that implements the ActivityPub protocol, similar to Mastodon or Misskey, using Fedify, an ActivityPub server framework.

@hongminhee@hollo.social

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how / works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

github.com

GitHub - boyter/activitypub: Sequence diagrams of how ActivityPub works

Sequence diagrams of how ActivityPub works. Contribute to boyter/activitypub development by creating an account on GitHub.

@tatmius@vivaldi.net

韓国語の文法解説読んでると、自分がこれまでSVO言語の勉強しかしてこなかったんだな、というのを如実に感じる(母語がSOV言語とはいえ)