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

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

Did you know your MacBook has a sensor that knows the exact angle of the screen hinge?

It’s not exposed as a public API, but I figured out a way to read it and make it sound like an old wooden door.

Source code and a downloadable app to try it yourself: https://github.com/samhenrigold/LidAngleSensor

I have this bad habit. When something annoys me enough times, I end up building a library for it. This time, it was CLI validation code.

See, I spend a lot of time reading other people's code. Open source projects, work stuff, random GitHub repos I stumble upon at 2 AM. And I kept noticing this thing: every CLI tool has the same ugly validation code tucked away somewhere. You know the kind:

if (!opts.server && opts.port) {
  throw new Error("--port requires --server flag");
}

if (opts.server && !opts.port) {
  opts.port = 3000; // default port
}

// wait, what if they pass --port without a value?
// what if the port is out of range?
// what if...

It's not even that this code is hard to write. It's that it's everywhere. Every project. Every CLI tool. The same patterns, slightly different flavors. Options that depend on other options. Flags that can't be used together. Arguments that only make sense in certain modes.

And here's what really got me: we solved this problem years ago for other types of data. Just… not for CLIs.

The problem with validation

There's this blog post that completely changed how I think about parsing. It's called Parse, don't validate by Alexis King. The gist? Don't parse data into a loose type and then check if it's valid. Parse it directly into a type that can only be valid.

Think about it. When you get JSON from an API, you don't just parse it as any and then write a bunch of if-statements. You use something like Zod to parse it directly into the shape you want. Invalid data? The parser rejects it. Done.

But with CLIs? We parse arguments into some bag of properties and then spend the next 100 lines checking if that bag makes sense. It's backwards.

So yeah, I built Optique. Not because the world desperately needed another CLI parser (it didn't), but because I was tired of seeing—and writing—the same validation code everywhere.

Three patterns I was sick of validating

Dependent options

This one's everywhere. You have an option that only makes sense when another option is enabled.

The old way? Parse everything, then check:

const opts = parseArgs(process.argv);
if (!opts.server && opts.port) {
  throw new Error("--port requires --server");
}
if (opts.server && !opts.port) {
  opts.port = 3000;
}
// More validation probably lurking elsewhere...

With Optique, you just describe what you want:

const config = withDefault(
  object({
    server: flag("--server"),
    port: option("--port", integer()),
    workers: option("--workers", integer())
  }),
  { server: false }
);

Here's what TypeScript infers for config's type:

type Config = 
  | { readonly server: false }
  | { readonly server: true; readonly port: number; readonly workers: number }

The type system now understands that when server is false, port literally doesn't exist. Not undefined, not null—it's not there. Try to access it and TypeScript yells at you. No runtime validation needed.

Mutually exclusive options

Another classic. Pick one output format: JSON, YAML, or XML. But definitely not two.

I used to write this mess:

if ((opts.json ? 1 : 0) + (opts.yaml ? 1 : 0) + (opts.xml ? 1 : 0) > 1) {
  throw new Error('Choose only one output format');
}

(Don't judge me, you've written something similar.)

Now?

const format = or(
  map(option("--json"), () => "json" as const),
  map(option("--yaml"), () => "yaml" as const),
  map(option("--xml"), () => "xml" as const)
);

The or() combinator means exactly one succeeds. The result is just "json" | "yaml" | "xml". A single string. Not three booleans to juggle.

Environment-specific requirements

Production needs auth. Development needs debug flags. Docker needs different options than local. You know the drill.

Instead of a validation maze, you just describe each environment:

const envConfig = or(
  object({
    env: constant("prod"),
    auth: option("--auth", string()),      // Required in prod
    ssl: option("--ssl"),
    monitoring: option("--monitoring", url())
  }),
  object({
    env: constant("dev"),
    debug: optional(option("--debug")),    // Optional in dev
    verbose: option("--verbose")
  })
);

No auth in production? Parser fails immediately. Trying to access --auth in dev mode? TypeScript won't let you—the field doesn't exist on that type.

“But parser combinators though…”

I know, I know. “Parser combinators” sounds like something you'd need a CS degree to understand.

Here's the thing: I don't have a CS degree. Actually, I don't have any degree. But I've been using parser combinators for years because they're actually… not that hard? It's just that the name makes them sound way scarier than they are.

I'd been using them for other stuff—parsing config files, DSLs, whatever. But somehow it never clicked that you could use them for CLI parsing until I saw Haskell's optparse-applicative. That was a real “wait, of course” moment. Like, why are we doing this any other way?

Turns out it's stupidly simple. A parser is just a function. Combinators are just functions that take parsers and return new parsers. That's it.

// This is a parser
const port = option("--port", integer());

// This is also a parser (made from smaller parsers)
const server = object({
  port: port,
  host: option("--host", string())
});

// Still a parser (parsers all the way down)
const config = or(server, client);

No monads. No category theory. Just functions. Boring, beautiful functions.

TypeScript does the heavy lifting

Here's the thing that still feels like cheating: I don't write types for my CLI configs anymore. TypeScript just… figures it out.

const cli = or(
  command("deploy", object({
    action: constant("deploy"),
    environment: argument(string()),
    replicas: option("--replicas", integer())
  })),
  command("rollback", object({
    action: constant("rollback"),
    version: argument(string()),
    force: option("--force")
  }))
);

// TypeScript infers this type automatically:
type Cli = 
  | { 
      readonly action: "deploy"
      readonly environment: string
      readonly replicas: number
    }
  | { 
      readonly action: "rollback"
      readonly version: string
      readonly force: boolean
    }

TypeScript knows that if action is "deploy", then environment exists but version doesn't. It knows replicas is a number. It knows force is a boolean. I didn't tell it any of this.

This isn't just about nice autocomplete (though yeah, the autocomplete is great). It's about catching bugs before they happen. Forget to handle a new option somewhere? Code won't compile.

What actually changed for me

I've been dogfooding this for a few weeks. Some real talk:

I delete code now. Not refactor. Delete. That validation logic that used to be 30% of my CLI code? Gone. It feels weird every time.

Refactoring isn't scary. Want to know something that usually terrifies me? Changing how a CLI takes its arguments. Like going from --input file.txt to just file.txt as a positional argument. With traditional parsers, you're hunting down validation logic everywhere. With this? You change the parser definition, TypeScript immediately shows you every place that breaks, you fix them, done. What used to be an hour of “did I catch everything?” is now “fix the red squiggles and move on.”

My CLIs got fancier. When adding complex option relationships doesn't mean writing complex validation, you just… add them. Mutually exclusive groups? Sure. Context-dependent options? Why not. The parser handles it.

The reusability is real too:

const networkOptions = object({
  host: option("--host", string()),
  port: option("--port", integer())
});

// Reuse everywhere, compose differently
const devServer = merge(networkOptions, debugOptions);
const prodServer = merge(networkOptions, authOptions);
const testServer = merge(networkOptions, mockOptions);

But honestly? The biggest change is trust. If it compiles, the CLI logic works. Not “probably works” or “works unless someone passes weird arguments.” It just works.

Should you care?

If you're writing a 10-line script that takes one argument, you don't need this. process.argv[2] and call it a day.

But if you've ever:

• Had validation logic get out of sync with your actual options
• Discovered in production that certain option combinations explode
• Spent an afternoon tracking down why --verbose breaks when used with --json
• Written the same “option A requires option B” check for the fifth time

Then yeah, maybe you're tired of this stuff too.

Fair warning: Optique is young. I'm still figuring things out, the API might shift a bit. But the core idea—parse, don't validate—that's solid. And I haven't written validation code in months.

Still feels weird. Good weird.

Try it or don't

If this resonates:

• Tutorial: Build something real, see if you hate it
• Concepts: Primitives, constructs, modifiers, value parsers, the whole thing
• GitHub: The code, issues, angry rants

I'm not saying Optique is the answer to all CLI problems. I'm just saying I was tired of writing the same validation code everywhere, so I built something that makes it unnecessary.

Take it or leave it. But that validation code you're about to write? You probably don't need it.

#GNOME picks of the day:

➡️ @gnome - Official GNOME account in English

➡️ @gnome_br - GNOME in Portuguese

➡️ @haeckerfelix - GNOME developer, foundation member, author of "This Week in GNOME"

➡️ @Tuba - FOSS Fediverse app for GNOME, forked from Tootle

➡️ @WebKitGTK - GTK port of WebKit, official browser engine in GNOME

➡️ @GTK - FOSS cross-platform toolkit for creating GUIs

➡️ @EvolutionGnome - Free open source personal information manager software

🧵 1/2

참고로 Hackers' Pub은 패스키 인증을 지원하고 있습니다. ✌️

@activitypub.blog
워드프레스 액티비티펍 플러그인의 한국어 설명 페이지를 대대적으로 수정했습니다.
자동번역을 전체적으로 검토하고 맥락에 맞게 수정해 가독성과 번역 품질을 대폭 개선했습니다!

이제 한국어 사용자들도 페디버스와 워드프레스의 연결을 보다 더 쉽게 이해하고 활용할 수 있습니다. 앞으로도 최신 문서와 기능 번역을 계속 업데이트할 예정이니 많은 관심과 피드백 부탁드립니다.
@pfefferle @obenland

#Automattic #WordPress #Activitypub
#워드프레스 #액티비티펍 #페디버스 #fediverse
https://ko.wordpress.org/plugins/activitypub/

Recently there has been a lot of discourse about ActivityPub and AT Protocol which has been quite dividing and heated.

Yesterday at the Social Web CG meeting (the group that maintains the ActivityPub and related specifications), I proposed releasing a statement that counters the narrative that one of these protocols must win, when both protocols can co-exist and have a lot to learn from each other.

The statement has been co-signed by various members of both Social Web CG, SocialCG, and the AT Protocol community.

“We do not win by tearing each other down, which only emboldens and empowers those who do not want either protocol to succeed.”

“Arguing between us only emboldens those that seek to derail and destroy efforts to build an open social web.”

You can read the full statement here:
https://writings.thisismissem.social/statement-on-discourse-about-activitypub-and-at-protocol/

This was originally in the swicg/general repository, and you can learn about that here:
https://github.com/swicg/general/blob/master/statements/2025-09-05-activitypub-and-atproto-discourse.md

#activitypub #atprotocol #atproto #SocialWeb

그래도 한 5%정도 사이트의 꼬라지를 갖춰간다... 이번달 안에 (테스트로) 공개할 수 있겠지...?

@dansup not sure if you're aware, flags are usually not the best choice to represent languages 🙂

Optique 0.4.0 Released!

Big update for our type-safe combinatorial #CLI parser for #TypeScript:

• Labeled merge groups: organize options logically
• Rich docs: brief, description & footer support
• @optique/temporal: new package for date/time parsing
• showDefault: automatic default value display

The help text has never looked this good!

#JavaScript #opensource #Node.js #Deno #Bun

Loops now has i18n support, you can demo it with English/French on our demo instance:

https://getloops.social/

#loops #i18n

@silverpill Thanks!

@hongminhee FEP-3b86 defines many such relations:

https://codeberg.org/fediverse/fep/src/branch/main/fep/3b86/fep-3b86.md

We're excited to announce Optique 0.4.0, which brings significant improvements to help text organization, enhanced documentation capabilities, and introduces comprehensive Temporal API support.

Optique is a type-safe combinatorial CLI parser for TypeScript that makes building command-line interfaces intuitive and maintainable. This release focuses on making your CLI applications more user-friendly and maintainable.

Better help text organization

One of the most visible improvements in Optique 0.4.0 is the enhanced help text organization. You can now label and group your options more effectively, making complex CLIs much more approachable for users.

Labeled merge groups

The merge() combinator now accepts an optional label parameter, solving a common pain point where developers had to choose between clean code structure and organized help output:

// Before: unlabeled merged options appeared scattered
const config = merge(connectionOptions, performanceOptions);

// Now: group related options under a clear section
const config = merge(
  "Server Configuration",  // New label parameter
  connectionOptions,
  performanceOptions
);

This simple addition makes a huge difference in help text readability, especially for CLIs with many options spread across multiple reusable modules.

The resulting help output clearly organizes options under the Server Configuration section:

Demo app showcasing labeled merge groups
Usage: demo-merge.ts --host STRING --port INTEGER --timeout INTEGER --retries
       INTEGER

Server Configuration:
  --host STRING               Server hostname or IP address
  --port INTEGER              Port number for the connection
  --timeout INTEGER           Connection timeout in seconds
  --retries INTEGER           Number of retry attempts

The new group() combinator

For cases where merge() doesn't apply, the new group() combinator lets you wrap any parser with a documentation label:

// Group mutually exclusive options under a clear section
const outputFormat = group(
  "Output Format",
  or(
    map(flag("--json"), () => "json"),
    map(flag("--yaml"), () => "yaml"),
    map(flag("--xml"), () => "xml"),
  )
);

This is particularly useful for organizing mutually exclusive flags, multiple inputs, or any parser that doesn't natively support labeling. The resulting help text becomes much more scannable and user-friendly.

Here's how the grouped output format options appear in the help text:

Demo app showcasing group combinator
Usage: demo-group.ts --json
       demo-group.ts --yaml
       demo-group.ts --xml

Output Format:
  --json                      Output in JSON format
  --yaml                      Output in YAML format
  --xml                       Output in XML format

Rich documentation support

Optique 0.4.0 introduces comprehensive documentation fields that can be added directly through the run() function, eliminating the need to modify parser definitions for documentation purposes.

Brief descriptions, detailed explanations, and footers

Both @optique/core/facade and @optique/run now support brief, description, and footer options through the run() function:

import { run } from "@optique/run";
import { message } from "@optique/core/message";

const result = run(parser, {
  brief: message`A powerful data processing tool`,
  description: message`This tool provides comprehensive data processing capabilities with support for multiple formats and transformations. It can handle JSON, YAML, and CSV files with automatic format detection.`,
  footer: message`Examples:
  myapp process data.json --format yaml
  myapp validate config.toml --strict

For more information, visit https://example.com/docs`,
  help: "option"
});

These documentation fields appear in both help output and error messages (when configured), providing consistent context throughout your CLI's user experience.

The complete help output demonstrates the rich documentation features with brief description, detailed explanation, option descriptions, default values, and footer information:

A powerful data processing tool
Usage: demo-rich-docs.ts [--port INTEGER] [--format STRING] --verbose STRING

This tool provides comprehensive data processing capabilities with support for
multiple formats and transformations. It can handle JSON, YAML, and CSV files
with automatic format detection.

  --port INTEGER              Server port number [3000]
  --format STRING             Output format [json]
  --verbose STRING            Verbosity level

Examples:
  myapp process data.json --format yaml
  myapp validate config.toml --strict

For more information, visit https://example.com/docs

These documentation fields appear in both help output and error messages (when configured), providing consistent context throughout your CLI's user experience.

Display default values

A frequently requested feature is now available: showing default values directly in help text. Enable this with the new showDefault option when using withDefault():

const parser = object({
  port: withDefault(
    option("--port", integer(), { description: message`Server port number` }),
    3000,
  ),
  format: withDefault(
    option("--format", string(), { description: message`Output format` }),
    "json",
  ),
});

run(parser, { showDefault: true });

// Or with custom formatting:
run(parser, {
  showDefault: {
    prefix: " (default: ",
    suffix: ")"
  }  // Shows: --port (default: 3000)
});

Default values are automatically dimmed when colors are enabled, making them visually distinct while remaining readable.

The help output shows default values clearly marked next to each option:

Usage: demo-defaults.ts [--port INTEGER] [--format STRING]

  --port INTEGER              Server port number [3000]
  --format STRING             Output format [json]

Temporal API support

Optique 0.4.0 introduces a new package, @optique/temporal, providing comprehensive support for the modern Temporal API. This brings type-safe parsing for dates, times, durations, and time zones:

import { instant, duration, zonedDateTime } from "@optique/temporal";
import { option } from "@optique/core/parser";

const parser = object({
  // Parse ISO 8601 timestamps
  timestamp: option("--at", instant()),

  // Parse durations like "PT30M" or "P1DT2H"
  timeout: option("--timeout", duration()),

  // Parse zoned datetime with timezone info
  meeting: option("--meeting", zonedDateTime()),
});

The temporal parsers return native Temporal objects with full functionality:

const result = parse(timestampArg, ["2023-12-25T10:30:00Z"]);
if (result.success) {
  const instant = result.value;
  console.log(`UTC: ${instant.toString()}`);
  console.log(`Seoul: ${instant.toZonedDateTimeISO("Asia/Seoul")}`);
}

Install the new package with:

npm add @optique/temporal

Improved type inference

The merge() combinator now supports up to 10 parsers (previously 5), and the tuple() parser has improved type inference using TypeScript's const type parameter. These enhancements enable more complex CLI structures while maintaining perfect type safety.

Breaking changes

While we've maintained backward compatibility for most APIs, there are a few changes to be aware of:

• The Parser.getDocFragments() method now uses DocState<TState> instead of direct state values (only affects custom parser implementations)
• The merge() combinator now enforces stricter type constraints at compile time, rejecting non-object-producing parsers

Learn more

For a complete list of changes, bug fixes, and improvements, see the full changelog.

Check out the updated documentation:

• Structured messages guide for the new documentation features
• Construct combinators reference for merge() and group() usage
• Value parsers guide for temporal parsing
• CLI patterns cookbook for practical examples

Installation

Upgrade to Optique 0.4.0:

npm update @optique/core @optique/run
# or
deno add jsr:@optique/core@^0.4.0 jsr:@optique/run@^0.4.0

Add temporal support (optional):

npm add @optique/temporal
# or
deno add jsr:@optique/temporal

We hope these improvements make building CLI applications with Optique even more enjoyable. As always, we welcome your feedback and contributions on GitHub.

Optique 0.4.0 Released!

Big update for our type-safe combinatorial #CLI parser for #TypeScript:

• Labeled merge groups: organize options logically
• Rich docs: brief, description & footer support
• @optique/temporal: new package for date/time parsing
• showDefault: automatic default value display

The help text has never looked this good!

#JavaScript #opensource #Node.js #Deno #Bun

In #WebFinger, are there any relations that use the template property instead of the href property, excluding the http://ostatus.org/schema/1.0/subscribe relation?

#fedidev

I woke up at dawn and couldn't go back to sleep, so I added Temporal value parsers to Optique.

SF숏포머블 공모전 장려상 https://www.sfstory.co.kr/community/notice/view/147

Oh no y'all, I started writing something:

nodeinfo path is auto-generated by starlette (fastapi)

Coding ActivityPubServer...

Are you a moderator on the Fediverse? A server operator?

If so, you should definitely fill out the IFTAS Moderator Needs Assessment:

(IFTAS doesn't require you to identify yourself, so you can remain anonymous if you wish)

https://about.iftas.org/moderator-needs-assessment/

https://hackers.pub/ap/notes/01990ddf-6e44-769a-995c-6fac70d06920

確かにHaskellにもあるか。使わなさすぎて忘れてた

個人的には、一時的に開発目的で使うActivityPubサーバーにはngrokやfedify tunnelなどを活用し、長期的に継続して開発するActivityPubサーバーであればTailscale FunnelやCloudflare Tunnelを使用しています。

今のところローカル専用の https ドメインはメインマシンに建てた caddy へ流してそこから各アプリケーションに分岐してるんよね

で let's encrypt の証明書は DNS チャレンジでワイルドカード証明書を取ってるんで取得には問題無いんだけど、ローカルのネットワークルーティングをどうするかが非常に悩ましい

Fediverseの開発環境、自分は何回か作り直しては崩してをしてるんだけど、現実どうするといいんだろうな

自分の環境の場合 tailscale + ローカルホスト用自前ドメインでローカルに閉じた https 環境を用意出来てるんだけど、この環境、コンテナだとホストのネットワークを使わないと tailscale の ip へ到達できないんだよね

「割とモダンな言語」というわけではないが、Haskellもかなり昔からnewtypeというキーワードでサポートしていた。

最近はScalaとかSwiftとかの「割とモダンな言語」が基底型に型消去するみたいなコンパイルテクでゼロオーバーヘッドのラッパー定義できる言語が増えてる気がしているので、別にRustだけではないと思う。
Rustが気軽に定義できるって話なら、そりゃそうだと思うけれど

Value Objectが好きだけどオーバーヘッドが看過できない人向けの言語 → Rustすぎる

1시간 만에 완판! 걱정마세요 아직 대기 신청이 남아있습니다!