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

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

In other news, I'm almost there with a version 0.1.0 of FIRES

I've just authentication to land, and then you'll be able to spin up the FIRES reference server and create Labels for labelling things in the future (label vocabularies)

These labels will then be used for the Datasets which will be in 0.2.0 of FIRES

For the full diff of all the work that has gone into FIRES over the last few months, have a look at: https://github.com/fedimod/fires/compare/d6e10be5f92603f6422610592ace1309847bfa2e...main

@kur0den0010 Hackers' Pubは招待制なので、自分で参加することはできません。DMでメールアドレスを教えていただければ、招待状をお送りします！

Fedify에 드디어 RFC 9421을 얼추 구현했고, 이제 상호운용성 테스트를 위해 Mastodon의 특정 브랜치를 실제로 인스턴스로 띄워서 액티비티를 송수신해봐야 한다. 그런데 Mastodon 띄우기가 너무나 귀찮다… (Mastodon 띄우기 귀찮아서 ActivityPub 개발 시작한 사람.)

@gabboman I've just reached you on Discord! Let's talk there!

@dave @renchap I've just implemented RFC 9421 in Fedify with both verification and signing support, including the double-knocking mechanism. I was actually looking for other ActivityPub implementations to test interoperability with.

I'd love to collaborate on testing between Fedify and Mastodon. Our implementation also prioritizes RFC 9421 first and falls back to draft cavage if needed, similar to the approach described in the ActivityPub and HTTP Signatures spec.

Would you be interested in coordinating some interoperability tests? Feel free to reach out if this sounds helpful for both our implementations!

Looking for #ActivityPub implementations with #RFC9421 support! 🔍

As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.

The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:

• has implemented RFC 9421 (even in a development branch)
• is currently implementing it
• has plans to implement it soon

Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.

Any leads or connections would be greatly appreciated! 🙏

#fedidev

I shipped a fix to https://fedidb.com addressing missing servers, the culprit was our updated crawler robots.txt logic.

Next up: software version tracker, feature matrix, FEP Library, People Directory, Dev Tools, and Starter Kits.

The fedi deserves great tools. We deliver. ✨

#fediDB

We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.

This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.

As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.

Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.

We look forward to contributing to a more standardized and secure fediverse!

#fedidev

民防衛(민방위) 敎育(교육) 받는 中(중)… 이것도 몇 年(연) 안 남았다. 😩

TIL: popes choose a new name once they are elected, so Robert Francis Prevost becomes Pope Leo XIV.

유심 식별번호:
- IMSI('임지'라고도 읽음): 이동통신망에서 가입자를 식별할 때 사용하는 번호. SIM에 기록되어 있다.
- ICCID: 신용카드의 카드번호와 동일한 규칙으로 부여되며, 물리적인 SIM 카드를 식별한다. 이동통신망 그 자체에서는 사용되지 않으며, 통신사 영업 전산에서 사용한다.
유심 인증키:
- K_i/OPc: 털리면 엿 되는 것.
- KIc/KID: 원격 접근에 사용하는 인증 키. KIc는 암호화, KID는 RC/CC/DS를 담당함.(GSMA FS.22 § 4 참조)
- KIK: 위 두 KIc, KID를 보호하기 위한 원격 프로비저닝 키.
유심 비밀번호:
- PIN1/PUK1: SIM 카드 탈취를 막기 위한 비밀번호. SIM에 최초 전원 인가 후 사용하기 전에 입력해야 함.
- PIN2/PUK2: SIM 카드의 특정 설정에 접근하기 위한 비밀번호. 통신사에 따라서 사용되지 않는 경우가 있음.
- ADM: SIM 카드의 파일을 조작하기 위한 비밀번호.

이제 국회 청문회나 공개되는 정보에서도 IMSI와 IMEI와 같은 약어가 나온다. 그러나 "유심 식별번호"나 "유심 인증키", "유심 비밀번호"가 구체적으로 뭔지는 아직도 언급되지 않고 있다. "유심 식별번호"에는 최소한 두 가지가 있고, "유심 인증키"라고 부를 수 있는 것만 최소한 5가지가 있으며, "유심 비밀번호"라고 부를 수 있는 것도 최소한 5가지가 있다. 그 중에서는 메모리 내에서도 가급적 암호화되어야 하는 것과, 디스크에서만 암호화할 수 밖에 없는 것도 섞여 있다. 대부분 여기에 사용되는 암호화 방식은 대칭 키 방식이기 때문에 평문 키에 접근해야 하며, 전가의 보도로 사용되는 "해시"도 사용할 수 없다.

구체적으로 무슨 정보가 유출되었는지가 알려지지 않는 이상, 쓸데없는 보안 관련 규제가 생길 가능성도 간과할 수 없다.

https://youtu.be/tKScucURjV0?t=10210

昨日のラジオハングル講座

韓国語では「ある」「いる」が同じ있다。
日本語ではモノが「ある」、生き物が「いる」と使い分ける。

しかし日本語でも古典では「むかしをとこありけり」みたいに「あり」が使われていた。「いる」は「座る」の意味で、「居ても立ってもいられない」のように使う。
和歌山らへんでは今も「ある」を使う方言があるらしい。

The abbreviation #a11y itself is not very accessible. #accessibility

国産のコードでdenwaの様な識別子を目にした際、我々は「なぜphoneやtelではないのか」と問うのではなく、「なぜ電話には成らないのか」と問うべきだと考える。

국산 코드에서 gubun 같은 식별자를 볼 때, 우리는 그게 왜 type 내지는 discriminator가 아닌지 물을 것이 아니라, 어째서 구분이 될 수 없는지를 물어야 한다.

@shugo Thanks for your answer! I hope RubyGems will have mechanism for binary packages soon. 😄

혹시 Rails 프로젝트 좀 경험해보신 분 계신가요? Mastodon 저장소에서 단위 테스트를 돌리고 싶은데 어떻게 돌리는지 잘 모르겠습니다. 일단 bundle install로 의존성은 다 설치해둔 상태입니다.

By the way, is Ruby still not offering prebuilt binary distributions for C extension packages? 🤔

I'm setting up a local Mastodon development environment to find out the signature base of the test vector used in Mastodon's RFC 9421 implementation… 😩

@dave @renchap One more question! Where did you source the test vectors for your RFC 9421 implementation? If you ran these test vectors directly, were you able to obtain the signature base used to generate each signature?

@dave @renchap Thanks!

@dave @renchap Okay, thanks for your answer! Then, does it default to rsa-v1_5-sha256 or rsa-v1_5-sha512?

@dave @renchap When implementing RFC 9421 signature verification, what algorithm do you default to when the alg parameter is not specified in the signature parameters?

FedifyにRFC 9421を実装した後、昨晩からhttpsig.orgで生成（署名）したテストベクターとの照合を試みていたが、どう見てもテストに成功せず、一日を無駄にした末に、httpsig.orgで生成したテストベクターがhttpsig.orgでも検証に失敗するという事実を悟ってしまった。🫩

Hmm, test vectors for rsa-v1_5-sha256 made with httpsig.org seem something wrong…?

Introducing https://fedidb.com 🥳

The same great FediDB, just on a easier to remember domain ✨

#fediDB

@renchap Do you have a working branch implementing RFC 9421 in Mastodon? I'm implementing it in Fedify, and would like to test against Mastodon's implementation of RFC 9421.

@hollo 독음 자동으로 달리는 건, 네, 그렇습니다. Hollo 설정에 SEONBI_URL이라는 문서화되지 않은 저만 쓰는 환경 변수가 있습니다. 다음은 제 Docker Compose 설정입니다. (일부 가림.)

services:
  caddy:
    image: caddy:2-alpine
    volumes:
    - ./Caddyfile:/etc/caddy/Caddyfile
    depends_on:
    - hollo
    ports:
    - "8080:8080"

  hollo:
    image: ghcr.io/fedify-dev/hollo:0.6.0-dev.14
    environment:
      # … 생략 …
      SEONBI_URL: http://seonbi:3800/
    depends_on:
    - seonbi
    restart: unless-stopped
    extra_hosts:
    - "host.docker.internal:host-gateway"

  seonbi:
    image: ghcr.io/dahlia/seonbi/bin:0.5.0
    ports:
    - "3800:3800"
    command: ["seonbi-api", "--allow-origin=*"]
    restart: unless-stopped