洪 民憙 (Hong Minhee)

@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 쒸익쒸익

方今(방금) LLM이 「표식」이라는 表現(표현)을 쓰길래 생각나서 썼다.

이제는 사람들이 漢字語(한자어) 【標識(표지)】를 한글로 「표지」가 아니라 「표식」이라고 적는 것을 그러려니 하고 받아들여야만 하는데… 아직도 너무나 거슬리는 것이다. 【標識板(표지판)】은 「표식판」이라고 안 읽을 거면서!

https://www.joongang.co.kr/article/14879259

@jj1bdx.tokyo Thanks!

@heybran Don't you have any photos that someone else took of you instead of selfies? Selfies are fine, but I think photos taken by others look more natural and better!

My previous avatar was pretty outdated, so I updated it with a more recent photo.

OTel Isn't Going Well (And I Made A Spreadsheet About It) https://lobste.rs/s/ubeyqf #distributed
https://matduggan.com/otel-isnt-going-well-and-i-made-a-spreadsheet-about-it/