XiNiHa

@xiniha@hackers.pub · 87 following · 105 followers

GitHub
@XiNiHa
Bluesky
@xiniha.dev
Twitter
@xiniha_1e88df
5
0
0
9
0
2
8

Fedify에 꽤 예전 버전부터 존재했던 보안 취약점(CVE-2025-54888)이 어제 저녁에 발견되어서 (Ghost 팀에서 보고해 줬다), 오늘 아침에는 각종 관련 소프트웨어에 모두 보안 패치를 적용하느라 푸닥거리를 엄청 했다.

다 하고 나니까 오전이 사라져 있었다.

18

With Linux 6.16 now out in the wild, it’s time for yet another progress report! As we mentioned last time, the Asahi and Honeykrisp Mesa drivers have finally found their way upstream. This has resulted in a flurry of exciting GPU-related work. And now we've got merch!

As always, we want to thank everyone who support us as none of this would be possible without your generous support.

asahilinux.org/2025/08/progres

2

정보 리터러시 관련 의견을 보존하러 왔다. 우리는 흔히 영어 자료가 한국어 자료보다 낫다는 문화사대주의적 의견에 공감하곤 한다. 하지만 여기엔 숨은 의견이 여럿 있다. 하나씩 까보며 음미해보자.

영어 자료는 한국어 자료보다 낫다. => 왜 나을까? 도움이 되기 때문에. 왜 도움이 될까? => (진실에 가깝기 때문에, 다양한 경험이 전시되어 있기 때문에). 왜 진실에 가까울까? => 1차 출처에 가깝기 때문에. 왜 1차 출처에 가까울까? => 사용자가 다수이기 때문에 직접 사용하거나 번역되어 2차 출처로 기능하기 때문에. 왜 다양한 경험이 있을까? => 생산자가 자료 작성 시 영어를 선택할 확률이 한국어보다 높기 때문에.

그렇다면 우리는 영어 자료가 나은 이유를 구체적으로 표현할 수 있다.

  • (일반적으로) 한국어 웹보다 영어 웹이 더 크기 때문에 원하는 자료를 구할 확률이 더 높다.
  • (일반적으로) 한국어 웹보다 영어 웹에서 1차 출처에 가까운 자료를 구할 확률이 더 높다.

탐색 공간을 넓히고, 정보 전파 과정에서의 왜곡을 줄이기 위해서 영어 웹 탐색이 효과적이다. 다만 영어 웹이 "언제나" 좋은 건 아니다. 한컴오피스 자료가 미국에 많겠는가, 아니면 한국에 많겠는가? 1차 출처에 가까운 곳을 향해 왜곡을 줄이고, 그 안에서 탐색 공간을 최대한 효율적으로 넓혀야 한다.

영어 검색이라는 피상적인 행위에서 벗어나 정보 탐색의 본질을 좇는 것이 좋다.

11
0
0
2

오랜만에 프로그래밍 언어 이야기하러 왔다. 오늘 주제는 타입스크립트의 핵심 가치다.

많은 사람들이 정적 타입 언어를 도입하는 이유로 안전성(Soundness)를 이야기한다. 맞는 말이다. 하지만 타입스크립트에서 안전성은 2등 가치다. 그럼 1등 가치는 뭘까?

바로 개발 경험 개선이다. 구체적으로, 오류 나기 쉬운 구문을 적당히 줄이고 자동 완성을 개선하며 큰 규모 리팩토링 시 심리적(그리고 any 같은 기능을 안 썼다는 가정하에 런타임에도 유의미한 수준의) 안정성을 얻겠다는 거다.

타입스크립트 공식 위키 문서에도 안전성은 목표가 아니라고 나와있다 (#). 우리는 때때로 도구의 목적에 들어맞지 않는 불필요한 기대를 하곤 한다. 하지만 도구 개발자와 싸우는 건 사용자로서 좋은 전략이 아니다.

조건부 타입과 재귀 타입, 템플릿 문자열 타입, infer 등을 보라. 정적 분석 난이도가 지수적으로 올라가는 희한한 기능들이 언어에 계속 추가되는 이유가 무엇인가. 추론을 포기하고 any가 나오곤 하는 이유가 무엇인가.

그들이 추구하는 게 안전한 세계가 아닌 실용적인 세계이기 때문이다.

8
0
0

We're thrilled to announce Fedify 1.8.1, a mega release made possible through the incredible efforts of contributors from South Korea's (Open Source Contribution Academy). This release marks a significant milestone in 's development, bringing major architectural changes, new packages, and numerous enhancements across the board.

Note: Version 1.8.0 was skipped due to a versioning error.

🎉 Major Milestone: Monorepo Architecture

Fedify has been restructured as a , consolidating all packages into a single repository with unified versioning. This change streamlines development and ensures all packages are released together with consistent version numbers.

Consolidated Packages

All existing Fedify packages now live under one roof:

  • @fedify/fedify — Main library
  • @fedify/cli — CLI toolchain
  • @fedify/amqp — AMQP/RabbitMQ driver
  • @fedify/express — Express integration
  • @fedify/h3 — h3 framework integration
  • @fedify/postgres — PostgreSQL drivers
  • @fedify/redis — Redis drivers

🆕 New Packages

This release introduces four new packages to the Fedify ecosystem:

  • @fedify/elysiaElysia integration for Bun-powered applications
  • @fedify/nestjsNestJS integration for enterprise Node.js apps
  • @fedify/sqlite — SQLite driver compatible with Bun, Deno, and Node.js
  • @fedify/testing — Testing utilities with mock Federation and Context classes

@fedify/fedify

Custom Collection Dispatchers

A powerful new feature that allows you to create custom collections beyond the standard ActivityPub collections. This enables implementation of domain-specific collections while maintaining federation compatibility.

Contributors: ChanHaeng Lee [#310, #332]

  • Added comprehensive types and interfaces for custom collection handling
  • New methods on Federatable interface: setCollectionDispatcher() and setOrderedCollectionDispatcher()
  • Added getCollectionUri() method to the Context interface
  • Full support for paginated custom collections

Compare-and-Swap (CAS) Support for KV Stores

Key–value stores now optionally support CAS operations for atomic updates, enabling optimistic locking and preventing lost updates in concurrent environments.

  • Added optional KvStore.cas() method
  • Implemented in MemoryKvStore and DenoKvStore
  • Useful for implementing distributed locks and counters

Fediverse Handle Utilities

New utility functions make working with handles more convenient.

Contributors: ChanHaeng Lee [#278]

  • parseFediverseHandle() — Parse handles into components
  • isFediverseHandle() — Validate handle format
  • toAcctUrl() — Convert handles to URLs
  • FediverseHandle interface for type safety

Enhanced HTTP Request APIs

Contributors: Lee ByeongJun [#248, #281], Hyunchae Kim [#51, #315]

  • Added LookupWebFingerOptions.maxRedirection option for controlling redirect behavior
  • APIs now support AbortSignal for request cancellation
  • New DocumentLoaderOptions interface
  • Added signal options to LookupObjectOptions, LookupWebFingerOptions, and DoubleKnockOptions

@fedify/cli

New Commands and Enhancements

The CLI has received significant improvements thanks to our OSSCA contributors:

fedify webfinger Command

Contributors: ChanHaeng Lee [#260, #278], KeunHyeong Park [#311, #328]

Look up WebFinger information for any fediverse resource:

  • Supports handles (@user@server) and URLs
  • --user-agent option for custom User-Agent headers
  • --allow-private-address for local testing
  • --max-redirection to control redirect following

fedify nodeinfo Command

Contributors: Hyeonseo Kim [#267, #331, #168, #282, #304]

Replaces the deprecated fedify node command with improved terminal rendering.

Enhanced fedify lookup Command

Contributors: Jiwon Kwon [#169, #348, #261, #321]

  • Terminal-specific image display for Kitty, WezTerm, Konsole, Warp, Wayst, st, and iTerm
  • -o/--output option to save results to files

Improved fedify inbox Command

Contributors: Hasang Cho [#262, #285], Jang Hanarae [#191, #342]

  • --actor-name and --actor-summary options for customizing temporary actors
  • Now displays object types contained in activities

fedify init --dry-run

Contributors: Lee ByeongJun [#263, #298]

Preview project initialization without creating files.

Better Terminal Support

Contributors: Cho Hasang [#257, #341]

Correctly handles color output based on TTY detection and NO_COLOR environment variable.

@fedify/elysia

Contributors: Hyeonseo Kim [#286, #339]

New Elysia integration brings Fedify to Bun-powered applications with a simple plugin interface:

import { Elysia } from "elysia";
import { fedify } from "@fedify/elysia";

const app = new Elysia()
  .use(fedify(federation, { /* options */ }))
  .listen(3000);

@fedify/nestjs

Contributors: Jaeyeol Lee [#269, #309]

Enterprise-ready NestJS integration with dependency injection support:

import { FedifyModule } from "@fedify/nestjs";

@Module({
  imports: [
    FedifyModule.forRoot({
      kv: new MemoryKvStore(),
      queue: new InProcessMessageQueue(),
      origin: "https://example.com",
    }),
  ],
})
export class AppModule {}

@fedify/sqlite

Contributors: An Subin [#274, #318]

SqliteKvStore implementation compatible across all major JavaScript runtimes:

import { SqliteKvStore } from "@fedify/sqlite";

const kv = new SqliteKvStore("./fedify.db");

@fedify/testing

Contributors: Lee ByeongJun [#197, #283]

Comprehensive testing utilities with mocking support for Fedify applications:

import { MockFederation, MockContext } from "@fedify/testing";

const mockFederation = new MockFederation();
const mockContext = new MockContext();

// Track sent activities with full metadata
// Support custom path registration
// Multiple activity type listeners

🙏 Acknowledgments

This release represents an extraordinary community effort, particularly from the participants of South Korea's OSSCA (Open Source Contribution Academy) (Note: page in Korean). We extend our heartfelt thanks to all contributors:

Core Contributors

Test Infrastructure Contributors

Your contributions have made Fedify stronger and more versatile than ever. The OSSCA program's support has been instrumental in achieving this milestone release.

Migration Guide

Updating from Previous Versions

If you're using separate Fedify packages, update all packages to version 1.8.1:

{
  "dependencies": {
    "@fedify/fedify": "^1.8.1",
    "@fedify/cli": "^1.8.1",
    "@fedify/express": "^1.8.1"
  }
}

All packages now share the same version number, simplifying dependency management.

Breaking Changes

There are no breaking changes in this release. All existing code should continue to work without modifications.

What's Next

With the monorepo structure in place and new integrations available, we're excited to continue improving Fedify's developer experience and expanding its capabilities. Stay tuned for more updates, and thank you for being part of the Fedify community!

For detailed technical information about all changes, please refer to the full changelog.


Fedify is an open-source project that helps developers build federated server applications powered by ActivityPub. Join us on GitHub or Discord to contribute or get help!

7
0
0
10
1
2
2

를 더 명확하게 관리하기 위해서라도 Relay같은 물건이 필수적으로 보이는데, React 바깥에서 제대로 사용하기 좀 어려워서 고민임

5

DBMS 같은 데에서 파일을 관리 할 때엔 항상 4096 바이트 단위의 페이지 형태로 관리합니다. 왜그럴까요? 여러가지 이유가 있는데, 보통은 OS도 4096 바이트 단위로 파일 시스템을 관리하기 때문입니다. 그래서 캐시 같은 OS의 여러 가속 장치들의 도움을 받을 수 있죠.

근데 정말로 그럴까요?

그게 궁금해서 직접 한번 페이지 파일 매니저를 구현해서 실험해봤습니다. 통계적으로 유의하게 빠르네요.

페이지 파일 시스템을 사용 할 때, 페이지 크기가 4096인게 가장 빠르다는 실험 결과에 대한 스크린샷.
9

Fedify를 활용하여 제가 만드는 텍스트 전용 블로깅 플랫폼인 타이포 블루에 연합우주 기능을 구현했습니다. 많은 관심 부탁드립니다!

14
0
0

요즘 gemini-cli를 많이 쓰고 있는데 이게 TUI라서 복붙 같은 것도 미묘하게 잘 안 되고 텍스트도 깨지고 하는 게 짜증난 나머지 내 코딩 에이전트를 만들겠답시고 Angel이라는 걸 만들기 시작했다. https://github.com/lifthrasiir/angel

소프트웨어 스택은 Go + TypeScript + React. 프론트엔드를 내가 만들어도 되지만 사실 React에 그렇게 자신이 있는 건 아니라서 100% 바이브 코딩을 해 보겠다는 목표로 하고는 있는데 결국 디버깅은 내가 다 하고 있다는 함정이 있다. 이를테면 사진에 나와 있는 코드는 JS에서 String.prototype.split이 받는 limit 인자의 해석 관련된 질문인데 이거랑 관련된 버그로 2시간 정도를 날렸다. (JS는 놀랍게도 'a,b,c'.split(',', 2) 하면 ['a','b']가 나온다. ['a','b,c']가 아니라!!!! 그럼 왜 처음에 그렇게 짜 줬는데???)

Angel의 2025-08-01 현재 스크린샷. 좌측에 New Session, Settings 버튼 및 세션 목록이 있다. 오른쪽에는 주황색 시스템 프롬프트, 초기 사용자 입력, 생각 거품(12개 중 7번째가 선택되어 보여지고 있음), 에이전트 출력, 그리고 후속 사용자 입력까지가 보이며, 그 하단에는 파일 첨부 버튼, 사용자 입력 칸(여러 줄 지원), 그리고 Send 버튼이 표시된다.

사용자 입력:
다음 코드가 [...] const [type, data] = eventString.slice(6).replace(/\ndata: /g, '\n').split('\n', 2); [...] 다음과 같은 로그를 출력하는 문제를 고쳐 줘. [...]

에이전트 출력:
The problem stems from the `split('\n', 2)` part of your code. This function limits the split to a maximum of two parts. When `eventString` is processed, `type` correctly captures the first part (`M`), but `data` only captures the content until the *next* newline, effectively truncating the rest of your message.

To fix this, we need to first remove all the `data: ` prefixes from the `eventString` and then split the resulting string into `type` (the first line) and `data` (all subsequent lines).

Here's the corrected code:
5
7

Hackers' Pub의 로고 디자인이 완료되었습니다! 디자인은 박은지 님(@murinono무리노노)께서 해주셨습니다.

연합우주라는 콘셉트에 맞게 고양이의 입 주변을 별 모양으로, 목 아래에도 고리(orbital ring) 모양으로 디자인했습니다. 고양이를 고른 이유는 소프트웨어 프로그래머 커뮤니티에서 다른 동물보다 유독 고양이가 사랑 받기 때문이기도 하고, 고양이가 호기심이 강하기 때문이기도 합니다.

로고 디자인은 CC-BY-SA 4.0 라이선스로 배포됩니다.

23
1
1

@bglbgl gwyng Vite 같은 경우에는 기본적으로 import.meta.env.DEV이 빌드 시에는 false로 치환되어서 minifier 돌리면 안쪽 코드가 통째로 날아가게 할 수 있습니다. 다른 번들러들에서도 비슷한 방법을 찾아볼 수 있을 것 같네요

2
0
0

XiNiHa shared the below article:

프론트엔드 애플리케이션 상태를 다루는 법

@disjukr@hackers.pub

이 글은 리액티브 프로그래밍에서 시간의 흐름에 따른 의존 그래프 관리를 설명하며, 특히 프론트엔드 상태 관리에 있어 옵저버블보다 시그널이 더 적합한 이유를 제시합니다. 저자는 프론트엔드 상태가 시간에 따라 결정적으로 변하지 않고, 노드의 의존 관계가 렌더 트리에 따라 변화무쌍하게 바뀌기 때문이라고 주장합니다. Rx, Redux, XState와 같은 기존 상태 관리 방식의 한계를 지적하며, 시그널(+ DI와 수명관리)을 중심으로 옵저버블, 리듀서, 스테이트머신을 함께 사용하는 것이 각 기술의 장점을 극대화할 수 있다고 설명합니다. 애니메이션, 폼 관리, NPC 인공지능과 같이 특정 상황에 적합한 기술을 시그널로 묶어 전체 애플리케이션 상태를 선언적으로 관리하는 방법을 제안하며, 이를 통해 애플리케이션의 구조를 더욱 명확하고 효율적으로 만들 수 있다고 강조합니다.

Read more →
6

XiNiHa shared the below article:

커뮤니케이션 지점은 도로위 신호등 같은 거다

@disjukr@hackers.pub

커뮤니케이션 비용을 간과하는 사람들은 소통에 직접 소요되는 시간만을 고려하지만, 실제로는 그 이상의 숨겨진 비용이 발생합니다. 커뮤니케이션 지점은 마치 도로 위의 신호등과 같아서, 잦은 소통은 불필요한 지연을 초래합니다. 회신 지연, 컨텍스트 스위칭 등 다양한 요인들이 쌓여 업무 속도를 늦추는 주범이 됩니다. 이러한 커뮤니케이션 비용을 줄이는 가장 효과적인 방법은 문제 해결에 필요한 수단을 제공하여 불필요한 소통 자체를 줄이는 것입니다. 문제 해결 수단을 만드는 비용이 커뮤니케이션 비용보다 크다고 생각하는 것은 오산일 수 있으며, 장기적으로 볼 때 문제 해결 능력을 키우는 것이 훨씬 효율적입니다.

Read more →
7
2

SMC made it just in time for the merge window! Now it's finally possible to reboot M1/M2 with an upstream kernel ;)

This also allows to enable the power gpios for e.g. wifi and allows us to upstream drivers for the power button, hardware sensors, battery status and RTC next.

lore.kernel.org/asahi/17533469

1
17
3
0
1
9
1

제가 꾸준히 개발하고 운영하는 서비스들을 소개합니다.

  • 나루: 한국의 Geocities/Neocities를 지향하는 개인 웹사이트 호스팅 플랫폼
  • 오이카페: 2000년대 인터넷 감성을 느낄 수 있는 오에카키 커뮤니티
  • 타이포 블루: 메일링 리스트 기능을 지원하는 텍스트 전용 블로깅 플랫폼

모두 공익을 위한 비영리 프로젝트이며, AGPLv3 하에 소스 코드가 공개되어 있습니다.

14
0
0

XiNiHa shared the below article:

Upyo 0.2.0 Release Notes

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

Upyo 0.2.0 has been released, introducing new features to this cross-runtime email library that supports Node.js, Deno, Bun, and edge functions. The latest version expands its capabilities with Amazon SES transport support, enabling AWS Signature v4 authentication and session-based authentication. Additionally, comprehensive OpenTelemetry integration has been added, offering distributed tracing, metrics collection, and error classification without altering existing code. The OpenTelemetry transport automatically instruments email operations, tracking delivery rates and latency, and integrates with existing OpenTelemetry infrastructure. Community feedback is encouraged to further improve Upyo, whether through testing the new Amazon SES transport, implementing OpenTelemetry, or contributing to the GitHub repository. This release enhances Upyo's utility by providing more transport options and robust observability features, making it a valuable tool for developers needing reliable email sending across various environments.

Read more →
4

@xiniha Bunja에 비슷한 로직이 포함되어 있을거 같아요. 다른걸 만드는데 좀더 작은 라이브러리가 필요해서 따로 만들었어요. 근데 Bunja에서 deferred cleanup이 가능한가요?

1

https://github.com/bglgwyng/deferred-cleanup-resource-map 이런 라이브러리를 만들었다. ref counting 해서 GC 해주는 map인데, 해제를 임의로 늦출수 있다. LRU 캐시같은걸 일반화한 형태라고 보면 된다.

이름이 참 저질인데, 나도 upyo같은 센스있는 이름을 붙이고 싶었지만, 이게 클로드랑 머리맞대서 나온 최선이다;;

0
4
1
0

이와 비슷하게 청개구리 스택 경로라는 것도 생각해 볼 수 있겠다. 예를 들어 Deno를 선택했으면 Fresh는 청개구리 스택 경로가 아니다. 그런데 Deno를 선택한 다음 Next.js를 선택하면 오히려 청개구리 스택 경로가 된다.

7

여성향 커미션 중개 플랫폼 크레페를 운영하는 쿠키플레이스에서 시니어 백엔드 엔지니어 채용을 진행중입니다. 채용공고에 해당 직무 소개, 복지, 연봉, 회사문화의 내용이 포함돼 있습니다. 많은 관심 부탁드립니다. Node.js, TypeScript, GraphQL에 대한 높은 숙련도 및 지식으로 팀에 기여해주실 분을 쿠키플레이스에서 극진히 기대하고 있습니다.

크레페에서는 이런 기술스택을 사용합니다

  • Node.js, TypeScript, Vitest, Fastify
  • GraphQL  - Yoga, Relay, Pothos, Prisma
  • ElasticSearch, MongoDB, FCM
  • Docker, Github Actions
  • AWS  - ElasticBeanstalk, CloudWatch, Aurora PostgreSQL, Lambda, SES, S3, ElastiCache (Redis)
  • Grafana, Sentry

구성원의 성장과 덕질을 지원해요

  • 희망 도서 구매 (만화책 및 TRPG 룰북 포함)
  • 워크샵 및 교육 프로그램 지원
  • 전시, 공연 및 각종 행사 티켓 지원
  • 월 5만 크레페 포인트
  • 전동작탁 AMOS JP-EX COLOR
  • 6인용 TRPG/보드게임 테이블

지원자님이 예상하실 수 있는 처우는 이래요

  • 연봉: 최소 8000만원 ~ 최대 2억원 (주 40시간)
  • 스톡옵션 부여에 열려있는 포지션
크레페, 나만의 레시피, 나만의 창작물
10
1
0

XiNiHa shared the below article:

힙스택 보존 법칙

RanolP @ranolp@hackers.pub

이 글에서는 프로젝트 진행 시 기술 스택 선정에 대한 경험적 법칙인 "힙스택 보존 법칙"을 소개하며, 힙한 기술 스택을 과도하게 선택할 경우 프로젝트가 산으로 갈 수 있음을 경고합니다. 저자는 신기술 도입 시 발생하는 호환성 문제와 그로 인한 추가 작업의 부담을 설명하며, 커뮤니티가 크고 성숙한 기술의 중요성을 강조합니다. 힙한 기술을 사용하더라도 프로젝트를 성공적으로 이끌 수 있는 두 가지 조건, 즉 기술의 안정성과 개발자의 숙련도를 제시하며, 힙스택을 사용하기 전에 충분한 학습과 경험을 통해 기술적 내성을 길러야 함을 역설합니다. 이 글은 기술 스택 선택의 중요성과 개발자의 역량 강화 필요성을 동시에 강조하며, 균형 잡힌 기술 스택 선택이 프로젝트 성공에 미치는 영향을 시사합니다.

Read more →
13
1
1

Node.js 커뮤니티는 환경 변수를 너무 좋아하는 것 같다. 거의 라이브러리 API의 일부로 생각하는 듯?

Deno만 해도 환경 변수는 --allow-env 플래그를 통해 명시적으로 허용하지 않으면 접근 못하고, Haskell에서도 getEnvString이 아니라 IO String을 반환하게 되어 있다.

반면 Node.js에서는 process.env로 너무 쉽게 접근 가능해서 그런가, 환경 변수 접근이 입출력이라는 생각을 아예 안 하는 모양이다.

8
2

JS Error 클래스에

class Error {
  ...
  throw() {
    throw this
  }
}

이런 메소드 있으면 편할 것 같은데 왜 없지? 예를 들면:

# 현재
const user = findUser();
if (!user) {
  throw new Error("Not found user");
}

# `throw` 메소드
const user = findUser() ?? new Error("Not found user").throw();

이렇게 쓸 수도 있고 이름 별로면 raise 써도 되고 TC39 에 한번 제안해볼까...

3