洪 民憙 (Hong Minhee)

I have archived the apmodel repository. While developing apkit, I encountered the problematic aspects of apmodel, so I plan to redesign it. This does not mean I intend to abandon apkit.

@hypolite The Jevons point is well taken, but I think the assumption that model size and model capability move in lockstep is already starting to break down. Smaller, more specialized models have been closing the gap with frontier models faster than most people expected a couple of years ago. That doesn't settle the question, but it does suggest the trajectory isn't as fixed as the current “bigger is better” trend implies.

On IP: I think that argument assumes the legal and social framework around training data is static. If a public foundation model existed, the question of how its training data was collected would be negotiated very differently—with public accountability, with legislative pressure, with the possibility of opt-in or compensated datasets. The current situation is partly so bad because private actors made unilateral decisions with no one to answer to. That changes when the entity doing the training is public.

But honestly, what strikes me most about your last message is that we may be closer in position than the argument suggests. You're saying rejection is symbolic, but useful as a social signal that could hasten the collapse of the current unsustainable model. I'm not sure I disagree with that. Where we differ, I think, is in what we expect to find in the ruins. You seem to expect something more modest and less harmful to emerge on its own. I'm less confident about that—I think what fills the vacuum depends heavily on what political and social structures we've built in the meantime. Which is, I suppose, exactly why I think the direction of reclamation matters now, even if the specific path is still unclear.

연합우주를 어떻게하면 사람들이 더 자발적으로 다가오고 더 재밌는 컨텐츠로 만들 수 있을까? 라는 고민이 들면서도 한편으로는 니치한 것 자체가 연합우주의 감성이 아닌가 싶은 생각이 들고, 한편으로는 내가 만드는 연합우주 서비스 자체만으로 사람들에게 어필이 되었으면 좋겠고 복잡한 생각이 드는 것이다..

@hypolite You raise fair points, and I don't think I can fully refute them. The Uber analogy is genuinely worrying, and I share your concern about what “profitability” will eventually mean for people who currently depend on LLMs as tools.

That said, I think there's a tension in your argument worth examining. You note that LLMs are still fledgling and heavily subsidized, and I agree. But that same fledgling status means we're also at the beginning of the efficiency curve, not the end. Inference costs have dropped dramatically over the past two years, and experiments like DeepSeek suggest training costs can fall significantly too. “It's expensive now” and “it will always be expensive” are two different claims, and I don't think the first settles the second.

On the redundancy point: the current setup has every major company independently training overlapping foundation models in competition with each other, which is itself an enormous waste. If every software company built its own operating system from scratch instead of sharing one, the cost of software development would be staggering. Public infrastructure like CERN works precisely because the baseline investment is shared, and innovation happens on top of it. I think a similar logic applies here, even if the path there is unclear.

But the question I keep coming back to is: what does rejection actually achieve? If the goal is to limit the harms you describe—the IP violations, the labor displacement, the toll-booth dynamic—it's not obvious to me that individuals and communities blocking scrapers meaningfully slows any of that down. The companies driving this have enough momentum and capital that our refusal mostly affects us. I'm not saying refusal is wrong; I'm genuinely uncertain. I just think the burden of demonstrating impact falls on both sides of this argument, not only on mine.

@Yohei_Zuho @kur0den0010 ありがとうございます！6日（金）にお会いできると嬉しいです。もしよろしければ、私の旅行仲間であるHaze Leeさん（@nebuleto）も一緒に行っても大丈夫でしょうか？（日本語可能です）

3月4日(水)から11日(水)まで東京に滞在します。この機会に日本のフェディバースの皆さんとお会いしたいです。ランチでもディナーでも、お茶やコーヒーでも構いません。私と会ってくださる方はいらっしゃいますか？食事やお茶は私がおごります。私はこの期間中、特に予定がないので、皆さんのご都合に合わせることができます。（ただし、最終日を除きます）

By the way, if you're building a complex CLI app in Node.js, Deno, or Bun, please give Optique a try—I bet you will be satisfied. Curious why? Read this document.

One good thing of my extended sabatical from corporate employment is that while I'm working on #GoActivityPub there's so many things to do, that as soon as something interesting catches my eye, I can go explore it and learn a new thing that can be used, adapted or added to one of the components of the library or its adjacent tooling and applications.

Currently, I'm excited to replace the existing HTML sanitizer for TrustedTypes and setHTML in #ONI as they're finally making its way to Firefox.

#Optique 1.0.0 is shaping up, and three API changes are worth knowing about in advance.

• Runner consolidation: run() from @optique/run now accepts source contexts directly, which makes runWith() and runWithConfig() redundant for most use cases. runWithConfig() is removed outright—no deprecation, since we have a major version to absorb the break. For the typical CLI, run() is now the single entry point.

• Meta command config redesign: help, version, and completion in RunOptions no longer use mode: "command" | "option" | "both". Each now takes independent command and option sub-configs, which makes it possible to give --help a -h alias, hide a meta command from usage lines while keeping it in the help listing, or group the command and option forms differently. String shorthands (help: "both", version: "1.2.3", etc.) still work exactly as before.

• Config-file-relative paths: bindConfig()'s key callback now receives config file metadata as a second argument—configDir and configPath—so you can resolve paths relative to the config file's location rather than the working directory. This matches how tools like the TypeScript compiler handle outDir and similar path options.

More details on the 1.0.0 milestone.

@hypolite Yeah, I’ll admit the licensing idea is “cute.” It was just something that came to mind on the spot. As I wrote in my piece, Acting materialistically in an imperfect world: LLMs as means of production and social relations, I think there are still many other potential ways to reclaim LLMs from private corporations. The point is, the whole act of rejecting LLMs isn't going to do much to help us achieve what we want. I believe the only hope lies in reclaiming the LLMs themselves for the public good.

3月4日(水)から11日(水)まで東京に滞在します。この機会に日本のフェディバースの皆さんとお会いしたいです。ランチでもディナーでも、お茶やコーヒーでも構いません。私と会ってくださる方はいらっしゃいますか？食事やお茶は私がおごります。私はこの期間中、特に予定がないので、皆さんのご都合に合わせることができます。（ただし、最終日を除きます）

@cnx To be honest, I tried using conventional machine translation to properly understand your comment, but it was useless, so I had to use an LLM. I run into this kind of situation often.

My position is that the public should reclaim the LLMs that are currently monopolized by private corporations. On this topic, I would appreciate it if you read my previous article, Histomat of F/OSS: We should reclaim LLMs, not reject them.

@liaizon @hypolite @yhancik

One thing I find a bit disappointing is that the Sanitizer API is [Exposed=Window] only, so there's no way to use it server-side in Node.js or Deno. A simple sanitize(html: string): string method would have been enough to retire a whole category of npm packages. The irony is that sanitizing untrusted HTML is arguably more common on the server—that's where you receive user input, store it, and render it back.

For now, server-side JavaScript still has to rely on DOMPurify (dragging jsdom along with it) or something like sanitize-html, each shipping its own HTML parser that may subtly disagree with how browsers actually parse markup—which is exactly the problem this API was supposed to solve.

https://hacks.mozilla.org/2026/02/goodbye-innerhtml-hello-sethtml-stronger-xss-protection-in-firefox-148/

The Sanitizer API landed in Firefox 148, along with element.setHTML().

This lets you fully configure how HTML strings are cleaned as they're parsed.

https://hacks.mozilla.org/2026/02/goodbye-innerhtml-hello-sethtml-stronger-xss-protection-in-firefox-148/

洪民憙さんのサイトめちゃくちゃ恰好いいな

@Gargron @liaizon That might be the case for European languages. But for distant language pairs like English → Korean, LLM-based translation is necessary. This is especially true for deep discussions like in @tante's writing.

「@tante's decision to block LLM scrapers is consistent with his own logic, but it ended up reinforcing the asymmetry between readers who are fluent in English and those who are not. This is not just an irony. The asymmetry operates across the whole of technology discourse. Whose viewpoint is set as the default? What social relations produced that default?」
- @hongminhee
https://writings.hongminhee.org/2026/02/acting-materialistically-in-an-imperfect-world

https://writings.hongminhee.org/2026/01/histomat-foss-llm/index.ja.html

労働が非人間的になるのは「疎外」と呼ばれるけど、先日洪民憙さんの記事を読んだばかりだった。

Marxは『資本論』第一巻で、イギリスのラッダイト運動をこう評した。

労働者が機械そのものと機械の資本主義的利用とを区別し、したがって物質的生産手段そのものではなく、その社会的搾取形態を攻撃することを学ぶまでには、時間と経験が必要だった。

機織り機を打ち壊した労働者たちの怒りは正当だった。方向が間違っていただけだ。問題は機械ではなく、機械をめぐる資本主義的社会関係だった——機械が労働時間を短縮するどころか延長し、労働者を解放するどころか機械の付属物にしてしまうのは、機械の本性ではなく、機械を配置する方式の問題だった。Marxは彼らを嘲笑したのではなく、闘争が成熟していく過程を叙述したのだ。

https://writings.hongminhee.org/2026/02/acting-materialistically-in-an-imperfect-world/

F/OSSの唯物史観——LLMを拒絶するのではなく、取り戻すべきだ — 洪民憙雑記
https://writings.hongminhee.org/2026/01/histomat-foss-llm/

🚀 New libraries for @graphql on Vapor and Hummingbird dropped!

Expose GraphQL APIs with just one line of code:
routeBuilder.graphql(schema: schema) { ... }

✅ Full spec compliance
✅ WebSocket subscriptions
✅ Built-in GraphiQL IDE

Check them out 👇
https://forums.swift.org/t/introducing-graphql-vapor-hummingbird-packages/84758

Fedify로 어디까지 할 수 있나 프로덕션에서 실험하는 사람이 돼

미스키에서도, 마스토돈에서도, 해커스펍에서도 호환이 되는 밋업 플랫폼 만들고 있는데 관심있으신분

@julian That's a fair point; honestly, right now there's no reliable way to know. If a server supports both RFC 9421 and draft cavage, and you lead with cavage, you can't infer anything about its RFC 9421 support from a successful response.

The workaround I applied is intentionally temporary, just to keep things working while Bonfire instances catch up with the fix. Once they do, I'll revert firstKnock back to RFC 9421.

The longer-term answer to your question might be FEP-844e, which proposes a capability discovery mechanism—servers could explicitly advertise which specifications they implement (including RFC 9421) via an Application object. That would make the guesswork unnecessary. It's still a draft, but worth keeping an eye on.

@elena Thanks! 🥰

A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent a follow request—but the Accept never came back, even though they hadn't enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.

I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.

This matters because Fedify implements a double-knocking mechanism—if a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.

I filed two issues on the Bonfire #ActivityPub repo—one requesting RFC 9421 support, and one about returning 401 on invalid signatures. For the latter, I also sent a PR, which got merged pretty quickly: bonfire-networks/activity_pub#9.

That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.

One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as “supports RFC 9421”—because they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.

After all that, the mutual follow went through and my DM reply landed. Worth it.

#fedidev #fediverse #Hollo #HackersPub

The recent Hollo 0.7.3 and 0.7.4 updates have improved interoperability with #Bonfire. The issue where sending/receiving DMs or mutual following with Bonfire wasn't working properly has been resolved.

@box464 Thank you! I've got an account on the indieweb.studio instance for now, but I'll ask you if I need another one later!

@fedicat Oh, didn't know that. Thank you!

Hi #fediverse and #ActivityPub developers!

I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.

Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!

#fedidev #BonfireNetworks