洪 民憙 (Hong Minhee)

Hello, I'm an open source software engineer in my late 30s living in #Seoul, #Korea, and an avid advocate of #FLOSS and the #fediverse.

I'm the creator of @fedify, an #ActivityPub server framework in #TypeScript, @hollo, an ActivityPub-enabled microblogging software for single users, and @botkit, a simple ActivityPub bot framework.

I'm also very interested in East Asian languages (so-called #CJK) and #Unicode. Feel free to talk to me in #English, #Korean (#한국어), or #Japanese (#日本語), or even in Literary Chinese (#文言文, #漢文)!

#introduction

安寧(안녕)하세요, 저는 서울에 살고 있는 30代(대) 後半(후반) 오픈 소스 소프트웨어 엔지니어이며, 自由(자유)·오픈 소스 소프트웨어와 聯合宇宙(연합우주)(fediverse)의 熱烈(열렬)한 支持者(지지자)입니다.

저는 TypeScript用(용) ActivityPub 서버 프레임워크인 @fedify 프로젝트와 싱글 유저用(용) ActivityPub 마이크로블로그인 @hollo 프로젝트와 ActivityPub 봇 프레임워크인 @botkit 프로젝트의 製作者(제작자)이기도 합니다.

저는 東(동)아시아 言語(언어)(이른바 #CJK)와 유니코드에도 關心(관심)이 많습니다. 聯合宇宙(연합우주)에서는 國漢文混用體(국한문 혼용체)를 쓰고 있어요! 제게 韓國語(한국어)나 英語(영어), 日本語(일본어)로 말을 걸어주세요. (아니면, 漢文(한문)으로도!)

#툿친소 #연친소 #별친소

こんにちは、私はソウルに住んでいる30代後半のオープンソースソフトウェアエンジニアで、自由・オープンソースソフトウェアとフェディバースの熱烈な支持者です。名前は洪 民憙（ホン・ミンヒ）です。

私はTypeScript用のActivityPubサーバーフレームワークである「@fedify」と、ActivityPubをサポートする1人用マイクロブログである 「@hollo」と、ActivityPubのボットを作成する為のシンプルなフレームワークである「@botkit」の作者でもあります。

私は東アジア言語（いわゆるCJK）とUnicodeにも興味が多いです。日本語、英語、韓国語で話しかけてください。（または、漢文でも！）

#自己紹介

민주당이 성공적으로 극우를 밀어내고 보수 자리를 차지하기를 바란다. 근데 진보 사람들한테 욕먹고 비판받는 건 걍 좀 당연하게 생각하고 감수하시길. 맨날 현실을 못 보는 이상주의자들이라고 억울해 하는데 어차피 한줌 아닌가? 한줌이라 생각하니까 전략적으로 다른 방식을 취한 게 아닌가? 한줌 사람들은 이상을 추구하게 냅두시고 전략대로 정치 무관심층 공략이나 콘크리트 부수는 데 에너지를 쓰기 바람.

@maxd Here's why:

https://hollo.social/@hongminhee/0196cdba-8ce9-711c-80c0-d0b64c1ffa99

@PuercoPop @thisismissem You raise a really good point. You're right that different types of applications have different needs, and a one-size-fits-all approach probably isn't ideal.

I think this actually aligns with what I was considering—not a universal API for the entire fediverse, but rather domain-specific standardized APIs that share common patterns where it makes sense.

For example, we might have:

• A standardized GraphQL API for microblogging platforms (Mastodon, Pleroma, Misskey)
• A different standardized API for discussion/forum platforms (Lemmy, Mbin, PieFed)
• Yet another for media-centric platforms (PeerTube, Pixelfed)

Each domain would have APIs optimized for their specific use cases, but they could share common patterns, authentication methods, and even some base types.

This approach would still give us the benefits of standardization within each domain (better tooling, consistent developer experience) while acknowledging the fundamental differences between these application types.

@twilliability @thisismissem That's a fair point about implementation complexity! GraphQL backends can indeed get complex, especially with deeply nested queries.

Regarding REST standardization—it's actually a great question. We could certainly create a more standardized REST API with OpenAPI/Swagger specs for code generation and type safety. This would be simpler to implement on the server side and still provide many benefits.

The reason I'm drawn to GraphQL + Relay is the client-side developer experience, particularly:

1. Declarative data fetching—components specify exactly what data they need
2. Automatic request batching and deduplication
3. Optimistic UI updates and client-side cache management
4. Built-in pagination handling with cursor-based connections

These features dramatically reduce client-side boilerplate and edge cases when building complex social UIs.

I think the real question is whether the implementation complexity is worth the developer experience gains. For large-scale applications with many different views of the same data, I believe it often is. But for smaller instances or simpler clients, maybe not.

I'm actually not wedded to GraphQL specifically—I'm more interested in finding a standardized client API that's both ergonomic and has good tooling support. What do you think would be the most pragmatic approach?

@thisismissem You're right that C2S doesn't provide efficient ways to fetch common app views like chronological feeds or pending follow requests. That's exactly why I think we need something better designed for client use cases.

Regarding GraphQL complexity—that's a valid concern. I've also worked with GraphQL in production, and security, performance, and complexity management are real challenges. However:

1. We could define a standard schema with best practices built-in
2. Many of these challenges have established patterns now (depth limiting, persisted queries, etc.)
3. Server implementations could share common GraphQL middleware for security

The key advantage would be that clients wouldn't need to implement the heavy processing themselves, as the server would handle the data shaping via resolvers.

As for SPARQL—interesting alternative! It does have performance challenges as you mentioned. My thinking is that GraphQL has much wider adoption and tooling, which might make it easier for developers to work with.

What I'm really seeking is something that combines ActivityPub's federation capabilities with a more client-friendly query interface. Do you have other ideas that might achieve this balance?

@bgl 흠, 그렇군요… 그래도 일단 요주의 인물인 것 같긴 해요.

신청서 양식 마지막에 빈 입력란이 있는데 실수로 추가된 것입니다. 이벤터스에서 한 번 신청 양식을 정하면 수정할 수가 없다고 하네요. 그냥 아무 글자나 넣고 신청하시면 됩니다.

5월 24일(土) 한국 연합우주 개발자 모임(FediDev KR)에서 두 번째 스프린트 모임을 개최합니다! 장소는 뚝섬역 5번 출구쪽에 위치한 튜링의 사과(@TuringAppleDev)입니다.

참고로 스프린트 모임이란 함께 모여서 오픈 소스 코딩을 하는 자리인데, 한국 연합우주 개발자 모임의 스프린트에서는 새로운 연합우주 서비스나 앱을 개발하거나, 번역이나 문서에 기여하는 등 연합우주와 관련된 다양한 오픈 소스 활동을 모여서 함께 합니다. 지난 스프린트 모임의 기록을 스프린트 블로그(@sprints.fedidev.kr)에서 살펴보실 수 있습니다.

저는 그날 Fedify, Hollo, Hackers' Pub에 기여하시고자 하는 분들을 옆에서 도와드릴 예정입니다. Fedify, Hollo, Hackers' Pub에 기여해보고 싶었던 분들이 계시다면 모임에 참가하여 저와 함께 스프린트를 해보는 것도 좋을 것 같습니다.

이번 모임에 관심이 있으신 분은 행사 신청 페이지를 참고하시기 바랍니다.

於此彼(어차피) 元來(원래) OpenAI(라고는 하지만 事實上(사실상) ClosedAI) 製品(제품)은 안 썼지만, 앞으로도 쓰지 말아야겠다.

https://www.hankyung.com/article/2025010964607

@deadsuperhero That's a creative application idea! The concept of vehicles as actors with maintenance timelines is quite elegant.

While Fedify's current vocabulary extension capabilities are somewhat limited, the core ActivityPub concepts could still provide a useful starting point for your system.

Good luck with your project—it's the kind of innovative thinking the fediverse needs!

@reiver Yeah, of course! The major back-end platforms have their own GraphQL sever frameworks.

@reiver I believe it's quite common in client app programming, e.g., Flutter, Swift.

음. 이거 페디버스 소개하는 발표 장표에 넣어야겠다

인간이 일개 기업에서 의도적으로 방치하고 있는 추천알고리즘에 프로그래밍되지 않으려면 탈중앙화를 해야한다...

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

@aslakr That's a great suggestion! Headless CMS platforms like Sanity would be excellent candidates for ActivityPub integration. I'll definitely add Sanity to my outreach list.

@mrtoto That's actually a brilliant use case! Location check-ins and POIs map really well to ActivityPub's social model. The Place object in AS2 vocabulary was designed with this in mind.

If you ever decide to pursue this idea, I'd be happy to provide guidance on implementing it with Fedify. It's exactly the kind of specialized federation that could benefit from a structured approach.

@SymfonyStation Sorry, could you elaborate your ideas? I'd like to hear!

@wordshaper That's an interesting idea! Actually, if you're looking to integrate with Discord, BotKit might be a better fit than Fedify directly. BotKit sits on top of Fedify but provides a much simpler API specifically designed for creating fediverse bots.

With BotKit, you could create a Discord bridge with just a few dozen lines of code—handling events like mentions and messages becomes really straightforward. The event-based model would pair nicely with Discord's bot framework.

I wouldn't call it a “horrible idea” at all! For certain communities (gaming servers, developer groups), having a Discord-fediverse bridge could be quite valuable. Though I agree it shouldn't be obligatory—more like an optional plugin for those who want that cross-platform connection.

Curious to hear if you've worked with ActivityPub before or if this would be your first foray into the fediverse world?

@sef That's an intriguing perspective! While ActivityPub was designed primarily for social networking, I appreciate you thinking outside the conventional use cases.

I do have some reservations about how well it would map to accounting needs. ActivityPub's semantics are optimized for social interactions rather than financial transactions, which have stricter requirements for consistency, atomicity, and compliance.

That said, there are some interesting parallels in the bilateral nature of transactions you mentioned. The “your asset is my liability” relationship does mirror certain social interactions.

For specialized business domains like accounting, a purpose-built protocol might ultimately serve better than adapting ActivityPub. But I wonder if there might be value in a hybrid approach—perhaps using federation for notifications and approvals around financial activities, while keeping the core transaction logic in systems designed specifically for accounting.

Have you explored any specific aspects of how ActivityPub's vocabulary might be extended to handle accounting concepts? I'd be curious to hear more about where you see the strongest fit.

@PossiblyMax Thanks for the thoughtful feedback!

The sidecar container idea is intriguing. I've considered similar approaches but haven't prioritized it yet. Fedify's core is tightly coupled with TypeScript's type system, which helps prevent many common ActivityPub implementation errors. A containerized version would need a well-defined API surface that maintains these safety guarantees while being language-agnostic.

It's definitely on my radar now though. Are you working with a specific language/framework where you'd want to use this?

As for unusual fediverse use cases—those examples are actually spot-on! Blog comments via ActivityPub is a perfect use case (similar to how Mastodon threads can function as comments). And publishing notifications about new content is exactly what Ghost is doing with their Fedify integration.

Other interesting examples include:

• Event RSVPs that work across platforms
• Reading lists that can be shared and followed
• Federated webmentions for cross-site interactions

I'd love to hear if you have other specific scenarios in mind!

@mariusor Hmm, yeah, Node.js (or Deno or Bun) is less straightforward to deploy to bare metals than Go or Rust, but I believe nowadays it's getting easier as now we have LXCs and some container formats they offer (e.g., Deno allows you to pack your application into a single executable).

Actually, choosing TypeScript was quite strategic for me, because I'd never written any serious software in TypeScript before Fedify—my go-to languages were Haskell and Python at that time. However, I wanted Fedify to reach out wider audience, so I decided to write it in TypeScript, which is very popular for building web applications today. It might be a wrong decision though, haha.

@bgl Yeah, that's because we don't have things like POP3 or SMTP for fediverse. Hmm, technically we may have few similar ones, like ActivityPub C2S and Mastodon-compatible APIs, but they are quite limited (e.g., you can't quote posts using Mastodon APIs) or not adopted enough. I hope we will have C2S adopted someday though. 🤔

@hongminhee As a developer building a service that is planned to join the fediverse, I'm still uncertain about what the timeline should look like in the fediverse app. Why do users need multiple apps with each timeline sharing some of their content? When you have multiple email accounts, then you might need a single email client that supports all of them at the same time. In which aspect fediverse differs from this situation?

As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?

While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.

Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.

Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.

I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?

Would appreciate perspectives from both developers and platform owners.

@realgsong 그런 문제가 또 있군요… 😵

Okay, I've just ordered it finally!

아아~ 여러분 이만한 기여 맛집이 어디 없습니다~
ActivityPub 기반의 오픈소스 블로깅 서비스 HackersPub에 현장에서 기여할 수 있는 기회! 그 외에도,,,

* Fedify : ActivityPub 기반의 소프트웨어 개발하는 난이도를 낮춰주는 라이브러리
* Hollo : 1인 블로깅 플랫폼
* 혹은... 프론트엔드 하시는 분 한정, 마스토돈 클라이언트 만들기 온보딩까지 가능...!!!!

https://hackers.pub/@hongminhee/0196b961-2b85-7b25-b6cf-9900405d52eb

臺灣(타이완)에서는 乖乖(괴괴)라는 菓子(과자)를 서버 같은 컴퓨터 옆에 符籍(부적)처럼 두는 風習(풍습)이 있는데요. 乖乖(괴괴)는 中國語(중국어)로 「말을 잘 듣는다」는 뜻인데다, 草綠色(초록색) 封套(봉투)가 順航(순항)을 象徵(상징)한다고 합니다. (그래서 여러 色(색) 封套(봉투) 中(중)에서도 草綠色(초록색) 封套(봉투)만 效果(효과)가 있다고 여겨집니다.)

그런데 아내가 지난 臺北(타이베이) 出張(출장)에서 乖乖(괴괴)를 한 封紙(봉지) 사 왔더라고요. 그래서 저도 이 인스턴스 hollo.social과 Hackers' Pub이 돌아가는 Mac mini 옆에 두기로 했습니다. 乖乖(괴괴) 封套(봉투)에는 「請(청)〈乖乖(괴괴)〉，不要當機(불요당기)」(말 잘 듣고, 다운되지 말아라)라고 썼습니다.

乖乖(괴괴)의 效驗(효험)은 流通期限(유통 기한)까지 持續(지속)된다고 하는데요, 제가 둔 封紙(봉지)는 2026年(년) 4月(월) 11日(일)까지입니다. 그 때까지 다운이 안 되는지 한 番(번) 지켜보도록 합시다. 🤣

韓国のLinuxユーザーはLinux版KakaoTalkがなくて困っているけど、日本のLinuxユーザーはLinux版LINEがなくて困っているんだな。