洪 民憙 (Hong Minhee)

@jj1bdx.tokyo 私も同じ感覚です。韓国語でもこの意味の変化が起きたのは、やはりこの10年ぐらいからだと思います。日本語の漢語は韓国語でもそのまま漢字語として受け入れられやすいせいか、こういう言葉の変化が連動して起きることが結構多い気がします。

本来「課金する」という言葉は「料金を課す」という意味だが、近年モバイルゲームなどの影響で「料金を払う」という意味にまで拡大しているという趣旨の日本語記事。ちなみに韓国語でも（おそらく日本のモバイルゲーム、あるいはその影響を受けた韓国・中国のモバイルゲームの影響で）「課金(グァグム)하다(ハダ)」という言葉が「料金を払う」という意味まで含むようになる現象が同じく起きている。

https://salon.mainichi-kotoba.jp/archives/280630

'과금'이 원래는 판매자가 요금을 매기는 의미인데 최근에는 소비자가 돈을 내는 의미로 확장되고 있다. 비슷한 사례로 '모금'은 본래는 돈을 요청하는 뜻이었는데 기부하는 의미가 새로 붙었고. https://salon.mainichi-kotoba.jp/archives/280630

LogTapeを日本語で紹介する記事が公開されました。「ライブラリの中では黙って待つ」という設計思想を軸に、configure()を呼ぶまでログが一切出力されない仕組みや、ゼロ依存・5.3KBでNode.js・Deno・Bun・ブラウザ・エッジランタイムを横断して動く点、階層的カテゴリや構造化ログの実践的な使い方まで、実際に動かせるサンプル付きで解説してくださっています。設計の背景まで汲み取ってもらえて嬉しいです。

https://easegis.jp/blog/logtape/

@Profpatsch To be honest, I haven't decided yet, but I'm leaning toward Bitwarden. I'm still thinking it over a bit after reading this post, though.

After almost fifteen years, I'm done with @1password. I just read through the email exchange @mvsde posted, where 1Password's support team defended the company's patronage of DHH's Omacom Foundation with the usual “we're funding the foundation, not the individual” line. That distinction doesn't hold up when the money still legitimizes him and everyone his politics attract. I've trusted 1Password with my passwords for longer than most of my relationships have lasted, and that's exactly why this matters: loyalty like that shouldn't be free. Migration starts this week.

@tooearly 이거 페디버스 연동도 되는 거예요?

@sl007 These vocabularies should be implemented in Fedify. See also the docs on extending the vocabulary. Could you file an issue for this?

I think this is the most sophisticated and rigorous piece on the philosophy of technology I've read recently. It was a bit long and challenging to get through, but I'm glad I read it. I highly recommend it to anyone working in the software industry.

New article: this time, we use Heidegger to explain why the "it's just a tool" line that often comes up in tech is so very silly:

https://deadsimpletech.com/blog/no-such-thing-as-just-a-tool

The dates for FOSDEM 2027 have been confirmed for next year, January 30th–31st (the full weekend). Is anyone planning on going?

The @fedify team, including myself, @z9mb1, and @2chanhaeng, will likely all be heading there together.

#FOSDEM will happen on the weekend of 2027-01-30 and 2027-01-31!

We'll post a proper news item once all the automations work after our yearly archiving cutover.

https://fosdem.org/2027/

퍼슈트의 기원을 찾아서

@dansup Making a brand new account just to be mean about someone's dog is pretty sad. Your dog is lovely.

ちなみに、自分のGitHubのユーザー名である@dahliaも、実はX JAPANの1996年のアルバム『DAHLIA』から来ているんだ。

最近（…というか、ここ半年間）、思春期の頃によく聴いていたXの「ENDLESS RAIN」にまたどっぷりハマってる。正確には1990年に発売されたシングル『WEEK END』の2曲目に収録されてる、1990年2月4日の日本武道館ライブバージョン。自分ももう、どうしようもないノンバおじ（ノンバイナリーのおじさんを何と呼べばいいかわからないからノンバおじと呼ぶことにする）なのかな。

日本語で書かれたFedifyの紹介記事が掲載されたんですね。ありがとうございます。

https://easegis.jp/blog/fedify/

@evan Thanks for all the detail, this is really helpful context. I didn't realize the CfC process on the mailing list carried that much weight, that alone changes how I'd describe the participation options to people here.

I'm happy to read over the Korean version for style, though depending on how long the document ends up being it might take me a bit. For Japanese I should say upfront that I'm not a native speaker, so I'd rather not be the one vouching for naturalness there. @tesaguri would be a much better fit for that, if they're up for it.

@foxmask @evan By “those people,” do you mean the ActivityPub spec editors?

Why Free Software usability tends to suck via @isagalaev https://lobste.rs/s/a5qr8n #design #philosophy
https://web.archive.org/web/20030201183139/http://mpt.phrasewise.com/discuss/msgReader$173

I think the #RFC9421 HTTP Signature algorithm should be explicitly included in #Mastodon's requests.

Feedback welcome - especially those explaining politely why I'm a wrong about this.

https://github.com/mastodon/mastodon/issues/29905#issuecomment-5440336919

@evan I think the language barrier is the first thing to tackle. Live video calls are the hardest format for non-native speakers, so shifting more of the work to written communication would help a lot, and every meeting really needs minutes, even rough ones, since at least those can be run through a translator afterward. I've tried the newer real-time transcription and translation tools a few times and honestly the quality still isn't there, especially with ActivityPub-specific jargon that general models just don't recognize; feed a bad transcript into a translator and it gets worse, not better. Written async channels, like the FEP process already is, seem like a better fit for now. On the community side, @fedidevkr (a Korean fediverse developer group I'm part of) has been kicking around the idea of a session where people draft FEP proposals together in Korean first, then translate and refine into English as a group. Still an early idea, but I think local hubs like that could lower the barrier more than any single W3C-side change.

@hongminhee how can we get more East Asian #ActivityPub developers involved in the #W3C #SocialCG and #SocialWG?

@ntek 現在、latestタグが0.9.14を指しているのですが、確認してもらえますか？

Hollo security updates: 0.8.11 and 0.9.14

If you run Hollo, update to a current patched release now. Fedify has disclosed two vulnerabilities, one of which affects Hollo: CVE-2026-77632, a high-severity server-side request forgery vulnerability in Fedify's authenticated document loader.

Hollo relies on the authenticated document loader when it fetches remote documents such as actors and public keys with a signed HTTP request. Affected Fedify versions checked that the initial URL resolved to a public network destination, but did not apply the same check when that URL returned an HTTP redirect. An attacker who controlled the public URL could therefore redirect the signed request to a loopback address, a link-local cloud metadata service, or an RFC 1918 private address.

An unauthenticated attacker could reach this path by sending an inbox request with a signature whose keyId points to an attacker-controlled public URL. Fedify has to fetch the key before it can verify the signature, so even a bogus signature is enough to trigger the request. The demonstrated attack is blind SSRF: the internal response is consumed while resolving the remote document and is not automatically returned to the attacker.

The fix validates every redirect target before fetching it. Hollo's existing ALLOW_PRIVATE_ADDRESS option still permits private destinations when an operator explicitly opts in, such as for a closed federation or test environment.

The other disclosed vulnerability, CVE-2026-69132, concerns unbounded circuit-breaker state in Fedify 2.3.0 through 2.3.4. Hollo's supported 0.8.x and 0.9.x release lines use Fedify 2.1.x and 2.2.x respectively, so this issue does not affect them.

For full technical details, see the Fedify security advisories for CVE-2026-77632 and CVE-2026-69132, and the Fedify security announcement.

All Hollo versions in the supported 0.8.x and 0.9.x release lines up to and including 0.8.9 and 0.9.12 are affected by CVE-2026-77632. The fix first appeared in 0.8.10 for the 0.8.x series and 0.9.13 for the 0.9.x series. The current releases are 0.8.11 and 0.9.14, and those are the versions we recommend installing.

Hollo 0.7.x is also affected. It and earlier release lines are no longer supported under the Hollo security policy. Upgrade to a supported release series rather than remaining on an older version.

For 0.8.x deployments, update to 0.8.11:

docker pull ghcr.io/fedify-dev/hollo:0.8.11

For 0.9.x deployments, update to 0.9.14:

docker pull ghcr.io/fedify-dev/hollo:0.9.14

After pulling the new image, restart your Hollo container. If you deploy from source, pull the corresponding release tag and restart.

Thanks to Jace for reporting CVE-2026-77632 and to @nyanrus for reporting CVE-2026-69132, and for their responsible disclosure to the Fedify project.

If anything is unclear, ask below.

If you use BotKit, update to a patched release now. Two vulnerabilities affect Fedify versions included by BotKit as a dependency: CVE-2026-77632, a high-severity server-side request forgery vulnerability in the authenticated document loader, and CVE-2026-69132, a medium-severity denial-of-service vulnerability in the outbound delivery circuit breaker.

CVE-2026-77632 affects the authenticated document loader Fedify uses to fetch remote documents such as actors and public keys with signed HTTP requests. Affected versions checked that the initial URL was public, but did not apply the same check when the URL returned an HTTP redirect. An attacker who controlled the public URL could redirect the signed request to a loopback address, a link-local cloud metadata service, or an RFC 1918 host. In the ordinary inbox path, Fedify may fetch a signature's keyId before it can verify the signature, so a bogus signature is enough to reach this path. The demonstrated attack is blind SSRF: the internal response is consumed while resolving the remote document and is not automatically returned to the attacker.

The fix validates every redirect target before it is fetched. The existing allowPrivateAddress option continues to permit private destinations when an application explicitly opts in, such as for a closed federation or test environment.

CVE-2026-69132 affects the outbound delivery circuit breaker introduced in Fedify 2.3, which records delivery failures in the configured key–value store using the remote inbox's host:port as part of the key. An attacker could send signed Follow activities from actors whose inbox URLs pointed to distinct ports where delivery would fail. Each failure created a separate record, allowing the attacker to grow circuit-breaker state until storage or memory was exhausted. Fedify 2.3.0 and 2.3.1 were vulnerable with every circuit-breaker configuration. In versions 2.3.2 through 2.3.4, the vulnerable configuration was a custom failure policy without an explicit stateTtl.

The fix gives custom failure policies a bounded default stateTtl, equal to recoveryDelay plus heldActivityTtl (7 days 30 minutes with the default values). On stores that support compare-and-set operations, Fedify also sweeps circuit-breaker state left by affected releases and stamps it with a TTL.

BotKit 0.4.x versions through 0.4.5 and BotKit 0.5.x versions through 0.5.1 include a Fedify version affected by CVE-2026-77632. The circuit-breaker issue, CVE-2026-69132, affects only the BotKit 0.5.x line. Patched releases are BotKit 0.4.6 and 0.5.2. BotKit 0.4.6 uses Fedify 2.1.21, and BotKit 0.5.2 uses Fedify 2.3.5.

For BotKit 0.5.x, update @fedify/botkit:

npm  update  @fedify/botkit
yarn upgrade @fedify/botkit
pnpm update  @fedify/botkit
bun  update  @fedify/botkit
deno update  @fedify/botkit

For BotKit 0.4.x, update @fedify/botkit:

npm  update  @fedify/botkit@0.4.6
yarn upgrade @fedify/botkit@0.4.6
pnpm update  @fedify/botkit@0.4.6
bun  update  @fedify/botkit@0.4.6
deno update  @fedify/botkit@0.4.6

After updating, redeploy. The GitHub Security Advisories are GHSA-cxc3-7q96-6cpx and GHSA-fx98-wc5v-jrg5. See also Fedify's own announcement.

Thanks to Jace and @nyanrus for the reports and responsible disclosure.

If anything is unclear, feel free to ask on GitHub Discussions or Matrix.

If you use an affected Fedify release, update now. Two vulnerabilities have been fixed in @fedify/fedify: CVE-2026-77632, a high-severity server-side request forgery vulnerability in the authenticated document loader, and CVE-2026-69132, a medium-severity denial-of-service vulnerability in the outbound delivery circuit breaker.

CVE-2026-77632 affects versions 1.6.1 through 2.3.4. Fedify uses an authenticated document loader when it fetches remote documents such as actors and public keys with a signed HTTP request. Affected versions checked that the initial URL was public, but did not apply the same check when that URL returned an HTTP redirect. An attacker who controlled the public URL could redirect the signed request to a loopback address, a link-local metadata service, or an RFC 1918 host. In the ordinary inbox path, Fedify may fetch a signature's keyId before it can verify the signature, so a bogus signature is enough to reach this path. The demonstrated attack is blind SSRF: the internal response is consumed while resolving the remote document and is not automatically returned to the attacker.

The fix validates every redirect target before it is fetched. The existing allowPrivateAddress option still permits private destinations when an application explicitly opts in, such as for a closed federation or test environment.

CVE-2026-69132 affects versions 2.3.0 through 2.3.4. Fedify 2.3 introduced an outbound delivery circuit breaker that records failures in the configured key–value store, using the remote inbox's host:port as part of the key. An attacker could send signed Follow activities from actors whose inbox URLs pointed to distinct ports where delivery would fail. Each failure created a separate record, allowing the attacker to grow circuit-breaker state until storage or memory was exhausted. Versions 2.3.0 and 2.3.1 were vulnerable with every circuit-breaker configuration. In versions 2.3.2 through 2.3.4, the vulnerable configuration was a custom failure policy without an explicit stateTtl.

The fix gives custom failure policies a bounded default stateTtl, equal to recoveryDelay plus heldActivityTtl (7 days 30 minutes with the default values). On stores that support compare-and-set operations, Fedify also sweeps circuit-breaker state left by affected releases and stamps it with a TTL. Applications that need a different retention period for a custom failure policy can continue to set stateTtl explicitly.

The SSRF fix first appeared in 2.0.25, 2.1.21, 2.2.10, and 2.3.5; the circuit-breaker fix first appeared in 2.3.5. The current releases on those lines are 2.0.26, 2.1.22, 2.2.11, and 2.3.6, and those are the versions we recommend installing. The circuit-breaker issue only affects the 2.3 line; the authenticated document-loader issue affects every Fedify release from 1.6.1 through 2.3.4. If you still use Fedify 1.x, change your dependency to a current 2.x release because package-manager update commands do not cross the declared major-version range.

The GitHub Security Advisories are GHSA-cxc3-7q96-6cpx and GHSA-fx98-wc5v-jrg5.

Update @fedify/fedify:

npm  update  @fedify/fedify
yarn upgrade @fedify/fedify
pnpm update  @fedify/fedify
bun  update  @fedify/fedify
deno update  @fedify/fedify

After updating, redeploy. If you run other Fedify-based servers, update those too.

Thanks to Jace and @nyanrus for the reports and responsible disclosure.

If anything is unclear, ask below.

@hboon Unless there's a specific reason not to, I tend to write my prompts in my native language, Korean. Within the Korean developer community, there's some talk that writing prompts in English is more token-efficient, but I don't think that's been proven. Even if it were true, I keep using Korean because I feel it's better for conveying subtle nuances and giving detailed instructions compared to writing in English.

@2chanhaeng 😡

@2chanhaeng 쒸익쒸익