洪 民憙 (Hong Minhee)

@hongminhee@hackers.pub · 415 following · 277 followers

Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub!

Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다.

Fedify、Hollo、BotKit、そしてこのサイト、Hackers' Pubを作っています。

嗨，我是 Fedify、Hollo、BotKit 以及這個網站 Hackers' Pub 的開發者！

Website
hongminhee.org
GitHub
@dahlia
Hollo
@hongminhee@hollo.social
DEV
@hongminhee
velog
@hongminhee
Qiita
@hongminhee
Zenn
@hongminhee
Matrix
@hongminhee:matrix.org
X
@hongminhee
Clairement crevée @Claire@social.sitedethib.com
Quiet public
Shared by 洪 民憙 (Hong Minhee)

@TakTak! @hongminhee洪 民憙 (Hong Minhee) it's the other way around, FEP-5624 pre-dates GTS' interaction policies but was never implemented anywhere and did not get much traction; the bulk of the discussion at the time was about who should control the reply policy (original post author or person you immediately reply to)

GTS decided to pick the second solution even if it's not necessarily the ideal one, because it's much simpler to implement

GTS' interaction policies were then refined with a lot of back-and-forth with Mastodon devs when we were working on quote posts (resulting in FEP-044F which re-use GTS' interaction policies)

maybe we should retire FEP-5624

0
0
0
1
0
0
0
0
0
2
0
0
1
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

After reviewing FEP-5624: Per-object reply control policies and GoToSocial's interaction policy spec, I find myself leaning toward the latter for long-term considerations, though both have merit.

FEP-5624 is admirably focused and simpler to implement, which I appreciate. However, 's approach seems to offer some architectural advantages:

  1. The three-tier permission model (allow/require approval/deny) feels more flexible than binary allow/deny
  2. Separating approval objects from interactions appears more secure against forgery
  3. The explicit handling of edge cases (mentioned users, post authors) provides clearer semantics
  4. The extensible framework allows for handling diverse interaction types, not just replies

I wonder if creating an that extracts GoToSocial's interaction policy design into a standalone standard might be worthwhile. It could potentially serve as a more comprehensive foundation for access control in .

This is merely my initial impression though. I'd be curious to hear other developers' perspectives on these approaches.

Summary card of repository fediverse/fep

fep/fep/5624/fep-5624.md at main

fep - Fediverse Enhancement Proposals

codeberg.org · Codeberg.org

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

There would be some potential downsides to consider though:

  • Performance overhead: Each interaction requires policy verification, and approval object dereferencing adds network latency.
  • UX complexity: The three-tier permission model (allow/approve/deny) might confuse users compared to simpler binary choices.
  • State management burden: Servers need to persistently store approval objects and handle revocation edge cases gracefully.
0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

After reviewing FEP-5624: Per-object reply control policies and GoToSocial's interaction policy spec, I find myself leaning toward the latter for long-term considerations, though both have merit.

FEP-5624 is admirably focused and simpler to implement, which I appreciate. However, 's approach seems to offer some architectural advantages:

  1. The three-tier permission model (allow/require approval/deny) feels more flexible than binary allow/deny
  2. Separating approval objects from interactions appears more secure against forgery
  3. The explicit handling of edge cases (mentioned users, post authors) provides clearer semantics
  4. The extensible framework allows for handling diverse interaction types, not just replies

I wonder if creating an that extracts GoToSocial's interaction policy design into a standalone standard might be worthwhile. It could potentially serve as a more comprehensive foundation for access control in .

This is merely my initial impression though. I'd be curious to hear other developers' perspectives on these approaches.

Summary card of repository fediverse/fep

fep/fep/5624/fep-5624.md at main

fep - Fediverse Enhancement Proposals

codeberg.org · Codeberg.org

4
1
1
1
0
0
0
1
0
1
0
0
2
1
0
김무훈 @iamuhun@hackers.pub
Public

<section> 버리고 <article> 써야 하는 이유

〈section〉 태그 안의 글에 헤딩(제목)을 포함하면 화면상에서는 그 헤딩들이 논리적인 순차 구조를 가지고 있는 것처럼 보인다. 하지만 이는 순전히 시각적인 것일 뿐 보조 기술과 연동된 구조 정보가 아니다. 〈section〉 태그의 용도는 무엇이고, 헤딩을 어떻게 코딩해야 보조 기술 사용자에게 정말 중요한 구조 정보를 전달할 수 있을까?

<section>을 버리고 HTML5의 <article>을 써야 하는 이유

각 태그는 목적에 맞게 쓰여야 합니다. 제목을 표시할 때는 헤딩 태그를 <h1>, <h2>··· 순차적으로 나열하는 구조여야 합니다. 같은 레벨의 <h> 태그에 <section>을 둘러싸서 제목 크기를 조절하는 방법은 겉모양만 달라질 뿐입니다. <section>은 구획을 나눌 때 쓰세요. <main>, <header>, <footer>, <nav> 등은 스크린리더 사용자에게 매우 유용한 태그입니다. 보조 기술을 사용하지 않는 사용자에게는 아무 영향을 주지 않으니 적극적으로 활용하셔도 됩니다. <article>은 여러모로 유용합니다. 블로그 기사를 만들 수 있을 뿐만 아니라 스스로 독자적인 페이지가 될 수도 있습니다. 유튜브 홈페이지에서는 동영상을 <article> 태그에 넣어 나열하는 식으로 이용할 수도 있습니다. 다른 요소를 추가하기보다 태그의 기본 기능을 올바르게 적용한 웹 페이지를 만들 수 있기를 바랍니다.

webactually.com · Webactually

1
0
0
3
0
0
1
1
0
1
1
0
0
0
0
2
1
0
0
1
0
2
0
0
1
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

Hackers' Pubに興味はあるけれど、DMで招待状をお願いするのは気が引けるという方のために、Googleフォームを作成しました。メールアドレスを入力するだけで、Hackers' Pubの招待状をお送りします。たくさんのご応募をお待ちしています‼️

https://forms.gle/F3ETSDvaGmkSV2hh6

2
0
0
bgl gwyng @bgl@hackers.pub
Public

똑같은 인터페이스에 대한 여러 구현체에 대해 같은 테스트를 적용하기위한 좋은 방법이 뭘까요? vitest의 경우에 test.each(implementations) 이런식으로 할수 있다는데, 이러면 구현체가 늘어났을때 테스트 파일을 수정해야하는점이 마음에 안든단 말이죠. 지금 구현체를 인자로 받아 테스트를 정의하는 함수를 만들고 각 구현체 마다 .test.ts파일을 만들어서 호출하는 방식을 고려하고 있습니다. 더 좋은 방법이 있을까요?

1
0
0
13
0
1
Yukiharu YABUKI @yabuki@pao.moe
Public
Shared by 洪 民憙 (Hong Minhee)

あー。drizzleって、PostgreSQLlのmoney(通貨型)はまだサポートしてないのか。なるほど、試さないと分からないもんだ。他の型で代用するか。

書籍「テスト駆動開発」か「リファクタリング第二版」でいうプログラムだけでなく、データベースもリファクタリングの対象にするというか、将来に向かって現在動くものを作る感じなんだな。これも。

1
0
1
2
1
0
0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

현재 Hackers' Pub은 Fresh 2.0 알파 버전을 사용하고 있는데, Fresh 자체의 한계점도 많이 느꼈고 무엇보다 최근 몇 달 사이에 정식 릴리스를 향한 진전이 보이지 않기에 GraphQL 준비가 끝나면 프런트엔드를 SolidStart로 점진적으로 옮겨가고자 한다.

2
0
0
1
1
0
XiNiHa @xiniha@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

아까 Post에 달린 이모지 리엑션 쪽 API 깎느라고 n시간 동안 삽질하다가 결국 때려치고 질문을 올렸었는데 아직 구현이 안 된 부분이었다고 해서 PR을 올렸다 (???

https://github.com/hayes/pothos/pull/1440

This PR enables using drizzleConnectionHelper to create advanced Drizzle connections outside Drizzle objects.

Allow entry connections with drizzleConnectionHelper by XiNiHa · Pull Request #1440 · hayes/pothos

This PR enables using drizzleConnectionHelper to create advanced Drizzle connections outside Drizzle objects.

github.com · GitHub

2
0
0
XiNiHa @xiniha@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

@bglbgl gwyng 커스텀 렌더러 (Solid에선 Universal Rendering이라고 부름) 지원 자체는 잘 되어 있는데 그냥 커뮤니티 망치가 부족해서 유지보수가 안 되는 것에 가깝고 😅 이런 물건은 왜인진 도저히 모르겠지만 나름 관리가 잘 되고 있습니다

SolidJS Framework for Lightning Renderer. Contribute to lightning-tv/solid development by creating an account on GitHub.

GitHub - lightning-tv/solid: SolidJS Framework for Lightning Renderer

SolidJS Framework for Lightning Renderer. Contribute to lightning-tv/solid development by creating an account on GitHub.

github.com · GitHub

3
0
0
Perlmint @perlmint@hackers.pub
Public

캘린더 이벤트로 변환이 가능한 데이터들 (예약 서비스의 예약 내역, 캘린더 양식이 아니어서 변환이 필요한 데이터, 매우 낮은 에러 레이트 리밋(?) 같은 이유로 인하여 일반적인 캘린더 동기화에 넣기 불안한 출처)를 모아다가 주로 사용하는 캘린더 서비스로 보내주는 서비스를 만들려고 합니다.

1
1
0
0
3
0
2
0
0
0
0
0
1
0
0
3
1
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

현재 Hackers' Pub은 Fresh 2.0 알파 버전을 사용하고 있는데, Fresh 자체의 한계점도 많이 느꼈고 무엇보다 최근 몇 달 사이에 정식 릴리스를 향한 진전이 보이지 않기에 GraphQL 준비가 끝나면 프런트엔드를 SolidStart로 점진적으로 옮겨가고자 한다.

3
1
0
lionhairdino @lionhairdino@hackers.pub
Public

딱 ORM은 아니지만, 목적은 같은 하스켈의 opaleye 가 있습니다. 쿼리에 타입을 도입한 모양이라, 쿼리 검사에 타입 체커의 도움을 받을 수 있습니다. 처음 봤을 때, 함수형 방식으로 ORM 같은 걸 만든다면, 이렇게 되는 구나 감탄했는데, 익히는 비용이 만만치 않은 것 같습니다. @hongminhee洪 民憙 (Hong Minhee)

Contribute to tomjaguarpaw/haskell-opaleye development by creating an account on GitHub.

GitHub - tomjaguarpaw/haskell-opaleye

Contribute to tomjaguarpaw/haskell-opaleye development by creating an account on GitHub.

github.com · GitHub

洪 民憙 (Hong Minhee) @hongminhee@hollo.social
Public
Shared by 洪 民憙 (Hong Minhee)

Hackers' PubにLLMを活用した記事の自動翻訳機能が追加されました。これにより、Hackers' Pubに投稿された英語や韓国語の記事を日本語で閲覧できるだけでなく、日本語で書いた記事を海外の読者に紹介する事も可能に成りました。

なお、Hackers' Pubは招待制で運営されています。ご興味のある方は、DMでメールアドレスを教えていただければ、招待いたします。

5
0
0

Hackers' Pub 업데이트: LLM 기반의 게시글 번역 기능

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub

LLM 기반의 게시글 번역 기능이 추가되었습니다. 우선, 자신이 쓴 게시글이 LLM을 이용해 번역되는 것을 허용하려면, 게시글 공개 설정에서 “LLM 기반 자동 번역 허용” 옵션을 켜 주셔야 합니다. 기존 게시글은 모두 이 옵션이 꺼져 있습니다만, 새로 쓰는 게시글의 경우 기본적으로 켜져 있습니다.

한국어판 게시글 공개 설정 페이지에 추가된 “LLM 기반 자동 번역 허용” 옵션
한국어판 게시글 공개 설정 페이지에 추가된 “LLM 기반 자동 번역 허용” 옵션
영어판 게시물 공개 설정 페이지에 추가된 “Allow LLM-powered automatic translation” 옵션
영어판 게시물 공개 설정 페이지에 추가된 “Allow LLM-powered automatic translation” 옵션

위와 같이 옵션을 켜 준 게시글은 위쪽에 다음과 같이 “다른 언어로 읽기” 메뉴가 표시되게 됩니다. 이 메뉴에 나오는 언어 목록은 언어 설정에서 정할 수 있습니다.

게시글 첫 부분에 표시되는 “다른 언어로 읽기” 메뉴 (한국어판)
게시글 첫 부분에 표시되는 “다른 언어로 읽기” 메뉴 (한국어판)
게시글 첫 부분에 표시되는 “Read in other languages” 메뉴 (영어판)
게시글 첫 부분에 표시되는 “Read in other languages” 메뉴 (영어판)

이 중에서 이미 번역이 완료된 언어는 바로 표시되지만, 아직 번역이 완료되지 않은 언어의 경우, 아래와 같이 기다리라는 메시지가 뜨게 됩니다. 게시글의 분량에 따라 번역 시간은 차이가 나지만, 짧으면 30초에서 길면 5분 정도 걸립니다.

게시글이 번역중이라는 메시지 (한국어판): “이 게시글은 영어에서 한국어로 번역중입니다. 번역이 완료될 때까지 기다려 주세요.”
게시글이 번역중이라는 메시지 (한국어판): “이 게시글은 영어에서 한국어로 번역중입니다. 번역이 완료될 때까지 기다려 주세요.”
게시글이 번역중이라는 메시지 (영어판): “This article is being translated from Korean to English. Please wait until the translation is complete.”
게시글이 번역중이라는 메시지 (영어판): “This article is being translated from Korean to English. Please wait until the translation is complete.”

번역이 완료되면, 아래와 같이 메시지가 바뀝니다.

게시글의 번역본 상단에 뜨는 메시지 (한국어판): “이 게시글은 영어에서 한국어로 번역되었습니다.”
게시글의 번역본 상단에 뜨는 메시지 (한국어판): “이 게시글은 영어에서 한국어로 번역되었습니다.”
게시글의 번역본 상단에 뜨는 메시지 (영어판): “This article has been translated from Korean to English.”
게시글의 번역본 상단에 뜨는 메시지 (영어판): “This article has been translated from Korean to English.”

번역 기능은 제가 Hackers' Pub을 맨 처음 구상할 때부터 핵심 기능으로 고려하고 있던 것이었습니다. 소프트웨어 프로그래머로서 일정 수준 이상 성장하기 위해서는 반드시 영어를 배워야만 하는 불합리함이나 그리고 일본어나 중국어 등 영어가 아닌 언어로 쓰인 다양한 자료에 대부분의 외국인은 접근하지 못한다는 아쉬움을 오래 전부터 느꼈기 때문입니다. 다행히 얼마 전부터 LLM의 번역 품질이 아주 좋아졌고, 이를 활용하여 꽤 괜찮은 품질의 번역 기능을 Hackers' Pub 같은 작은 웹사이트에서도 구현할 수 있게 되었네요.

참고로 현재 번역에 쓰이는 모델은 Claude Sonnet 3.7입니다. 저렴하다고는 할 수 없는 모델인데요. 시범적으로 운영해 보고, 비용이 너무 부담된다고 여겨지면 Gemini 2.5 Flash 같은 다른 모델로 전환하는 것도 고려하고 있습니다.

아무튼, 모처럼 추가한 번역 기능이니 많은 분들이 유용함을 누리셨으면 좋겠습니다.

아래는 제가 샘플로 미리 만들어 둔 번역본들입니다:

  • Ditch the DIY Drama: Why Use Fedify Instead of Building ActivityPub from Scratch? (영어) → 〈DIY 드라마는 그만: 왜 ActivityPub을 처음부터 구축하는 대신 Fedify를 사용해야 할까요?〉 (한국어)
  • 〈애플리케이션 개발 측면에서 본 Drizzle ORM 대 Kysely 비교〉 (한국어) → 「アプリケーション開発の観点から見たDrizzle ORMとKyselyの比較」 (일본어)
  • 〈deno-task-hooks: Git 훅을 Deno 태스크로 쉽게 관리하기〉 (한국어) → deno-task-hooks: Easily Manage Git Hooks as Deno Tasks (영어)
  • Browser-Native Translation and Language Detection APIs Coming Soon (영어) → 〈브라우저 네이티브 번역 및 언어 감지 API 곧 출시 예정〉 (한국어)
Read more →
6
0
1
2
0
0
4
0
0
4
2
1