洪 民憙 (Hong Minhee)

Hello! I'm Hong Minhee (洪 民憙), an open source software engineer in my late 30s, living in Seoul, Korea. I'm bisexual and non-binary (they/them), and an enthusiastic advocate of free/open source software and the fediverse.

I work full-time on @fedify, an ActivityPub server framework in TypeScript, funded by @sovtechfund. I'm also the creator of @hollo, a single-user ActivityPub microblog; @botkit, an ActivityPub bot framework; Hackers' Pub, a fediverse platform for software developers; and LogTape, a logging library for JavaScript and TypeScript.

I have a long interest in East Asian languages (CJK) and Unicode. I post mostly in English here, though occasionally in Japanese or in mixed-script Korean (國漢文混用體), a traditional writing style that interleaves Chinese characters with the native Korean alphabet. Wanting to write in that style was actually one of the reasons I joined the fediverse. Feel free to talk to me in English, Korean, Japanese, or even Literary Chinese!

#introduction

はじめまして！ソウル在住の30代後半のオープンソースソフトウェアエンジニア、洪 民憙（ホン・ミンヒ）と申します。バイセクシュアル（bisexual）・ノンバイナリー（non-binary）で、自由・オープンソースソフトウェア（F/OSS）とフェディバース（fediverse）の熱烈な支持者です。

STF（@sovtechfund）の支援を受け、TypeScript用ActivityPubサーバーフレームワーク「@fedify」の開発に専念しています。他にも、おひとり様向けのActivityPubマイクロブログ「@hollo」、ActivityPubボットフレームワーク「@botkit」、ソフトウェア開発者向けフェディバースプラットフォームHackers' Pub、JavaScript・TypeScript用ロギングライブラリLogTapeなどの制作者でもあります。

東アジア言語（いわゆるCJK）とUnicodeにも興味があります。このアカウントでは主に英語で投稿していますが、時々日本語や国漢文混用体（漢字ハングル混じり文）の韓国語でも書いています。実はこの文体で書きたくてフェディバースを始めた、という経緯もあります。日本語、英語、韓国語、漢文でも気軽に話しかけてください！

#自己紹介

安寧(안녕)하세요! 저는 서울에 살고 있는 30代(대) 後半(후반)의 오픈 소스 소프트웨어 엔지니어 洪民憙(홍민희)입니다. 兩性愛者(양성애자)(bisexual)이자 논바이너리(non-binary)이며, 自由(자유)·오픈 소스 소프트웨어(F/OSS)와 聯合宇宙(연합우주)(fediverse)의 熱烈(열렬)한 支持者(지지자)이기도 합니다.

STF(@sovtechfund)의 支援(지원)을 받아 TypeScript用(용) ActivityPub 서버 프레임워크 @fedify 開發(개발)에 專業(전업)으로 任(임)하고 있습니다. 그 外(외)에도 싱글 유저用(용) ActivityPub 마이크로블로그 @hollo, ActivityPub 봇 프레임워크 @botkit, 소프트웨어 開發者(개발자)를 위한 聯合宇宙(연합우주) 플랫폼 Hackers' Pub, JavaScript·TypeScript用(용) 로깅 라이브러리 LogTape 等(등)의 製作者(제작자)이기도 합니다.

東(동)아시아 言語(언어)(이른바 CJK)와 Unicode에도 關心(관심)이 많습니다. 이 計定(계정)에서는 主(주)로 英語(영어)로 포스팅하지만, 때때로 日本語(일본어)나 國漢文混用體(국한문 혼용체) 韓國語(한국어)로도 씁니다. 聯合宇宙(연합우주)에 오게 된 動機(동기) 中(중) 하나가 바로 國漢文混用體(국한문 혼용체)로 글을 쓰고 싶었기 때문이기도 하고요. 韓國語(한국어), 英語(영어), 日本語(일본어), 아니면 漢文(한문)으로도 말을 걸어주세요!

#툿친소 #연친소 #별친소 #자기소개

@Yohei_Zuho 勿論いいです！ありがとうございます！

24日(일)(土(토)) FediDev KR 스프린트 모임에 오시는 분들께는, 귀여운 Fedify 로고 스티커를 나눠 드리겠습니다.

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

Here is the exciting thing about "vertical decentralization", Bluesky's core innovation: since your PDS and your "app view" can be hosted by two different entities, this means the pool of people who can make Bluesky stop working for you can be taken to a theoretical maximum. For example with Mastodon, if Eugen screws up my app doesn't work. But with Bluesky, since I self-host my PDS, if *either* I *or* Bluesky mess up, it doesn't work! *Everybody* must have a good day *at once* or there's no app

What's actually happening right now is the Bluesky *website* is broken but the *phone app* still works. I propose the following theory:

Mastodon is "horizontally decentralized"; this means if one part of the network goes down the other parts continue working.

Bluesky is "vertically decentralized"; they separated each tech stack component into a slice that can be hosted by a different company. This means if any part of the network goes down they ALL stop working, because the layers interconnect

제가 추천하는 ActivityPub 입문 가이드 목록입니다.

그동안 페디버스 잘 이해 못했는데
되게 혁신적이고 민주적인(?) 온라인 지구촌 방식이네요.

개인적으론 2000년대에 인터넷 처음 썼을 때 느낀 신세계 이후로 두번째입니다

라는 멘션을 받았는데, 혁신적이고 민주적인 온라인 지구촌 방식이라는 표현 좋다

마스토돈이 윤리적인 SNS라고 언급된 기사

https://www.theguardian.com/world/2024/apr/30/stop-children-using-smartphones-until-they-are-13-say-french-experts-in-report

엄밀하게는 프랑스 쪽 연구를 인용한것이긴 한데.... 미성년자에게는 어지간하면 SNS를 멀리하도록 하되, 15세 이상부터는 마스토돈 같은 윤리적 SNS를 쓰도록하는 것은 괜찮다 뭐 그런 언급이 있음

@mikebroberts While the W3C specs exist as a reference, I wouldn't recommend starting there—they're underspecified and don't provide enough practical guidance for implementation.

Instead, I'd suggest these more practical resources:

1. Fedify's Creating your own federated microblog tutorial:

   • Provides a hands-on, step-by-step implementation
   • Covers both the theory and practice in an accessible way
   • Shows how to handle common ActivityPub patterns

2. For a better conceptual overview:

   • Sebastian Jambor's excellent Understanding ActivityPub series
   • Darius Kazemi's A highly opinionated guide to learning about ActivityPub

3. The SocialHub forum has many discussions about implementation practices and challenges faced by developers.

4. The FEP (Fediverse Enhancement Proposals) process documents community-developed extensions and conventions that go beyond the official spec.

The biggest challenge with ActivityPub isn't understanding the core concepts, but navigating all the de facto standards and practices that have evolved beyond the specs. Starting with practical tutorials rather than specs will give you a much clearer path forward.

@silverpill I agree that domain-specific APIs have their place and serve their communities well. Mastodon API, Lemmy API, etc. are certainly designed by experts in their respective domains.

Where I'd offer a different perspective is on the potential for improvement. I believe there's still significant room to enhance developer experience, especially for client apps aiming to provide optimal UI/UX.

My interest in GraphQL isn't about replacing domain expertise, but rather providing a more efficient abstraction layer that could:

1. Reduce over-fetching and under-fetching of data (getting exactly what's needed)
2. Provide better type safety and IDE integration
3. Simplify complex state management on clients
4. Enable more responsive UIs with optimistic updates

I see this as complementary to domain-specific knowledge, not contradictory. Domain experts would still design the underlying data models and relationships—GraphQL would just provide a more flexible way to query them.

As for ActivityPub C2S, I agree it should be the foundation of any universal client API. But the current C2S spec alone doesn't provide the ergonomics needed for modern app development. Ideally, we'd have something that combines ActivityPub's semantic model with more developer-friendly query capabilities.

@mikebroberts While the W3C specs exist as a reference, I wouldn't recommend starting there—they're underspecified and don't provide enough practical guidance for implementation.

Instead, I'd suggest these more practical resources:

1. Fedify's Creating your own federated microblog tutorial:

   • Provides a hands-on, step-by-step implementation
   • Covers both the theory and practice in an accessible way
   • Shows how to handle common ActivityPub patterns

2. For a better conceptual overview:

   • Sebastian Jambor's excellent Understanding ActivityPub series
   • Darius Kazemi's A highly opinionated guide to learning about ActivityPub

3. The SocialHub forum has many discussions about implementation practices and challenges faced by developers.

4. The FEP (Fediverse Enhancement Proposals) process documents community-developed extensions and conventions that go beyond the official spec.

The biggest challenge with ActivityPub isn't understanding the core concepts, but navigating all the de facto standards and practices that have evolved beyond the specs. Starting with practical tutorials rather than specs will give you a much clearer path forward.

@mikebroberts Your project sounds exciting! The blend of blogging and social photos with ActivityPub support is exactly the kind of application that can benefit from federation.

Fedify should work well with your AWS Lambda setup since you're using TypeScript. Fedify supports Node.js (which Lambda offers), along with Deno and Bun. A few considerations for serverless environments:

1. For persistence, you'd want to use something like DynamoDB with Fedify's KvStore interface
2. Lambda's stateless nature means you'll need to handle message queue processing carefully
3. Cold starts might impact performance for less frequent federation operations

The docs include integration examples with Express, which you can adapt for Lambda + API Gateway. Feel free to reach out when you get to the ActivityPub implementation phase—would be happy to provide guidance on adapting Fedify to serverless architecture.

Good luck with your project!

@maxd Thank you for sharing these important concerns and that article. You've raised valid points about GraphQL that definitely deserve careful consideration.

I completely agree that authorization and rate limiting present significant challenges in GraphQL implementations. The article you shared highlights these pain points well, and they're issues I've also witnessed in production environments.

That said, I'm still drawn to GraphQL + Relay because of the tremendous productivity benefits they offer on the client side. In my experience, features like declarative data fetching, automatic request batching, optimistic UI updates, and built-in pagination handling can dramatically reduce client-side complexity for certain applications.

Marc-Andre Giroux's thoughtful response article Why, after 8 years, I still like GraphQL sometimes in the right context acknowledges these challenges while offering a more nuanced view. As he points out, persisted queries are practically essential for addressing security and performance concerns - they transform GraphQL from “hard mode” into something much more manageable.

You're absolutely right that for open public APIs with untrusted clients, the challenges you mentioned become significantly harder to overcome. There's a reason we see fewer public GraphQL APIs compared to REST/OpenAPI ones.

I'm still learning and exploring this space myself, so I really appreciate your perspective. I think ultimately it comes down to carefully weighing these tradeoffs based on the specific context—the nature of the clients, team expertise, and data access patterns all factor into whether GraphQL's client-side benefits justify the server-side complexity for any given project.

Thanks again for adding this important dimension to the conversation!

「大器晩成(대기만성)」이란 旣得權層(기득권층)에게나 許容(허용)되는 스토리이다.

@PossiblyMax What a coincidence! When prototyping what became Fedify (codenamed FediKit then), I actually tried implementing ActivityPub in C# too, alongside TypeScript and Python.

C# posed challenges with ActivityPub's dynamic nature—the strongly typed system was harder to align with ActivityPub's flexible object structures. That's partly why I settled on TypeScript.

Thanks for the kind words!

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

@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.