v1의 구현방식이 매력적이었는데 한계로 인해 결국 v2의 방식을 택하게된게 참 아쉬웠다…

RE: https://hl.pkgu.net/@pkgupdt/019627a1-2be1-763a-90e2-1e10ce1df445

패디버스 앱으로서 해커스펍이 누릴 수 있는 기능 중 하나가 Remote Follow인데, 이건 다른 페디버스 앱에서도 마찬가지로 이런 기능이라는게 있다는걸 알지 못하는 경우가 많다. 새로 진입하는 분들 타겟으로 카드뉴스 같은거라도 만들어야 하나...... 라는 생각이 문득 들었다.

좋은 기능이 있어도 설명이 필요하다는 것 자체가 성공한 UX는 아닌 것 같은데, 이게 구조 상 어쩔 수 없이 생기는 문제인건가 싶기도 하고

Fedify 프로젝트의 메인테이너로서 2025年(년) 오픈소스 컨트리뷰션 아카데미 參與型(참여형) 멘토團(단)에 選拔(선발)되었습니다!

5月(월) 21日(일)(水(수))부터 6月(월) 22日(일)(日(일))까지 멘티도 募集(모집)한다고 하니 많은 參與(참여) 바랍니다.

UI로 노출하는 건 나중에 만드려고 했지만, 어차피 테스트도 해야 해서 UI로도 노출했습니다. 자신의 팔로워 목록 페이지에 가시면 각 팔로워마다 오른쪽 위에 X 모양 아이콘이 생겼을 겁니다. 그걸 누르면 팔로워를 삭제할 수 있습니다. (X로 치면 “블언블”한 효과.)

협업을 할 때 미묘하게 거슬리는 것들$\ldots$

• 텍스트 파일의 마지막 줄 완성 안 하기 Posix 표준 기준으로 각 줄은 새줄 문자(line feed, '\n')로 끝나야 하며, 마지막 줄도 예외는 아님
• 그리고 위의 일이 주기적으로 재발할 때$\ldots$

쿠버네티스는 컴포즈만으로는 할 수 없는 HA (네트워킹 포함) 까지 책임져주는 솔루션 중 de-facto 라서 쓴다고 생각해요

앵간한 상황 다 대응되고

복잡하고 어려운 이유는 "앵간한 상황 다 대응"되기 때문이 아닐까 싶음... 컨테이너만 띄울거면 이렇게 복잡해질 이유가 없었음 - 사실 그 부분만 보면 컴포즈랑 비슷하기도 하고

GeekNews의 〈소프트웨어 엔지니어로 산다는 건 미친 짓이야〉 주제에 @youknowone 님께서 쓰신 좋은 댓글:

소프트웨어 개발이 어려운 일이라는 사람들은 본인이 그 일을 하는 이유가 뭘까요? 고되고 힘든 일이지만 보람있는 일이라서 하시나요? 이 업계에서 그런 분들은 그리 많지는 않았던 것 같습니다. 남들이 못하는 것 같으니까 어렵다고 주장하는거지, 실상은 그게 본인한테 가장 쉬운 일이니까 하시는 것 아닌가요? 남들이 좀 띄워준다고 자화자찬하면서 나만 특별한 양 여기면서 눈을 가리지 말고 주위를 봐야합니다. 이공계에서 어떤 분야가 방구석에서 인터넷 좀 보고 독학한다고 (잘 하면) 몇달만에 현업에 투입할 수 있는 전문가가 됩니까?

(…중략…)

물론 남들이 가지지 못한 훌륭한 손재주를 가진 사람은 존중받아 마땅하지만, 약간의 손재주를 연마했다고 해서 소싯적 배워둔 손재주로 평생 먹고 살면 좋을텐데 왜 그럴수 없을까, 나는 이런 훌륭한 손재주를 가졌는데 다른 사람들처럼 힘들게 일하지 않아야 하는 것 아닐까, 나는 남들은 쉽게 하지 못하는 대단한 재능을 가진 것이 아닐까 등등의 특별한 나에 심취하는건 교만에 가까운 일이 아닐까 합니다.

⚛️📝 New on Overreacted: React for Two Computers

React for Two Computers — over...

사실 애초부터 Drizzle ORM이 클라이언트에서 계산되는 칼럼 같은 기능을 제공해 주면 일이 이렇게 복잡하지 않을 것 같은데. 무슨 ORM이 게터(getter)를 정의할 수 없는 건지… 아니면 있는데 나만 모르고 있는 건가!?

메타적인 얘기지만, 저는 오늘 “Kubernetes는 적정 기술인가?”라는 떡밥이 Hackers' Pub 내부적으로 발생했다는 사실이 아주 기쁩니다. 여태까지는 Hackers' Pub 자체에 대한 떡밥이거나, GeekNews나 X에서 넘어온 떡밥이었거든요.

오늘부터 쿠버세를 걷겠다

저, 저도 90% 이상의 경우 도커 컴포즈 정도가 적당한 추상화 수준이라고 생각해요...

실제로 쿠버네티스 쓰는 팀에서 일해 본 경험도 그렇고, 주변 이야기 들어 봐도 그렇고, 도입하면 도입한 것으로 인해 증가하는 엔지니어링 코스트가 분명히 있다는 점은 누구도 부인하지 않는 것 같은데요. 쿠버네티스를 제대로 쓰는 것 자체도 배워야 할 것도 많고, 엔지니어가 유능해야 하고, 망치도 들여야 하고... 웬만하면 전담할 팀이 필요하지 않나 싶어요. (전담할 '사람' 한 명으로 때우기에는, 그 사람 휴가 가면 일이 마비되니까.)

엔지니어만 100명이 넘는 곳이라면 확실히 도입의 이득이 더 크겠지만, 반대로 혼자 하는 프로젝트라면 도무지 수지타산이 안 나올 것이라고 생각합니다. 따라서 쟁점은 그 손익분기점이 어디냐일 텐데... "대부분의" 서비스는 대성공하기 전까지는 도입 안 해도 되지 않나, 조심스럽게 말씀드려 봅니다. 즉 쿠버네티스가 푸는 문제는 마세라티 문제인 것이죠...

특히 클라우드 남의 컴퓨터 를 쓰지 않고 베어메탈 쓰는 경우는 더더욱...

RE: https://hackers.pub/@hongminhee/019618b4-4aa4-7a20-8e02-cd9fed50caae

Hackers' Pub의 에모지 반응 기능은 Mastodon의 좋아요, Misskey 계열, Pleroma 계열, kmyblue 및 Fedibird의 에모지 반응 기능과 호환됩니다. 기술적으로는 기본 에모지인 ❤️는 Like 액티비티로 표현되며 그 외 나머지 에모지는 EmojiReact 액티비티로 표현됩니다. Mastodon, kmyblue, Fedibird의 좋아요는 ❤️ 에모지 반응으로 변환됩니다 (Misskey의 동작과 유사). 또한, Misskey 계열과 달리 한 사람이 한 콘텐츠에 여러 에모지 반응을 남길 수도 있습니다 (Pleroma 계열의 동작과 유사). Hackers' Pub 사용자가 남길 수 있는 에모지 반응은 ❤️, 🎉, 😂, 😲, 🤔, 😢, 👀 이렇게 7종이며, 그 외의 에모지 및 커스텀 에모지는 보낼 수는 없고 받는 것만 됩니다.

에모지 반응 기능이 배포되었습니다. 당분간 버그가 좀 있을 수도 있지만 양해 바랍니다. 전 이제 차단을 구현하러 가겠습니다…

@hongminhee洪 民憙 (Hong Minhee) (소근소근) 보는 사람들은 대개 더 잘게 쪼갤수록 좋아합니다. 체인지로그 한 덩어리가 너무 길면 읽을 엄두가 안 나서요. 더 자주 릴리스하면 더 활발하고 더 건강한 프로젝트처럼 보이게 되는 것은 덤...

홍민희에게서 보기 힘든 말투다 욱기네
https://hackers.pub/@hongminhee/019613cb-d1ce-7826-a289-918fb81655d4

패치 릴리스할 때 되도록이면 많은 버그 수정을 하나의 릴리스에 담고 싶은 충동.

간혹 "이모지"가 아니라 "에모지"라고 쓰는 이유에 대한 질문을 받습니다. 여기다 써 두면 앞으로 링크만 던지면 되겠지?

요약: 에모지라서 에모지라고 씁니다.

"이모지"라는 표기는 아마도 "emoji"가 "emotion"이나 "emoticon"과 관련이 있다고 생각해서 나오는 것으로 보이는데요. "emoji"와 "emoticon"은 가짜동족어(false cognate)입니다. "emoji"는 일본어 絵文字(에모지)를 영어에서 그대로 받아들여 쓰고 있는 것입니다. 심지어 구성원리도 에모+지가 아니고 에+모지(絵+文字)입니다. "emotion"과 유사해 보이는 것은 순전히 우연일 뿐, 계통적으로 전혀 아무 상관이 없습니다. "이모티콘"과 "이미지"의 합성어가 아닙니다. (그랬으면 "-ji"가 아니라 "-ge"였겠죠.)

그리고 그렇기 때문에 에모지를 에모지로 표기할 실익이 생깁니다. :), ¯\_(ツ)_/¯, ^_^ 등은 이모티콘입니다. 반면 😂는 명확히 에모지입니다.

프로그래머에게 이건 정말 중요한 구분입니다. "이모티콘을 잘 표현하는 시스템"과 "에모지를 잘 표현하는 시스템"은 전혀 다른 과제이기 때문입니다. 에모지는 "그림 문자"라는 원래 뜻 그대로, 어떤 문자 집합(예를 들어 유니코드)에서 그림 문자가 "따로 있는" 것입니다. 내부 표현이야 어떻든, 적어도 최종 렌더링에서는 별도의 글리프가 할당되는 것이 에모지입니다. "무엇이 에모지이고 무엇이 에모지가 아닌가"는 상대적으로 명확합니다(문자 집합에 규정되어 있으니까).

반면 이모티콘은 "무엇이 이모티콘인가?"부터 불명확합니다. 우선 대부분의 이모티콘은 이모티콘이 아닌 문자를 조합하여 이모티콘이 만들어지는 형식입니다. 예를 들어 쌍점(:)이나 닫는 괄호())는 그 자체로는 이모티콘이 아니지만 합쳐 놓으면 :) 이모티콘이 됩니다. 하지만 조합에 새로운 의미를 부여했다고 해서 다 이모티콘이라고 부르지도 않습니다. -_- 같은 것은 대다수가 이모티콘으로 인정하지만, -> 같은 것은 이모티콘이라고 부르지 않는 경향이 있습니다.

- 문자와 > 문자에는 화살표라는 의미가 없기 때문에, -> 조합과 화살표의 시각적 유사성에 기대어 화살표라는 새로운 의미로 "오용"한 것은 이모티콘의 구성 원리에 해당합니다. 하지만 화살표는 인간의 특정한 정서(emotion)에 대응하지 않으므로 이모티콘이라고는 잘 부르지 않습니다. 그렇다고 얼굴 표정을 나타내야만 이모티콘인가 하면 그렇지도 않습니다. orz 같은 것은 이모티콘으로 간주하는 경향이 있어 보입니다. 오징어를 나타내는 <:=는 이모티콘인가? 이모티콘이 맞다면, 왜 ->는 이모티콘이 아니고 <:=는 이모티콘인가? 알 수 없습니다. ㅋㅋ과 ㅠㅠ는 둘 다 정서를 나타내는데, ㅠㅠ만이 아이콘적 성질을 가지므로 이모티콘이고 ㅋ는 이모티콘이 아닌가? 알 수 없습니다. 만약 ㅋ만 이모티콘이 아니라고 한다면, ㅋ큐ㅠ 에서 큐는 이모티콘인가 아닌가?? 알 수 없습니다. 이 알 수 없음은 이모티콘의 생래적 성질입니다. 어쩔 수 없죠.

JavaScript에 Object.map() 같은 함수 하나 있었으면 좋겠다. 맨날 Object.fromEntries(Object.entries(obj).map(...)) 하기 귀찮다. (게다가 TypeScript에서 타입도 보존이 안 되어서 as 키워드 써야 함…)

Gemini Pro 2.5 엄청 똑똑하다... 기존 모델들은 대화가 길어지고 내용이 깊어지면 그냥 뻔한소리를 반복하기 시작하던데, 얘는 계속 생각해서 아이디어를 살려준다.

러스트에서 SIMD 코드 짜기 너무 고통스럽다 어떻게 좀 해달라... Rust 2024에선 unsafe_op_in_unsafe_fn 때문에 더 고통스러워졌다...

액펍 특성상 완전한 삭제는 매우 어렵습니다 (삭제 액티비티가 전달되지 않는 서버가 있을 수 있음)

일본에 Fediverse Linux Users Group이라는 모임이 있는데, 거기서 〈국한문혼용체에서 Hollo까지〉라는 이상한 주제로 오늘 발표를 합니다…

RE: https://hollo.social/@hongminhee/019603c7-b5ef-7d81-bbd4-4c37d46edce9

가끔 보면 Misskey는 ActivityPub을 마지못해 지원하는 것 같다니까요. (실제로 만든 사람이 그런 뉘앙스의 얘기도 몇 번 했었고.)

Servo vs Ladybird

https://thelibre.news/servo-vs-ladybird/

Hackers' Pub의 소스 코드 저장소를 제 개인 계정에서 hackers-pub 조직 계정으로 옮겼습니다.

https://github.com/hackers-pub/hackerspub

Hackers' Pub에 이제 알림 기능이 생겼습니다. 우상단 프로필 사진 바로 왼쪽에 알림 아이콘이 추가되었고, 이제 읽지 않은 알림이 있을 경우 그 위에 빨간 동그라미가 표시됩니다. 알림의 종류는 현재 다음 다섯 가지입니다:

• 누가 날 팔로했을 때
• 누가 날 언급했을 때
• 누가 내 글에 답글을 달았을 때
• 누가 내 글을 인용했을 때
• 누가 내 글을 공유했을 때

지금 Hackers' Pub에는 Fresh 2.0 알파를 쓰고 있는데, 여러 가지 아쉬운 점이 많지만 그 중 하나가 아일랜드 컴포넌트로 콘텍스트가 전달이 안 된다는 것. 현재 아일랜드 컴포넌트에는 로캘 같은 정보를 일일히 프랍(prop)으로 넘겨줘야 한다…

RE: https://hackers.pub/@kodingwarrior/0195f94d-61f3-7cab-8a34-f2a8ab0f9a4a

사실 Hackers' Pub은 저희 집 홈 서버인 Mac mini M4 깡통 모델에서 돌아가고 있을 뿐만 아니라, 배포도 compose.yaml 파일의 image: 필드를 매번 손으로 고친 뒤 docker compose up -d를 치는 전근대적인 방식으로 이뤄지고 있습니다… 뭔가 자동화를 하고 싶긴 한데 귀찮은 마음이 커서 아직까지 이대로 살고 있네요.

쿨엔조이 M.2 SSD 방열판 벤치마크 4년이 넘은 글이긴 한데...

• 제조사에서 권장하는 방식을 유유히 비웃으며 직접 이상한 짓(서멀패드를 끼워줬는데 버리고 다른 서멀패드를 쓴다든지)을 해야 실측 결과 더 좋게 나오는 제품이 수두룩... 하긴 M.2 SSD의 표면 요철 형상까지는 표준화가 안 되어 있으니
• 방열 성능만 따지면 서멀패드보다 서멀그리스가 우월한 것은 어쩔 수 없는 듯
• "조이쿨 JH-M.2 SSD 30MM"은 당시 6570원이었고 "조이쿨 M.2 SSD 히트파이프 쿨러"는 무려 16000원으로 두 배도 훨씬 넘는 가격이었는데, 6570원짜리가 더 성능 우수. 심지어 같은 회사인데
• RGB LED 달고 있으면 성능 폭락 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

인용한 글의 내용과는 상관 없는 이야기인데, 현재는 단문에서는 단문이든 게시글이든 인용할 수 있는 반면, 게시글에서는 단문도 게시글도 인용을 못 하게 되어 있다. 별 생각을 안 하고 그렇게 만든 거긴 한데, 잘 생각해 보니 오히려 인용 기능은 게시글에서 더 유용할 것 같다.

하루 빨리 게시글에서도 인용이 가능하게 개선을 하도록 하겠습니다…

RE: https://hackers.pub/@xt/2025/stackage-why

@xtjuxtapose ActivityPub의 한계는 아닌데 Mastodon을 비롯한 주요 구현들이 지원을 안 하는 건 사실입니다. 음… SVG를 업로드하면 Hackers' Pub 내부에서는 SVG로 보여주고 ActivityPub으로는 래스터화해서 보내는 식으로 편법을 쓸 수는 있을 것 같네요.

많은 부분 Hackers' Pub에서 이미 사용하고 있는 패턴들. 그리고 기본 키를 uuid로 했을 때 지역성(locality)가 떨어져서 성능상 손해를 보는 문제는 UUIDv7을 쓰면 해결된다.

RE: https://sns.lemondouble.com/notes/a61hofry16

레트로 웹 마니아 @limeburstJihyeok Seo 가 만든 호스팅 플랫폼 나루(https://naru.pub/)에 나도 2005년 감성의 홈페이지를 하나 깎아서 띄워볼까 함…(2005년인 이유: 내 html, css, js 지식이 20년 전에 멈춰있음)

많은 분들이 인용 방법을 혼란스러워 하셔서, 인용 버튼을 추가했습니다. 게시글이나 단문 아래의 아이콘들 중에 왼쪽에서 세 번째 아이콘을 누르시면 해당 콘텐츠를 인용한 글들이 나열되고, 그 위에 인용 글 입력란이 뜨게 됩니다. 거기서 인용 글을 쓸 수 있습니다. 아, 종래의 인용 UI도 그대로 사용하실 수 있습니다.

참고로 인용 아이콘은 @xtjuxtapose 님께서 수고해 주셨습니다. 감사합니다.

RE: https://hackers.pub/@xt/0195eb06-9f50-763d-85c8-5600ec78c539

요즘 주의 깊게 보고 있는 두 언어:

• Gleam: Erlang의 OTP 런타임에서 돌아간다는 점에서 Elixir와 비슷한데, 처음부터 정적 타입 언어로 설계되었다. 아, JavaScript 타깃도 지원한다. Haskell의 타입클래스(typeclass)나 Rust의 트레이트(trait)에 해당하는 기능이 없다는 게 개인적으로는 조금 아쉬운 점.

• MoonBit: 중국 쪽에서 주도해서 만들고 있는 WebAssembly 타깃 언어로, 이지 모드 Rust에 가까워 보인다. 다만 개발 과정이 완전히 오픈 소스는 아니고, (오픈 소스 라이선스이긴 하지만) 소스만 공개하는 형태라 거버넌스 측면에서 아쉬움이 있다.

We're incredibly honored to announce that #Ghost (@indexBuilding ActivityPub) has become a formal sponsor of Fedify through Open Collective!

This is a significant milestone for our project, and we're deeply grateful to @johnonolanJohn O'Nolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.

Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.

If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:

https://opencollective.com/fedify

Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️

Wine을 이용해서 Windows 실행 파일을 곧바로 실행할 수 있는 Linux 배포판이 필요하다는 주장. 황당하긴 한데, 이유를 들어보면 말은 된다. Linux 실행 파일들은 죄다 libc를 링크해서 시스템 콜을 직접 하기에 실행 파일들이 불안정(unstable)한 반면, 사유 소프트웨어인 Windows는 처음부터 실행 파일이 직접 시스템 콜을 하게 하지 않고 user32.dll 같은 시스템에서 제공되는 라이브러리를 동적 링크하여 쓰도록 하기 때문에 Windows 95 시절의 실행 파일도 Windows 11에서 실행할 수 있을 만큼 실행 파일이 안정적(stable)이다. 따라서 Linux에서 안정적으로 배포할 수 있는 유일한 실행 파일 형식은 Wine을 통한 Windows 실행 파일 뿐인 셈이 된다.

나도 비슷한 까닭으로 15년 넘게 Vim/Neovim 써 오다가, 몇 해 전부터 VS Code를 써 왔고, 요즘엔 Zed를 함께 쓰고 있다. Zed가 조금만 더 발전하면 Zed를 메인으로 쓰게 될 날이 올 듯…!

RE: https://yuri.garden/notes/a5zx8jmbwl

언젠가 해커스펍 오프라인 밋업 같은 거 하면 사진기사 겸 봉사자로 놀러가고 싶음

ActivityPub 효율적으로 익히려면 그냥 fedify 문서 첨부터 끝까지 읽으면 되는듯요

연합우주에 새 계정 만들기 (즐겁다)

@kodingwarriorJaeyeol Lee @curry박준규 알림은 조만간 구현 예정이고, Mastodon API는 아마도 구현 안 될 것 같아요. 대신 @xiniha 님 주도로 GraphQL API가 생길 예정!

오에카키 커뮤니티 오이카페를 오픈 소스로 공개했습니다.

Rust, Axum, MiniJinja, HTMX 등으로 만들었고, 그림판은 PaintBBS NEO와 tegaki.js를 지원합니다.

많은 관심 부탁드립니다!

We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:

Two-Stage Fan-out Architecture for Efficient Activity Delivery

#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.

This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.

For specific requirements, we've added a new fanout option with three settings:

// Configuring fan-out behavior
await ctx.sendActivity(
  { identifier: "alice" },
  recipients,
  activity,
  { fanout: "auto" }  // Default: automatic based on recipient count
  // Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);

Canonical Origin Support for Multi-Domain Setups

You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.

const federation = createFederation({
  // Use example.com for handles but ap.example.com for ActivityPub URIs
  origin: {
    handleHost: "example.com",
    webOrigin: "https://ap.example.com",
  },
  // Other options...
});

Optional Followers Collection Synchronization

Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.

await ctx.sendActivity(
  { identifier: sender },
  "followers",
  activity,
  { 
    preferSharedInbox: true,
    syncCollection: true,  // Explicitly enable collection synchronization
  }
);

Enhanced Key Format Compatibility

Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.

Improved Key Selection Logic

The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.

New Authorization Options

Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.

Efficient Bulk Message Queueing

Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:

• @fedify/redis 0.4.0
• @fedify/postgres 0.3.0
• @fedify/amqp 0.2.0

If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.

CLI Improvements

The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.

Additional Improvements and Bug Fixes

• Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
• Fixed bundler errors with uri-template-router on Rollup
• Improved error handling and logging for document loader when KV store operations fail
• Added more log messages using the LogTape library
• Internalized the multibase package for better maintenance and compatibility

For the complete list of changes, please refer to the changelog.

To update to Fedify 1.5.0, run:

# For Deno
deno add jsr:@fedify/fedify@1.5.0

# For npm
npm  add     @fedify/fedify@1.5.0

# For Bun
bun  add     @fedify/fedify@1.5.0

Thank you to all contributors who helped make this release possible!

#fedidev #fediverse

@hongminhee洪 民憙 (Hong Minhee) 전.. branch를 브런치라 읽으시는 분을 봤습니다... 배고프셨나봅니다.