洪 民憙 (Hong Minhee)

Hello, I'm an open source software engineer in my late 30s living in #Seoul, #Korea, and an avid advocate of #FLOSS and the #fediverse.

I'm the creator of @fedify, an #ActivityPub server framework in #TypeScript, @hollo, an ActivityPub-enabled microblogging software for single users, and @botkit, a simple ActivityPub bot framework.

I'm also very interested in East Asian languages (so-called #CJK) and #Unicode. Feel free to talk to me in #English, #Korean (#한국어), or #Japanese (#日本語), or even in Literary Chinese (#文言文, #漢文)!

#introduction

安寧(안녕)하세요, 저는 서울에 살고 있는 30代(대) 後半(후반) 오픈 소스 소프트웨어 엔지니어이며, 自由(자유)·오픈 소스 소프트웨어와 聯合宇宙(연합우주)(fediverse)의 熱烈(열렬)한 支持者(지지자)입니다.

저는 TypeScript用(용) ActivityPub 서버 프레임워크인 @fedify 프로젝트와 싱글 유저用(용) ActivityPub 마이크로블로그인 @hollo 프로젝트와 ActivityPub 봇 프레임워크인 @botkit 프로젝트의 製作者(제작자)이기도 합니다.

저는 東(동)아시아 言語(언어)(이른바 #CJK)와 유니코드에도 關心(관심)이 많습니다. 聯合宇宙(연합우주)에서는 國漢文混用體(국한문 혼용체)를 쓰고 있어요! 제게 韓國語(한국어)나 英語(영어), 日本語(일본어)로 말을 걸어주세요. (아니면, 漢文(한문)으로도!)

#툿친소 #연친소 #별친소

こんにちは、私はソウルに住んでいる30代後半のオープンソースソフトウェアエンジニアで、自由・オープンソースソフトウェアとフェディバースの熱烈な支持者です。名前は洪 民憙（ホン・ミンヒ）です。

私はTypeScript用のActivityPubサーバーフレームワークである「@fedify」と、ActivityPubをサポートする1人用マイクロブログである 「@hollo」と、ActivityPubのボットを作成する為のシンプルなフレームワークである「@botkit」の作者でもあります。

私は東アジア言語（いわゆるCJK）とUnicodeにも興味が多いです。日本語、英語、韓国語で話しかけてください。（または、漢文でも！）

#自己紹介

My theory on egos: People with big egos can't stand other people with big egos. People without big egos don't really notice other people's egos.

If you find it unbearable to be around people with big egos, you might want to consider whether your own ego is the problem.

できた https://amasecocoa.github.io/fep/

파이콘 한국 2025의 Hackers' Pub 및 FediDev KR 커뮤니티 부스가 성공적으로 마무리되었습니다. 모두 여러분 덕분입니다.

양일간 부스 지키느라 도와주신 분들께 모두 감사드립니다! @nebuleto @kodingwarrior @akastoot @2chanhaeng @z9mb1 @joonnot @gaebalgom 🙏🏼

오늘과 내일 PyCon KR 2025에서 해커스펍 부스 도우미로 나와있습니다! 파이콘 오신 분들 많이 들러주세요 :)

파이콘 와서 더위에 시달리다 정신차려보니 왠지 부스에 앉아있었다

점심시간 한정!!!! 부스 지킴이 용병하고 있습니다

RE: https://hackers.pub/@2chanhaeng/0198b0d2-8970-7300-977c-20b0e4143dee

@crohasang 님이 작명해주신 덕분에, 찝찝한 기분도 덜어내고 진행하고 있는 프로젝트에 좀 더 속도를 낼 수 있을 것 같다..... 압도적 감사.... 기념으로 도메인도 샀다. https://cosmosli.de 뽕을 뽑자 이젠.....

이번 주말에는 양일 모두 파이콘 한국 2025에 가서 Hackers' Pub 부스를 지킵니다!

RE: https://hackerspub-ask-bot.deno.dev/message/0198ab62-41b8-76b7-8f05-eb833c27d7f1

단발로 잘랐다가 오늘 숏컷 함 ㅋㅋㅋ 민희 좋다 말음… 내가 봐도 숏컷보단 단발이 낫다

ちなみに、韓国語で「點心（ゾムシム ）」は点心（ディムサム）ではなく、昼食という意味です。

오늘의 點心(점심). 도미 貫子(관자) 솥밥.

@thisismissem @hongminhee @cocoa

FEP-844e: Capability discovery https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md

See also, FEP-0151 section on capability detection: https://codeberg.org/fediverse/fep/src/branch/main/fep/0151/fep-0151.md#capability-detection

Signed, a guy with links 🙂

이 글 德分(덕분)에 未來(미래)에서 온 揭示物(게시물)이 Hollo 타임라인 最上端(최상단)을 佔有(점유)하는 버그를 發見(발견)하여, Hollo 이슈트래커에 이슈를 만들어 두었다.

@thisismissem @cocoa Oh, are there already similar proposals in FEP? Could you possibly link them?

As you mentioned, there are limitations to feature detection based on NodeInfo, but I still think it can be useful in some situations. For example, it's currently difficult to tell whether a remote node can see emoji reactions just from the JSON-LD information.

@cocoa @hongminhee sorry to reply in English, but yes, there's a few FEPs along these lines, but technically you don't need nodeinfo for AP, so you wouldn't passively discover this information, unlike detecting certain properties in json-ld objects over activitypub. Feature discovery can be hard too because what features you think they have (cached) might not be the features they actually have at present, or if you're upgrading from version 1 to version 2, and you have multiple backend servers with a load balancer, you might get unpredictable results from nodeinfo as the update rolls out (e.g., node 1 gives new feature, node 2 & 3 gives old feature, you'll only get new feature 1/3 of the time and your old nodes won't be able to immediately handle new feature until you roll out the update to all nodes, which would cause unpredictable behaviour)

feature-info?

まぁこれはnodeinfoのmeta使ってある程度決まったjsonを埋め込むようにすれば良さそうだけども。

こんな感じにするとか？

[
 "fep:8b32",
　"rfc:9421",
 "protocol:activitypub"
]

実装間でのFEDERATION.mdみたいなのがほしいかもしれない🤔

We'd like to recognize the valuable contributions from two developers who participated in Korea's #OSSCA (Open Source Contribution Academy) program. Both contributors identified important gaps in #Fedify's functionality and documentation, providing thoughtful solutions that benefit the broader #ActivityPub ecosystem.

@gaebalgom contributed PR #365, addressing issue #353 regarding NodeInfo parser compatibility, originally reported by @andypiper. The issue arose when Fedify incorrectly rejected #NodeInfo documents from snac instances due to overly strict version string parsing that required semantic versioning compliance. Their solution improves the fallback behavior in the parseSoftware() function to handle non-SemVer version strings by parsing dot-separated numbers and defaulting to zero for missing components. The implementation includes thorough test coverage for various edge cases, including single numbers (3), two-part versions (2.81), and malformed version strings. This fix provides immediate compatibility improvements across the fediverse while maintaining backward compatibility, and will be included in Fedify 1.9. The contribution serves as an interim solution, with a more comprehensive fix planned for Fedify 2.0 (issue #366), where the NodeInfo software.version field will be changed from the SemVer type to a plain string to fully comply with the NodeInfo specification.

@z9mb1 contributed PR #364, resolving issue #337 by adding practical examples for Fedify's custom collection dispatchers feature. Custom collections were introduced in Fedify 1.8 but lacked clear documentation for developers seeking to implement them. Their contribution provides a comprehensive example demonstrating how to set up custom collections for tagged posts, including proper routing patterns, pagination handling, and counter functionality. The example includes mock data structures, shows how to configure collection dispatchers with URL patterns like /users/{userId}/tags/{tag}, and demonstrates the complete request/response cycle using federation.fetch(). This work provides developers with a clear, runnable reference that reduces the complexity of implementing custom collections in ActivityPub applications.

We appreciate these meaningful contributions that help make Fedify more accessible and robust for the entire ActivityPub community.

#opensource #fedidev #fediverse

金剛兔(금강토)(@tokolovesme)가 머리 자르고 왔다! 超(초)可愛(카와이)!

Every time this company has been in the news over the last two years, it's always something bad and/or internet-breaking. They don't deserve their users.

We need to move on from Reddit

https://mastodon.social/@verge/115011236901681082

なにこれおいしそ

처음으로 筆洞麵屋(필동면옥)에 와 본다!

‘앞/전’과 ‘뒤/후’의 비대칭성은 한국어 학습자들에게 지옥을 선사할 것이다.

참고로 이거 다 국립국어원의 잘못이 아니라 한국어의 잘못임. 이건 표준국어대사전이 그냥 현실을 반영했을 뿐이다. 즉 이 글을 읽고 있는 당신도 0.000001% 정도 잘못이 있다.

- ‘앞일’은 미래인데(예: 앞일을 예측하다), ‘뒷일’도 미래다(예: 뒷일을 부탁하네). 맞죠?

- 마찬가지로, ‘앞길’은 미래다(예: 앞길이 창창한 젊은이). 그런데 ‘뒷길’도 미래다(예: 자식의 뒷길을 생각하면 걱정이 앞선다).

- ‘뒷날’도 미래고(예: 우리는 뒷날 또 만나게 되었다), ‘훗날’도 미래다(예: 훗날을 기약하다). 그런데 ‘앞날’도 미래다(예: 앞날이 창창하다). 희한하게 ‘전날’만 과거이다.

- 그런데 ‘앞날’은 간혹 과거를 가리킬 수도 있다(예: 일찍이 앞날의 폭군은 있었고…).

- 관형사형에 ‘뒤’나 ‘후’를 붙여서 시점을 나타낼 수 있다(예: “고친 뒤의 모습” 또는 “고친 후의 모습”). 그런데 반대로 하려면 관형사형이 아니라 명사형을 써야 한다(예: “고치기 전의 모습”). 그리고, ‘전’만 쓸 수 있다. ‘앞’은 여기서 아예 쓸 수 없다.

- ‘후일’은 미래의 아무 날이나 다 가리키며, 특정한 날을 가리킬 수 없다. 반면 ‘전일’은 직전, 즉 인접한 과거의 1일만 가리킨다.

- 그런데 또 ‘전날’은 인접한 과거의 1일을 가리킬 수도 있고, 과거의 아무 날을 가리킬 수도 있다.

- 그런데 또 ‘훗날’은 미래의 아무 날을 뜻하며, 인접한 미래의 1일을 가리킬 수 없다.

- ‘전년’과 ‘후년’은 각각 과거의 아무 해, 또는 미래의 아무 해를 가리킬 수 있다. 대, 대칭인가?!

- 하지만 특정한 해를 가리키는 경우, ‘전년’은 인접한 과거의 해를 가리킨다. 반면 ‘후년’은 ‘올해의 다음다음 해’이다.

- …뭐라고? 왜냐하면 미래의 해들은 순서대로 ‘내년’-‘후년’-‘내후년’이기 때문이다. 책상 엎어버리고 싶죠?

- 참고로 ‘내후년’은 동음이의어이다. 올해가 2025년이라면 내후년은 2027년을 가리킬 수도 있고 2028년을 가리킬 수도 있다. (이게 언어냐?)

- ‘후년’이 ‘올해의 다음다음 해’가 되는 이 원리는 오직 ‘년’에만 적용된다. 예를 들어 ‘후일’, ‘후주’, ‘후월’ 등에는 그런 의미가 없다.

- ‘후일’은 미래의 아무 날이다. 하지만 ‘후주’와 ‘후월’은 인접한 미래의 것 하나만 가리킨다.

- ‘전년’은 인접한 과거의 해이지만, 과거의 모든 해를 다 가리킬 수도 있다(예: 우리는 전년의 기록들을 검토하여 그 사람의 행적을 조사해 보기로 했다).

- 반면 ‘전일’, ‘전주’, ‘전월’은 오직 인접한 과거의 하나만 가리킬 수 있다.

- ‘전달’과 ‘훗달’도 비대칭이다.

도대체 이걸 어떻게 배워서 쓰라는 것인지. 생각해 보면 나도 실제로 이렇게 쓰고 있다는 것도 기가 찬다.

그밖에:

- ‘지난날’에는 특정한 날을 가리키는 뜻이 전혀 없다. 반면 ‘지난주’, ‘지난달’, ‘지난해’는 모두 과거의 인접한 하나만 가리킨다.

- ‘다음 날’과 ‘다음날’은 의미가 완전히 다르다. ‘다음날’은 ‘정하여지지 아니한 미래의 어떤 날’이다. 따라서 인접한 미래의 1일을 가리킬 때에는 ‘다음 날’만 쓸 수 있다. (도저히 못 외우시겠으면 그냥 ‘이튿날’로 피신하시라…)

주소하니까 생각난 거지만, 한국에서 도로명주소 제대로 적는 건 우체국 외에 없지 않을까. 특히 “〇〇로n(번)길”을 중간에 공백을 삽입해서 “〇〇로␣n(번)길”이라고 적는 건 내노라하는 펌에서 나오는 서면 등에서도 무시로 보임. 도로명주소와 상세주소 사이에 쉼표(,)를 넣지 않는 것도 예사고.

사실 난 전자는 몰라도 후자는 굳이 그렇게 쓰라고 하는 쪽의 문제가 맞다고 보는데, “〇〇로n길 m, x동 y호”보다 그냥 “〇〇로n길 m번 x동 y호”라고 적으라고 하는 게 일반대중이 쉽게 배우고 규격에 맞춰서 잘 적을 거라고 생각함.

분명 예전에는 일본에서 주소 적을 때 「何町２―３―４」이라고 적고 끝냈던 것 같은데 요즘은 신기하게 「何町２丁目３―４」라고 적는 게 훨씬 보편적이 된 것 같아서, 조금 조사를 해보니까, 보통 우편번호 넣으면 주소 1번 필드에 「〇〇県〇〇市何町」까지는 자동입력되고 쵸메(丁目)와 번지수를 주소 2번 필드에 채워넣는 식으로 주소 입력을 받는데, 그냥 “숫자―숫자―숫자” 식으로 입력하면 엑셀 등에서 그걸 “연-월-일” 포맷으로 인식, 자동변환해 DB가 망가져버리는 경우가 종종 생겨서 그런 상황을 막으려 입력할 때 숫자와 대시만 쓰지 말고 문자를 넣어달라는 사이트가 많이 생기고, 그게 정착한 모양.

솔직하게는 역시 개발자가 제대로 문자열 이스케이프 처리 안 해둔 걸 UX 나빠지게 이용자에게 덮어씌우는 건 만국공통인가 싶은 생각이 들기는 하는데, 어쨌든 이런 디테일한 부분의 관습이 몇 년만에 확 달라지는 걸 보는 건 매우 흥미로운 경험이긴 한 것 같음.

最近、中学生の頃によく聴いていたX JAPANをまた聴いている。改めて聴くと、懐かしい感じがいい。😂

@reiver In the local language of the host city and in English? Or we might need an interpreter. 🤔

I just sponsored dahlia. Go sponsor your open source dependencies! https://github.com/sponsors/dahlia?o=sp&sc=t&sp=limeburst