AOC2025 DAY 5 무식하게 하려다가 맥북 뻗어서 머리 써서 풀었다... 진작 머리 쓸걸..

Karpathy의 프로그래밍 관련 발언: "이렇게까지 뒤처진 느낌은 처음이다"
------------------------------
- Andrej Karpathy가 현재의 프로그래밍 환경에서 *자신이 크게 뒤처지고 있다고* 강하게 느낀다고 밝힘
- 프로그래머가 직접 작성하는 코드 비중은 줄어들고, 이미 존재하는 도구와 시스템을 *어떻게 연결하고 조합하느냐* 가 핵심 역량으로 이동 중
- 지난 1년간 등장한 도구들을 제대로 엮기만 해도 *생산성이…
------------------------------
https://news.hada.io/topic?id=25434&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

Unity의 Mono 문제: 왜 당신의 C# 코드는 기대보다 느리게 실행되는가
------------------------------
- Unity가 사용하는 *Mono 런타임* 은 최신 .NET 대비 현저히 느린 실행 속도를 보이며, 동일한 C# 코드가 *최대 15배까지* 차이 나는 사례가 있음
- 실제 게임 코드에서 *Mono 기반 Unity 실행은 100초* , 동일 코드의 .NET 실행은 *38초* 로 측정되어, 디버깅과 테스트 효율에도 큰 영향을 줌
- *Release 모드…
------------------------------
https://news.hada.io/topic?id=25421&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

BGE-M3, MarkItDown, 그리고 마크다운 구조 파서를 이용해 시맨틱 청킹을 수행하고, 그 결과를 Parquet 파일에 저장하는 aipack 프레임워크의 첫 버전을 릴리스합니다. 모델과 데이터베이스에 종속되지 않는 중립적 상태를 유지하여 언제든 재사용할 수 있는 파일 포맷을 기반으로 RAG를 구현하고, MCP 서버까지 구동할 수 있도록 설계했습니다.

aipack의 지향점은 NPU나 GPU에 의존하지 않는 RAG를 구현함과 동시에, 향후 다양한 RAG 구조로 확장하기 용이한 환경을 만드는 데 방점이 찍혀 있습니다. "고품질의 Parquet 파일을 만들어낼 수 있다면 무엇이든 할 수 있다"는 전제 아래, 업계에서 흔히 쓰이는 RAG 파이프라인을 디커플링(Decoupling)해본 실험적 프로젝트입니다.

프로젝트에 대한 피드백과 후기, 평가를 공유해 주시면 감사하겠습니다. 또한, 지속 가능한 오픈소스 활동을 위해 후원을 더해 주신다면 큰 힘이 됩니다.

GitHub: https://github.com/rkttu/aipack

#aipack #RAG #시맨틱청킹 #AI #MCP #BGE #로컬RAG

Fedify에 기여하다보면 진짜 민희님이 괜히 STF 받으신게 아니구나... 싶어지는 코드들이 종종 있음
걍 눈 앞이 캄캄해지고 아찔해져서 눈 질끈 감게 됨

#코스모슬라이드 업로드 기능을 뜯어고치고 있다. 일단 GPT한테 바이브 시켰더니 적당히 잘 작동...하네. 겉모습은.

@aburkaaburka 🫣 You're judging before you've tried, and that's the disservice. You're assuming your skills will dull if you use an agent, and you're treating that assumption as a conclusion. That's the mistake. Try it first. See what actually happens. Then adjust your thinking based on experience, not fear.

I'm using them for months now, and in no way is it dulling my skills. I haven't learned as much as a programmer in years personally.

And I'm saying this also because I saw multiple people now who I knew learned throughout the year what AI agents are and it didn't click, until they took the time over Christmas to really dive in.

If you are a programmer and an AI hold-out, and you have some time off during Christmas: gift yourself a 100 USD subscription to Claude Code and … try it. But really try it. Take a week if you can afford it and dive in. It will change your opinion on these tools.

식탁보 1.15.0 버전을 출시했습니다. 1년여만의 대규모 업데이트로, .NET 10 적용과 함께 커뮤니티에서 불편 사항으로 여겨졌던 Windows Sandbox의 vGPU 기본 사용 문제, 언어 표시 문제, 그리고 인스톨러 간소화 등 성능과 기능 간소화는 물론, 코드의 분량을 대폭 간소화했습니다.

추후 TableCloth3 프로젝트에서 개발 중인 Avalonia 기반 프론트엔드로 쉽게 전환할 수 있도록 땅 다지기 작업도 같이 진행해두었고 계속 업데이트해나갈 예정입니다. 그리고 이번 업데이트부터 ARM64 빌드도 정식으로 제공됩니다.

꾸준한 관심과 성원에 늘 감사드립니다.

#식탁보 #오픈소스 #인터넷뱅킹 #전자정부 #공동인증서 #NPKI

https://forum.dotnetdev.kr/t/1-15-0/14191

I finally managed to complete a working RFC9421 implementation... I didn't realize that Fedify's RFC9421 public key retrieval didn't include assertionMethod...

오 witr #macOS 지원

❯ witr ghostty
Target      : ghostty

Process     : ghostty (pid 36529)
User        : mck
Service     : launch job demand
Command     : /Applications/Ghostty.app/Contents/MacOS/ghostty
Started     : just now (Mon 2025-12-29 10:08:55 +00:00)

Why It Exists :
  launchd (pid 1) → ghostty (pid 36529)

Source      : application.com.mitchellh.ghostty.34914134.34914139 (launchd)
              Type : Launch Agent

Working Dir : /
Open Files  : 100 of 256 (39%)
Locks       : /Users/mck/Library/Caches/com.mitchellh.ghostty/sentry/8c48f586-5c27-49c8-71a1-7727494394fc.run.lock

Warnings    :
  • Process is running from a suspicious working directory: /
  • Service name and process name do not match

최근 보안의 화두는 제로트러스트지만, 정작 가장 민감한 공동인증서 파일은 여전히 NPKI라는 고전적인 디렉터리 구조 속에 노출되어 있습니다.

OS 수준의 암호화 기술인 BitLocker나 VBS의 이점을 전혀 활용하지 못하는 현 상황을 개선해보고자, Windows 인증서 저장소를 백엔드로 활용하는 방식을 고민 중입니다. macOS의 Keychain 시스템처럼 인증서를 시스템 보안 영역 내부로 끌어들임으로써, 파일 탈취 위험을 획기적으로 낮추는 것이 목표입니다.

인프라 자체를 바꿀 순 없어도, 엔드포인트 단에서 '방어의 밀도'를 높이는 유의미한 시도가 될 것 같습니다. :-D

https://forum.dotnetdev.kr/t/npki/14187

Claude Code Subagent를 가만 살펴봤는데, 내가 일하는 방식 그리고 다른 사람에게 위임할 수 있는 방식을 잘 정의하면 그럭저럭 쓸만한 것 같음. 생각을 글로 잘 정리하는 버릇을 들여야겠다.

(오프라인에서 했던 얘기를 온라인에서도 하기) @hongminhee洪 民憙 (Hong Minhee) 님 블로그는 국한문혼용으로 보면 세로쓰기 가로스크롤로 바뀌는 게 꽤나 운치가 있다고 생각해요..... 한자를 못 읽는 건 아쉽지만

FOSDEM 2026 Social Web Speakers

I have been trying to create a list for #fosdem26 and realized that (ironically) most of the people in the socialweb track ... does not have a fediverse account listed there.

I am also at fault, btw, so shame to me.

If you know someone who is presenting at #fosdem26 please send them my way. I will update this thread with the list of confirmed speakers.

The Fosdem 26 social web track List:

@pfefferleMatthias Pfefferle
@evanEvan Prodromou @evanprodromou
@haubleshannah aubry
@mapacheMaho 🦝🍻
@dariusDarius Kazemi
@bjoernstaBjörn Staschen
@django
@resieguenRebecca Sieber
@openforfutureOpen For Future | Italia
@iusondemandValentino Spataro
@cwebberChristine Lemmer-Webber
@tsyesikaJessica Tallon
@zzepposs
@melaniebartos
@Pepijn
@FloppyJames Smith 💾
@tobias
@mayel
@ivan
@hongminhee@hackers.pub洪 民憙 (Hong Minhee)
@samviesamvie ⁂
@benpateBen Pate 🤘🏻
@neiman
@hongminhee@hollo.social洪 民憙 (Hong Minhee)
@filippodb filippodb ⁂ @magostinelliMichele Agostinelli
@publicspaces
@cubicgardenIan Forrester | @cubicgarden
@samviesamvie ⁂
@bonfire
@FediVariety
@vishnee
@cypherhippiePaul Fuxjaeger
@nextgraph

Non Social Web Track presenters:

@bogoBogomil Shopov - Бого
@localfirstOpen Local First

Social Web Track schedule:

https://fosdem.org/2026/schedule/track/social-web/

Boosts are also appreciated!

P.S. Special thanks to @liaizonwakest ⁂,
@andypiper, @michaelMichael Foster, @toon

#askfedi #activitypub #fosdem

주소 저장 https://arxiv.org/html/2505.22962v1

asdf + direnv 조합을 mise로 바꾸고 나서, 초반에는 환경 변수 제어가 쉽고 다양한 점이 좋았다면 시간이 갈수록 tasks 기능이 기존 프로젝트까지 mise로 전환하게 만든다.

[tasks."dev:db"]
dir = "./data"
run = "./docker-run-postgres.sh --no-tty"

[tasks."dev:cms"]
dir = "./cms"
run = """
until nc -z localhost 5432; do
  echo "Waiting for database to be ready..."
  sleep 1
done
corepack yarn dev || [ $? -eq 129 ] || [ $? -eq 130 ]
"""

[tasks.dev]
depends = ["dev:db", "dev:cms"]

pyodide를 사용해서 python으로 된 앱을 정적 웹사이트로 서빙 https://khris.github.io/woodcut/

I'm working on a new JavaScript/TypeScript library for natural language translation powered by LLMs. I want a name that feels elegant, memorable, and reflects the essence of translation.

I've narrowed it down to four candidates from different linguistic roots. Which one do you think fits bets?

• Xindaya (信達雅): Derived from Yan Fu (嚴復)'s Three Pillars of Translation—faithfulness (信), expressiveness (達), and elegance (雅).

• Vertana (वर्तन): Means transformation, turning, or process. It evokes the fluid and sacred process of transforming meaning from one language to another.

• Glosso (γλῶσσα): The root for tongue or language. It's the origin of terms like glosssary and polyglot.

• Fanyi (飜譯): The direct and minimal term for translation. It's punchy and honors the long-standing tradition of translation in East Asia.

With high-performance #Python type checkers like #Pyright, #Pyrefly, and #ty now available, what's the value proposition of #Mypy? Is it the reference implementation? Or does Mypy still have the most features? I'm not trying to knock Mypy, I'm genuinely asking because I don't know.

@hongminhee洪 民憙 (Hong Minhee) 저도 전에 제미니 프로토콜 관심 있었는데 이런 점은 생각조차 못해봤네요. 심지어 해커뉴스에 가끔 올라오는 제미니 프로토콜 소개 글에 달리는 비판 댓글들조차도 이 문제를 언급한 적이 없었던 것 같아요. 분명 생각해봐야 할 문제인데 말이죠...

세상의 발전이란건 참 빠르구나... 라는 생각이 새삼 들었어요 한 30년쯤 전에는 프로그램이 메모리와 장치에 직접 접근할 수 있었고 협조 안 해주면 혼자서 CPU를 다 먹을 수 있는 시대가 있었다는게 믿기지 않지 않아요??

예전에 LLM이 얼마나 복잡한 코드를 이해할 수 있는지 파악하기 위해 Gemini 2.5 모델들로 내 IOCCC 2012 수상작을 던지고 무슨 일을 하는지 실행 없이 알아 맞춰 보라고 했더니 하나도 제대로 파악하지 못했던 적이 있다. 문득 생각이 나서 Gemini 3 Pro는 개선되었을려나 생각했는데, 힌트 하나만 받고 10분동안 생각하더니 완벽하게 응답에 성공했다! 심지어 설명도 실행 없이 분석했다는 걸 감안할 때 매우 정확했다. IOCCC 수상작을 모두 기억하고 있을 가능성을 감안해 이전에 본 적이 있냐고 물어 보니 환각(...)을 내뱉는 것도 그렇고(그보다 외웠다면 처음에 바로 정답을 얘기했겠지), 실제로 생각 과정을 보면 사람이 할 법한 분석을 전부 하고 있는 걸 보니 진짜로 LLM들의 reasoning 능력이 이 정도 수준에 도달했음을 알 수 있다. 세상 참 많이 발전했네.

I've opened a proposal for #LogTape to support configuration from plain objects, making it possible to load #logging configs from JSON/YAML/TOML files.

The idea is similar to Python's logging.config.dictConfig()—you'd be able to configure sinks, formatters, and loggers declaratively, making it easier to manage different configs for dev/staging/prod without touching code.

Would love to hear your thoughts, especially if you've worked with similar patterns in other ecosystems.

https://github.com/dahlia/logtape/issues/117

LLM(과 그것을 사용한 앱)을 사용한다는 것은 확률을 내가 어느정도는 조작할 수 있는 가챠인것 같다.

오늘도 오라클의 기묘한 버그? 스펙??을 밟아서 기록하려 왔는데요 nginx-ingress-controller를 기본 설정으로 설치하면 Service의 externalTrafficPolicy가 Local이라서 controller pod이 떠 있는 node에서만 접속이 되는데요 이랬더니 왠지 NLB 자체가 연결이 안 되고(포트가 닫힘) externalTrafficPolicy를 Cluster로 바꾸서 모든 node에서 접속할 수 있게 만드니까 NLB가 열리는데 보통 NLB의 백엔드 Healthcheck는 문제있는 백엔드를 제외하기 위해 존재한다고 생각했는데 오라클 NLB는 일부 백엔드에 문제가 생기면 전체가 안되는 기묘한 구조인가봐요??? 대체왜??????

Writing an NES emulator in Haskell via @abnvAbhinav 🌏 https://lobste.rs/s/jkomyi #haskell #retrocomputing
https://arthi-chaud.github.io/posts/funes/

정말 IaC 사용자만 고객인 정도가 아니라 테라폼 사용자만 고객인게 쿠버네티스 클러스터 구축할때 콘솔에서 빠른시작으로 구축해도 안돼고 Pulumi로 구축해도 안됐는데 테라폼 쓰니까 빠르게 성공해서 좀 허무했어요

확실히 오라클에 1%쯤 배신감 든 게 전에 발표에서 오라클은 설정한 유저데이터 스크립트 조회도 못하게 한다라고 욕하고 왔는데 알고보니 API로는 제공하는데 콘솔엔 없었다는게 참 테라폼 사용자들만 고객이구나... 같은 느낌 (물론 저도 이젠 테라폼을 쓰지만요...)

@akastoot악하 (개인적인 억까 평가지만) 오라클은 자기네 모든 고객이 테라폼을 사용한다는 상정이라도 하고 있는 거 같으니 이번 기회에 테라폼을 사용해보시는걸 추천드려요... https://registry.terraform.io/providers/oracle/oci/latest/docs 문서 AI에 던져주면 그래도 그럭저럭 짜더라구요

Lite-XL 일주일 사용기

최근 에디터 시장이 치열합니다. Zed와 Visual Studio Code, Helix와 Neovim, 그리고 Fleet도 있습니다.

이 중 가장 주목받는건 역시 Zed와 Visual Studio Code입니다. Visual Studio Code와 가장 비슷한 UI를 보유하면서도 강력한 확장성과 정통성을 보유한 에디터로써 Zed의 입지는 공고합니다.

특히, Zed는 Rust와 GPU 렌더링을 활용한 빠른 에디터로써 Visual Studio Code의 느린 Electron 기반이라는 점을 정확히 타격하며 높은 인기를 얻고 있습니다.

이런 GPU 가속 에디터가 높은 인기를 얻고 있는 시장에서, 제 눈에 띄인 것은 바로 Lite-XL입니다. Lite-XL은 Lite라는 GPU 가속 에디터의 포크로, 많은 기능을 추가한 Vi와 Vim의 관계와 비슷합니다.

가장 특징을 가지는 부분은 코어는 Rust나 Zig가 아닌 Pure C로만 작성되어 있으며, 런타임은 Lua를 통해 작성되어 있어 모든 부분이 Lua 스크립트로 커스텀이 가능하다는 점입니다. 매우 Emacs스러운 부분이라고 할 수 있습니다.

하지만, 어느정도 Battery Included인 Emacs와는 달리 Lite-XL은 다운로드 시 오직 코드 하이라이팅과 편집 정도만 지원합니다. 모든 기능은 전부 플러그인으로 다운로드 해야 합니다. 내장 터미널조차 없고, LSP조차 없으며, Git 기능조차 없습니다.

이를 해결하기 위하여 lpm이라는 가벼운 패키지 매니저를 지원합니다. lpm은 마치 일반 리눅스의 패키지 매니저와 같아 간단한 입력만으로 플러그인을 설치할수 있습니다.

lpm install lsp_go

이렇게 플러그인을 설치한 후의 Lite-XL은 Visual Studio Code와 비견해 매우 빠르고 강력한 에디터로 발돋움합니다. Lite-XL의 실행파일 크기는 고작 10MB밖에 되지 않으며, 반응 속도 또한 매우 빨라 실행하자마자 바로 창이 렌더링 될 정도로 빠른 점도 Pure C로 매우 가볍고 빠르게 작성된 특징에서 기인합니다.

Vibe Coding을 위한 플러그인은 없지만 Claude CLI, Gemini CLI, OpenAI Codex 등을 터미널에서 실행 가능하기 때문에 로컬 환경 개발에서는 매우 빠른 속도와 바이브 코딩의 편안함도 챙길 수 있습니다.

거의 모든 기능에 단축키를 부여할수 있으며, (저는 Ctrl-S, Ctrl-Shift-O, Ctrl-Shift-P만 사용합니다.) 컬러 스킴도 Visual Studio Code에 비교해 더욱 많은 컬러 스킴을 기본 제공합니다.

다만, 가장 아쉬운 부분으로는 Remote Working이 제대로 되지 않는다는 점에서 있는데, Visual Studio Code가 code-server에 바탕한 Code Tunnel 기능을 지원하지만, Lite-XL은 이를 지원하지 못하고, 오직 네이티브 환경과 로컬 환경에서만 작업이 가능하다는 단점이 존재합니다.

또한, 많은 LSP 서버들이 존재하지 않으며, 플러그인의 자유도와 패키지 매니저는 강력하지만 절대적으로 Zed와 Visual Studio Code와 비교해서 수가 적은 것은 단점으로 꼽을 수 있습니다.

가장 대표적인 예로, 제가 PS를 할 때 애용하는 플러그인인 CPH Problem Solver와 같은 니치한 보조 도구가 부족하며, Visual Studio Code에 내장된 Stack Trace Debugger나 Docker 통합 등 많은 기능이 부재합니다.

그럼에도 가볍게 프로그래밍 한다는 점에선 Notepad++나 Sublime Editor와 비슷한 가벼움을 가지면서도, Zed나 Visual Studio Code에 꿇리지 않는 기능과 플러그인 매니지먼트 시스템을 가진다는 점에서 저는 Lite-XL을 매우 만족스럽게 사용하고 있습니다.

클로드 코드 쓰면서 처리가 가장 오래걸리는 프롬프트: /compact

#오라클클라우드 도전...

데이터베이스 공부 중 하나로 B+트리 C로 구현하고 있는데, 포인터 사용, 정렬, 재귀 호출, DFS, 이진 탐색까지 한 번에 연습하기 좋은, 학습에 아주 훌륭한 자료구조구만.

It's Christmas, but I don't really have anything to do, so I'm just coding. (I'm not Christian.)

Upyo 0.4.0 released. Upyo is an email sending library for Node.js, Deno, Bun, and edge functions. New in this version:

• JMAP transport for modern email servers
• DKIM signing support in SMTP transport
• Message-level idempotency keys for reliable retries

https://github.com/dahlia/upyo/discussions/21

TIL: <form>에 .submit()을 하면 이벤트를 거치지 않고 검증도 안하고 냅다 제출이 된다. 이벤트를 거치게 만들려면 .requestSubmit()을 해야 된다

deno install 명령어를 실행할 때 패치 패키지가 암묵적으로 npm 패키지로 덮어쓰여지는 버그를 수정하였습니다! 😊

https://github.com/denoland/deno/pull/31711

루비, 레일즈에서 페디버스를 구현하려면 https://gitlab.com/experimentslabs/federails 이 프로젝트가 구현 정도가 잘 되어 있으나 2명이서 틈틈히 개발하고 있어서 진행 상황이 느린 상태. 컨트리뷰터가 되어야 하나 포크를 해야 하나...

크리스마스는 새 프로그래밍 언어를 공개하기에 좋은 날이죠. 아직 미완성이지만 요즘 작업하고 있던 프로젝트를 소개합니다. https://github.com/Kroisse/tribute

순수 함수형이고, 모나드는 없고, 소유권도 없고, 타입클래스나 트레잇도 없습니다. 물론 객체 시스템도 없고요. 대신 제네릭과 대수적 효과를 넣을 예정입니다. ad-hoc polymorphism을 배제하고 어디까지 갈 수 있는지 시험해보려는 게 목적 중 하나인데 생각보다 할만할 것 같아요.

그리고 매우 vibe-coded되어 있습니다. Claude Code와 Codex가 없었으면 엄두도 못 냈을 듯.

문법적으로는 Rust와 Gleam에, 의미론적으로는 Gleam과 Unison에 영감을 많이 받았습니다. 사실 Gleam과 Unison 둘 다 네이티브 바이너리로 컴파일을 아직 못 하고 있어서 시작한 프로젝트이기도 합니다. 하지만 정작 Tribute도 첫 타겟은 네이티브가 아니라 WebAssembly 3.0입니다. GC 구현을 만들기 귀찮았거든요.

크리스마스를 맞아 크리스마스 트리... 가 아닌 Hackers' Pub 초대 트리를 꾸몄습니다.

기존 초대 트리는 작은 규모에서는 충분히 제 역할을 했으나 회원이 점차 늘어나면서 구조를 파악하기 어렵고, 페이지가 너무 길어져 변화가 필요하다고 생각했습니다. 다음 개편되는 Hackers' Pub의 초대 트리 페이지에서는 초대 관계를 잘 드러내면서, 많은 회원이 한 눈에 들어올 수 있도록 만들었습니다. Hackers' Pub의 회원은 앞으로도 많이 늘어날 예정이니까요. 그렇겠죠? 내년에도 Hackers' Pub에서 많은 분들을 만날 수 있기를, 더 풍성한 초대 트리를 볼 수 있기를 기대해봅니다.

Complete! It will be included in the next release of Upyo.

https://github.com/dahlia/upyo/pull/20

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

• activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

• MemoryKvStore — filters in-memory keys by prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang크롸상), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang크롸상) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

#fedidev #release

크리스마스에는 모두 #오라클클라우드 에 입문해보아요

(아무도 관심없겠지만) 요거의 예시로는 tree-sitter의 파싱 테이블 + AST node 메타데이터 export가 있다. 지금은 파싱 테이블 대신 parser.c만 뱉고 중요한 메타데이터를 몇개 빼먹는다. 하는 김에 rewrite in haskell도 하면 더 좋고..