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.

GLM-4.7의 성능이 그렇게나 좋다고 들어서 요금제를 보니 상당히 파격적인 가격이라 조금 시도해 봤다. 우선 LogTape에 있던 이슈 하나를 수행하게 했고, 혹시 몰라서 Claude Code에서 Claude 4.5 Opus로 PLAN.md 계획 파일을 꽤 꼼꼼하게 만들게 한 뒤, 그걸 참고하게 했다. 그럼에도 불구하고:

• 모든 export되는 API에 대해서는 JSDoc 주석을 써야 한다는 당연한 절차를 수행하지 않음 (코드베이스의 다른 코드는 다 그렇게 되어 있는데도 눈치가 없음)
• JSDoc 주석을 쓰랬더니 Python docstring 스타일로 정의부 “안쪽”에 주석을 씀…
• Deno.env 같은 특정 런타임에 의존적인 API를 씀 (코드베이스의 다른 코드는 그런 API 안 쓰고 있음)
• 아주 기본적인 JavaScript 구문 오류를 냄 (예를 들면 세미콜론 빼먹는 식의) → 이것 때문에 상당히 토큰 소모를 많이 함
• 한국어가 살짝 귀여움 (“나옵니다”가 아니라 “나옴니다”라고 쓰는 식)
• 결국에는 JavaScript 구문 오류를 못 고쳐서 테스트 스위트도 아예 못 돌리는데 전체 작업이 완료되었다고 스스로 결론 내림

소문난 잔치에 먹을 게 없다더니, 역시나 벤치마크만 보고 모델을 골라서는 안 되겠다는 교훈만 재확인 한 것 같다.

@markeb54맹꽁이 사실 기본적으로는 웹의 역사를 무시하는 반동적인 프로젝트가 아닌가 하는 회의감이 있습니다.

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

웹의 좀 더 단순한 대안으로 만들어진 제미니 프로토콜에 한 때 관심이 조금 있었는데, 얼마 지나지 않아 금방 흥미가 식었더랬다. 다른 것보다 텍스트를 중요시 한다는 철학에 비해 텍스트가 무엇인지에 대한 관점이 너무 나이브하다고 느꼈다. 제미니는 아랍어나 히브리어 같은 RTL 언어들의 텍스트를 담아낼 수 있는가? 몽골어나 한문 같은 세로쓰기 언어의 텍스트는? 난독 한자에 후리가나나 한글을 달 수 있는가? 이런 질문들에 대답을 해주지 못한다고 느꼈다.

세상의 발전이란건 참 빠르구나... 라는 생각이 새삼 들었어요 한 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을 매우 만족스럽게 사용하고 있습니다.

FEPs 문서들은 Codeberg에 있는 fediverse/fep 저장소에 들어 있는데요. 문제는 AI 도구들이 Codeberg에 모종의 이유로 접근이 안 된다는 겁니다. (아마도 Codeberg의 의도적인 정책에 따라.) 아무튼, 그래서 LLM으로 FEP 문서를 번역해서 읽는다든가 하기가 까다로운데요. 이를 해결하기 위해 FEP MCP를 만들어 보았습니다. 사용하려면 시스템에 Deno가 설치되어 있어야 합니다. 이런 느낌으로 사용할 수 있습니다. 필요한 분들이 얼마나 되실지 모르겠지만, 한 번 공개해 봅니다.

클로드 코드 쓰면서 처리가 가장 오래걸리는 프롬프트: /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도 하면 더 좋고..

좀 웃긴 생각이 났는데, '해결해주면 나랑 친해질수 잇는 문제들'이란 목록을 만들어서 공유하고 싶다. 네임드가 되면 실제로 잘 동작하려나.

오늘은 @xo 님이랑 화상으로 커피챗을 했다. 같은 오픈 소스 프로젝트 메인테이너로서 고충을 공유했다… 😂

Now trying to implement a JMAP transport for Upyo…

https://news.hada.io/topic?id=25285

추상화가 강력한 더 좋은 언어를 쓰는 것 이상의 확실한 방법이 없고, 그 외에는 그냥 임시방편이라고 생각함.

내 트리를 꾸며줘!

helix/kakoune는 selection 기능 정리에 힘을 줬는데, 나는 emacs의 mark식 selection이 가장 편하다. h/k는 형식을 지키기 위해서 복잡해진 감이 있음. 통일성 없는 vi보다는 낫긴 한데.

Meta, Valve의 Steam Deck용으로 설계된 Linux 스케줄러를 대규모 서버에 사용
------------------------------
- Valve의 Steam Deck를 위해 설계된 *SCX-LAVD 리눅스 스케줄러* 가 Meta의 대규모 서버 환경에서도 효과적으로 작동한다는게 공개됨
- 이 스케줄러는 *게임 콘솔 수준의 효율적 자원 관리* 를 목표로 설계된 것인데, Meta는 이를 통해 *서버 워크로드의 성능 향상* 과 *지연 시간 최소화* 를 추구
- 휴대용 게…
------------------------------
https://news.hada.io/topic?id=25293&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

iOS에서 내가 쓸 단모음 키보드 앱을 만들고 있다.

기존에 쓰던 앱들이 있긴 했는데, 하나는 어느샌가 키보드 자판 위에 툴바를 붙이더니 월 구독 결제를 안하면 숨길 수 없게 해놨고 다른 하나는 최근 iOS 업데이트 이후로 텍스트를 지울때 단어가 망가지는 문제가 생겨서 대체제를 찾다가 마음에 드는게 없어서 결국 직접 만들기로 결정함..

직접 만들어서 테스트하다보니 유저 입장에서 어떤 부분이 불편한지 - 해소해야할지 보인다. 재미는 있는데 생각보다 신경써야 할 게 많다.

(1.x, 3.x)는 모든 조건을 만족하기 때문에 변환기를 거쳐 마이그레이션할 수 있다. (1.x, 3.x-beta)도 모든 조건을 만족한다. 반면 (3.x-beta, 1.x)는 (1), (3)을 위반하기 때문에 변환기를 사용할 수 없다. (2.x-alpha.1, 3.x-alpha.0)는 (1), (2)를 위반한다. 이렇게 출발 버전부터 시작해 a ≺ b 관계를 만족하고, b가 목적 버전이 아닌 경우 안정 버전이어야 한다는 조건을 적용해 나가면 도착 버전까지의 경로도 얻을 수 있다.

그런데 실제로 이를 조건 분기로 구현해보면 상당히 복잡해진다. 더 일반화된 방법이 필요하다. 버전 관계를 다시 정의해보자. 변환기를 기준으로 생각해보면 모든 버전 사이에 순서가 있다고 할 수는 없다. 버전을 poset으로 모델링해보면 어떨까? a ≺ b 관계가 성립하는 경우에는 b의 변환기를 이용해 a를 마이그레이션할 수 있다. 이 관계가 성립하려면 (1) a가 안정 버전이고, (2) b가 알파 버전이 아니고, (3) major(a) < major(b)이어야 한다.

오랜만에 복잡한 문제를 단순한 형태로 모델링해서 해결했다. 문제 상황은 대략 라이브러리의 메이저 버전을 위해 자동 마이그레이션을 지원하는 것이다. 각 메이저 버전에는 이전 버전의 코드를 자동으로 변환해주는 변환기가 함께 배포된다. 만약 1.x에서 3.x로 업데이트할 때는 2.x 변환기, 3.x 변환기를 순차적으로 실행해야 한다. 즉, 하위 버전에서 출발해 상위 버전에 도착하는 경로를 구해야 한다.

그런데 베타 버전(x.y-beta)과 알파 버전(x.y-alpha.z)을 고려해야 한다. 베타 버전에는 직전 버전에 대한 변환기가 있고, 알파 버전에는 변환기가 없다. 나이브하게 생각해보면 출발 버전 유형과 도착 버전 유형의 조합에 대해 모든 경우를 분기해서 경로를 구할 수 있을 것처럼 보인다.

On a related note, if you learn better by building things, @fedifyFedify: ActivityPub server framework has a step-by-step tutorial where you create a federated microblog from scratch—implementing actors, inbox/outbox, following, and posts along the way:

https://fedify.dev/tutorial/microblog

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

GUI앱을 못보니까 콘솔로 출력해서 본다는 점이 정말... 나보다 낫군

According to @tchambersTim Chambers's My 2026 Open Social Web Predictions:

Fedify will power the federation layer for at least one mid-sized social platform (500K+ users) that adds ActivityPub support in 2026. The “build vs. buy” calculation for federation shifts decisively toward “just use Fedify.”

We're honored by this recognition and will keep working hard to make #ActivityPub adoption easier for everyone. Thank you, Tim!

#Fedify #fediverse #fedidev

Here's a #TypeScript API design challenge I'm working on: adding async support to #Optique (CLI argument parser) without breaking the existing sync API.

The tricky part is combinators—when you compose parsers with object() or or(), the combined parser should automatically become async if any child parser is async, but stay sync if all children are sync. This “mode propagation” needs to work at both type level and runtime.

I've prototyped two approaches and documented findings. If you've tackled similar dual-mode API designs, I'd love to hear how you approached it.

https://github.com/dahlia/optique/issues/52

목공용 절단도면 만들어주는 프로그램 뇌 비우고 Claude Code한테 시켰더니 때깔이 좋네