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

洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · 993 following · 1395 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 메인테이너. , , , 等으로 自由 소프트웨어 만듦.

()

Fedify: ActivityPub server framework's avatar
Fedify: ActivityPub server framework

@fedify@hollo.social

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.

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

@hongminhee@hollo.social

Now trying to implement a JMAP transport for Upyo

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

@hongminhee@hollo.social

내 트리를 꾸며줘!

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

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

If there's one downside to this keyboard, it's that it's too heavy to be portable. That's because it's a full aluminum keyboard.

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

@hongminhee@hollo.social

I ordered the Keychron Q60 Max yesterday and it arrived today. I tried typing on it and it feels amazing! I'm so happy with it that I can't stop typing on Monkeytype. 😂

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

@hongminhee@hollo.social · Reply to jnkrtech's post

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

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

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

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

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

@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

Fedify: ActivityPub server framework's avatar
Fedify: ActivityPub server framework

@fedify@hollo.social

According to @tchambers's My 2026 Open Social Web Predictions:

Fedify will power the federation layer for at least one mid-sized social platform (500K+ users) that adds ActivityPub support in 2026. The “build vs. buy” calculation for federation shifts decisively toward “just use Fedify.”

We're honored by this recognition and will keep working hard to make adoption easier for everyone. Thank you, Tim!

tatmius(タミアス)'s avatar
tatmius(タミアス)

@tatmius@vivaldi.net

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

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

@hongminhee@hollo.social

Here's a API design challenge I'm working on: adding async support to (CLI argument parser) without breaking the existing sync API.

The tricky part is combinators—when you compose parsers with object() or or(), the combined parser should automatically become async if any child parser is async, but stay sync if all children are sync. This “mode propagation” needs to work at both type level and runtime.

I've prototyped two approaches and documented findings. If you've tackled similar dual-mode API designs, I'd love to hear how you approached it.

https://github.com/dahlia/optique/issues/52

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

@hongminhee@hollo.social

오늘은 @nebuleto 님, @2chanhaeng 님, @z9mb1 님과 함께 西嶺(서령)에 왔다.

불고기
ALT text details불고기
饅頭
ALT text details饅頭
純麵
ALT text details純麵
불고기
ALT text details불고기
불고기
ALT text details불고기
洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to Rastagong's post

@lrwerther Thank you. I appreciate the solidarity.

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

@hongminhee@hollo.social · Reply to Stefan Bohacek's post

@stefan Thanks, I appreciate the support. It's one of those things you never quite get used to.

Kagami is they/them 🏳️‍⚧️'s avatar
Kagami is they/them 🏳️‍⚧️

@krosylight@fosstodon.org · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

@hongminhee And like as if Chinese devs have some fundamental differences than "a programmer out of this community" 🤣

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

@hongminhee@hollo.social

Just had someone leave feedback on my F/OSS project saying “maybe that's fine if a product is focused on your Chinese community.”

I'm Korean. Every single piece of documentation is in English. There's nothing in Chinese anywhere in the project.

This kind of microaggression is exhausting. As a non-white maintainer, you deal with these assumptions constantly—people who feel entitled to your labor while casually othering you based on your name.

It chips away at your motivation. It makes you wonder why you bother.

https://github.com/dahlia/optique/issues/59#issuecomment-3678606022

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

@hongminhee@hollo.social · Reply to marius's post

@mariusor Fair point! To clarify: FediChatBot is just a tech demo for @botkit, the ActivityPub bot framework I've been building. BotKit itself has nothing to do with LLMs—it's for creating any kind of fediverse bot (weather bots, notification bots, RSS feeds, etc.). I just happened to use an LLM for the demo since it makes for an interactive example. Not advocating for AI integration in the fediverse, just showcasing what the framework can do.

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

@hongminhee@hollo.social

Hey @FediChatBot, what LLM are you based on?

Hollo :hollo:'s avatar
Hollo :hollo:

@hollo@hollo.social · Reply to Hollo :hollo:'s post

セキュリティアップデート: Hollo 0.6.19 リリース

FedifyのHTMLパースコードにおけるセキュリティ脆弱性に対応したHollo 0.6.19をリリースしました。

この脆弱性 (CVE-2025-68475) は ReDoS (正規表現によるサービス拒否) の問題であり、攻撃者がフェデレーション操作中に特別に細工されたHTMLレスポンスを送信することで、サービス停止を引き起こす可能性があります。悪意のあるペイロードは小さい (約170バイト) ですが、Node.jsのイベントループを長時間ブロックする可能性があります。

すべてのHollo運営者の皆様には、直ちにバージョン 0.6.19 へのアップグレードを強くお勧めします。

項目 詳細
CVE CVE-2025-68475
深刻度 高 (CVSS 7.5)
対応 Hollo 0.6.19 にアップグレード

Hollo :hollo:'s avatar
Hollo :hollo:

@hollo@hollo.social · Reply to Hollo :hollo:'s post

보안 업데이트: Hollo 0.6.19 릴리스

Fedify의 HTML 파싱 코드에서 발견된 보안 취약점을 수정한 Hollo 0.6.19를 릴리스했습니다.

이 취약점(CVE-2025-68475)은 ReDoS(정규 표현식 서비스 거부) 문제로, 공격자가 연합 작업 중 특수하게 조작된 HTML 응답을 보내 서비스 장애를 유발할 수 있습니다. 악성 페이로드는 작지만(약 170바이트), Node.js 이벤트 루프를 장시간 차단할 수 있습니다.

모든 Hollo 운영자분들께 즉시 버전 0.6.19로 업그레이드하실 것을 강력히 권고드립니다.

항목 상세
CVE CVE-2025-68475
심각도 높음 (CVSS 7.5)
조치 Hollo 0.6.19로 업그레이드

Hollo :hollo:'s avatar
Hollo :hollo:

@hollo@hollo.social

Security Update: Hollo 0.6.19 Released

We have released Hollo 0.6.19 to address a security vulnerability in Fedify's HTML parsing code.

This vulnerability (CVE-2025-68475) is a ReDoS (Regular Expression Denial of Service) issue that could allow an attacker to cause service unavailability by sending specially crafted HTML responses during federation operations. The malicious payload is small (approximately 170 bytes) but can block the Node.js event loop for extended periods.

We strongly recommend all Hollo operators upgrade to version 0.6.19 immediately.

Field Details
CVE CVE-2025-68475
Severity High (CVSS 7.5)
Action Upgrade to Hollo 0.6.19

Fedify: ActivityPub server framework's avatar
Fedify: ActivityPub server framework

@fedify@hollo.social

🚨 Security Advisory: CVE-2025-68475

A ReDoS (Regular Expression Denial of Service) vulnerability has been discovered in Fedify's HTML parsing code. This vulnerability could allow a malicious federated server to cause denial of service by sending specially crafted HTML responses.

CVE ID CVE-2025-68475
Severity High (CVSS 7.5)
Affected versions ≤1.9.1
Patched versions 1.6.13, 1.7.14, 1.8.15, 1.9.2

If you're running Fedify in production, please upgrade to one of the patched versions immediately.

For full details, see the security advisory: https://github.com/fedify-dev/fedify/security/advisories/GHSA-rchf-xwx2-hm93

Thank you to Yue (Knox) Liu for responsibly reporting this vulnerability.

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

@hongminhee@hollo.social · Reply to Kaito's post

@kai Haha, your friend Su is right! Nowadays, many Koreans (especially the younger generations) don't use hanja in their daily lives, and some don't even know how to write their own names in hanja. I'm a bit of an outlier for displaying it on my profile—I just happen to like how it looks and the meaning it carries! 😊

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

@hongminhee@hollo.social · Reply to Bart Louwers's post

@bart Spot on. The vendor lock-in is exactly what's holding me back from moving to Codeberg. It's frustrating that standard security features like OIDC publishing are becoming a golden cage that keeps us tied to big platforms. I'd love to see npm support OIDC from Forgejo/Gitea, but it feels like we're still a long way from a truly forge-agnostic ecosystem. 2FA tokens for life, I guess? 🥲

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

@hongminhee@hollo.social

Is it just me, or is 's trusted publishing unnecessarily rigid? Only one workflow filename allowed per package. It's like they never imagined a project having multiple release branches or evolving CI structures. Moving from build.yaml to publish.yaml shouldn't be this annoying. 😩

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

@hongminhee@hackers.pub

Calling all developers for help: I'm currently trying to implement a () feature for Hackers' Pub, an -enabled community for software engineers. Is there a formal specification for how cross-instance reporting should work in ActivityPub? Or, is there any well-documented material that explains how the major implementations handle it?

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

@hongminhee@hollo.social

이번 週末(주말)에는 반드시 브뤼셀() 航空券(항공권)을 끊어야 한다…

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

@hongminhee@hollo.social

When I was young, I really liked Pokémon, but after I became interested in animal rights as an adult, Pokémon battles started to remind me of abusive customs like dogfighting or cockfighting, so it's untenable to like them as much as I used to. 😔

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

@hongminhee@hollo.social · Reply to 3A29, raspberry pi in a fox's post

@3a29 That's a very logical and objective approach. I appreciate the careful consideration before making any assumptions!

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

@hongminhee@hollo.social · Reply to Ian Wagner's post

@ianthetechie Haha, I guess I have an old soul vibe! 😂 You're right—it's definitely rare for my generation to use hanja as a display name. I just personally love the aesthetics and the history behind it. The Japanese posts definitely add another layer to the puzzle!

Older →