洪 民憙 (Hong Minhee) :nonbinary:

Update: we've decided to go ahead and submit the CFP to @COSCUP@floss.social 2026. The track will be called Fediverse & Social Web—think FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.

If the track is accepted, would you be interested in coming to Taipei (Aug 8–9) to give a talk?

(Boosts appreciated!)

@hongminhee@hollo.social

#fedidev #fediverse #SocialWeb #ActivityPub

I've been thinking about adding federation health monitoring to #Fedify—not as a separate data store or custom API, but by extending the existing #OpenTelemetry integration. The idea is to expose delivery outcomes, signature verification failures, and per-remote-host error rates as OpenTelemetry metrics alongside the spans Fedify already emits. If you already have a Prometheus or Grafana setup, you'd get federation observability basically for free. Circuit breaker behavior (temporarily skipping a remote server that's been consistently unreachable) could surface as OpenTelemetry events, keeping everything in the same trace context rather than scattered across separate logs.

Does this sound useful to you? I'm curious whether people building on Fedify—or running federated servers in general—would actually reach for this, and what kinds of things you'd most want to observe. Happy to hear any thoughts.

#fedidev #ActivityPub

I'm writing this in English.

Not because English is my first language—it isn't. I'm writing this in English because if I wrote it in Korean, the people I'm addressing would run it through an outdated translator, misread it, and respond to something I never said. The responsibility for that mistranslation would fall on me. It always does.

This is the thing @Gargron@mastodon.social misses, despite its good intentions.

@Gargron@mastodon.social argues that LLMs are no substitute for human translators, and that people who think otherwise don't actually rely on translation. He's right about some of this. A machine-translated novel is not the same as one rendered by a skilled human translator. But the argument rests on a premise that only makes sense from a certain position: that translation is primarily about quality, about the aesthetic experience of reading literature in another language.

For many of us, translation is first about access.

The professional translation market doesn't scale to cover everything. It never has. What gets translated—and into which languages—follows the logic of cultural hegemony. Works from dominant Western languages flow outward, translated into everything. Works from East Asian languages trickle in, selectively, slowly, on someone else's schedule. The asymmetry isn't incidental; it's structural.

@Gargron@mastodon.social notes, fairly, that machine translation existed decades before LLMs. But this is only half the story, and which half matters depends entirely on which languages you're talking about. European language pairs were reasonably serviceable with older tools. Korean–English, Japanese–English, Chinese–English? Genuinely usable translation for these pairs arrived with the LLM era. Treating “machine translation” as a monolithic technology with a uniform history erases the experience of everyone whose language sits far from the Indo-European center.

There's also something uncomfortable in the framing of the button-press thought experiment: “I would erase LLMs even if it took machine translation with it.” For someone whose language has always been peripheral, that button looks very different. It's not an abstract philosophical position; it's a statement about whose access to information is expendable.

I want to be clear: none of this is an argument that LLMs are good, or that the harms @Gargron@mastodon.social describes aren't real. They are. But a critique of AI doesn't become more universal by ignoring whose languages have always been on the margins. If anything, a serious critique of AI's political economy should be more attentive to those asymmetries, not less.

The fact that I'm writing this in English, carefully, so it won't be misread—that's not incidental to my argument. That is my argument.

韓國語(한국어) 母語(모어) 話者(화자)로서 @Gargron@mastodon.social이네… 只今(지금) 東京(도쿄) 旅行中(여행중)이라 글을 쓸 수가 없는데, 있다가 角(각) 잡고 제대로 反駁(반박) 글을 써 봐야 할 듯.

I'm thinking of proposing a #fediverse/social web community track at @COSCUP@floss.social 2026 (Aug 8–9, Taipei)—think FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?

(Boosts appreciated!)

#ActivityPub #SocialWeb #fedidev #COSCUP

While I have no ill will toward the “ATmosphere” (Bluesky/AT Protocol), the contrast in funding models is hard to ignore. The fediverse's support from strategic investments in open infrastructure (like NLnet or STF) feels far healthier than ATmosphere's heavy backing from crypto-linked VCs—a sector often fraught with bubbles and social harm. I'm a bit envious of their smooth R&D resources, but I'm ultimately convinced that building on a foundation of digital public goods is the more sustainable path for a truly decentralized web.

Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedify—server-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.

https://github.com/fedify-dev/fedify/issues/288#issuecomment-3971459585

#fedidev #fediverse #PortableObjects

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

Optique 0.10.0 released—the biggest update yet for this TypeScript CLI parser library.

What's new:

• Runtime context system for composing config files, env vars, and other data sources
• New @optique/config package with Standard Schema validation
• Man page generation from parser metadata (@optique/man)
• Inter-option dependencies with context-aware shell completions
• 11 network value parsers (IP address, port, hostname, email, CIDR, etc.)
• Program interface: define metadata once, reuse everywhere

This is the last pre-release before 1.0.0.

https://github.com/dahlia/optique/discussions/108

Someone who enthusiastically uses an open source project I made and actively reports issues is an absolute gem. I'm so grateful for them.

We have only 4 issues left until the Fedify 2.0 milestone!

Fedify 2.0 will probably be out by the end of February. No, it has to be.

Working on @fedify/debugger, an embedded ActivityPub debug dashboard for Fedify applications. It will be shipped with Fedify 2.0.

https://github.com/fedify-dev/fedify/pull/564

Did you know there's a community space for #Fedify, #Hollo, #BotKit, and other Fedify ecosystem projects?

Whether you have questions, want to share what you're building, or just want to hang out with fellow fediverse developers—come join us!

• Matrix: #fedify:matrix.org
• Discord

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

Recently, @moreal@hackers.pub 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.

I'll be presenting @fedify@hollo.social at @fosdem@fosstodon.org 2026! My talk Fedify: Building ActivityPub servers without the pain was accepted for the Social Web Devroom. See you in Brussels on January 31–February 1!

8月3日（日）にOSC 2025 京都で開催される「@Yohei_Zuho@mstdn.y-zu.org」セミナーで、「BotKit by Fedify：誰でも簡単に作れるActivityPubボット」というテーマでオンラインにて約10分間発表します。普段からフェディバースボットの制作に興味がある方には、きっと興味深く聞いていただけるのではないかと思います。参加費も無料ですので、ぜひ多くの方のご参加をお待ちしております。

OSC京都2025でどちらの発表を聞きたいですか？

8月3日のOSC京都で10分間のセミナー発表をすることになりました。二つのテーマで迷っているので、皆さんのご意見をお聞かせください！

どちらのテーマに興味がありますか？

#OSC2025 #ActivityPub #Fedify #BotKit #fediverse

I'm currently experimenting with a poll creation feature for @botkit@hollo.social. If this experiment pans out, the feature will likely be included in the next release, BotKit 0.3.0. So far, so good. Each vote will trigger a Bot.onVote event in real-time. This could open up a lot of interesting possibilities, like a bot that uses emoji selection for one-time authentication.