Profile img

Lee Dogeon

@moreal@hackers.pub · 102 following · 86 followers

어느 한 개발자입니다.

GitHub
@moreal

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 Eugen Rochko's post misses, despite its good intentions.

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

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

4
9
0

제가 일하는 팀에서 채용중입니다. https://careers.linecorp.com/ko/jobs/2964/

회사 이름이 LINE 으로 시작하지만 메신저는 안만듭니다. 국내외 선물 시장에서 거래하는 자동매매 전략과 그 전략을 서빙하는 플랫폼을 만듭니다. Rust, FPGA, AI 같은 키워드를 나열할 수 있긴 한데, 그냥 코딩 잘하시는분이면 좋겠습니다. 시장은 몰라도 됩니다. 근데 혼자 코딩 잘하는거 말고 AI랑 같이도 잘 코딩해야 합니다.

저는 이런 사람입니다 https://github.com/youknowone/

같이 일할 @perlmint 님은 https://github.com/perlmint/

함께 일하고 싶으신 분을 찾습니다.

7
0
0

Lee Dogeon shared the below article:

성공적인 AI 에이전트 시스템을 만들려면

Seo Sanghyeon @sanxiyn@hackers.pub

AI 에이전트 시스템을 구축하며 얻은 실전 경험을 바탕으로 효율적인 설계와 운영 전략을 심도 있게 다룹니다. 성공적인 에이전트를 위해 목표는 측정 가능하고 유용하며 달성 가능한 범위로 좁혀야 하며, 로그 인프라 구축과 정교한 평가 설계(evaluation design)를 통해 지속적인 개선의 토대를 마련하는 것이 필수적입니다. 특히 도메인 특화 지식을 스킬(skill) 형태로 패키징하여 모델의 추론 능력을 극대화하고, 프롬프트 캐싱과 적절한 모델 선택으로 비용 효율성을 확보하는 방법론을 제시합니다. 구체적인 구현 단계에서는 컨텍스트 윈도(context window) 관리를 위한 멀티 에이전트 구조와 서브 에이전트의 실행 제어 기법을 살펴봅니다. 또한 복잡한 도구 호출 대신 모델이 직접 코드를 생성하고 실행하게 함으로써 토큰 사용량을 혁신적으로 줄이는 코드 생성(code generation) 패턴의 효용성을 강조합니다. 이와 더불어 신뢰할 수 있는 파일 편집 방식과 샌드박스 기반의 강력한 인가 제어(authorization) 시스템 구축은 안전한 자율 시스템을 위한 핵심 요소로 작용합니다. 이 글은 빠르게 진화하는 AI 에이전트 분야에서 기술적 정확성과 실용성을 겸비한 아키텍처를 설계하려는 개발자들에게 구체적이고 실질적인 인사이트를 제공합니다.

Read more →
12
0
0
3

Lee Dogeon shared the below article:

Nix Store에서 언어의 특권적 지위 제거: Sandbox 기반 아키텍처 제안

bgl gwyng @bgl@hackers.pub

Nix 아키텍처에서 Nix 언어가 스토어(store)에 대해 가지는 특권적 지위와 그로 인한 생태계 종속성 문제를 짚어보고, 이를 해결하기 위한 샌드박스(sandbox) 기반의 구조적 개선안을 제안합니다. 핵심은 언어의 순수성에 의존하던 기존의 신뢰 모델을 OS 레벨의 격리와 데몬(daemon) 프로토콜로 전환하는 것입니다. 이러한 변화를 통해 Nix 언어뿐만 아니라 파이썬(Python)이나 러스트(Rust) 등 다양한 언어가 동등한 지위에서 스토어와 상호작용할 수 있게 되며, 빌드와 평가의 경계를 허물어 더욱 유연하고 견고한 시스템을 구축할 수 있는 통찰을 제공합니다.

Read more →
3
5

그 뭐시냐.... 제가 모임 개최 플랫폼 (대충 event-us.kr 혹은 connpass.com 같은거) + 지역 기반 리뷰 서비스 (대충 포스퀘어 같은거) 를 만들었는데요.

**당연히, 연합우주 거주민 대상으로 만들어진 서비스이고, 연합우주에 계정이 있다면 누구나 OTP 로그인으로 인증이 가능합니다**

어떻게 만들어나갈지 나름 고민은 많이 해봤고, 내가 생각하는 고민이랑 다른 사람들이 생각하는 수요가 일치하는지 확인도 하고 싶어서 이렇게 공개적인 글을 올립니다.

moim.live

많은 관심과 사랑 부탁드리고, 문의사항이나 피드백 있으면 GitHub Issue로 부탁드리겠습니다. GitHub 링크 : github.com/moim-social/moim

물론, 다른 창구도 열어둘 여지는 있습니다. 디스코드 채널은.. 당장은 fedidev.kr 채널을 이용하지 않을까 싶구요.

4
2
1

오랜만입니다. 근황 겸...

2월 말 퇴사했습니다. 역시 Web3는 제가 "잘" 하는거지 "좋아" 하진 않는 것 같습니다. 평가도 좋고 계속 할 수도 있었지만 뭔가 이젠 시들해지기도 했고, 원래부터 Web3로 커리어를 잡으려고 했던 것도 아니라서 다음 직장을 알아봤습니다.

그래서 4월 1일부터 크레페(쿠키플레이스)로 옮깁니다. 김민상(bis_cir_kit) 님 추천으로 지원하게 되었는데, 타입으로 그래프 나타내는 건 원래 좋아하던 일이라서 스택도 잘 맞고, 회사 감성도 완전 찰떡이라 일주일 만에 합류 결정이 되었습니다.

그 사이엔 결혼 일정때문에 바빴습니다. 3월 7일에 대구에서 결혼합니다. 너무 멀어서 미안한 나머지 청첩장은 많이 못 돌렸지만 이렇게나마 소식은 전합니다.

wedding.suho.io 에서 저희 사진과 정보를 더 확인하실 수 있습니다.

또한 2월 중순쯤 퇴사가 확정되고 나서 만들고 있는 프로젝트가 있습니다. whaleback.suho.io 입니다. 한국 주식을 각 종목별로 퀀트 분석해 주고, AI 리포트로 일간 트렌드를 알려주는 등, 각종 정보를 보기 편하게 정리했습니다.

사용해 보시고 궁금한 점 있거나, 아니면 저 개인이 궁금하시더라도 연락주세요. 감사합니다.

9

I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:

@COSCUP 2026 (Taipei, Aug 8–9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track there—something in the spirit of the Social Web devroom at FOSDEM.

Nothing is decided yet, but if you're working on , the , or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.

https://floss.social/@COSCUP/116152356550445285

()아시아에도 FediCon 같은 行事(행사)가 있으면 좋겠다는 말을 여러 () 해왔는데요. 獨立的(독립적)인 컨퍼런스는 아직 어렵더라도, 작은 첫걸음으로 생각해보고 있는 게 있습니다.

@COSCUP 2026(臺北(타이베이), 8() 8()–9())이 커뮤니티 트랙 提案(제안)을 받고 있어요. FOSDEM의 Social Web devroom 같은 느낌으로, 거기서 Social Web 트랙을 열 수 있지 않을까 하고 構想(구상) 중입니다.

아직 確定(확정)된 건 아무것도 없지만, , , ()은 소셜 웹 全般(전반)을 다루고 있고 發表(발표)共同(공동) 오거나이징에 關心(관심)이 있으신 분이 있다면 이야기 걸어주세요.

https://floss.social/@COSCUP/116152356550445285

1
0
0

오늘 하루 Hackers Pub iOS 앱에 작업한 것들

  1. 긴 글을 잘라서 보여줄 때 HTML truncate할 때 HTML 태그 구조에 이상이 없게끔 안전하게 처리
  2. 글 리스트 보여줄 때 렌더링 최적화
  3. 글 리스트 / 상세 페이지에서 인용된 글도 제대로 보이도록 수정하고 인용 기능 추가
  4. 글에 반응하기 기능 추가
  5. 누가 글을 공유하거나 인용했는지 화면 추가

조금만 더 하면... 앱스토어 올려도 되겠다...

3월 1일 하루에 hackers-pub/ios에 16개 커밋을 올렸다.
5
0
3
0
2

Claude Code를 사용하다가 마크다운에서 [Link Name](link) 같이 표기하면 Link Name 으로 렌더링 되는 것처럼 클릭 가능한 링크를 보여줘서 이게 뭐지해서 찾아보니 OSC 8[1] 이라는 것이 있다고 한다. 지원하나 해서 찾아보니 Optique의 url()[2] 도 이를 지원한다고 한다.


  1. https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda ↩︎

  2. https://optique.dev/concepts/messages#urls ↩︎

1

앗! 나도 해커스펍 기여자? Hackers Pub 기여자 모임 스프린트

Hackers' Pub 리뉴얼, 손꼽아 기다리고 계시지 않으신가요? Hackers' Pub, 한 번쯤 직접 기여해 보고 싶다는 생각, 해보신 적 없으신가요? Hackers' Pub, 이용하면서 어딘가 아쉽다 느꼈던 부분, 혹시 있지 않으셨나요? 이번 스프린트 모임은 리뉴얼 진도도 팍팍 빼면서, 기여자들끼리 서로 얼굴도 익히고 친분도 쌓는 자리입니다. 부담 없이 참여해 주세요. 모임은 서울특별시 성동구 상원길 26, 뚝섬역 5번 출구 근처 어딘가에 있는 튜링의 사과에서 진행합니다. 일정은 3월 1일 ~ 3월 2일. 모여서 각자 편하게 해커스펍 기여하다가 가시면 됩니다. 몸만 오시면 됩니다. 비용은 튜링의 사과 이용료만 챙겨 주시면 돼요. 감사합니다. 이 글은 연합우주를 위한 모임 개최 서비스 moim.live의 첫 게시글로 영광스럽게 공유합니다

📅 2026-03-01T02:00:00.000Z — 2026-03-02T10:00:00.000Z

Organized by: @hongminhee@hollo.social

View event details

1
0
1
3

오래 기다리셨습니다!!!

BlueBase: Python으로 밑바닥부터 직접 만들어보는 DBMS

https://theeluwin.github.io/BlueBase/

결국 완성은 못했지만, 일단 공개할 수 있는 부분이라도 공개합니다.

RedBase DBMS을 구성하는 PF, RM, IX, SM, QL 중 PF와 RM을 여러분들이 직접 구현 할 수 있게, 과제의 형태로 제공합니다.

PF는 paged file의 약자로, file을 page 단위로 관리하는 컴포넌트입니다. 대충 4096 바이트 단위로 관리하는데요, file에 바로바로 read하거나 write하지 않고, 자주 사용되는 page는 가능한 memory에 있도록 중간에 buffer manager를 둡니다. 그렇다면 buffer에 공간이 모자라면? buffer에 있는 page 중 누군가를 evict 할 수밖에 없습니다. 그럼 뭘 기준으로 하면 좋을까요? 이 부분을 잘 생각해서 구현해보고, 성능을 비교해보기 바랍니다. 제가 cache hit/miss 시뮬레이션 구현해둔게 있으니, 제 custom 보다 높은 성능을 달성해주세요!

이후 RM은 record management의 약자인데, PF를 사용해서 record들을 가져오거나, 새로 넣거나 등을 하게 해줍니다. 그렇다면 전체 record를 순회하는 scan 연산이 중요하겠죠. 이 부분을 구현하는 것이 핵심입니다. record는 page 앞 부분에 bitmap을 둬서 slot이 비어있는지 아닌지를 확인하는데, 만약 record 삭제 명령이 마지막 slot을 비우게 된다면 해당 page는 더이상 필요 없겠죠. 그렇지만 이를 바로 free로 만드는건 조금 비싼 연산이 필요합니다. free page list를 다시 계산해야하거든요. 그래서 보통 DBMS에서는 이러한 작업들을 vacuum 연산으로 해결합니다. 추가로, 지금은 고정 길이 record만 다룰 수 있습니다만, 가변 길이를 허용하려면 어떻게 해야할까요? 이 부분들은 자유롭게 구현해보시면 좋겠습니다.

문서와 테스트는 모두 공개되어있습니다. 기여해주시면 감사하겠습니다! 다만, 정답 코드와 핵심 로직은 마지막까지 저 혼자 해보고 싶습니다 (도전).

https://github.com/theeluwin/BlueBase

밑바닥부터 직접 만들어보는 DBMS에서 page cache policy에 따른 성능 비교.
5
1
1

We're gradually moving our community from Discord to Matrix. The maintainers and contributors are already there, so you'll get faster responses on Matrix going forward. Discord will stay up for a while, but Matrix is now our primary home.

For the full details and the list of Matrix rooms, see: https://github.com/fedify-dev/fedify/discussions/573.

저희 커뮤니티를 Discord에서 Matrix로 조금씩 이전하고 있습니다. 메인테이너와 기여자들은 이미 Matrix로 옮긴 상태라, 앞으로는 Matrix 쪽이 응답이 더 빠를 거예요. Discord는 당분간 유지되지만, Matrix가 이제 메인 거점입니다.

자세한 내용과 Matrix 룸 목록은 여기서 확인하세요: https://github.com/fedify-dev/fedify/discussions/573.

0

아직 배포는 못 했는데 개밥먹기 싸이클(?) 한 번 돌아본 것 같다. Slidev 버그(?) 디버깅 하는데 시간을 좀 썼고.. 나중에 진짜 발표할 일 생기면 쓰면서 개밥먹기 더 해봐야지.

2

🕐 2026-02-15 12:02 UTC

📰 技術発信を後回しにした私が、転職で詰んだ話。 (👍 223)

🇬🇧 How neglecting tech blogging destroyed job prospects. Skills without documentation = skills without proof. Share imperfect work early and often.
🇰🇷 기술 블로깅을 미루다 이직에 실패한 이야기. 증명되지 않은 실력은 없는 것과 같다. 불완전해도 일찍 자주 공유하라.

🔗 zenn.dev/igz0/articles/skill-w

0

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

0

지금 해보고 있는 작업 과정에서 optique, optparse-applicative 같은 류의 커맨드라인 파서의 (개인적으로) 신기한 점을 알게 되었다. --server 가 있을 때 --server-port 도 함께 require할 수 있게 의존 관계를 표현할 수 있다, 같은 느낌에서 "와" 였었는데 오늘 알게 된 것은 같은 옵션을 상황에 따라 다르게 쓸 수 있다는 점이었다.

예를 들자면 --server가 있을 때 -P의 의미가 --port의 short option이라고 할 때 --server가 없을 때 -P의 의미가 --program[1]의 short option이 될 수도 있다. 이렇게 -P가 여러 의미를 가지게 되는 것이 좋은가 같은 이야기와 별개로 신기했다.


  1. p로 시작하는 더 좋은 옵션이 당장 생각 안 나서 --program이라 하였다 ↩︎

3

Dear FOSS maintainers,

here’s a list of funding programs currently accepting proposals for maintenance work:

Codeberg: codeberg.org/mechko/awesome-ma

GitHub: github.com/mechko/awesome-main

Thanks to everyone who helped crowdsource it! I’ll keep it updated, issues and PRs are very welcome :)

0
0
1

AI FOMO에 휩쓸려 뭐라도 해야겠다는 생각이 드는 입문자(?)라면, 대뜸 강의든 장비든 뭐든 비싼 무엇을 사지 말고 다음 두 가지를 하시길 권해봅니다.

  1. 가장 비싼 Plan으로 마음껏 써보기 클로드 코드, 코덱스 등 AI 에이전트 서비스의 가장 비싼 Plan을 한 달 정도는 경험해보세요. 사용량 제한받거나 성능이 떨어지는 AI 모델을 쓰면, AI에 대한 관점도 그 정도에 갇힐 가능성이 커요.

프론티어급 모델을 토큰 화끈하게 사용했을 때 AI 서비스가 제공하는 가치는 꼭 경험해봐야 합니다.

AI 모델 이용료는 더 줄어들 수 있지만, AI 모델을 더 내 손 위에 쥐어주는 AI 에이전트 서비스는 부가가치를 높이는 방향으로 이용료가 낮아지진 않을 겁니다. 게다가 현재는 경쟁하느라 적자 감수하며 퍼주는 것에 가까워서 고객에게 잔치 시기가 끝나면 이용료가 오르거나 제약이 커질 것 같습니다.

제 직업 환경의 상황으로 예로 들지요. 새로운 소프트웨어 개발 도구를 도입할 때, 잘못 도입하면 발생하는 비용이 크기 때문에 많은 시간 분석하고 검증하고, 학습하였습니다. 가치있는 일이지만 시간 비용이 너무 큽니다. 그러나 최근에 AI 코딩 에이전트를 이용해 후보 도구를 동시에 적용해봅니다. 예전엔 여러 사람이 동원되거나 긴 시간을 들여야 했지만, 이제는 혼자서 짧게는 몇 시간, 길어도 며칠 안에 실 경험에 기반한 판단 자료를 도출합니다.

리서칭하는 도구에 대해 직접 조사하거나 AI가 조사한 걸 리뷰하고 재검증하기도 했습니다. 하지만 사용량이 넉넉한 Plan을 사용한 이후로는 사용할 도구가 오픈소스인 경우, 코드 전체를 AI 에게 분석시키곤 합니다. 토큰 사용량으로 보면 1시간도 안 되어 몇 만원을 쓰는 셈인데, 제가 알고싶은 정보를 자세히 학습하기에도 좋고, AI 환각을 줄여주는 데에도 도움이 됩니다.

사용량 제한이 큰 Plan을 사용할 땐 마치 토큰을 아껴쓰느라 예전처럼, 즉 현재처럼 AI를 활용할 엄두를 못냈습니다.

  1. 가능성과 한계 인식하기 1번의 연장인데, 화끈하게 AI 에이전트를 여러 방향으로 사용하다보면 자연스레 생각이 복잡해질텐데, 특히 다음 두 가지를 고민해보세요.
  • 내가 하는 일, 내 환경에 대해 재정의하기
  • 재정의한 내 상황에 비추어 가능성(미래)과 한계(현재)를 정의하기

그동안 많은 일하는 방식, 학습하는 방식, 협업하는 방식은 “사람”을 대상으로, 기준으로 하여 오랜 세월 고도화되어 잡힌 체계입니다. AI는 사람과 다릅니다.

소프트웨어를 만드는 환경을 예로 들겠습니다. 조직의 협업 체계에서 대개는 개발팀, 즉 소프트웨어 개발이 병목 자원입니다. 그래서 병목 자원 관리에 초점을 많추는 소프트웨어 개발 방법이나 협업 체계가 대부분입니다. 과감히 납작하게 본다면, 기획을 조직에 전파하는 용도로 발표 장표를 만드는 이유는, 그 작업 비용이 더 싸기 때문입니다. 전달력이 떨어지지만 전체적으로 봤을 때 저렴한 경우가 많습니다. 만약 발표 장표 만드는 목적이 비용이라면, AI 코딩 에이전트를 사용하여 데모 버전을 만드는 게 더 저렴합니다. 이용료, 시간은 물론이고, 실제 돌아가는 데모 버전의 전달력도 정적인 글, 그림보다 낫습니다.

AI 에이전트를 펑펑 사용하면서 자신이 일하는 체계, 방식에서 사람 간 협업을 기준으로 하는 부분이 무엇인지 고민해보세요.

대체하거나 효율을 높일 부분 뿐만 아니라 한계도 고민하세요. 그 한계가 AI 모델이나 에이전트에서 기인하는 걸 수도 있고, 사람(자기 자신)에게서 기인하는 걸 수도 있습니다.


2번 단계에 오면 다음에 뭘 해야할지 방향이 잡힙니다. 하다못해 강의나 강좌, 책도 무엇을 봐야할지 관점이 생깁니다. 어떤 사람과 어떻게 협업할지, 어떤 도구에 돈을 더 들일지, 내가 몸으로 떼우는 게 나을지. 그 단계에 돈을 쓰세요.

이 과정을 경험하고, 내 관점을 갖는 데 1~2달이면 충분합니다. 요즘처럼 AI 발전이 빠른 시기에 너무 느린 것 아니냐고요. 불과 1년 전만 해도 AI 코딩 에이전트의 수준은 현재와 비교불가 수준이었다는 걸 보면 그런 마음이 들 수 있습니다. 근데, AI가 도구라는 점은 전혀 달라지지 않았습니다. 문제를 정의하고, 실제 문제를 해결하는(execution) 결정과 방식은 사람이 합니다. 끊임없이 새로운 도구는 나왔고 발전해왔지만, hello world에 머무르는 사람은 그때나 지금이나 hello world에 머무르고, 변화를 일으키거나 변화하는 사람도 그때나 지금이나 있어왔습니다.


보안 위협 등 조심해야 할 건 많은데, 이또한 앞서 거론한 “한계”로 파악하는 게 우선입니다. 문제를 알고, 정의할 수 있으면 해결 방법도 찾을 가능성이 큽니다. 더군다나 AI가 끝내주는 점 중 하나는 자연어로 소프트웨어 “엔지니어링”을 실행하는 겁니다. 그리고 “소프트웨어”여서 실행 비용이 상대적으로 저렴하고요.

고환율 시기라 100 USD, 200 USD가 부담스럽지만, 고성능 AI 도구를 다양한 방법으로 써보며 내 생각과 관점을 넓히는 비용으로는 저렴합니다.

7

I have deeply mixed feelings about 's adoption of JSON-LD, as someone who's spent way too long dealing with it while building .

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.

2
28
1
1

@mariusormarius Hello, thank you for trying this out 🙏. When I created this program, what I defined as a "Thread" was a long post continued by replying to one's own post.

For example, you write post A, hit the character limit, continue in reply B, hit the character limit again, and continue in reply C to B, and so on.

Looking at the link you provided https://brutalinks.tech/~marius/2e6cf5a8-ffa8-4fca-b4cd-8e0c9a584a75, it doesn't appear that there are any replies chained to that Note object.

Therefore, since it doesn't fall under the above definition of a "Thread," this is not a bug. However, if needed, it may be worth reconsidering how we define a "Thread."

@hongminhee洪 民憙 (Hong Minhee) :nonbinary:

1

Recently, @morealLee Dogeon 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.

0
1
0
0
0

Spring 2026 @CMUDBCMU Database Group Seminar Series: PostgreSQL vs. The World → db.cs.cmu.edu/seminars/spring2

Starting Mon Feb 2nd @ 4:30pm EST over Zoom. We will alternate between a speaker from either a Postgres DBMS or a non-Postgres DBMS. Open to the public. Videos available on YouTube afterwards.

SCHEDULE
‣ Feb 2: Redpanda Oxla
‣ Feb 9: Amazon Aurora DSQL
‣ Feb 16: TopK
‣ Feb 23: Microsoft Azure HorizonDB
‣ Mar 9: turbopuffer
‣ Mar 16: YugabyteDB
‣ Mar 23: TonicDB
‣ Mar 30: PixelTable
‣ Apr 6: SpacetimeDB
‣ Apr 13: Supabase Multigres
‣ Apr 20: VillageSQL

PostgreSQL vs. The World Seminar Series — Spring 2026
https://db.cs.cmu.edu/seminars/spring2026/PostgreSQL vs. The World Seminar Series Schedule
https://db.cs.cmu.edu/seminars/spring2026/
0

음 조금 보니까 나머지는 다 dl.deno.land (Google IP, 아마 GCP?) 에서 가져오는데 버전 목록만 deno.com (Deno Deploy)에서 가져와서 Deno Deploy에 문제가 생기면 setup-deno 가 모두 실패한다. 이거 deno.com/versions.jsondl.deno.land/versions.json 로 옮기면 안 되려나... 는 다음에 또 장애 생기면 이슈 만들어야겠다

1

Secretive(혹은 1Password)로 SSH 키를 관리하는데 Touch ID로 인증을 해야하다 보니 노트북 저 멀리에 두고 모니터와 별도 키보드를 쓰는 상황에서 팔을 쭉 뻗어 Touch ID에 손가락을 올리는 것이 여간 불편한 것이 아니었다. 예전에 Apple Watch로 인증이 되고 그랬다고 했던 기억이 나서 오늘에서야 써보는 데 팔을 뻗지 않아도 되서 매우 편하다 :D

1
3