洪民憙 (Hong Minhee)

@hongminhee@hollo.social

1,081 following 1,892 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 #TypeScript, #Haskell, #Rust, & #Python. They/them.

서울에 사는 交叉女性主義者이자 社會主義者. 金剛兔(@tokolovesme)의 配偶者. @fedify, @hollo, @botkit 메인테이너. #TypeScript, #Haskell, #Rust, #Python 等으로 自由 소프트웨어 만듦.

#國漢文混用體 #한국어 (#朝鮮語) #English #日本語

Website: https://hongminhee.org/
GitHub: https://github.com/dahlia
Blog: https://writings.hongminhee.org/
Hackers' Pub: https://hackers.pub/@hongminhee

Pinned

洪民憙 (Hong Minhee)

@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

洪民憙 (Hong Minhee)

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

はじめまして！ソウル在住の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

洪民憙 (Hong Minhee)

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

安寧(안녕)하세요! 저는 서울에 살고 있는 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

洪民憙 (Hong Minhee)

@hongminhee@hollo.social · Reply to mcc

@mcc I'm not sure, but that would break some ActivityPub implementations relying on JSON-LD processors. 🤔

洪民憙 (Hong Minhee)

@hongminhee@hollo.social

Es bedarf Zeit und Erfahrung, bevor der Arbeiter die Maschinerie von ihrer kapitalistischen Anwendung unterscheiden und daher seine Angriffe vom materiellen Produktionsmittel selbst auf dessen gesellschaftliche Exploitationsform übertragen lernt.

—Karl Marx, Das Kapital, Bd. I, Kap. 13, Abschn. 5

zeno.org

Marx, Karl, Das Kapital, I. Band: Der Produktionsprozeß des Kapitals, IV. Die Produktion des relativen Mehrwerts, 13. Maschinerie und große Industrie, 5. Kampf zwischen Arbeiter und Maschine

Volltext Philosophie: Karl Marx, Friedrich Engels: Werke. Berlin 1962, Band 23, S. 450-461.: 5. Kampf zwischen Arbeiter und Maschine

@kopper@not-brain.d.on-t.work

i was a bit curious about the actual transfer size impact of json-ld, and what would happen if you replaced json-ld with simply explicitly repeating the namespaces. so i threw a few payloads, both compacted and expanded, into lynn.github.io/flateview/ at gzip level 6

my actor, compacted - 1855 bytes gzip'd
my actor, expanded - 1877 bytes gzip'd
my actor, compacted with no context - 1793 bytes gzip'd

quoted post, compacted - 2024 bytes gzip'd
quoted post, expanded - 2033 bytes gzip'd
quoted post, compacted with no context - 1985 bytes gzip'd

mastodon.social instance actor, compacted - 2761 bytes gzip'd
mastodon.social instance actor, compacted, with unused context values removed - 644 bytes gzip'd
mastodon.social instance actor, expanded - 707 bytes gzip'd
mastodon.social instance actor, compacted, with no context - 667 bytes gzip'd

RE: not-brain.d.on-t.work/notes/aihcsxrs45sw0wbq

not-brain.d.on-t.work

kopper :colon_three: (@kopper)

@hongminhee@hollo.social from the point of view of someone who is "maintaining" a JSON-LD processing fedi software and has implemented [their own JSON-LD processing library](https://iceshrimp.dev/iceshrimp/linkeddata.net) (which is, to my knowledge, [the fastest in it's progra...

@kopper@not-brain.d.on-t.work · Reply to 洪民憙 (Hong Minhee) :nonbinary:

@hongminhee from the point of view of someone who is "maintaining" a JSON-LD processing fedi software and has implemented their own JSON-LD processing library (which is, to my knowledge, the fastest in it's programming language), JSON-LD is pure overhead. there is nothing it allows for that can't be done with

1. making fields which take multiple values explicit
2. always using namespaces and letting HTTP compression take care of minimizing the transfer

without JSON-LD, fedi software could use zero-ish-copy deserialization for a majority of their objects (when strings aren't escaped) through tools like serde_json and Cow<str>, or System.Text.Json.JsonDocument. JSON-LD processing effectively mandates a JSON node DOM (in the algorithms standardized, you may be able to get rid of it with Clever Programming)

additionally, due to JSON-LD 1.1 features like @type:@json, you can not even fetch contexts ahead of time of running JSON DOM transformations, meaning all JSON-LD code has to be async (in the languages which has the concept), potentially losing out on significant optimizations that can't be done in coroutines due to various reasons (e.g. C# async methods can't have ref structs, Rust async functions usually require thread safety due to tokio's prevalence, even if they're ran in a single-threaded runtime)

this is after context processing introducing network dependency to the deserialization of data, wasting time and data on non-server cases (e.g. activitypub C2S). sure you can cache individual contexts, but then the context can change underneath you, desynchronizing your cached context and, in the worst case, opening you up to security vulnerabilities

json-ld is not my favorite part of this protocol

socialhub.activitypub.rocks

Potential security vulnerability: Remote JSON-LD contexts may be used to bypass restrictions when arbitrary objects are allowed to be created

Assumption: Remote instance software adhere to the origin based security model and expand JSON-LD with support for fetching remote @context entries (not all do JSON-LD obviously, but in an ideal world (as expected by the spec anyway) they would). Therefore, if a user can create an actor-like object with private keys in their control, they can impersonate any other actor on their instance. There are several ways this can be done that can be checked for and blocked by the C2S server implementati...

@kopper@not-brain.d.on-t.work · Reply to kopper :colon_three:

@hongminhee if i can give one piece of advice to devs who want to process JSON-LD: dont bother compacting. you already know the schema you output (or you're just passing through what the user gives and it doesn't matter to you), serialize directly to the compacted representation, and only run expansion on incoming data

expansion is the cheapest JSON-LD operation (since all other operations depend on it and run it internally anyhow), and this will get you all the compatibility benefits of JSON-LD with little downsides (beyond more annoying deserialization code, as you have to map the expanded representation to your internal structure which will likely be modeled after the compacted one)

@kopper@not-brain.d.on-t.work · Reply to kopper :colon_three:

@hongminhee take this part with a grain of salt because my benchmarks for it are with dotNetRdf which is the slowest C# implementation i know of (hence my replacement library), but JSON-LD is slower than RSA validation, which is one of the pain points around authorized fetch scalability

wetdry.world/@kopper/114678924693500011

wetdry.world

no longer kopper (@kopper@wetdry.world)

``` | Method | Mean | Error | StdDev | Gen0 | Allocated | |------------------ |---------:|---------:|---------:|-------:|----------:| | RsaValidation | 19.77 μs | 0.043 μs | 0.033 μs | 0.1526 | 3.16 KB | | FlattenYesContext | 7.907 ms | 0.0788 ms | 0.0658 ms | 171.8750 | 46.8750 | 4.01 MB | | Frame | 12.342 ms | 0.0810 ms | 0.0677 ms | 250.0000 | 78.1250 | 5.94 MB | ```

@kopper@not-brain.d.on-t.work · Reply to 洪民憙 (Hong Minhee) :nonbinary:

@hongminhee from the point of view of someone who is "maintaining" a JSON-LD processing fedi software and has implemented their own JSON-LD processing library (which is, to my knowledge, the fastest in it's programming language), JSON-LD is pure overhead. there is nothing it allows for that can't be done with

1. making fields which take multiple values explicit
2. always using namespaces and letting HTTP compression take care of minimizing the transfer

without JSON-LD, fedi software could use zero-ish-copy deserialization for a majority of their objects (when strings aren't escaped) through tools like serde_json and Cow<str>, or System.Text.Json.JsonDocument. JSON-LD processing effectively mandates a JSON node DOM (in the algorithms standardized, you may be able to get rid of it with Clever Programming)

additionally, due to JSON-LD 1.1 features like @type:@json, you can not even fetch contexts ahead of time of running JSON DOM transformations, meaning all JSON-LD code has to be async (in the languages which has the concept), potentially losing out on significant optimizations that can't be done in coroutines due to various reasons (e.g. C# async methods can't have ref structs, Rust async functions usually require thread safety due to tokio's prevalence, even if they're ran in a single-threaded runtime)

this is after context processing introducing network dependency to the deserialization of data, wasting time and data on non-server cases (e.g. activitypub C2S). sure you can cache individual contexts, but then the context can change underneath you, desynchronizing your cached context and, in the worst case, opening you up to security vulnerabilities

json-ld is not my favorite part of this protocol

socialhub.activitypub.rocks

Potential security vulnerability: Remote JSON-LD contexts may be used to bypass restrictions when arbitrary objects are allowed to be created

Assumption: Remote instance software adhere to the origin based security model and expand JSON-LD with support for fetching remote @context entries (not all do JSON-LD obviously, but in an ideal world (as expected by the spec anyway) they would). Therefore, if a user can create an actor-like object with private keys in their control, they can impersonate any other actor on their instance. There are several ways this can be done that can be checked for and blocked by the C2S server implementati...

@douginamug@mastodon.xyz · Reply to 洪民憙 (Hong Minhee) :nonbinary:

@hongminhee I'm reading this thread as a relative noob, but what I see again and again: almost no one "properly" implents #ActivityPub largely because #JSONLD is hard but also because the spec itself is unclear. Most people who get stuff done have to go off-spec to actually ship.

This seems a fundamental weakness of the #fediverse - and that disregarding the limitations coming from base architecture. Seems to pose a mid/long-term existential threat.

What can we do to help improve things?

洪民憙 (Hong Minhee)

@hongminhee@hollo.social · Reply to marius

@mariusor It's barely documented, but has worked well so far!

https://github.com/fedify-dev/fedify/tree/main/packages/vocab-tools

洪民憙 (Hong Minhee)

@hongminhee@hollo.social · Reply to silverpill

@silverpill @mariusor But if you omit @context, wouldn't it fail to work correctly in some implementations that rely on a JSON-LD processor? Fedify is actually one of those cases.

@linear@hackers.pub

‘급진적으로 존재하기’에서 시각장애인 천문학자가 음향화 기술을 활용해 다시 연구에 복귀한 이야기를 읽으면서 문득 장애인들에게 최근의 AI 기술은 어떤 영향을 미치고 있을까 궁금해졌다. 삶에 변화가 생겼다고 느낄지. 이조차도 장애인들은 피해 갔다고 느낄지.

洪民憙 (Hong Minhee)

@hongminhee@hollo.social · Reply to silverpill

@silverpill @linos That's good to know! Thanks!

@kodingwarrior You might be interested in this?

@silverpill@mitra.social · Reply to 洪民憙 (Hong Minhee) :nonbinary:

@hongminhee I don't know about Mobilizon but @linos considers adding related features to the Events FEP

https://codeberg.org/linos/fep/issues/18

codeberg.org

FEP-8a8e: Flag for PayAsYouWish vs Commercial?

fep - Fediverse Enhancement Proposals

洪民憙 (Hong Minhee)

@hongminhee@hollo.social · Reply to near

@computersandblues Actually, this question came up when my acquaintance, @kodingwarrior, mentioned wanting to use a fediverse-based event hosting service for an event he's organizing, which is when we started talking about Mobilizon. The main scenario we envisioned was allowing only those who have paid the participation fee to RSVP. And, of course, they would need to be refunded if they cancel.

@kodingwarrior, are there any other requirements besides this?

洪民憙 (Hong Minhee)

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

어떤 點(점)들을 어필할 수 있을까?

聯合宇宙(연합우주)를 이루는 소프트웨어 自體(자체)가 大部分(대부분) 오픈 소스이다?
海外(해외)의 많은 오픈 소스 소프트웨어 開發者(개발자)들이 聯合宇宙(연합우주)를 쓰고 있다?

또 뭐가 있을까…?

洪民憙 (Hong Minhee)

@hongminhee@hollo.social

早晩間(조만간) 소프트웨어 엔지니어 커뮤니티로서의 聯合宇宙(연합우주)를 어필하는 韓國語(한국어) 글을 하나 써 봐야겠다.

洪民憙 (Hong Minhee)

@hongminhee@hollo.social

Does Mobilizon currently support hosting paid events that charge a participation fee? If not, is there a roadmap for a future feature update that will make this possible?

#Mobilizon #fediverse

mobilizon.org

Mobilizon

洪民憙 (Hong Minhee)

@hongminhee@hollo.social · Reply to Evan Prodromou

@evan I don't remember exactly, but I think I came across it while doing research before developing Fedify. I probably didn't use it because the TypeScript type definitions were missing. In the end, I ended up making something similar in Fedify anyway.

fedify.dev

Vocabulary | Fedify

The Activity Vocabulary is a collection of type-safe objects that represent the Activity Vocabulary and the vendor-specific extensions. This section explains the key features of the objects.

洪民憙 (Hong Minhee)

@hongminhee@hollo.social

아무래도 時差(시차) 適應(적응)에 完全(완전)히 失敗(실패)한 듯… 이제 일어났다.

洪民憙 (Hong Minhee)

@hongminhee@hollo.social · Reply to Luke Kanies

@lkanies @jalefkowit To be honest, I'm not too sure myself. I just know that JSON-LD was originally planned as a foundation for the Semantic Web. I can only guess that if ontology is useful in a certain area, then JSON-LD would probably be useful there too.

洪民憙 (Hong Minhee)

@hongminhee@hollo.social

I never thought this little rant of mine would be read by so many people. 😲

洪民憙 (Hong Minhee)

@hongminhee@hollo.social

I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.

Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.

But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.

Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.

To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.

Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.

#JSONLD #fedidev

洪民憙 (Hong Minhee)

@hongminhee@hollo.social · Reply to 초무

@chomu.dev JSON-LD를 그냥 JSON으로 다뤄도 괜찮다고 보는 사람이 많은 것 같아요.

洪民憙 (Hong Minhee)

@hongminhee@hollo.social · Reply to 초무

@chomu.dev JavaScript는 이미 JSON-LD 具顯(구현)이 있어서 Fedify는 안 그래도 그걸 가져다 쓰고 있어요 ㅋㅋㅋ

洪民憙 (Hong Minhee)

@hongminhee@hollo.social · Reply to Doug Webb

@douginamug Thank you so much for recognizing my hard work!

洪民憙 (Hong Minhee)

@hongminhee@hollo.social

I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.

Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.

But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.

Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.

To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.

Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.

#JSONLD #fedidev

nicole mikołajczyk 🔜 piwo ➡️ gpn

@mkljczk@fediverse.pl

apparently Mobilizon 5.2.0 broke JSON-LD stuff for the few AP implementations that care, without any announcement other than ‘bugfix: Replace joinmobilizon.org by mobilizon.org’

A commit that changes the JSON-LD header to include the domain mobilizon. org rather than joinmobilizon.org for the namespace — ALT text
A commit that changes the JSON-LD header to include the domain mobilizon. org rather than joinmobilizon.org for the namespace

洪民憙 (Hong Minhee)

@hongminhee@hollo.social

Thanks @_elena for taking a photo of me!

@mariusor@metalhead.club · Reply to 洪民憙 (Hong Minhee) :nonbinary:

@hongminhee it's no biggie - I doubt there's many projects that accept and thread correctly for this corner case - I just like to use this conversation as a test for threading. :D

Btw, I don't know if it's relevant to #fedify but I have the logic for threading (based on JWZ's old email threading algorithm) in the ONI project: https://git.sr.ht/~mariusor/oni/tree/master/item/src/js/items-threading.js

git.sr.ht

~mariusor/oni (master): src/js/items-threading.js - sourcehut git

洪民憙 (Hong Minhee)

@hongminhee@hollo.social · Reply to marius

@mariusor Oh, yeah, apparently @moreal should fix this!

洪民憙 (Hong Minhee)

@hongminhee@hollo.social

Recently, @moreal built ap-thread-reader, a tool that displays threaded posts on a single page. Works with any ActivityPub platform, not just Mastodon.

Try it at https://ap-thread-reader.fly.dev/.

Built with Fedify and released as open source: https://github.com/moreal/ap-thread-reader.

More details at https://blog.moreal.dev/2026/02/ap-thread-reader-introduction/index.en.html.

blog.moreal.dev

ap-thread-reader, ActivityPub-compatible Thread Reader — 잡다한 블로그

Introduce ap-thread-reader's feature

洪民憙 (Hong Minhee)

@hongminhee@hollo.social · Reply to 돔베기 :spinny_cat_gay:

@thx 感謝(감사)합니다…!