SPF & DKIM records
Permalink: https://wizardzines.com/comics/spf-dkim/
洪 民憙 (Hong Minhee)
@hongminhee@hackers.pub · 1032 following · 730 followers
Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub! My main account is at 
@hongminhee洪 民憙 (Hong Minhee) 
.
Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다. 제 메인 계정은: @hongminhee洪 民憙 (Hong Minhee) .
Fedify、Hollo、BotKit、そしてこのサイト、Hackers' Pubを作っています。私のメインアカウントは「@hongminhee洪 民憙 (Hong Minhee) 」に。
Website- hongminhee.org
GitHub- @dahlia
Hollo- @hongminhee@hollo.social
DEV- @hongminhee
velog- @hongminhee
Qiita- @hongminhee
Zenn- @hongminhee
Matrix- @hongminhee:matrix.org
X- @hongminhee
#Optique 0.9.0 is here!
This release brings #async/await support to #CLI parsers. Now you can validate input against external resources—databases, APIs, Git repositories—directly at parse time, with full #TypeScript type safety.
The new @optique/git package showcases this: validate branch names, tags, and commit SHAs against an actual Git repo, complete with shell completion suggestions.
Other highlights:
- Hidden option support for deprecated/internal flags
- Numeric choices in
choice() - Security fix for shell completion scripts
Fully backward compatible—your existing parsers work unchanged.
My last salaried job was at a company that built blockchain technology. No, it wasn't for cryptocurrency. The goal was to use blockchain to create a fully peer-to-peer, decentralized game. I found it a technically interesting goal. I've always been fascinated by decentralized technologies, which is also why I'm drawn to ActivityPub. Another thing that attracted me was the promise that this technology would be implemented as 100% open source. I had always wanted to work on open source full-time, so I accepted the offer.
However, once I started working there, I found myself increasingly disappointed. The organization gradually filled up with so-called “crypto bros,” and the culture shifted toward prioritizing token price over technical achievement. I and a few close colleagues believed that introducing partial centralization to the fully decentralized system—whether to defend the token price or to rush a release—was not a “minor compromise” but a “major corruption.” The rest of the organization didn't see it that way.
One of the most painful things about being in that organization was the fact that the technology I was creating was not only unhelpful to society, but was actually harming the environment and society. At the time, I felt like I was working for a tobacco company—knowing that cigarettes harm people's health, yet turning a blind eye and doing the job anyway.
I'm no fan of cryptocurrency, but I still think blockchain has technically interesting aspects. However, blockchain has already become socially inseparable from cryptocurrency, and even if blockchain is technically interesting, there are very few domains where it's actually useful. Furthermore, the negative environmental impact of blockchain technology is a problem that must be solved for it to be taken seriously. In its current state, when I weigh the harm against the utility, I believe the harm overwhelmingly outweighs it.
Anyway, I have now completely said goodbye to blockchain technology. I feel at ease now that I don't have to live with that guilt anymore. I also came to realize that engineers must consider not only the technical interest of a technology but also its social impact. So for now, I want to focus on ActivityPub. I find it both technically interesting and socially meaningful!
Wrote about designing type-safe sync/async mode support in TypeScript. Making object({ sync: syncParser, async: asyncParser }) automatically infer as async turned out to be trickier than expected.
https://hackers.pub/@hongminhee/2026/typescript-sync-async-type-safety
複数のパーサーを合成するとき、一つでも非同期なら結果も非同期になる——これをTypeScriptの型レベルで表現するのが意外と難しかった。Optiqueでの設計過程を書きました。
클로드 코드 쓰고있으니 더 나은 VCS에 대한 욕심이 커진다. 나는 클로드가 브랜치를 더 자주 쪼개서, 원하는 시점으로의 롤백이 더 편해졌으면 좋겠다.
하나 생각나는 아이디어는 브랜치 명을 hierachial하게 만들어서 가령 fix-bug-1/refactor-class-foo/fix-function-bar 이런식으로, 무슨 일하는지의 맥락을 브랜치명에 나타내는 것이다. 그리고 a/b 브랜치는 a 브랜치의 자식이어야 한다는 제약도 강제한다.
...는 git은 a란 브랜치가 이미 있으면 a/b, a/c 같은 브랜치를 못만든다. 이유는 바로... git 브랜치가 이름 디렉토리로 관리되기 때문이다. 뭐 이런;;
근데 솔직히 마크다운이 "너 진짜 **핵심**을 찔렀어"의 형태로 대중화가 될 줄은 몰랐지...
프로젝트에 Deno와 pnpm을 함께 쓰고 있었는데, mise의 태스크 기능을 사용해서 개발에 필요한 커맨드들을 일원화했더니 속이 편하다.
릴리스도 매번 수동으로 하고 있었는데 이참에 SKILL.md 써서 자동화를 해 보았다.
에이전트가 도구를 다루는 방식에 대한 인식을 동료들과 맞추기 위해 자손킴님의 Tool Use 글을 팀에 공유했고 (👍 을 받음)
프로젝트에 Deno와 pnpm을 함께 쓰고 있었는데, mise의 태스크 기능을 사용해서 개발에 필요한 커맨드들을 일원화했더니 속이 편하다.
@hongminhee洪 民憙 (Hong Minhee) 저도 한달째 Zed 쓰고 있는데 Git 연동 개선이 시급합니다. 말씀대로 요즘은 에이전트가 작업한거 리뷰하는 시간이 상당한데, 이때 Zed가 많이 불편합니다. 그냥 Zed 터미널에서 lazygit쓰고 마네요.
@bglbgl gwyng
고등학생 때부터 Vim을 썼으니까, Vim/Neovim을 합치면 거의 15년 가까이 썼던 것 같다. 그러다가 Deno와 TypeScript를 접하면서 Visual Studio Code로 갈아탔는데, 그러고 한 2–3년? Zed가 나와서 Zed를 또 1년 가까이 썼다. (아, VS Code를 쓸 때도 Zed를 쓸 때도 Vim 키 바인딩을 끄지는 못 했다.)
그런데 요즘에는 Claude Code니 OpenCode니 LLM 기반의 코딩 에이전트들을 꽤 열심히 쓰게 되면서 에디터 자체를 잘 안 쓰게 되었다. 심지어 import 한 줄 추가하는 것도 프롬프트로 해결하게 된다. 그래야 LLM한테 맥락이 주어져서 혼선이 없기 때문이다. (내가 말 없이 코드를 고쳐 두면 LLM이 뭔가의 이상 상황으로 받아들이거나, 무심코 원래 코드로 되돌리기도 한다.) 그러다 보니 커밋 직전에 디테일을 손 보거나 코드를 리뷰할 때 빼고는 에디터를 잘 안 켜게 된다. 켜더라도 즉각적으로 열리는 걸 선호하게 되어서, Vim/Neovim이 가장 먼저 손이 가더라.
결국에는 몇 년 동안의 방황을 거쳐 다시 Vim/Neovim으로 돌아오게 되었다는 이야기. 그래서 조만간 먼지가 쌓인 Vim/Neovim 설정도 새해 맞이를 겸해서 한 번 청소를 해야겠다 싶다.
@hongminhee洪 民憙 (Hong Minhee) 저도 비슷한 이유로 Emacs로 회귀했다가 지금은 Zed를 쓰게 되었습니다 😂
모든 연락 다 끊고 (트위터 제외) 쭉 쉬었더니 아주 좋았다
I wrote Zig bindings to quickjs-ng with 96% API coverage (~240 exported C decls) with unit tests, examples, and doc strings on all functions in less than 6 total hours with AI assistance. I never want to hear that AI isn't faster ever again. https://github.com/mitchellh/zig-quickjs-ng
This isn't slop. I worked for those 6 hours.
I was reviewing everything it outputted, updating my AGENTS.md to course correct future work, ensuring the output was idiomatic Zig, writing my own tests on the side to verify its work (while it worked), and more. My work was split across ~40 separate Amp threads (not one mega session, which doesn't work anyways unless you're orchestrating).
I have a ton of experience writing bindings to libraries for various languages, especially Zig. I have never achieved this much coverage in so little time with such high quality (e.g. test coverage). My usual approach is to get bind just-enough of the surface area to do my actual work and move on. This time I thought I'd draw the whole owl, because it's a new world. And I'm very happy with the result.
Anyone with experience writing bindings knows that you do some small surface area, then the rest of the coverage is annoying repetition. That's why I usually stopped. Well, LLMs/agents are really, really good at annoying repetition and pattern matching. So going from 5% API coverage to 95% is... cake.
There is probably some corners that are kind of nasty still, but I've been re-reviewing every line of code manually and there is nothing major. Definitely some areas that can just use a nicer Zig interfaces over the C API, but that's about it.
I plan on writing a longer form blog showcasing my threads, but you can at least see the final AGENTS.md I produced in the linked repo.
I will repeat that I was not sitting back at all during those 6 hours. While agents were working, I was working, just on separate -- but related -- tasks. I know for a fact that I could not have completed this amount of work in 6 hours fully manually (based on the experience that I've written something like 30+ bindings to C libraries in the past decade, probably more).
I wrote Zig bindings to quickjs-ng with 96% API coverage (~240 exported C decls) with unit tests, examples, and doc strings on all functions in less than 6 total hours with AI assistance. I never want to hear that AI isn't faster ever again. https://github.com/mitchellh/zig-quickjs-ng
This isn't slop. I worked for those 6 hours.
I was reviewing everything it outputted, updating my AGENTS.md to course correct future work, ensuring the output was idiomatic Zig, writing my own tests on the side to verify its work (while it worked), and more. My work was split across ~40 separate Amp threads (not one mega session, which doesn't work anyways unless you're orchestrating).
I have a ton of experience writing bindings to libraries for various languages, especially Zig. I have never achieved this much coverage in so little time with such high quality (e.g. test coverage). My usual approach is to get bind just-enough of the surface area to do my actual work and move on. This time I thought I'd draw the whole owl, because it's a new world. And I'm very happy with the result.
Anyone with experience writing bindings knows that you do some small surface area, then the rest of the coverage is annoying repetition. That's why I usually stopped. Well, LLMs/agents are really, really good at annoying repetition and pattern matching. So going from 5% API coverage to 95% is... cake.
There is probably some corners that are kind of nasty still, but I've been re-reviewing every line of code manually and there is nothing major. Definitely some areas that can just use a nicer Zig interfaces over the C API, but that's about it.
I plan on writing a longer form blog showcasing my threads, but you can at least see the final AGENTS.md I produced in the linked repo.
jekyll 블로그에도 심플한 좋아요 기능을 달 수 있을 것인가? https://burgeonlab.com/blog/add-appreciation-buttons-to-hugo-with-iine/ 가 도움이 될 거 같아서 일단 북마크. 계속 jekyll 을 쓸지도 생각 좀 해봐야 되는데.
Heya! I just released XenoAtom.Terminal https://github.com/XenoAtom/XenoAtom.Terminal, a modern replacement for System.Console for .NET CLI/TUI apps. 🎉
It keeps a familiar Console-like feel, but adds the terminal-native stuff System.Console doesn't cover well: ANSI/VT styling + markup, unified async input events (keys/resize/mouse/paste), restore-on-dispose scopes (raw/cbreak, alternate screen, hide cursor…), clipboard, a rich ReadLine editor, & testable backends, built on top of XenoAtom.Ansi ✨
고등학생 때부터 Vim을 썼으니까, Vim/Neovim을 합치면 거의 15년 가까이 썼던 것 같다. 그러다가 Deno와 TypeScript를 접하면서 Visual Studio Code로 갈아탔는데, 그러고 한 2–3년? Zed가 나와서 Zed를 또 1년 가까이 썼다. (아, VS Code를 쓸 때도 Zed를 쓸 때도 Vim 키 바인딩을 끄지는 못 했다.)
그런데 요즘에는 Claude Code니 OpenCode니 LLM 기반의 코딩 에이전트들을 꽤 열심히 쓰게 되면서 에디터 자체를 잘 안 쓰게 되었다. 심지어 import 한 줄 추가하는 것도 프롬프트로 해결하게 된다. 그래야 LLM한테 맥락이 주어져서 혼선이 없기 때문이다. (내가 말 없이 코드를 고쳐 두면 LLM이 뭔가의 이상 상황으로 받아들이거나, 무심코 원래 코드로 되돌리기도 한다.) 그러다 보니 커밋 직전에 디테일을 손 보거나 코드를 리뷰할 때 빼고는 에디터를 잘 안 켜게 된다. 켜더라도 즉각적으로 열리는 걸 선호하게 되어서, Vim/Neovim이 가장 먼저 손이 가더라.
결국에는 몇 년 동안의 방황을 거쳐 다시 Vim/Neovim으로 돌아오게 되었다는 이야기. 그래서 조만간 먼지가 쌓인 Vim/Neovim 설정도 새해 맞이를 겸해서 한 번 청소를 해야겠다 싶다.
NATが諸悪の根源（過激）
IPv6가 30주년을 맞았지만 여전히 세계를 장악하지 못한 이유
------------------------------
- 1995년 등장한 IPv6 는 32비트에서 128비트로 확장된 주소 체계를 통해 *인터넷 주소 고갈 문제* 를 해결하려 했음
- 그러나 *IPv4와의 비호환성* , *기능적 차별성 부족* , *NAT의 확산* 등으로 인해 전환이 지연됨
- 전문가들은 *배포 비용과 복잡성* , *ROI 부족* , *성능 불일치* 등이 여전히 주요 …
------------------------------
https://news.hada.io/topic?id=25533&utm_source=googlechat&utm_medium=bot&utm_campaign=1834
프로그래밍 언어 문법을 만들때, 비교 연산자에 <, <=, >, >= 등이 있는데, 어차피 좌우 순서만 바꾸면 되니까, >, >= 같은걸 그냥 압수하고 <, <=만 쓰게 한다음에 >, >= 요건 다른 용도로 쓰면 어떨까하는 생각이 듬.
@hongminhee洪 民憙 (Hong Minhee) 해커즈 퍼브에서 "그냥" 댓글을 막을 수 있게 해 주셨으면 합니다.
- 어떤 글에 대해서 댓글을 안 받고 싶다면, 안 받을 권리는 글쓴이에게 있어야 한다고 생각합니다.
- 댓글은 '내' 글을 남에게 보여줄 때 반드시 함께 노출되어 버리는데, '내'가 전혀 통제할 수 없습니다.
- 댓글 그 자체가 사실 별로 책임 있는 소통에 적합한 수단이 아니라고 감히 주장하겠습니다. 한국어 언어 생활만 봐도, '악플'은 있어도 '악글'이나 '악영상' 등은 없습니다. 유독 댓글에 대해서만 따로 '악플'이라는 조어가 등장할 만큼, 댓글 쪽이 가장 더럽다는 것을 언중도 인식하고 있는 것입니다. 이것은 댓글에 대해서만 '남의 집'이라는 인식이 적용되는 인간 심리 때문입니다. 실제로 네이버 뉴스의 헤비 악플러들을 보면, 자기 블로그를 만들어서 그 온갖 입에 담지 못할 모욕적인 말을 늘어놓는 사람은 사실상 없다시피 하고, 꼭 댓글에만 그 짓을 하고 다니죠. 자기 집 안방, 자기 집 대문, 자기 간판, 자기 얼굴에다 똥을 싸기는 싫은 거죠. 즉 이것은 댓글 그 자체의 매체적 특성에서 온다는 것입니다.
- 물론 모든 분들이 "댓글 그 자체가 나쁜 문명" 이라는 제 의견에 동의하실 필요는 없습니다만, 적어도 댓글 거부권은 개별적으로 존중되는 것이 맞다고 생각합니다. 그리고 많은 플랫폼이 이미 이것을 지원하고 있습니다(트위터, 유튜브, 네이버 블로그 등).
현재 액티비티퍼브 프로토콜에서 '댓글 안 받기' 관련 지원이 아직 부족한 것으로 보이기는 합니다. 하지만, 이 문제는 어차피 프로토콜에서 완벽한 해법을 도출할 수 없습니다. 예를 들어 악의적인 인스턴스가 내 글을 가져가서 악플을 주렁주렁 달며 조리돌림을 하려 한다 해도, 기술적으로 그걸 사전에 원천 차단할 방법은 없겠죠. 내가 '댓글 안 받기' 설정을 하든 말든, 저쪽 인스턴스에서 무시할 수 있습니다.
더 나아가 생각해 보면, 내 글을 연합우주도 아닌 그냥 다른 '사이트'에서 링크 가져간 뒤에, 자기들끼리 조롱하고 능욕하는 일도 얼마든지 있을 수 있는데, 그것도 글을 '공개'하는 이상 원천적으로 막는 것은 불가능할 것입니다.
다만 댓글이 '내' 글의 하단에 직접 박히는 것은 '내'가 거부할 수 있어야 한다고 생각합니다. 따라서 완벽한 해법을 기다릴 것이 아니라(어차피 불가능하므로), 그냥 지금 당장 '내' 글의 하단에 댓글이 달리는 것을 막는 간단한 구현부터 적용하는 것이, 맞는 접근이라고 생각합니다. 해커즈 퍼브에 이것을 구현해 주셨으면 합니다.
다만 현실적인 상황을 말씀드리자면, Hackers' Pub은 제가 전업으로 개발하는 프로젝트가 아니다 보니, 지금 당장 이 기능을 최우선으로 구현하기가 어렵습니다. (실은 이 기능만 그런 게 아니라 Hackers' Pub 개발 전반에 제가 참여를 거의 못하고 있습니다—오히려 다른 분들께서 기여를 해주고 계세요.) 이 기능을 안 하겠다는 게 아니라, 바로 지금은 어렵다는 점 양해 부탁드립니다. GitHub 이슈로 남겨주시면 로드맵에 참고하겠습니다.
한편 Hackers' Pub은 오픈 소스 프로젝트이기도 해서, 혹시 직접 구현에 관심이 있으시다면 해당 PR은 최우선으로 리뷰하겠습니다. 코드베이스가 익숙하지 않으시더라도 어디서부터 손대면 좋을지, 어떤 식으로 구현하면 될지 등 제가 적극적으로 도와드릴 수 있으니 편하게 말씀해 주세요.
Using Nano Banana Pro, I composited an image to make it look like the cute dinosaur from the Fedify logo was standing in front of the ULB (Université libre de Bruxelles) building in Brussels, where FOSDEM is held.
This time, I tried writing a prompt to draw an illustration of the mascots from the Mastodon, Lemmy, Fedify, Misskey, and Akkoma projects all getting along together.
Using Nano Banana Pro, I composited an image to make it look like the cute dinosaur from the Fedify logo was standing in front of the ULB (Université libre de Bruxelles) building in Brussels, where FOSDEM is held.
미지의 영역을 프로토타이핑할때는 Sonnet으로 충분한듯... Opus 깊생하게 해봤자 토큰만 더먹는다
클로드 맥스 5x 월 16만원... 10만원만 됐어도 눈감고 지르는건데
洪 民憙 (Hong Minhee) shared the below article:
도커로 구축한 랩에서 혼자 실습하며 배우는 네트워크 프로토콜 입문 #5-3 DHCP
자손킴 @jasonkim@hackers.pub
DHCP(Dynamic Host Configuration Protocol)는 IP 주소와 서브넷 마스크 등 네트워크 접속에 필수적인 설정을 자동으로 배포하여 관리 효율성을 극대화하는 핵심 프로토콜입니다. 이 글은 수동으로 관리하는 정적 할당과 자동화된 동적 할당의 차이점을 비교하며, UDP 기반의 메시지 구조와 Discover부터 ACK로 이어지는 네 단계의 처리 과정을 상세히 다룹니다. 특히 할당받은 주소를 유지하기 위한 임대 시간(Lease Time) 관리와 갱신 메커니즘을 통해 네트워크 안정성이 어떻게 유지되는지 설명합니다. 또한 단순한 주소 할당을 넘어 옵션 필드를 활용한 네트워크 부팅(PXE) 기술을 소개하며, DHCP가 현대 인프라 자동화의 강력한 기반이 되는 과정을 보여줍니다. 이 포스팅은 네트워크의 기본 동작 원리부터 실무적인 확장성까지 폭넓은 인사이트를 제공하여 기술적 이해도를 한 단계 높여줄 것입니다.
Read more →洪 民憙 (Hong Minhee) shared the below article:
도커로 구축한 랩에서 혼자 실습하며 배우는 네트워크 프로토콜 입문 #5-4 SSL 오프로드
자손킴 @jasonkim@hackers.pub
TLS(SSL) 오프로드는 웹서버의 CPU 자원을 소모하는 암복호화 작업을 로드밸런서(Load Balancer)와 같은 전용 장비에 위임하여 애플리케이션의 처리 효율을 극대화하는 기술입니다. 중앙집중식 인증서 관리를 통해 운영 부담을 줄이는 장점이 있지만, 로드밸런서 통과 후 내부망에서 데이터가 평문으로 전달되는 보안 취약점이 발생할 수 있습니다. 특히 내부망이 항상 안전하다는 고정관념을 깨고 '결코 신뢰하지 말고 항상 검증하라'는 제로 트러스트(Zero Trust) 원칙에 따라, 상호 TLS(mTLS)를 활용한 마이크로 세그멘테이션의 중요성이 대두되고 있습니다. 하지만 L7 로드밸런서나 웹 애플리케이션 방화벽(WAF)이 HTTP 헤더와 경로를 분석하여 정교한 라우팅과 공격 탐지를 수행하려면 패킷의 내용을 확인할 수 있는 TLS 종료 과정이 여전히 필수적입니다. 이 포스팅은 성능을 위한 오프로드와 보안을 위한 재암호화 사이의 기술적 접점을 설명하며, 가시성과 안전성을 동시에 확보해야 하는 현대적인 네트워크 인프라 설계의 핵심적인 인사이트를 제공합니다.
Read more →@hongminhee洪 民憙 (Hong Minhee) I certainly like the focus on growth not punishment. It really aligns with the brief discussion in the " Alternative models of content moderation" sectino of Sarah Gilbert's Towards Intersectional Moderation: An Alternative Model of Moderation Built on Care and Power of justice-based models of moderation that "foster education, rehabilitation, and forgiveness" (as opposed to the more punitive and carceral models of moderation that are the norm in commercial social networks).
My impression is that most fedi moderation teams don't actually notify the reporters about what actions are or aren't taken. Some of that is due to software limitations -- if the report is forwarded from another instance, I'm pretty sure you don't even know who the reporter is (and the Mastodon moderator UX doesn't as far as I know directly support two-way communications, instead you. have to DM the user from the moderator account; and) . Just as importantly, though, reporters sometimes get upset and escalate if action isn't taken. If the original report is malicious, as part of a harassment campaign against the target, this sometimes leads to the moderators getting harassed as well.
Of course it's very frustrating to report something and never hear back so I can certainly see the arguments in favor of doing this as well! But with malicious reporting, or if a team of attackers are reporting different posts to try to understand just what borderline content get through the moderators, there are arguments against it as well. One possibility is to treat reports from people who are part of the HackersPub community (differently on this front than reports from other instances.
While I like the idea of not requiring the reporter to cite the specific clause(s) of the guidelines that are violated, I'm personally skeptical about using LLMs to address the problem. Even assuming the datasets used to train the LLMs were gathered with consent (which isn't typically the case) they're likely to have racial, gender, and cultural biases. Don't get me wrong, the idea of using a tool to help the moderators and report recipient understand just what's been violated is a good one, I'm just not sure this is the right technology. Timnit Gebru and others at DAIR have been thinkiing about approaches to content moderations, so might have some ideas here.
In terms of cross-instance reports, it's really important to leave it up to the reporter whether or not to forward to another instance -- sometimes the admins of the other instance are hostile! And like the discussion of malicious reporting above, this highlights the importance of threat modeling.
Anyhow those are my quick initial thoughts. Looking forward to seeing how the functionality evolves! As you're moving forward with this, it might be interesting to talk to some of the academic researchers who have looked at moderation on the Fediverse -- Sohyeon Hwang, Owen Xingjian Zhang, Tolulope Oshinowo and others at Princeton have done some excellent work and talked to a lot of people here in the process. If it's useful, I can see if they're interested in connecting with you.
@jdp23Jon Thank you so much for this thoughtful feedback and for the paper reference! I'll definitely read Sarah Gilbert's work.
You raise excellent points I hadn't fully considered:
-
On notifying reporters: The malicious reporting scenario is a real concern. I like your suggestion of treating reports from within the community differently from forwarded reports. We should think more carefully about what information to share and with whom.
-
On LLM usage: That's a fair criticism. The bias issue is something we need to take seriously. Perhaps the LLM should only assist moderators as a reference tool, not be exposed to reporters or reported users directly. I'll look into DAIR's work on this.
-
On cross-instance forwarding: Absolutely agreed; this should be opt-in by the reporter, not automatic. I'll update the spec to make that explicit.
I'd love to connect with the Princeton researchers if they're open to it. And thank you for taking the time to share your experience: this is exactly the kind of input we were hoping for.
Hi #fediverse! I'm working on Hackers' Pub, a small #ActivityPub-powered social platform for developers and tech folks.
We're currently drafting a content #moderation (#flag/#report) system and would really appreciate any feedback from those who have experience with federated moderation—we're still learning.
Some ideas we're exploring:
- Protecting reporter anonymity while giving reported users enough context to understand and improve
- Graduated responses (warning → content removal → suspension) rather than jumping to bans
- Using LLM to help match reports to code of conduct provisions
- Supporting ActivityPub
Flagactivity for cross-instance reports
Our guiding principle is that moderation should be about growth, not punishment. Expulsion is the last resort.
Here's the full draft if you're curious: https://github.com/hackers-pub/hackerspub/issues/192.
If you've dealt with moderation in federated contexts, what challenges did you run into? What worked well? We'd love to hear your thoughts.
洪 民憙 (Hong Minhee) shared the below article:
Hackers' Pub 신고(flag) 기능 기획서
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Hackers' Pub 커뮤니티의 신고 시스템은 단순한 제재를 넘어 구성원의 성찰과 성장을 돕는 분산형 네트워크 환경을 지향합니다. ActivityPub 프로토콜을 기반으로 설계된 이 시스템은 Mastodon 등 외부 플랫폼과의 연합(federation) 환경에서도 유연하게 작동하며, 신고자의 익명성 보호와 피신고자의 알 권리 사이의 균형을 유지합니다. 기술적으로는 거대언어모델(LLM)을 활용하여 자유 형식의 신고 사유를 실시간 행동 강령(code of conduct) 조항과 동적으로 매칭하고, 신고 시점의 콘텐츠 스냅샷과 행동 강령 버전을 기록하여 검토의 객관성을 확보합니다. 관리자는 경고, 콘텐츠 검열, 일시 및 영구 정지로 이어지는 단계적 제재 체계를 통해 투명하게 사건을 처리하며, 피신고자는 이의 제기(appeal) 프로세스를 통해 공정한 재심 기회를 보장받습니다. 이러한 체계적인 설계는 자율적인 커뮤니티 관리의 복잡성을 해결하고, 건강하고 지속 가능한 연합우주(fediverse) 생태계를 구축하는 데 필요한 실무적인 통찰을 제공합니다.
Read more →GLM-4.7의 성능이 그렇게나 좋다고 들어서 요금제를 보니 상당히 파격적인 가격이라 조금 시도해 봤다. 우선 LogTape에 있던 이슈 하나를 수행하게 했고, 혹시 몰라서 Claude Code에서 Claude 4.5 Opus로 PLAN.md 계획 파일을 꽤 꼼꼼하게 만들게 한 뒤, 그걸 참고하게 했다. 그럼에도 불구하고:
- 모든
export되는 API에 대해서는 JSDoc 주석을 써야 한다는 당연한 절차를 수행하지 않음 (코드베이스의 다른 코드는 다 그렇게 되어 있는데도 눈치가 없음) - JSDoc 주석을 쓰랬더니 Python docstring 스타일로 정의부 “안쪽”에 주석을 씀…
Deno.env같은 특정 런타임에 의존적인 API를 씀 (코드베이스의 다른 코드는 그런 API 안 쓰고 있음)- 아주 기본적인 JavaScript 구문 오류를 냄 (예를 들면 세미콜론 빼먹는 식의) → 이것 때문에 상당히 토큰 소모를 많이 함
- 한국어가 살짝 귀여움 (“나옵니다”가 아니라 “나옴니다”라고 쓰는 식)
- 결국에는 JavaScript 구문 오류를 못 고쳐서 테스트 스위트도 아예 못 돌리는데 전체 작업이 완료되었다고 스스로 결론 내림
소문난 잔치에 먹을 게 없다더니, 역시나 벤치마크만 보고 모델을 골라서는 안 되겠다는 교훈만 재확인 한 것 같다.
오늘은 OpenCode에서 공짜로 제공하길래 MiniMax M2.1로 코딩을 좀 해봤다. 몇 시간 정도 해본 느낌으로는 GLM-4.7보다는 훨씬 나았고, 체감상으로는 대충 Claude Sonnet 4와 비슷한 정도로 말귀를 잘 알아듣는 느낌이었다. 컨텍스트 윈도가 긴 것도 장점이었다. 다만, 컨텍스트가 좀 길어지니까 끝도 없이 삽질을 반복하게 되어서, 그 쯤에서 모델을 GPT-5.1 Codex Max로 바꿔서 진행했다. GPT-5.1 Codex Max로 삽질 구간 벗어난 뒤에 금방 다시 MiniMax M2.1로 돌아와서 계속 코딩을 했고, 전반적으로 싼 값을 감안하면 굉장히 좋다고 느꼈다.
요즘에는 평소에 Claude Opus 4.5를 주력으로 사용하니까, 아무래도 비교가 될 수밖에 없었는데:
- 역시나 눈치라고 해야 하나, 센스는 떨어진다. Claude Sonnet 4.5보다도 떨어지는 듯. 이를테면 Markdown 문서를 수정하도록 지시하면 기존의 일관성 있게 잘 짜여 있던 문서 서식이 금방 무너지는 게 느껴진다.
- AGENTS.md의 세세한 지시를 좀 뭉개는 느낌이 있다. 예를 들면 TypeScript 코딩할 때
any타입을 쓰지 말라고 했음에도 무시하고 사용한다든가. Claude 계열 모델들에서는 이런 건 잘 못 겪는다. - 작업의 맥락보다 이미 학습되어 있는 자신의 지식을 더 따르는 느낌이 있다. 이를테면 일부러 여러 JavaScript 런타임에서 두루 돌아가게 하려고 Deno API를 안 쓰고 Node.js API를 써서 짜 둔 코드베이스에서 갑자기 Deno API를 꺼내서 쓰기 시작하는 식이다. 이것도 눈치 문제로 볼 수도 있을 듯.
- 그렇게 중요하진 않지만 자연어 응답에 언어가 조금 섞인다. 특히 국한문혼용체가 종종 나온다. 나로서는 오히려 좋다(?). 그런데 자세히 보면 대륙에서 쓰는 간화자가 아니라서, 중국어가 섞이는 건 아닌 것 같다. 아마도 일본어 아니면 대만/홍콩의 중국어가 섞이는 것 같다. 아니면 정말로 국한문혼용체일지도? 그리고 아랍어도 한 번 섞이는 걸 봤다.
- 속도는 그냥저냥 쓸만하지만 딱히 빠른 것도 아닌데, 이건 OpenCode에서 공짜로 제공하는 걸 써서 그럴 수도 있다. Claude Opus 4.5보다는 약간 느리다고 느꼈지만, 이것도 그냥 체감이라 정확하진 않다. 삽질하는 걸 더 많이 봐서 느리다고 착각한 걸 수도 있고.
일단은 OpenCode에서 공짜로 제공하는 동안은 좀 더 써 볼 생각이다. 돈 내고 쓸 생각이 있냐 하면, 그건 좀 고민이 된다. 코딩 요금제를 보면 5시간에 300 프롬프트짜리가 월 20불 정도 된다. 지금은 Claude Max 요금제를 쓰고 있는데, 아무래도 부담이 좀 되긴 해서, Claude Pro로 내리고 MiniMax를 섞어서 쓰면 어떨까 생각만 해보고 있다.
洪 民憙 (Hong Minhee) shared the below article:
도커로 구축한 랩에서 혼자 실습하며 배우는 네트워크 프로토콜 입문 #5-2 DNS
자손킴 @jasonkim@hackers.pub
도메인 이름 시스템(DNS)은 숫자로 이루어진 IP 주소를 사람이 기억하기 쉬운 문자로 변환해주는 인터넷의 핵심 인프라입니다. 초기 아파넷(ARPANET)의 중앙 집중식 관리 방식에서 벗어나 계층적 트리 구조의 분산 데이터베이스로 발전한 DNS는 전 세계 네임서버들의 유기적인 협력을 통해 동작합니다. 사용자의 요청을 처리하는 스터브 리졸버(Stub Resolver)부터 최종 답변을 가진 권한 있는 네임서버까지, 재귀 쿼리와 반복 쿼리를 교차 활용하여 효율적인 이름 풀이를 수행합니다. 특히 도메인을 IP에 직접 매핑하는 A 레코드와 별칭을 부여하는 CNAME 레코드의 차이를 이해하면 유연한 네트워크 인프라 운영이 가능해집니다. 최근에는 평문 통신의 보안 취약점을 해결하기 위해 DNS over TLS(DoT)와 DNS over HTTPS(DoH) 같은 암호화 기술이 도입되었으며, 접속 대상의 노출을 막는 ECH 기술까지 등장하며 사용자 프라이버시 보호가 한층 강화되었습니다. 이 글은 복잡한 DNS의 내부 동작 원리와 최신 보안 프로토콜의 진화 과정을 상세히 다루며 현대 네트워크 시스템의 근간을 파악하는 데 필수적인 통찰을 제공합니다.
Read more →@hongminhee洪 民憙 (Hong Minhee) 是的，Ruby 是我最熟悉的编程语言，自制编程语言过程充满挑战和乐趣。多年以前，我还是编程新手时，也尝试了解 Lisphp 的实现方式，但由于能力所限，未能做到；有一段时间使用过 CoffeeScript，得知作者起初也是以 Ruby 作为实现语言，我想对于现在的我，Ruby 是最适合的选择。感谢您为编程爱好者提供这样的交流平台，祝新的一年万事如意！
@hongminhee洪 民憙 (Hong Minhee) 是的，Ruby 是我最熟悉的编程语言，自制编程语言过程充满挑战和乐趣。多年以前，我还是编程新手时，也尝试了解 Lisphp 的实现方式，但由于能力所限，未能做到；有一段时间使用过 CoffeeScript，得知作者起初也是以 Ruby 作为实现语言，我想对于现在的我，Ruby 是最适合的选择。感谢您为编程爱好者提供这样的交流平台，祝新的一年万事如意！
인터페이스가 구린 라이브러리를 쓸때는 반!드!시! 심호흡을 하고 멀쩡한 인터페이스의 wrapper를 만든후에! 기능 개발을 합시다. 절대 대충 꾸역꾸역 만들어보자고 덤비면 안됩니다. 결국 후회합니다.
- V모사의 AI 라이브러리를 쓰다가
Designing type-safe sync/async mode support in TypeScript https://lobste.rs/s/844jrt #api #javascript #plt
https://hackers.pub/@hongminhee/2026/typescript-sync-async-type-safety
바이브코딩이 취미가 되어가는 것일까요? 그새 또 뭔가 하나를 뚝딱여왔습니다... be-music-script라는 동인 리듬게임 에뮬레이터 비슷한 친구의 플레이 로그를 정리해주는 서비스를 만들어봤어요. 많은 리듬게임 유저들은 자기가 얼마나 잘했는지 자랑하고 싶어하는데, db 파일을 읽은 뒤 당일의 멋진 성과들을 정리해주는 서비스입니다. 제가 쓰려고 만든건데 이것도 결국 엔지니어링? 결과물인걸까? 싶어 올려봅니다.
요즘 AI의 도움 덕분에 아이디어를 구현하는게 두렵지 않아졌다는 기분이 드네요. https://sonohoshi.github.io/gosubms/
Claude Code의 인기와 함께 터미널에서 한글을 쓰는 모습을 자주 볼 수 있습니다. 하지만 터미널에서 쓰이는 한글은 글자간의 간격이 넓어 보기 좋지 않은 경우가 많습니다. 왜 이런 걸까요?
흔하게 쓰는 코드용 글꼴은 로마자, 숫자, 특수기호만을 다룰 뿐 한글은 다루지 않습니다. 그래서 터미널은 한글 표시를 하기 위해 대체 글꼴을 사용합니다. 대체 글꼴은 보통 OS의 기본 글꼴일 것입니다. 가변폭 글꼴이겠죠. 터미널은 이를 일부러 고정폭으로 만들기 위해 한글 한 자에 로마자 2자 폭을 할당하는데 이 과정에서 여백이 추가되면서 자간이 넓은 어색한 한글을 보게 되는 것입니다.
해결책은 한글 고정폭 글꼴을 사용하는 것입니다. 한글 고정폭 글꼴은 한글 1자를 로마자 2자 폭에 맞춰 만들었으므로 터미널이 더 이상 여백을 만들지 않습니다. 이러한 한글 고정폭 글꼴이 많진 않습니다. 10종이 안 되는 것 같네요. 저는 그중 Monoplex를 사용하고 있습니다. @hongminhee洪 民憙 (Hong Minhee) 님은 Sarasa Gothic을 사용하신다고 하네요. 적은 수의 글꼴이지만 맘에 드시는 걸 찾으셔서 예쁜 한글 출력을 보시면 좋겠습니다.
처음에는 Optique에 비동기 모드 추가하는 것에 거부감이 있었는데, 막상 구현하고 보니까 이런 저런 아이디어들이 떠오르는 듯? 그래서 이런 이슈도 하나 만들었다.
갠적으로 커밋 메시지나 PR 제목 앞에, feat:, fix:, chore: 붙이는 컨벤션은 뭘붙일지 애매한 경우가 너무 많아서 별로라고 본다.
@bglbgl gwyng Conventional Commits라고 부르더라고요. 저도 개인적으로 가뜩이나 50자 제한이 빠듯한데 접두사까지 붙이면 더 좁은 느낌이라 안 쓰고 있습니다. 일부 LLM들이 자꾸 Conventional Commits 쓰려고 굴어서 아예 AGENTS.md에서도 막아놨어요. ㅋㅋㅋㅋ
갠적으로 커밋 메시지나 PR 제목 앞에, feat:, fix:, chore: 붙이는 컨벤션은 뭘붙일지 애매한 경우가 너무 많아서 별로라고 본다.
Designing type-safe sync/async mode support in TypeScript
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Optique, a type-safe CLI parser for TypeScript inspired by functional programming principles, recently introduced support for both synchronous and asynchronous execution modes to handle complex requirements like dynamic shell completions. Implementing this feature required sophisticated type-level logic to ensure that combining an asynchronous parser with synchronous ones correctly results in an asynchronous aggregate. After evaluating several design patterns, the developer settled on an explicit mode parameter with a default value to maintain backward compatibility while allowing for runtime inspection. This approach leverages conditional types and advanced inference to compute combined modes automatically, even though it necessitated significantly increasing internal implementation complexity to support dual execution paths. The updated API now includes specialized runners that provide compile-time enforcement of the expected execution mode, preventing common pitfalls associated with asynchronous code. By prioritizing a clean user-facing interface, the library successfully integrates asynchronous capabilities without compromising its original simplicity or type safety. This architectural evolution demonstrates how TypeScript’s powerful type system can manage complex state propagation while keeping the development experience intuitive and robust.
Read more →Optique 0.9.0 pre-release is ready for testing!
The big new feature: sync/async mode support. You can now build CLI parsers with async value parsing and suggestions—perfect for shell completions that need to run commands (like listing Git branches/tags).
The API automatically propagates async mode through combinators, so you only decide sync vs async at the leaf level.
Try it:
npm add @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212
deno add --jsr @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212I'd love feedback before merging! Especially interested in:
- API ergonomics
- Edge cases I might have missed
- TypeScript inference issues
Docs:
Optique 0.9.0 pre-release is ready for testing!
The big new feature: sync/async mode support. You can now build CLI parsers with async value parsing and suggestions—perfect for shell completions that need to run commands (like listing Git branches/tags).
The API automatically propagates async mode through combinators, so you only decide sync vs async at the leaf level.
Try it:
npm add @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212
deno add --jsr @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212I'd love feedback before merging! Especially interested in:
- API ergonomics
- Edge cases I might have missed
- TypeScript inference issues
Docs:
Optique 0.9.0 프리릴리스 테스트 중입니다!
이번 주요 기능은 동기/비동기 모드 지원입니다. 이제 비동기 값 파싱과 자동완성을 지원하는 CLI 파서를 만들 수 있습니다. Git 브랜치/태그 목록처럼 셸 명령 실행이 필요한 자동완성에 딱이에요.
컴비네이터를 통해 async 모드가 자동으로 전파되기 때문에, 개발자는 말단 파서에서만 동기/비동기를 결정하면 됩니다.
설치:
npm add @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212
deno add --jsr @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212머지 전에 피드백 주시면 정말 감사하겠습니다! 특히 이런 부분이 궁금해요:
- API 사용성
- 에지 케이스
- TypeScript 타입 추론 문제
문서:
TCP/IP is a social construct
Modern optimizing compilers are truly amazing. Rust / LLVM just broke my brain by turning what I was SURE would be poorly optimized code due to indirection into a tight result with zero perceptible overhead.
Modern CPUs also probably help.
WinGet도 요즈음은 Microsoft Store와 비슷한 정책을 적용하기 시작해서, 자동화된 검사 과정에서 식탁보 새 버전 매니페스트 등록이 막혔었는데, Moderator께서 정확한 판단을 내려주신 덕분에 무사히 새 버전이 게시되었습니다.
안타깝게도 Microsoft Store에는 식탁보를 등록하는 것이 계속 어려울 것으로 보입니다만, 대신 WinGet에 등록이 가능할테니 UniGetUI 등의 수단을 이용해서 커맨드라인 없이 식탁보를 쉽게 설치할 수 있는 방법을 조만간 공식 가이드로 내도록 하겠습니다.
Apple will allow alternative browser engines for iPhone and iPad users (iOS/iPadOS) in Japan.
https://developer.apple.com/support/alternative-browser-engines-jp/
Apple should allow alt engine for the rest of the world too. No point holding it back.