
洪 民憙 (Hong Minhee)
OSC京都2025でどちらの発表を聞きたいですか?
8月3日のOSC京都で10分間のセミナー発表をすることになりました。二つのテーマで迷っているので、皆さんのご意見をお聞かせください!
どちらのテーマに興味がありますか?
Option | Voters |
---|---|
Fedify CLI:ActivityPubデバッグツール | 0 (0%) |
BotKit:誰でも作れるActivityPubボット | 0 (0%) |
OSC京都2025でどちらの発表を聞きたいですか?
8月3日のOSC京都で10分間のセミナー発表をすることになりました。二つのテーマで迷っているので、皆さんのご意見をお聞かせください!
どちらのテーマに興味がありますか?
Option | Voters |
---|---|
Fedify CLI:ActivityPubデバッグツール | 0 (0%) |
BotKit:誰でも作れるActivityPubボット | 0 (0%) |
OSC京都2025でどちらの発表を聞きたいですか?
8月3日のOSC京都で10分間のセミナー発表をすることになりました。二つのテーマで迷っているので、皆さんのご意見をお聞かせください!
どちらのテーマに興味がありますか?
Option | Voters |
---|---|
Fedify CLI:ActivityPubデバッグツール | 0 (0%) |
BotKit:誰でも作れるActivityPubボット | 0 (0%) |
OSC京都2025でどちらの発表を聞きたいですか?
8月3日のOSC京都で10分間のセミナー発表をすることになりました。二つのテーマで迷っているので、皆さんのご意見をお聞かせください!
どちらのテーマに興味がありますか?
Option | Voters |
---|---|
Fedify CLI:ActivityPubデバッグツール | 0 (0%) |
BotKit:誰でも作れるActivityPubボット | 0 (0%) |
OSC京都2025でどちらの発表を聞きたいですか?
8月3日のOSC京都で10分間のセミナー発表をすることになりました。二つのテーマで迷っているので、皆さんのご意見をお聞かせください!
どちらのテーマに興味がありますか?
Option | Voters |
---|---|
Fedify CLI:ActivityPubデバッグツール | 0 (0%) |
BotKit:誰でも作れるActivityPubボット | 0 (0%) |
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
And just finished writing a comprehensive contributor guide for the #OSSCA mentees!
You can check it out here—it's Korean though: https://hackers.pub/@hongminhee/2025/ossca-fedify-contributors-guide.
It covers everything from setting up the #fediverse accounts and development environment to finding good first issues. While it's primarily for the OSSCA participants, anyone interested in contributing to @fedify is welcome to use it as a reference.
Ready to onboard the next wave of #ActivityPub developers!
안내
이 문서는 기본적으로 오픈 소스 컨트리뷰션 아카데미 참여형 프로그램을 진행하게 된 멘티들을 위한 것입니다만, Fedify 프로젝트에 기여하고 싶은 분들이라면 얼마든지 활용하셔도 좋습니다.
안녕하세요. 오픈 소스 컨트리뷰션 아카데미 참여형 프로그램에서 Fedify 프로젝트를 함께 할 멘토 홍민희입니다.
Fedify 프로젝트에 참여하시게 된 것을 진심으로 환영합니다. 본 문서에서는 여러분이 앞으로 Fedify 프로젝트에 기여하기 위해서 알고 준비해야 하는 것들을 정리했습니다. 조금 긴 내용이 될 수도 있지만, 차근차근 읽어보시고 따라해야 할 과제는 따라해 주시기 바랍니다. 본 문서에 나온 과제들은 본격적인 기여를 위해 반드시 선행되어야 합니다.
중요
OSSCA 자체 Discord 서버에도 초대되셨을 것입니다만, 그곳에서는 행사에 관한 이야기만 주로 하게 될 겁니다. 실제 기여와 개발에 관련된 이야기는 지금부터 설명할 Fedify 프로젝트의 Discord 서버에서 이뤄지게 됩니다.
가장 먼저 해야 할 것은 Fedify 프로젝트의 Discord 서버에 입장하는 것입니다. 만약 아직 Discord 계정이 없다면 하나 만드세요. 꽤 많은 오픈 소스 프로젝트들이 Discord에서 소통을 합니다. Discord 계정을 만들어 두면 앞으로 다양한 오픈 소스 프로젝트에 기여할 때 쓸모가 많을 것입니다.
Fedify 프로젝트의 Discord 서버에 입장하면, 다음과 같은 질문이 뜹니다:
그러면 한국어를 포함해 자신이 이해할 수 있는 언어들을 선택하시면 됩니다. 그러면 여러 채널들이 보이게 되는데, 그 중에서 여러분이 주로 이용하게 될 채널은 #fedify-dev-ko 채널입니다.
본 문서를 읽고 따라하면서 중간에 어려움이 있거나 막히는 부분이 있으면 해당 채널에서 편하게 질문하시면 됩니다.
프로젝트 관련해서 궁금한 점은 사소한 것이라도 Discord 서버에서 질문 주세요. “시간이 날 때 천천히 해결해야지”보다는 일단 물어보는게 낫습니다. 특히 초반의 많은 문제는, 보통 질문을 많이 하면 빨리 해결됩니다. 시간을 정해두세요. 이를테면 30분으로 정했으면 30분 내로 해결이 안되면 일단 질문을 합시다.
과제
Discord 서버에 입장하신 뒤, #fedify-dev-ko 채널에서 간단히 자기 소개를 해 주세요. 본인의 이름과 GitHub 아이디를 꼭 알려주시기 바랍니다.
권고
원활하고 즉시적인 소통을 위해서는 모바일 앱으로 알림을 받을 수 있어야 합니다. 본인의 스마트폰에 Discord 앱을 설치하고 로그인한 뒤, 알림을 허용해 주세요. 랩톱 및 데스크톱 환경에서도 Discord 앱을 설치하고 항상 실행해 두실 것을 권합니다.
권고
가능하다면 Discord 계정의 아바타를 GitHub 계정의 프로필 사진과 통일해 주세요. 멘티가 워낙 많기 때문에 누가 누군지 기억하기 어렵기 때문입니다. 특히, 아무런 이미지도 설정해 두지 않은 분들은 아무 그림이라도 좋으니 시인성을 위해 설정을 부탁드립니다.
안내
이미 연합우주나 ActivityPub에 대해 익숙하신 분들은 설명은 건너 뛰시고 이 섹션 마지막의 과제만 하셔도 괜찮습니다.
Fedify 프로젝트가 어떤 프로젝트인지 이해하기 위해서는, 우선 페디버스(fediverse), 즉 한국어로 연합우주에 대해 기본적인 이해를 갖출 필요가 있습니다.
종래의 중앙집권적인 SNS들은 크게 두 가지 특징이 있습니다. 첫째로, SNS에 올리는 사용자들의 모든 데이터를 특정 기업이 사유한다는 것입니다. 둘째로, 서로 다른 SNS끼리는 소통할 수 없다는 것입니다. 특히, 두번째 특징은 이메일을 생각해 보면 아주 자연스러운 것은 아니라는 것을 알 수 있습니다. 네이버 메일을 쓰는 사람이 Gmail을 쓰는 사람과 소통할 수 없을까요? 그렇지 않지요. 하지만 Instagram 사용자는 X (舊 Twitter) 사용자와 소통할 수 없습니다.
이러한 문제를 해결하고자 나온 대안 SNS들이 있습니다. Mastodon이나 Pixelfed 같은 것들이 그렇습니다. 그리고 이러한 SNS들은 누구라도 자신의 서버에 설치가 가능합니다. 실제로 홈 서버에서 돌아가는 Mastodon 서버도 꽤 많습니다. 물론, 직접 서버를 운영하고 싶지 않은 대부분의 사람들에게는 대형 서버라는 선택지도 있습니다. 이를테면, Mastodon 서버 중에서 가장 사용자가 많은 서버인 mastodon.social은 Mastodon 개발 팀이 직접 운영하는 서버입니다.
하지만 이런 의문이 드실 수 있습니다. 자신의 홈 서버에 Mastodon을 설치해봤자 혼자 쓰는 일기장이 아닌가? 사실, Mastodon 서버들은 서로 소통이 가능합니다. 마치 이메일과도 같습니다. 자신의 홈 서버에 이메일 서버를 설치하여 자신만의 이메일 주소를 만들어도, 네이버 메일이나 Gmail과 서로 메일을 주고 받을 수 있는 것처럼요. 실제로, Mastodon의 계정 이름은 이메일 주소와 비슷하게 생겼습니다:
@[email protected]
이렇게 서로 다른 Mastodon 서버끼리 소통할 수 있도록 고안된 표준이 바로 ActivityPub 프로토콜입니다. 참고로, 이 ActivityPub 프로토콜은 Mastodon 프로젝트가 독자적으로 정한 게 아니라, W3C에서 웹 표준으로 정한 것입니다. 따라서 Mastodon 뿐만 아니라, Pixelfed 등 ActivityPub을 구현하는 다른 소프트웨어들도 서로 소통이 됩니다. Mastodon에서 Pixelfed로 댓글 다는 것도 되고, Pixelfed 사용자가 Mastodon 사용자를 팔로하는 것도 됩니다.
이렇게 서로 다른 SNS 소프트웨어, 사로 다른 서버끼리 자유롭게 소통이 가능한 구조를 연합(federation)이라고 부릅니다. 어떻게 보면, 이렇게 연합된 서로 다른 SNS들을 모두 합쳐서 하나의 SNS라고 볼 수도 있습니다. 이를 부르는 말이 바로 연합우주, 페디버스입니다.
연합우주는 현재도 꾸준히 커 가고 있습니다. 최근에는 Meta의 Threads도 ActivityPub을 구현하게 되었고, WordPress도 ActivityPub 플러그인을 공식적으로 개발했습니다. 특히, 기존의 연합우주 소프트웨어들은 각자의 서버에 직접 설치할 수 있는 오픈 소스 소프트웨어였던 것에 반해, Threads는 오픈 소스가 아님에도 ActivityPub을 구현했다는 점에서 상당히 이례적이라고 할 수 있습니다. 이런 방식의 연합도 가능하다는 것이죠.
안내
연합우주에 관해 좀 더 자세히 알고 싶어지셨다면, 〈연합우주(fediverse)와 ActivityPub 프로토콜 이해하기: 개발자를 위한 가이드〉라는 글도 읽어보시면 좋습니다.
과제
아직 연합우주를 경험해 본 적 없다면, 계정을 하나 만들어 봅시다. 계정을 만들기 위해서는 어떤 소프트웨어를 쓸 지 먼저 정해야 합니다. Mastodon과 Misskey는 일종의 X처럼 단문을 중심으로 한 SNS입니다. Pixelfed는 Instagram처럼 사진을 중심으로 한 SNS입니다. Meta의 Threads도 있습니다. 현재 읽고 계시는 이 글이 올라온 Hackers' Pub도 사실은 연합우주의 일부로서, 소프트웨어 개발자들을 위한 SNS입니다. 이 중 어떤 것을 선택하시든 서로 소통하는 데에는 문제가 없습니다.
만약 Mastodon이나 Misskey, Pixelfed를 선택하셨다면, 서버를 고르셔야 합니다. (물론, 서버를 직접 구축하시는 것도 괜찮습니다. 아마 많은 걸 배우실 수 있을 겁니다.) 무슨 서버를 골라야 할 지 모르시겠다면, Mastodon의 경우 silicon.moe 서버를, Misskey의 경우 stella.place 서버를, Pixelfed의 경우 chueok.pics 서버를 권합니다.
만약 Threads를 고르셨다면, 서버를 고를 필요가 없습니다. Threads는 설치형 소프트웨어가 아니라 Meta에서 운영하는 상용 서비스이기 때문입니다. 다만, 설정에 가셔서 페디버스 공유 설정을 켜 주셔야 합니다.
만약 Hackers' Pub을 고르셨다면, 역시 서버를 고를 필요가 없습니다. 단 하나의 서버만 있기 때문입니다. 다만, 초대장이 필요하므로 멘토에게 초대장을 요청하시기 바랍니다.
과제
연합우주 계정이 생기셨다면, 이제 친구를 사귀어야 합니다. 다른 멘티들에게 계정 주소를 물어보고 서로 팔로를 해 보세요. 멘토도 팔로해 보세요. (멘토도 맞팔 하겠습니다.) 멘토의 연합우주 계정 주소는 @[email protected]
입니다.
계정 주소로 팔로하는 방법은 소프트웨어마다 조금씩 다르지만, 대부분의 경우 검색창에 주소를 입력하면 해당 계정이 보입니다. 계정이 보인다면 팔로 버튼을 누르면 됩니다.
과제
생성한 계정으로 멘토의 계정인 @[email protected]
을 멘션하여 글을 써 주세요. 글 내용은 뭐든 좋습니다.
안내
이미 JavaScript와 TypeScript에 익숙하시다면 이 챕터는 넘기셔도 됩니다.
Fedify 프로젝트는 TypeScript로 작성되어 있습니다. TypeScript는 JavaScript에 정적 타입 검사를 추가한 언어로, 런타임에 버그를 발생시키는 잘못된 코드를 코드 작성 시에 미리 알 수 있도록 도와줍니다. TypeScript를 이해하려면 먼저 JavaScript를 이해해야 합니다.
아직 JavaScript에 익숙하지 않으신 분들은 《모던 JavaScript 튜토리얼》의 파트 1을 읽고 따라해 볼 것을 권합니다. 파트 2 이후의 내용은 Fedify 프로젝트에 기여하는 데에 크게 필요하지 않으므로 읽지 않으셔도 좋습니다.
JavaScript에는 어느 정도 익숙하지만 아직 TypeScript에 익숙하지 않으신 분들께는, 《The TypeScript Handbook》을 읽고 따라해 볼 것을 권합니다. 참고로 핸드북 페이지 우측 상단에 한국어 번역으로 가는 링크가 있습니다.
사실 오픈 소스 프로젝트에 기여하기 위해 반드시 그 프로젝트에서 쓰이는 언어를 속속들이 깊게 이해해야 하는 건 아닙니다. 기여할 때 필요한 만큼만 이해해도 좋으니, 어느 정도 언어 문법에 익숙해졌다 싶으면 실제 Fedify 코드를 읽는 것을 좀 더 추천합니다. 코드를 읽다가 이해가 안 되는 부분이 있으면 해당 언어 문법에 대해 따로 조사하는 식으로 익히시는 게 더 효율적입니다. 정 이해가 안 되는 경우에는 부담 없이 Fedify 프로젝트 Discord 서버의 #fedify-dev-ko 채널에서 질문해 주세요.
여러분은 웹 서버 애플리케이션을 만들 때 HTTP를 직접 구현하시나요? 아마도 대부분은 그렇지 않을 겁니다. 그러기엔 할 게 너무 많기 때문이죠. 대신 우리는 대부분 Express나 Next.js, Django 같은 웹 프레임워크를 이용해서 개발하게 됩니다.
마찬가지로, 연합우주 SNS 소프트웨어를 구현하려고 할 경우, ActivityPub을 바닥부터 구현하기에는 너무 할 게 많습니다. 따라서 개발을 쉽게 해 줄 프레임워크가 필요한데, 그게 바로 Fedify입니다.
어떤 오픈 소스 프로젝트든 간에, 해당 프로젝트에 기여하기 위해서는 먼저 그 소프트웨어를 써보고 기본적인 기능들을 숙지해야 합니다. 써보지도 않은 소프트웨어에 기여를 하는 것은 무리입니다. 여러분도 Fedify에 기여하기에 앞서 Fedify를 써 볼 필요가 있습니다.
Fedify는 연합우주 소프트웨어를 만드는 도구이므로, Fedify를 사용한다고 하면 연합우주 소프트웨어를 만들어 본다는 뜻이 됩니다. Fedify를 사용하여 작은 ActivityPub 서버 소프트웨어를 만들어 보세요. Fedify를 써 보면서 이해가 안 가거나 중간에 막히는 게 있다면 Discord 서버의 #fedify-help-ko 채널에서 질문하세요.
과제
Fedify를 배우고 써보는 가장 쉬운 방법은 튜토리얼을 읽고 따라하는 것입니다. Fedify 공식 튜토리얼의 한국어판인 〈나만의 연합우주 마이크로블로그 만들기〉를 읽고 그대로 따라서 진행하세요. 빠르면 하루, 느긋하게 하면 사흘 정도 걸립니다. 중간에 막히는 부분이 있으면 멘토에게 부담 없이 질문하세요.
주의
Windows 환경에서 작업하실 때는 (WSL을 사용하지 않는다면) Git의 core.autocrlf
설정을 꺼 주시기 바랍니다:
git config --global core.autocrlf false
안내
Fedify 프로젝트를 Windows 환경에서 개발할 수는 있지만, Linux나 macOS에 비해 편의성이 떨어지는 것도 사실입니다. 가능하면 WSL을 세팅하시고 WSL 안에서 작업하시는 걸 추천드립니다.
Fedify의 GitHub에 저장소가 올라가 있습니다. 해당 저장소를 각자 포크(fork)하신 뒤, 포크한 저장소를 로컬에 클론하세요. 클론하신 뒤, 클론한 로컬 저장소 안에 들어가 업스트림 저장소를 리모트로 추가하시는 것을 권합니다:
git remote add upstream https://github.com/fedify-dev/fedify.git
git fetch upstream
git pull --set-upstream upstream main
Fedify의 개발 환경 설정은 일반적인 JavaScript 프로젝트들에 비해 조금 복잡한 편입니다. Node.js 이외에도 Deno와 Bun 등 여러 런타임을 지원해야 하기 때문인데요. Fedify의 개발을 위해서는 다음 소프트웨어가 시스템에 모두 설치되어 있어야 합니다:
하나하나 직접 설치하셔도 좋습니다만, 귀찮으시다면 mise라는 개발 환경 설정 소프트웨어를 이용하는 것을 권합니다. mise는 정말 다양한 방법으로 설치가 가능합니다:
sudo pacman -S mise # Arch Linux
brew install mise # macOS
winget install jdx.mise # Windows
# 이 외에도 다양한 플랫폼 지원
설치하고 나서 PATH
환경 변수에 mise가 관리하는 소프트웨어들을 추가하도록 mise를 활성화해야 합니다. 활성화하는 방법은 어떤 셸을 사용하느냐에 따라 다릅니다:
echo 'eval "$(mise activate zsh)"' >> "${ZDOTDIR-$HOME}/.zshrc"
. "${ZDOTDIR-$HOME}/.zshrc"
echo 'eval "$(mise activate bash)"' >> ~/.bashrc
. ~/.bashrc
echo 'mise activate pwsh | Out-String | Invoke-Expression' >> $HOME\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
. $HOME\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
팁
대부분의 Linux의 경우 (또는 Windows의 WSL 안에서 작업하는 경우) 별 다른 설정을 하지 않았다면 bash를 쓰고 계실 것입니다. macOS를 쓰시고 별 다른 설정을 하지 않으셨다면 zsh을 쓰고 계실 것입니다. (WSL이 아닌) Windows의 경우에는 명령 프롬프트가 아닌 PowerShell 안에서 작업하셔야 합니다.
mise를 설치하셨다면, 로컬 저장소 안에 들어가 다음 명령어로 필요한 모든 소프트웨어를 한 번에 설치하실 수 있습니다:
mise install --yes
위 명령어를 실행하면 아래와 같이 Fedify 저장소 안에 들어있는 mise 설정 파일을 신뢰하겠냐는 프롬프트가 뜹니다. Yes를 선택해 주세요:
mise config files in ~/fedify are not trusted. Trust them?
Yes No All
←/→ toggle • y/n/a/enter submit
개발 환경이 잘 설정되었는지 확인하기 위해 Fedify의 전체 테스트 스위트를 실행해 봅시다. 첫 실행 시 통상 5분 정도 소요됩니다:
deno task test-all
Git 훅도 설치합니다:
deno task hooks:install
마지막으로 실제 편집 환경을 구성해야 합니다. 본 문서에서는 Visual Studio Code를 사용하는 것을 가정하겠습니다만, 같은 Visual Studio Code 계열인 Cursor나 Windsurf에서도 과정은 대동소이합니다.
경고
Visual Studio와 Visual Studio Code는 서로 전혀 다른 별개의 제품이니 주의하세요.
안내
여러분이 Emacs나 Vim의 독실한 신자라면 Visual Studio Code를 사용하고 싶지 않을 수 있습니다. 그런 경우, Deno의 공식 환경 설정 문서를 참고하여 Deno 랭귀지 서버를 설정해 주시기 바랍니다.
우선 로컬 저장소 안에서 code
명령어를 통해 Visual Studio Code를 띄웁니다:
code . # Visual Studio Code를 사용하는 경우
cursor . # Cursor를 사용하는 경우
windsurf . # Windsurf를 사용하는 경우
Visual Studio Code 창이 뜨면, 화면 가운데에 다음과 같은 프롬프트 창이 뜹니다:
프롬프트에서 예, 작성자를 신뢰합니다 버튼을 선택합니다. 그러면 오른쪽 아래에 다음과 같은 작은 프롬프트 창이 뜹니다:
프롬프트에서 설치 버튼을 선택합니다. 그러면 화면 가운데에 다음과 같은 프롬프트 창이 뜹니다:
프롬프트에서 게시자 신뢰 및 설치를 선택합니다. 그러면 Visual Studio Code에 Fedify 개발에 필요한 확장들이 설치되게 됩니다.
이로써 Fedify 기여에 필요한 기본적인 개발 환경 설정이 끝났습니다.
Fedify는 Deno, Node.js, Bun 등 다양한 JavaScript 런타임을 지원해야 합니다. 과연 JavaScript 런타임이 뭘까요?
JavaScript는 비교적 작은 언어입니다. 여러분이 process.exit()
같은 메서드를 활용하신 적 있다면, 이는 JavaScript 자체의 기능이 아니라 Node.js라는 특정한 JavaScript 런타임이 제공하는 기능입니다. 마찬가지로, 웹 브라우저에서 제공하는 DOM API 역시 JavaScript 자체의 기능이 아니라 웹 브라우저라는 (일종의) JavaScript 런타임이 제공하는 기능이라고 볼 수 있습니다.
JavaScript 런타임은 기본적으로 다음과 같은 역할을 합니다:
console.log()
, Node.js의 process.exit()
, 웹 브라우저의 window.alert()
같은 것들이 있습니다.앞서 설명한 모든 것을 속속들이 이해해야 할 필요는 없습니다. 중요한 것은, 같은 JavaScript라고 하더라도 어느 런타임에서 실행하냐에 따라 상당히 다른 방식으로 언어를 사용해야 한다는 점입니다.
그러면 Fedify 프로젝트는 다양한 JavaScript 런타임을 어떻게 동시에 다 지원할 수 있을까요? 크게 두 가지 방법이 있습니다:
Fedify 프로젝트는 두 가지 방법 모두 사용하고 있으며, 지원하는 모든 JavaScript 런타임에서 테스트 스위트를 실행해서 Fedify의 모든 기능이 각 JavaScript 런타임에서 잘 동작하는지를 검사합니다.
2025년 7월 현재, Fedify 프로젝트의 저장소는 다음과 같은 구조로 되어 있습니다:
여러분은 주로 fedify/ 디렉터리 및 cli/ 디렉터리에서 작업을 하게 될 것입니다.
여느 오픈 소스 프로젝트들이 그렇듯, Fedify 프로젝트도 나름의 코딩 컨벤션과 규칙들이 있습니다. 다행히 이들 대부분은 커밋하기 전에 기계적으로 검사가 가능합니다. 다음 명령어는 현재 프로젝트의 코드가 코딩 컨벤션을 잘 지키고 타입 오류가 없는지 검사합니다:
deno task check
다음 명령어는 코드를 코딩 컨벤션에 맞게 알아서 서식화합니다:
deno fmt
앞서 언급한 것처럼, 다음 명령어는 Fedify 프로젝트의 전체 테스트 스위트를 실행하고 필요한 검사를 수행합니다. 풀 리퀘스트를 올리기 전에 한 번 실행해 보십시오:
deno task test-all
@fedify/fedify 패키지를 수정했을 경우, 수정과 관련된 일부 테스트 코드만 빠르게 실행해 보고 싶을 수 있습니다. 그럴 때는 다음과 같이 -f @fedify/fedify
옵션과 --filter
옵션을 함께 활용해 보세요 (태스크 이름이 test-all
이 아니라 test
임에 주의하세요):
deno task -f @fedify/fedify test --filter verifyRequest
혹은 -f @fedify/fedify
옵션을 쓰는 대신 직접 fedify/ 디렉터리 안에서 deno task test
명령어를 사용하셔도 됩니다:
cd fedify/
deno task test --filter verifyRequest
참고로 --filter
옵션은 테스트 케이스 이름을 부분 문자열로 검색합니다. 이를테면, 다음과 같은 테스트가 있을 경우:
test("anArbitraryTest", () => {
// … 생략 …
});
다음과 같은 방식으로 모두 실행이 가능합니다:
deno task -f @fedify/fedify test --filter anArbitraryTest
deno task -f @fedify/fedify test --filter Arbitrary
deno task -f @fedify/fedify test --filter Test
앞서 설명한 deno task test
명령어는 Deno 런타임에서 테스트 스위트를 실행합니다. Node.js에서도 잘 돌아가나 확인하기 위해서는 Node.js 런타임에서도 테스트 스위트를 실행해 봐야 합니다. fedify/ 디렉터리 안쪽에서 pnpm test
명령어를 통해 Node.js에서 테스트 스위트를 돌려 볼 수 있습니다:
cd fedify/
pnpm test
일부 테스트만 빠르게 실행해 보고 싶을 경우 --test-name-pattern
옵션을 활용하세요:
pnpm test --test-name-pattern verifyRequest
Bun에서도 잘 돌아가는지 확인하려면 fedify/ 디렉터리 안쪽에서 pnpm test:bun
명령어를 사용하세요:
pnpm test:bun
일부 테스트만 빠르게 실행해 보고 싶을 경우 마찬가지로 --test-name-pattern
옵션을 활용하세요:
pnpm test:bun --test-name-pattern verifyRequest
마지막으로, Cloudflare Workers에서도 잘 돌아가는지 검사해야 합니다. 이 경우에는 pnpm test:cfworkers
명령어를 활용하세요:
pnpm test:cfworkers
일부 테스트만 빠르게 실행해 보고 싶을 경우 인자로 부분 문자열 키워드를 넘기면 됩니다:
pnpm test:cfworkers verifyRequest
사실, 앞서 설명했던 deno task test-all
명령어는 한 번에 Deno, Node.js, Bun, Cloudflare Workers 모두에서 테스트 스위트를 실행하는 명령어입니다.
안내
테스트 실행 시 실패하는 케이스가 있나요? 그것 자체가 기여할 좋은 기회입니다. 실패하는 테스트가 성공하도록 직접 코드를 고쳐서 풀 리퀘스트를 올리셔도 좋고, 이슈 트래커에 이슈를 만들기만 해도 좋은 기여가 됩니다.
@fedify/cli 패키지는 Fedify를 이용하여 ActivityPub 서버를 구현하는 개발자들을 위한 CLI 편의 도구로서, 주로 ActivityPub 서버 개발을 할 때 디버그나 테스트를 위해 필요한 기능들을 제공합니다. 라이브러리 패키지인 @fedify/fedify와 다르게 @fedify/cli는 패키지는 애플리케이션이기 때문에 코드를 수정한 뒤 바로 사용해 볼 수가 있습니다. 또한, 굳이 여러 런타임을 지원할 필요가 없기 때문에 Deno 환경만 신경쓰면 됩니다.
그런 이유로, @fedify/cli 패키지는 처음 기여하기에 좋습니다. 참고로 @fedif/cli는 CLI 애플리케이션 프레임워크로 Cliffy를 사용하고 있으니, 관련해서 궁금한 게 있다면 Cliffy 문서를 참고해 주세요.
중요
오픈 소스 프로젝트에서는 할 일을 자발적으로 찾아야 합니다. 직장이 아니므로, 다른 누군가가 할 일을 할당해 주지 않습니다. 사실, 오픈 소스에서 활발하게 활동하는 프로그래머들은 단순히 소프트웨어 개발 실력이 좋은 게 아니라, 적절한 할 일을 잘 찾아내는 능력이 있습니다. 이 때 “적절하다”는 것은 자신의 실력으로 해낼 수 있을 정도의 난이도면서도 프로젝트에 임팩트를 낼 수 있는 것을 뜻합니다.
대부분의 오픈 소스 프로젝트는 할 일을 이슈 트래커에서 관리합니다. Fedify 역시 GitHub에서 제공하는 이슈 트래커로 할 일들을 관리하고 있습니다. 특별한 이유가 없는 한, 이슈는 기본적으로 영어로 작성되거나, 적어도 영어가 병기되어야 합니다. 영어가 익숙치 않은 분들은 Kagi 번역 등을 활용하시면 될 것 같습니다. 언어 때문에 어려우신 분은 멘토에게 도움을 청하세요.
이슈는 크게 세 종류로 나뉩니다:
위의 분류와는 별개로, Fedify 이슈 트래커에서는 레이블을 구조화하여 활용하고 있습니다. 대부분의 레이블은 범례/레이블 이름 형식을 따르며, 대표적으로는 다음과 같은 것들이 있습니다:
안내
좀 더 자세히 확인하실 분은 전체 레이블 목록을 확인하세요.
여기서 여러분이 가장 주목하셔야 할 레이블은 바로 good first issue입니다. 해당 레이블이 붙은 이슈는 처음 기여하는 사람에게 적합하기 때문에, 여러분의 첫 기여 때 할 일을 찾을 때 도움이 됩니다. 이슈들을 찬찬히 읽어보시고 해 볼 만한 일감을 고르세요. 이슈를 읽어도 이해가 안 될 경우에는 댓글로 질문을 남기거나 멘토에게 질문하세요.
기여해 볼 이슈를 찾으셨다면, 해당 이슈를 이미 다른 사람이 진행중인지 확인하세요. 아무도 진행하고 있지 않다면 진행하겠다는 댓글을 이슈에 달아주세요.
과제
처음 기여할 이슈를 찾아 이슈에 댓글을 달아주세요. 이슈를 못 찾겠다면 멘토에게 도움을 요청하세요. 멘토가 기여할 만한 일을 함께 찾아줄 수 있습니다.
안내
굳이 이슈 트래커에 이미 있는 이슈 중에서만 고를 필요는 없습니다. Fedify를 써 보면서 개선할 부분을 발견하셨다면, 그걸 이슈로 만들어서 직접 해결하셔도 좋습니다. 사실, 오픈 소스의 많은 이슈들이 이슈를 제기한 사람에 의해 해결됩니다.
본 문서에서 다루지 못한 내용도 많이 있을 것입니다. 아래 문서들은 부족한 부분을 좀 더 보충해 줄 수 있습니다:
본 문서를 읽다가 혹은 읽고 나서도 궁금한 점이 있다면 얼마든지 멘토에게 질문해 주세요. Discord 서버에서 질문하셔도 좋고, GitHub Discussions에 질문 글을 올리셔도 좋습니다.
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
And just finished writing a comprehensive contributor guide for the #OSSCA mentees!
You can check it out here—it's Korean though: https://hackers.pub/@hongminhee/2025/ossca-fedify-contributors-guide.
It covers everything from setting up the #fediverse accounts and development environment to finding good first issues. While it's primarily for the OSSCA participants, anyone interested in contributing to @fedify is welcome to use it as a reference.
Ready to onboard the next wave of #ActivityPub developers!
안내
이 문서는 기본적으로 오픈 소스 컨트리뷰션 아카데미 참여형 프로그램을 진행하게 된 멘티들을 위한 것입니다만, Fedify 프로젝트에 기여하고 싶은 분들이라면 얼마든지 활용하셔도 좋습니다.
안녕하세요. 오픈 소스 컨트리뷰션 아카데미 참여형 프로그램에서 Fedify 프로젝트를 함께 할 멘토 홍민희입니다.
Fedify 프로젝트에 참여하시게 된 것을 진심으로 환영합니다. 본 문서에서는 여러분이 앞으로 Fedify 프로젝트에 기여하기 위해서 알고 준비해야 하는 것들을 정리했습니다. 조금 긴 내용이 될 수도 있지만, 차근차근 읽어보시고 따라해야 할 과제는 따라해 주시기 바랍니다. 본 문서에 나온 과제들은 본격적인 기여를 위해 반드시 선행되어야 합니다.
중요
OSSCA 자체 Discord 서버에도 초대되셨을 것입니다만, 그곳에서는 행사에 관한 이야기만 주로 하게 될 겁니다. 실제 기여와 개발에 관련된 이야기는 지금부터 설명할 Fedify 프로젝트의 Discord 서버에서 이뤄지게 됩니다.
가장 먼저 해야 할 것은 Fedify 프로젝트의 Discord 서버에 입장하는 것입니다. 만약 아직 Discord 계정이 없다면 하나 만드세요. 꽤 많은 오픈 소스 프로젝트들이 Discord에서 소통을 합니다. Discord 계정을 만들어 두면 앞으로 다양한 오픈 소스 프로젝트에 기여할 때 쓸모가 많을 것입니다.
Fedify 프로젝트의 Discord 서버에 입장하면, 다음과 같은 질문이 뜹니다:
그러면 한국어를 포함해 자신이 이해할 수 있는 언어들을 선택하시면 됩니다. 그러면 여러 채널들이 보이게 되는데, 그 중에서 여러분이 주로 이용하게 될 채널은 #fedify-dev-ko 채널입니다.
본 문서를 읽고 따라하면서 중간에 어려움이 있거나 막히는 부분이 있으면 해당 채널에서 편하게 질문하시면 됩니다.
프로젝트 관련해서 궁금한 점은 사소한 것이라도 Discord 서버에서 질문 주세요. “시간이 날 때 천천히 해결해야지”보다는 일단 물어보는게 낫습니다. 특히 초반의 많은 문제는, 보통 질문을 많이 하면 빨리 해결됩니다. 시간을 정해두세요. 이를테면 30분으로 정했으면 30분 내로 해결이 안되면 일단 질문을 합시다.
과제
Discord 서버에 입장하신 뒤, #fedify-dev-ko 채널에서 간단히 자기 소개를 해 주세요. 본인의 이름과 GitHub 아이디를 꼭 알려주시기 바랍니다.
권고
원활하고 즉시적인 소통을 위해서는 모바일 앱으로 알림을 받을 수 있어야 합니다. 본인의 스마트폰에 Discord 앱을 설치하고 로그인한 뒤, 알림을 허용해 주세요. 랩톱 및 데스크톱 환경에서도 Discord 앱을 설치하고 항상 실행해 두실 것을 권합니다.
권고
가능하다면 Discord 계정의 아바타를 GitHub 계정의 프로필 사진과 통일해 주세요. 멘티가 워낙 많기 때문에 누가 누군지 기억하기 어렵기 때문입니다. 특히, 아무런 이미지도 설정해 두지 않은 분들은 아무 그림이라도 좋으니 시인성을 위해 설정을 부탁드립니다.
안내
이미 연합우주나 ActivityPub에 대해 익숙하신 분들은 설명은 건너 뛰시고 이 섹션 마지막의 과제만 하셔도 괜찮습니다.
Fedify 프로젝트가 어떤 프로젝트인지 이해하기 위해서는, 우선 페디버스(fediverse), 즉 한국어로 연합우주에 대해 기본적인 이해를 갖출 필요가 있습니다.
종래의 중앙집권적인 SNS들은 크게 두 가지 특징이 있습니다. 첫째로, SNS에 올리는 사용자들의 모든 데이터를 특정 기업이 사유한다는 것입니다. 둘째로, 서로 다른 SNS끼리는 소통할 수 없다는 것입니다. 특히, 두번째 특징은 이메일을 생각해 보면 아주 자연스러운 것은 아니라는 것을 알 수 있습니다. 네이버 메일을 쓰는 사람이 Gmail을 쓰는 사람과 소통할 수 없을까요? 그렇지 않지요. 하지만 Instagram 사용자는 X (舊 Twitter) 사용자와 소통할 수 없습니다.
이러한 문제를 해결하고자 나온 대안 SNS들이 있습니다. Mastodon이나 Pixelfed 같은 것들이 그렇습니다. 그리고 이러한 SNS들은 누구라도 자신의 서버에 설치가 가능합니다. 실제로 홈 서버에서 돌아가는 Mastodon 서버도 꽤 많습니다. 물론, 직접 서버를 운영하고 싶지 않은 대부분의 사람들에게는 대형 서버라는 선택지도 있습니다. 이를테면, Mastodon 서버 중에서 가장 사용자가 많은 서버인 mastodon.social은 Mastodon 개발 팀이 직접 운영하는 서버입니다.
하지만 이런 의문이 드실 수 있습니다. 자신의 홈 서버에 Mastodon을 설치해봤자 혼자 쓰는 일기장이 아닌가? 사실, Mastodon 서버들은 서로 소통이 가능합니다. 마치 이메일과도 같습니다. 자신의 홈 서버에 이메일 서버를 설치하여 자신만의 이메일 주소를 만들어도, 네이버 메일이나 Gmail과 서로 메일을 주고 받을 수 있는 것처럼요. 실제로, Mastodon의 계정 이름은 이메일 주소와 비슷하게 생겼습니다:
@[email protected]
이렇게 서로 다른 Mastodon 서버끼리 소통할 수 있도록 고안된 표준이 바로 ActivityPub 프로토콜입니다. 참고로, 이 ActivityPub 프로토콜은 Mastodon 프로젝트가 독자적으로 정한 게 아니라, W3C에서 웹 표준으로 정한 것입니다. 따라서 Mastodon 뿐만 아니라, Pixelfed 등 ActivityPub을 구현하는 다른 소프트웨어들도 서로 소통이 됩니다. Mastodon에서 Pixelfed로 댓글 다는 것도 되고, Pixelfed 사용자가 Mastodon 사용자를 팔로하는 것도 됩니다.
이렇게 서로 다른 SNS 소프트웨어, 사로 다른 서버끼리 자유롭게 소통이 가능한 구조를 연합(federation)이라고 부릅니다. 어떻게 보면, 이렇게 연합된 서로 다른 SNS들을 모두 합쳐서 하나의 SNS라고 볼 수도 있습니다. 이를 부르는 말이 바로 연합우주, 페디버스입니다.
연합우주는 현재도 꾸준히 커 가고 있습니다. 최근에는 Meta의 Threads도 ActivityPub을 구현하게 되었고, WordPress도 ActivityPub 플러그인을 공식적으로 개발했습니다. 특히, 기존의 연합우주 소프트웨어들은 각자의 서버에 직접 설치할 수 있는 오픈 소스 소프트웨어였던 것에 반해, Threads는 오픈 소스가 아님에도 ActivityPub을 구현했다는 점에서 상당히 이례적이라고 할 수 있습니다. 이런 방식의 연합도 가능하다는 것이죠.
안내
연합우주에 관해 좀 더 자세히 알고 싶어지셨다면, 〈연합우주(fediverse)와 ActivityPub 프로토콜 이해하기: 개발자를 위한 가이드〉라는 글도 읽어보시면 좋습니다.
과제
아직 연합우주를 경험해 본 적 없다면, 계정을 하나 만들어 봅시다. 계정을 만들기 위해서는 어떤 소프트웨어를 쓸 지 먼저 정해야 합니다. Mastodon과 Misskey는 일종의 X처럼 단문을 중심으로 한 SNS입니다. Pixelfed는 Instagram처럼 사진을 중심으로 한 SNS입니다. Meta의 Threads도 있습니다. 현재 읽고 계시는 이 글이 올라온 Hackers' Pub도 사실은 연합우주의 일부로서, 소프트웨어 개발자들을 위한 SNS입니다. 이 중 어떤 것을 선택하시든 서로 소통하는 데에는 문제가 없습니다.
만약 Mastodon이나 Misskey, Pixelfed를 선택하셨다면, 서버를 고르셔야 합니다. (물론, 서버를 직접 구축하시는 것도 괜찮습니다. 아마 많은 걸 배우실 수 있을 겁니다.) 무슨 서버를 골라야 할 지 모르시겠다면, Mastodon의 경우 silicon.moe 서버를, Misskey의 경우 stella.place 서버를, Pixelfed의 경우 chueok.pics 서버를 권합니다.
만약 Threads를 고르셨다면, 서버를 고를 필요가 없습니다. Threads는 설치형 소프트웨어가 아니라 Meta에서 운영하는 상용 서비스이기 때문입니다. 다만, 설정에 가셔서 페디버스 공유 설정을 켜 주셔야 합니다.
만약 Hackers' Pub을 고르셨다면, 역시 서버를 고를 필요가 없습니다. 단 하나의 서버만 있기 때문입니다. 다만, 초대장이 필요하므로 멘토에게 초대장을 요청하시기 바랍니다.
과제
연합우주 계정이 생기셨다면, 이제 친구를 사귀어야 합니다. 다른 멘티들에게 계정 주소를 물어보고 서로 팔로를 해 보세요. 멘토도 팔로해 보세요. (멘토도 맞팔 하겠습니다.) 멘토의 연합우주 계정 주소는 @[email protected]
입니다.
계정 주소로 팔로하는 방법은 소프트웨어마다 조금씩 다르지만, 대부분의 경우 검색창에 주소를 입력하면 해당 계정이 보입니다. 계정이 보인다면 팔로 버튼을 누르면 됩니다.
과제
생성한 계정으로 멘토의 계정인 @[email protected]
을 멘션하여 글을 써 주세요. 글 내용은 뭐든 좋습니다.
안내
이미 JavaScript와 TypeScript에 익숙하시다면 이 챕터는 넘기셔도 됩니다.
Fedify 프로젝트는 TypeScript로 작성되어 있습니다. TypeScript는 JavaScript에 정적 타입 검사를 추가한 언어로, 런타임에 버그를 발생시키는 잘못된 코드를 코드 작성 시에 미리 알 수 있도록 도와줍니다. TypeScript를 이해하려면 먼저 JavaScript를 이해해야 합니다.
아직 JavaScript에 익숙하지 않으신 분들은 《모던 JavaScript 튜토리얼》의 파트 1을 읽고 따라해 볼 것을 권합니다. 파트 2 이후의 내용은 Fedify 프로젝트에 기여하는 데에 크게 필요하지 않으므로 읽지 않으셔도 좋습니다.
JavaScript에는 어느 정도 익숙하지만 아직 TypeScript에 익숙하지 않으신 분들께는, 《The TypeScript Handbook》을 읽고 따라해 볼 것을 권합니다. 참고로 핸드북 페이지 우측 상단에 한국어 번역으로 가는 링크가 있습니다.
사실 오픈 소스 프로젝트에 기여하기 위해 반드시 그 프로젝트에서 쓰이는 언어를 속속들이 깊게 이해해야 하는 건 아닙니다. 기여할 때 필요한 만큼만 이해해도 좋으니, 어느 정도 언어 문법에 익숙해졌다 싶으면 실제 Fedify 코드를 읽는 것을 좀 더 추천합니다. 코드를 읽다가 이해가 안 되는 부분이 있으면 해당 언어 문법에 대해 따로 조사하는 식으로 익히시는 게 더 효율적입니다. 정 이해가 안 되는 경우에는 부담 없이 Fedify 프로젝트 Discord 서버의 #fedify-dev-ko 채널에서 질문해 주세요.
여러분은 웹 서버 애플리케이션을 만들 때 HTTP를 직접 구현하시나요? 아마도 대부분은 그렇지 않을 겁니다. 그러기엔 할 게 너무 많기 때문이죠. 대신 우리는 대부분 Express나 Next.js, Django 같은 웹 프레임워크를 이용해서 개발하게 됩니다.
마찬가지로, 연합우주 SNS 소프트웨어를 구현하려고 할 경우, ActivityPub을 바닥부터 구현하기에는 너무 할 게 많습니다. 따라서 개발을 쉽게 해 줄 프레임워크가 필요한데, 그게 바로 Fedify입니다.
어떤 오픈 소스 프로젝트든 간에, 해당 프로젝트에 기여하기 위해서는 먼저 그 소프트웨어를 써보고 기본적인 기능들을 숙지해야 합니다. 써보지도 않은 소프트웨어에 기여를 하는 것은 무리입니다. 여러분도 Fedify에 기여하기에 앞서 Fedify를 써 볼 필요가 있습니다.
Fedify는 연합우주 소프트웨어를 만드는 도구이므로, Fedify를 사용한다고 하면 연합우주 소프트웨어를 만들어 본다는 뜻이 됩니다. Fedify를 사용하여 작은 ActivityPub 서버 소프트웨어를 만들어 보세요. Fedify를 써 보면서 이해가 안 가거나 중간에 막히는 게 있다면 Discord 서버의 #fedify-help-ko 채널에서 질문하세요.
과제
Fedify를 배우고 써보는 가장 쉬운 방법은 튜토리얼을 읽고 따라하는 것입니다. Fedify 공식 튜토리얼의 한국어판인 〈나만의 연합우주 마이크로블로그 만들기〉를 읽고 그대로 따라서 진행하세요. 빠르면 하루, 느긋하게 하면 사흘 정도 걸립니다. 중간에 막히는 부분이 있으면 멘토에게 부담 없이 질문하세요.
주의
Windows 환경에서 작업하실 때는 (WSL을 사용하지 않는다면) Git의 core.autocrlf
설정을 꺼 주시기 바랍니다:
git config --global core.autocrlf false
안내
Fedify 프로젝트를 Windows 환경에서 개발할 수는 있지만, Linux나 macOS에 비해 편의성이 떨어지는 것도 사실입니다. 가능하면 WSL을 세팅하시고 WSL 안에서 작업하시는 걸 추천드립니다.
Fedify의 GitHub에 저장소가 올라가 있습니다. 해당 저장소를 각자 포크(fork)하신 뒤, 포크한 저장소를 로컬에 클론하세요. 클론하신 뒤, 클론한 로컬 저장소 안에 들어가 업스트림 저장소를 리모트로 추가하시는 것을 권합니다:
git remote add upstream https://github.com/fedify-dev/fedify.git
git fetch upstream
git pull --set-upstream upstream main
Fedify의 개발 환경 설정은 일반적인 JavaScript 프로젝트들에 비해 조금 복잡한 편입니다. Node.js 이외에도 Deno와 Bun 등 여러 런타임을 지원해야 하기 때문인데요. Fedify의 개발을 위해서는 다음 소프트웨어가 시스템에 모두 설치되어 있어야 합니다:
하나하나 직접 설치하셔도 좋습니다만, 귀찮으시다면 mise라는 개발 환경 설정 소프트웨어를 이용하는 것을 권합니다. mise는 정말 다양한 방법으로 설치가 가능합니다:
sudo pacman -S mise # Arch Linux
brew install mise # macOS
winget install jdx.mise # Windows
# 이 외에도 다양한 플랫폼 지원
설치하고 나서 PATH
환경 변수에 mise가 관리하는 소프트웨어들을 추가하도록 mise를 활성화해야 합니다. 활성화하는 방법은 어떤 셸을 사용하느냐에 따라 다릅니다:
echo 'eval "$(mise activate zsh)"' >> "${ZDOTDIR-$HOME}/.zshrc"
. "${ZDOTDIR-$HOME}/.zshrc"
echo 'eval "$(mise activate bash)"' >> ~/.bashrc
. ~/.bashrc
echo 'mise activate pwsh | Out-String | Invoke-Expression' >> $HOME\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
. $HOME\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
팁
대부분의 Linux의 경우 (또는 Windows의 WSL 안에서 작업하는 경우) 별 다른 설정을 하지 않았다면 bash를 쓰고 계실 것입니다. macOS를 쓰시고 별 다른 설정을 하지 않으셨다면 zsh을 쓰고 계실 것입니다. (WSL이 아닌) Windows의 경우에는 명령 프롬프트가 아닌 PowerShell 안에서 작업하셔야 합니다.
mise를 설치하셨다면, 로컬 저장소 안에 들어가 다음 명령어로 필요한 모든 소프트웨어를 한 번에 설치하실 수 있습니다:
mise install --yes
위 명령어를 실행하면 아래와 같이 Fedify 저장소 안에 들어있는 mise 설정 파일을 신뢰하겠냐는 프롬프트가 뜹니다. Yes를 선택해 주세요:
mise config files in ~/fedify are not trusted. Trust them?
Yes No All
←/→ toggle • y/n/a/enter submit
개발 환경이 잘 설정되었는지 확인하기 위해 Fedify의 전체 테스트 스위트를 실행해 봅시다. 첫 실행 시 통상 5분 정도 소요됩니다:
deno task test-all
Git 훅도 설치합니다:
deno task hooks:install
마지막으로 실제 편집 환경을 구성해야 합니다. 본 문서에서는 Visual Studio Code를 사용하는 것을 가정하겠습니다만, 같은 Visual Studio Code 계열인 Cursor나 Windsurf에서도 과정은 대동소이합니다.
경고
Visual Studio와 Visual Studio Code는 서로 전혀 다른 별개의 제품이니 주의하세요.
안내
여러분이 Emacs나 Vim의 독실한 신자라면 Visual Studio Code를 사용하고 싶지 않을 수 있습니다. 그런 경우, Deno의 공식 환경 설정 문서를 참고하여 Deno 랭귀지 서버를 설정해 주시기 바랍니다.
우선 로컬 저장소 안에서 code
명령어를 통해 Visual Studio Code를 띄웁니다:
code . # Visual Studio Code를 사용하는 경우
cursor . # Cursor를 사용하는 경우
windsurf . # Windsurf를 사용하는 경우
Visual Studio Code 창이 뜨면, 화면 가운데에 다음과 같은 프롬프트 창이 뜹니다:
프롬프트에서 예, 작성자를 신뢰합니다 버튼을 선택합니다. 그러면 오른쪽 아래에 다음과 같은 작은 프롬프트 창이 뜹니다:
프롬프트에서 설치 버튼을 선택합니다. 그러면 화면 가운데에 다음과 같은 프롬프트 창이 뜹니다:
프롬프트에서 게시자 신뢰 및 설치를 선택합니다. 그러면 Visual Studio Code에 Fedify 개발에 필요한 확장들이 설치되게 됩니다.
이로써 Fedify 기여에 필요한 기본적인 개발 환경 설정이 끝났습니다.
Fedify는 Deno, Node.js, Bun 등 다양한 JavaScript 런타임을 지원해야 합니다. 과연 JavaScript 런타임이 뭘까요?
JavaScript는 비교적 작은 언어입니다. 여러분이 process.exit()
같은 메서드를 활용하신 적 있다면, 이는 JavaScript 자체의 기능이 아니라 Node.js라는 특정한 JavaScript 런타임이 제공하는 기능입니다. 마찬가지로, 웹 브라우저에서 제공하는 DOM API 역시 JavaScript 자체의 기능이 아니라 웹 브라우저라는 (일종의) JavaScript 런타임이 제공하는 기능이라고 볼 수 있습니다.
JavaScript 런타임은 기본적으로 다음과 같은 역할을 합니다:
console.log()
, Node.js의 process.exit()
, 웹 브라우저의 window.alert()
같은 것들이 있습니다.앞서 설명한 모든 것을 속속들이 이해해야 할 필요는 없습니다. 중요한 것은, 같은 JavaScript라고 하더라도 어느 런타임에서 실행하냐에 따라 상당히 다른 방식으로 언어를 사용해야 한다는 점입니다.
그러면 Fedify 프로젝트는 다양한 JavaScript 런타임을 어떻게 동시에 다 지원할 수 있을까요? 크게 두 가지 방법이 있습니다:
Fedify 프로젝트는 두 가지 방법 모두 사용하고 있으며, 지원하는 모든 JavaScript 런타임에서 테스트 스위트를 실행해서 Fedify의 모든 기능이 각 JavaScript 런타임에서 잘 동작하는지를 검사합니다.
2025년 7월 현재, Fedify 프로젝트의 저장소는 다음과 같은 구조로 되어 있습니다:
여러분은 주로 fedify/ 디렉터리 및 cli/ 디렉터리에서 작업을 하게 될 것입니다.
여느 오픈 소스 프로젝트들이 그렇듯, Fedify 프로젝트도 나름의 코딩 컨벤션과 규칙들이 있습니다. 다행히 이들 대부분은 커밋하기 전에 기계적으로 검사가 가능합니다. 다음 명령어는 현재 프로젝트의 코드가 코딩 컨벤션을 잘 지키고 타입 오류가 없는지 검사합니다:
deno task check
다음 명령어는 코드를 코딩 컨벤션에 맞게 알아서 서식화합니다:
deno fmt
앞서 언급한 것처럼, 다음 명령어는 Fedify 프로젝트의 전체 테스트 스위트를 실행하고 필요한 검사를 수행합니다. 풀 리퀘스트를 올리기 전에 한 번 실행해 보십시오:
deno task test-all
@fedify/fedify 패키지를 수정했을 경우, 수정과 관련된 일부 테스트 코드만 빠르게 실행해 보고 싶을 수 있습니다. 그럴 때는 다음과 같이 -f @fedify/fedify
옵션과 --filter
옵션을 함께 활용해 보세요 (태스크 이름이 test-all
이 아니라 test
임에 주의하세요):
deno task -f @fedify/fedify test --filter verifyRequest
혹은 -f @fedify/fedify
옵션을 쓰는 대신 직접 fedify/ 디렉터리 안에서 deno task test
명령어를 사용하셔도 됩니다:
cd fedify/
deno task test --filter verifyRequest
참고로 --filter
옵션은 테스트 케이스 이름을 부분 문자열로 검색합니다. 이를테면, 다음과 같은 테스트가 있을 경우:
test("anArbitraryTest", () => {
// … 생략 …
});
다음과 같은 방식으로 모두 실행이 가능합니다:
deno task -f @fedify/fedify test --filter anArbitraryTest
deno task -f @fedify/fedify test --filter Arbitrary
deno task -f @fedify/fedify test --filter Test
앞서 설명한 deno task test
명령어는 Deno 런타임에서 테스트 스위트를 실행합니다. Node.js에서도 잘 돌아가나 확인하기 위해서는 Node.js 런타임에서도 테스트 스위트를 실행해 봐야 합니다. fedify/ 디렉터리 안쪽에서 pnpm test
명령어를 통해 Node.js에서 테스트 스위트를 돌려 볼 수 있습니다:
cd fedify/
pnpm test
일부 테스트만 빠르게 실행해 보고 싶을 경우 --test-name-pattern
옵션을 활용하세요:
pnpm test --test-name-pattern verifyRequest
Bun에서도 잘 돌아가는지 확인하려면 fedify/ 디렉터리 안쪽에서 pnpm test:bun
명령어를 사용하세요:
pnpm test:bun
일부 테스트만 빠르게 실행해 보고 싶을 경우 마찬가지로 --test-name-pattern
옵션을 활용하세요:
pnpm test:bun --test-name-pattern verifyRequest
마지막으로, Cloudflare Workers에서도 잘 돌아가는지 검사해야 합니다. 이 경우에는 pnpm test:cfworkers
명령어를 활용하세요:
pnpm test:cfworkers
일부 테스트만 빠르게 실행해 보고 싶을 경우 인자로 부분 문자열 키워드를 넘기면 됩니다:
pnpm test:cfworkers verifyRequest
사실, 앞서 설명했던 deno task test-all
명령어는 한 번에 Deno, Node.js, Bun, Cloudflare Workers 모두에서 테스트 스위트를 실행하는 명령어입니다.
안내
테스트 실행 시 실패하는 케이스가 있나요? 그것 자체가 기여할 좋은 기회입니다. 실패하는 테스트가 성공하도록 직접 코드를 고쳐서 풀 리퀘스트를 올리셔도 좋고, 이슈 트래커에 이슈를 만들기만 해도 좋은 기여가 됩니다.
@fedify/cli 패키지는 Fedify를 이용하여 ActivityPub 서버를 구현하는 개발자들을 위한 CLI 편의 도구로서, 주로 ActivityPub 서버 개발을 할 때 디버그나 테스트를 위해 필요한 기능들을 제공합니다. 라이브러리 패키지인 @fedify/fedify와 다르게 @fedify/cli는 패키지는 애플리케이션이기 때문에 코드를 수정한 뒤 바로 사용해 볼 수가 있습니다. 또한, 굳이 여러 런타임을 지원할 필요가 없기 때문에 Deno 환경만 신경쓰면 됩니다.
그런 이유로, @fedify/cli 패키지는 처음 기여하기에 좋습니다. 참고로 @fedif/cli는 CLI 애플리케이션 프레임워크로 Cliffy를 사용하고 있으니, 관련해서 궁금한 게 있다면 Cliffy 문서를 참고해 주세요.
중요
오픈 소스 프로젝트에서는 할 일을 자발적으로 찾아야 합니다. 직장이 아니므로, 다른 누군가가 할 일을 할당해 주지 않습니다. 사실, 오픈 소스에서 활발하게 활동하는 프로그래머들은 단순히 소프트웨어 개발 실력이 좋은 게 아니라, 적절한 할 일을 잘 찾아내는 능력이 있습니다. 이 때 “적절하다”는 것은 자신의 실력으로 해낼 수 있을 정도의 난이도면서도 프로젝트에 임팩트를 낼 수 있는 것을 뜻합니다.
대부분의 오픈 소스 프로젝트는 할 일을 이슈 트래커에서 관리합니다. Fedify 역시 GitHub에서 제공하는 이슈 트래커로 할 일들을 관리하고 있습니다. 특별한 이유가 없는 한, 이슈는 기본적으로 영어로 작성되거나, 적어도 영어가 병기되어야 합니다. 영어가 익숙치 않은 분들은 Kagi 번역 등을 활용하시면 될 것 같습니다. 언어 때문에 어려우신 분은 멘토에게 도움을 청하세요.
이슈는 크게 세 종류로 나뉩니다:
위의 분류와는 별개로, Fedify 이슈 트래커에서는 레이블을 구조화하여 활용하고 있습니다. 대부분의 레이블은 범례/레이블 이름 형식을 따르며, 대표적으로는 다음과 같은 것들이 있습니다:
안내
좀 더 자세히 확인하실 분은 전체 레이블 목록을 확인하세요.
여기서 여러분이 가장 주목하셔야 할 레이블은 바로 good first issue입니다. 해당 레이블이 붙은 이슈는 처음 기여하는 사람에게 적합하기 때문에, 여러분의 첫 기여 때 할 일을 찾을 때 도움이 됩니다. 이슈들을 찬찬히 읽어보시고 해 볼 만한 일감을 고르세요. 이슈를 읽어도 이해가 안 될 경우에는 댓글로 질문을 남기거나 멘토에게 질문하세요.
기여해 볼 이슈를 찾으셨다면, 해당 이슈를 이미 다른 사람이 진행중인지 확인하세요. 아무도 진행하고 있지 않다면 진행하겠다는 댓글을 이슈에 달아주세요.
과제
처음 기여할 이슈를 찾아 이슈에 댓글을 달아주세요. 이슈를 못 찾겠다면 멘토에게 도움을 요청하세요. 멘토가 기여할 만한 일을 함께 찾아줄 수 있습니다.
안내
굳이 이슈 트래커에 이미 있는 이슈 중에서만 고를 필요는 없습니다. Fedify를 써 보면서 개선할 부분을 발견하셨다면, 그걸 이슈로 만들어서 직접 해결하셔도 좋습니다. 사실, 오픈 소스의 많은 이슈들이 이슈를 제기한 사람에 의해 해결됩니다.
본 문서에서 다루지 못한 내용도 많이 있을 것입니다. 아래 문서들은 부족한 부분을 좀 더 보충해 줄 수 있습니다:
본 문서를 읽다가 혹은 읽고 나서도 궁금한 점이 있다면 얼마든지 멘토에게 질문해 주세요. Discord 서버에서 질문하셔도 좋고, GitHub Discussions에 질문 글을 올리셔도 좋습니다.
#Fedify has moved to a monorepo structure with unified versioning across all packages (@fedify/fedify
, @fedify/cli
, database adapters & framework integrations).
All packages now release together, making dependency management much simpler!
#Fedify has moved to a monorepo structure with unified versioning across all packages (@fedify/fedify
, @fedify/cli
, database adapters & framework integrations).
All packages now release together, making dependency management much simpler!
#Fedify has moved to a monorepo structure with unified versioning across all packages (@fedify/fedify
, @fedify/cli
, database adapters & framework integrations).
All packages now release together, making dependency management much simpler!
#Fedify has moved to a monorepo structure with unified versioning across all packages (@fedify/fedify
, @fedify/cli
, database adapters & framework integrations).
All packages now release together, making dependency management much simpler!
【OSC京都で #Fediverse に関連したセミナーを開催します!】
2025年8月3日(日)の13:00〜 オープンソースカンファレンス京都 #osckyoto で「分散型SNSユーザー有志」として、
「Fediverseのつくりかた 〜開発者・管理者たちの現場から〜」
と題してセミナー講演を行います!
登壇者として私のほか、
#fedibird 運営者の @noellabo さん
#Fedify #Hollo
等の開発者である @hongminhee さん
京都のMastodon地域サーバー #マストどす 管理人の @7_nana さん
をお呼びして開催します。
ActivityPubを中心としたFediverseの今が知れるセミナーです。ぜひご参加ください!
会場:KRP ルーム2B(2階)
日時:2025年8月3日(日)13:00〜
参加費:無料
セミナー詳細:
https://event.ospn.jp/osc2025-kyoto/session/2211664
【OSC京都で #Fediverse に関連したセミナーを開催します!】
2025年8月3日(日)の13:00〜 オープンソースカンファレンス京都 #osckyoto で「分散型SNSユーザー有志」として、
「Fediverseのつくりかた 〜開発者・管理者たちの現場から〜」
と題してセミナー講演を行います!
登壇者として私のほか、
#fedibird 運営者の @noellabo さん
#Fedify #Hollo
等の開発者である @hongminhee さん
京都のMastodon地域サーバー #マストどす 管理人の @7_nana さん
をお呼びして開催します。
ActivityPubを中心としたFediverseの今が知れるセミナーです。ぜひご参加ください!
会場:KRP ルーム2B(2階)
日時:2025年8月3日(日)13:00〜
参加費:無料
セミナー詳細:
https://event.ospn.jp/osc2025-kyoto/session/2211664
As the maintainer of #Fedify, I'd be grateful for your support to help keep the project sustainable!
https://hollo.social/@fedify/0194b112-b604-7d03-84e0-4faaf4ab46cd
🎉 Excited to announce that #Fedify is now on Open Collective! Support the project's development starting at:
Your support will help us maintain and improve Fedify. Check it out here:
https://opencollective.com/fedify
As the maintainer of #Fedify, I'd be grateful for your support to help keep the project sustainable!
https://hollo.social/@fedify/0194b112-b604-7d03-84e0-4faaf4ab46cd
🎉 Excited to announce that #Fedify is now on Open Collective! Support the project's development starting at:
Your support will help us maintain and improve Fedify. Check it out here:
https://opencollective.com/fedify
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
We're pleased to share that Encyclia has joined our success stories.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
Learn more about Encyclia at https://encyclia.pub/. 📚
We're pleased to share that Encyclia has joined our success stories.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
Learn more about Encyclia at https://encyclia.pub/. 📚
We're pleased to share that Encyclia has joined our success stories.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
Learn more about Encyclia at https://encyclia.pub/. 📚
We're pleased to share that Encyclia has joined our success stories.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
Learn more about Encyclia at https://encyclia.pub/. 📚
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial
property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial
is set to true
, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue
— utilizes Deno KV's automatic retry with exponential backoffWorkersMessageQueue
— leverages Cloudflare Queues' automatic retry and dead-letter queue featuresAmqpMessageQueue
— can now be configured to use AMQP broker's native retry mechanismsThe InProcessMessageQueue
continues to use Fedify's internal retry mechanism, while ParallelMessageQueue
inherits the retry behavior from its wrapped queue.
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial
option to AmqpMessageQueueOptions
, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
The new FederationOptions.firstKnock
option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial
property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial
is set to true
, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue
— utilizes Deno KV's automatic retry with exponential backoffWorkersMessageQueue
— leverages Cloudflare Queues' automatic retry and dead-letter queue featuresAmqpMessageQueue
— can now be configured to use AMQP broker's native retry mechanismsThe InProcessMessageQueue
continues to use Fedify's internal retry mechanism, while ParallelMessageQueue
inherits the retry behavior from its wrapped queue.
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial
option to AmqpMessageQueueOptions
, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
The new FederationOptions.firstKnock
option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial
property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial
is set to true
, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue
— utilizes Deno KV's automatic retry with exponential backoffWorkersMessageQueue
— leverages Cloudflare Queues' automatic retry and dead-letter queue featuresAmqpMessageQueue
— can now be configured to use AMQP broker's native retry mechanismsThe InProcessMessageQueue
continues to use Fedify's internal retry mechanism, while ParallelMessageQueue
inherits the retry behavior from its wrapped queue.
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial
option to AmqpMessageQueueOptions
, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
The new FederationOptions.firstKnock
option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial
property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial
is set to true
, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue
— utilizes Deno KV's automatic retry with exponential backoffWorkersMessageQueue
— leverages Cloudflare Queues' automatic retry and dead-letter queue featuresAmqpMessageQueue
— can now be configured to use AMQP broker's native retry mechanismsThe InProcessMessageQueue
continues to use Fedify's internal retry mechanism, while ParallelMessageQueue
inherits the retry behavior from its wrapped queue.
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial
option to AmqpMessageQueueOptions
, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
The new FederationOptions.firstKnock
option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces first-class support for Cloudflare Workers, enabling #serverless deployment of #ActivityPub applications at the edge.
WorkersKvStore
: A key–value store implementation using Cloudflare's KV API for persistent storage in Workers environmentsWorkersMessageQueue
: A message queue implementation leveraging Cloudflare Queues for reliable message processingqueue()
methodFederation.processQueuedTask()
methodFor a complete working example, see the Cloudflare Workers example in the Fedify repository.
Fedify 1.6 introduces the FederationBuilder
class and createFederationBuilder()
function to support deferred federation instantiation. This pattern provides several benefits:
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Fedify 1.6 implements the official HTTP Message Signatures standard (RFC 9421) specification, the final revision of the HTTP Signatures specification.
To ensure maximum compatibility across the fediverse, Fedify 1.6 introduces an intelligent double-knocking mechanism:
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
The new Context.lookupWebFinger()
method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject()
method.
The new Context.clone()
method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
For new deployments, consider leveraging Cloudflare Workers support for:
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
#fedidev #RFC9421 #HTTPSignatures #HTTPMessageSignatures #CloudflareWorkers
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces first-class support for Cloudflare Workers, enabling #serverless deployment of #ActivityPub applications at the edge.
WorkersKvStore
: A key–value store implementation using Cloudflare's KV API for persistent storage in Workers environmentsWorkersMessageQueue
: A message queue implementation leveraging Cloudflare Queues for reliable message processingqueue()
methodFederation.processQueuedTask()
methodFor a complete working example, see the Cloudflare Workers example in the Fedify repository.
Fedify 1.6 introduces the FederationBuilder
class and createFederationBuilder()
function to support deferred federation instantiation. This pattern provides several benefits:
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Fedify 1.6 implements the official HTTP Message Signatures standard (RFC 9421) specification, the final revision of the HTTP Signatures specification.
To ensure maximum compatibility across the fediverse, Fedify 1.6 introduces an intelligent double-knocking mechanism:
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
The new Context.lookupWebFinger()
method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject()
method.
The new Context.clone()
method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
For new deployments, consider leveraging Cloudflare Workers support for:
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
#fedidev #RFC9421 #HTTPSignatures #HTTPMessageSignatures #CloudflareWorkers
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces first-class support for Cloudflare Workers, enabling #serverless deployment of #ActivityPub applications at the edge.
WorkersKvStore
: A key–value store implementation using Cloudflare's KV API for persistent storage in Workers environmentsWorkersMessageQueue
: A message queue implementation leveraging Cloudflare Queues for reliable message processingqueue()
methodFederation.processQueuedTask()
methodFor a complete working example, see the Cloudflare Workers example in the Fedify repository.
Fedify 1.6 introduces the FederationBuilder
class and createFederationBuilder()
function to support deferred federation instantiation. This pattern provides several benefits:
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Fedify 1.6 implements the official HTTP Message Signatures standard (RFC 9421) specification, the final revision of the HTTP Signatures specification.
To ensure maximum compatibility across the fediverse, Fedify 1.6 introduces an intelligent double-knocking mechanism:
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
The new Context.lookupWebFinger()
method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject()
method.
The new Context.clone()
method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
For new deployments, consider leveraging Cloudflare Workers support for:
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
#fedidev #RFC9421 #HTTPSignatures #HTTPMessageSignatures #CloudflareWorkers
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces first-class support for Cloudflare Workers, enabling #serverless deployment of #ActivityPub applications at the edge.
WorkersKvStore
: A key–value store implementation using Cloudflare's KV API for persistent storage in Workers environmentsWorkersMessageQueue
: A message queue implementation leveraging Cloudflare Queues for reliable message processingqueue()
methodFederation.processQueuedTask()
methodFor a complete working example, see the Cloudflare Workers example in the Fedify repository.
Fedify 1.6 introduces the FederationBuilder
class and createFederationBuilder()
function to support deferred federation instantiation. This pattern provides several benefits:
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Fedify 1.6 implements the official HTTP Message Signatures standard (RFC 9421) specification, the final revision of the HTTP Signatures specification.
To ensure maximum compatibility across the fediverse, Fedify 1.6 introduces an intelligent double-knocking mechanism:
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
The new Context.lookupWebFinger()
method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject()
method.
The new Context.clone()
method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
For new deployments, consider leveraging Cloudflare Workers support for:
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
#fedidev #RFC9421 #HTTPSignatures #HTTPMessageSignatures #CloudflareWorkers
Did you know? #Fedify provides #documentation optimized for LLMs through the llms.txt standard.
Available endpoints:
Useful for training #AI assistants on #ActivityPub/#fediverse development, building documentation chatbots, or #LLM-powered dev tools.
Did you know? #Fedify provides #documentation optimized for LLMs through the llms.txt standard.
Available endpoints:
Useful for training #AI assistants on #ActivityPub/#fediverse development, building documentation chatbots, or #LLM-powered dev tools.
Did you know? #Fedify provides #documentation optimized for LLMs through the llms.txt standard.
Available endpoints:
Useful for training #AI assistants on #ActivityPub/#fediverse development, building documentation chatbots, or #LLM-powered dev tools.
Hackers' Pub and hollo.social are the instances currently serving as testbeds for #Fedify. 😂
Hackers' Pub and hollo.social are the instances currently serving as testbeds for #Fedify. 😂
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare #Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#ActivityPub #fedidev #fediverse #RFC9421 #CloudflareWorkers
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare #Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#ActivityPub #fedidev #fediverse #RFC9421 #CloudflareWorkers
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare #Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#ActivityPub #fedidev #fediverse #RFC9421 #CloudflareWorkers
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare #Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#ActivityPub #fedidev #fediverse #RFC9421 #CloudflareWorkers
If you're on the fence about which driver to choose for #Fedify's message queue, here's a benchmark that just came out. In addition to no queue, we compare 5 drivers, for a total of 11 setups:
InProcessMessageQueue
DenoKvMessageQueue
RedisMessageQueue
PostgresMessageQueue
AmqpMessageQueue
InProcessMessageQueue
× 4DenoKvMessageQueue
× 4RedisMessageQueue
× 4PostgresMessageQueue
× 4AmqpMessageQueue
× 4Curious to see the results? Check out the GitHub repository!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
@thisismissem Here's the benchmark, and while it contains some questionable results, the overall conclusion is as following:
• Response times are much faster with queues than without.
• Overall throughput is better without queues.
• However, some queue setups can achieve throughput close to that of no queue.
This benchmark assumes communication within a single node, so the effect of queues may be greater in real-world networks.
If you're on the fence about which driver to choose for #Fedify's message queue, here's a benchmark that just came out. In addition to no queue, we compare 5 drivers, for a total of 11 setups:
InProcessMessageQueue
DenoKvMessageQueue
RedisMessageQueue
PostgresMessageQueue
AmqpMessageQueue
InProcessMessageQueue
× 4DenoKvMessageQueue
× 4RedisMessageQueue
× 4PostgresMessageQueue
× 4AmqpMessageQueue
× 4Curious to see the results? Check out the GitHub repository!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
@thisismissem Here's the benchmark, and while it contains some questionable results, the overall conclusion is as following:
• Response times are much faster with queues than without.
• Overall throughput is better without queues.
• However, some queue setups can achieve throughput close to that of no queue.
This benchmark assumes communication within a single node, so the effect of queues may be greater in real-world networks.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
🎉 #Cloudflare #Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
What's included:
@fedify/fedify/x/cfworkers
module with WorkersKvStore
and WorkersMessageQueue
Try it now: Available in the development release v1.6.1-dev.876+7b07d213:
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
🎉 #Cloudflare #Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
What's included:
@fedify/fedify/x/cfworkers
module with WorkersKvStore
and WorkersMessageQueue
Try it now: Available in the development release v1.6.1-dev.876+7b07d213:
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
🎉 #Cloudflare #Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
What's included:
@fedify/fedify/x/cfworkers
module with WorkersKvStore
and WorkersMessageQueue
Try it now: Available in the development release v1.6.1-dev.876+7b07d213:
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
🎉 #Cloudflare #Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
What's included:
@fedify/fedify/x/cfworkers
module with WorkersKvStore
and WorkersMessageQueue
Try it now: Available in the development release v1.6.1-dev.876+7b07d213:
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorial Creating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
I deployed my first #Fedify application on Cloudflare Workers and saw it running smoothly. Now all that's left is the documentation!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorial Creating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorial Creating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
ActivityPubサーバーを構築してみたいけれど、どこから始めればよいかわからない方には、Fedifyのチュートリアル『自分だけのフェディバースのマイクロブログを作ろう!』をおすすめします。包括的でステップバイステップのガイドで、完全に機能する連合型アプリケーションの構築方法を丁寧に解説しています。フェディバースに飛び込みたい開発者にぴったりです!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
ActivityPubサーバーを構築してみたいけれど、どこから始めればよいかわからない方には、Fedifyのチュートリアル『自分だけのフェディバースのマイクロブログを作ろう!』をおすすめします。包括的でステップバイステップのガイドで、完全に機能する連合型アプリケーションの構築方法を丁寧に解説しています。フェディバースに飛び込みたい開発者にぴったりです!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
ActivityPubサーバーを構築してみたいけれど、どこから始めればよいかわからない方には、Fedifyのチュートリアル『自分だけのフェディバースのマイクロブログを作ろう!』をおすすめします。包括的でステップバイステップのガイドで、完全に機能する連合型アプリケーションの構築方法を丁寧に解説しています。フェディバースに飛び込みたい開発者にぴったりです!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
ActivityPubサーバーを構築してみたいけれど、どこから始めればよいかわからない方には、Fedifyのチュートリアル『自分だけのフェディバースのマイクロブログを作ろう!』をおすすめします。包括的でステップバイステップのガイドで、完全に機能する連合型アプリケーションの構築方法を丁寧に解説しています。フェディバースに飛び込みたい開発者にぴったりです!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
ActivityPubサーバーを構築してみたいけれど、どこから始めればよいかわからない方には、Fedifyのチュートリアル『自分だけのフェディバースのマイクロブログを作ろう!』をおすすめします。包括的でステップバイステップのガイドで、完全に機能する連合型アプリケーションの構築方法を丁寧に解説しています。フェディバースに飛び込みたい開発者にぴったりです!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorial Creating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorial Creating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorial Creating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
We're planning to reorganize our #GitHub labels to better reflect #Fedify's project structure! 🏷️
Currently using GitHub's default labels, but we want something more tailored to our needs—like component-specific labels (vocab, federation, actor, etc.), runtime tags (Deno/Node/Bun), and #ActivityPub compatibility tracking.
The proposal includes hierarchical labeling with categories like:
type/
for bug, feature, documentationcomponent/
for different parts of Fedifyactivitypub/
for interop issues with Mastodon, Misskey, etc.We'd love your thoughts! What labels would be most helpful for contributors and maintainers?
Check out the full proposal: https://github.com/fedify-dev/fedify/issues/238.
We're planning to reorganize our #GitHub labels to better reflect #Fedify's project structure! 🏷️
Currently using GitHub's default labels, but we want something more tailored to our needs—like component-specific labels (vocab, federation, actor, etc.), runtime tags (Deno/Node/Bun), and #ActivityPub compatibility tracking.
The proposal includes hierarchical labeling with categories like:
type/
for bug, feature, documentationcomponent/
for different parts of Fedifyactivitypub/
for interop issues with Mastodon, Misskey, etc.We'd love your thoughts! What labels would be most helpful for contributors and maintainers?
Check out the full proposal: https://github.com/fedify-dev/fedify/issues/238.
While #Fedify's #Vocabulary API provides comprehensive support for #ActivityPub and major vendor extensions, its code-generation approach makes runtime extensions challenging. However, the project welcomes contributions to expand the supported types and properties.
Fedify accepts vocabulary contributions when they meet any of these criteria:
Contributing new vocabulary is straightforward. The vocabulary definitions live in YAML files within the fedify/vocab/ directory. To add a new type, create a new .yaml file. To add properties to existing types, extend the properties
section in the relevant .yaml file.
This approach ensures Fedify's vocabulary coverage grows with the fediverse ecosystem while maintaining type safety and comprehensive documentation. If you're working with custom ActivityPub extensions, consider contributing them upstream to benefit the entire community.
For detailed guidance on the contribution process, see the Extending the vocabulary section in Fedify's docs.
While #Fedify's #Vocabulary API provides comprehensive support for #ActivityPub and major vendor extensions, its code-generation approach makes runtime extensions challenging. However, the project welcomes contributions to expand the supported types and properties.
Fedify accepts vocabulary contributions when they meet any of these criteria:
Contributing new vocabulary is straightforward. The vocabulary definitions live in YAML files within the fedify/vocab/ directory. To add a new type, create a new .yaml file. To add properties to existing types, extend the properties
section in the relevant .yaml file.
This approach ensures Fedify's vocabulary coverage grows with the fediverse ecosystem while maintaining type safety and comprehensive documentation. If you're working with custom ActivityPub extensions, consider contributing them upstream to benefit the entire community.
For detailed guidance on the contribution process, see the Extending the vocabulary section in Fedify's docs.
This patch for @vite is blocking #Fedify's Cloudflare Workers support. They say it'll be included in #Vite 7, but I can't wait that long, so I'm not sure what to do… 🤔
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
We've just submitted an #application to the Sovereign Tech Fund for the #Fedify project! Hoping to further develop and enhance the framework for a more robust federated web.
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
We've just submitted an #application to the Sovereign Tech Fund for the #Fedify project! Hoping to further develop and enhance the framework for a more robust federated web.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
ActivityPub 구현을 고려 중이시거나, Fedify 프로젝트와 협력하고 싶으시다면 연락 주세요:
귀사의 요구사항과 목표에 맞는 맞춤형 협력 방안을 함께 모색하겠습니다.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
ActivityPub 구현을 고려 중이시거나, Fedify 프로젝트와 협력하고 싶으시다면 연락 주세요:
귀사의 요구사항과 목표에 맞는 맞춤형 협력 방안을 함께 모색하겠습니다.
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
Various projects are already leveraging Fedify:
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
We're excited to explore customized collaboration opportunities that align with your requirements and goals.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
ActivityPub 구현을 고려 중이시거나, Fedify 프로젝트와 협력하고 싶으시다면 연락 주세요:
귀사의 요구사항과 목표에 맞는 맞춤형 협력 방안을 함께 모색하겠습니다.
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
Various projects are already leveraging Fedify:
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
We're excited to explore customized collaboration opportunities that align with your requirements and goals.
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
Various projects are already leveraging Fedify:
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
We're excited to explore customized collaboration opportunities that align with your requirements and goals.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
ActivityPub 구현을 고려 중이시거나, Fedify 프로젝트와 협력하고 싶으시다면 연락 주세요:
귀사의 요구사항과 목표에 맞는 맞춤형 협력 방안을 함께 모색하겠습니다.
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
For those interested in supporting #Fedify's development, we do have an Open Collective page where community #sponsorship is welcome.
Even small contributions help sustain development and show there's interest in open source #ActivityPub tools. Thanks to our existing sponsors who've already been helping move the project forward!
The goal remains the same: make building federated applications more accessible to developers so the #fediverse can continue to grow and thrive.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
For those interested in supporting #Fedify's development, we do have an Open Collective page where community #sponsorship is welcome.
Even small contributions help sustain development and show there's interest in open source #ActivityPub tools. Thanks to our existing sponsors who've already been helping move the project forward!
The goal remains the same: make building federated applications more accessible to developers so the #fediverse can continue to grow and thrive.
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
For those interested in supporting #Fedify's development, we do have an Open Collective page where community #sponsorship is welcome.
Even small contributions help sustain development and show there's interest in open source #ActivityPub tools. Thanks to our existing sponsors who've already been helping move the project forward!
The goal remains the same: make building federated applications more accessible to developers so the #fediverse can continue to grow and thrive.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
Good news! We've officially added #Cloudflare #Workers support to the #Fedify roadmap. We've created a detailed issue to track our implementation plan: https://github.com/fedify-dev/fedify/issues/233.
The effort will be tackled in phases, including compatibility assessment, core adaptations for Workers' environment, KV store and message queue implementations, and finally integration with Cloudflare's ecosystem. This will be a substantial project that we'll break down into several sub-issues.
If you're interested in contributing to any specific aspect of Workers support, please comment on the main issue to coordinate efforts.
Good news! We've officially added #Cloudflare #Workers support to the #Fedify roadmap. We've created a detailed issue to track our implementation plan: https://github.com/fedify-dev/fedify/issues/233.
The effort will be tackled in phases, including compatibility assessment, core adaptations for Workers' environment, KV store and message queue implementations, and finally integration with Cloudflare's ecosystem. This will be a substantial project that we'll break down into several sub-issues.
If you're interested in contributing to any specific aspect of Workers support, please comment on the main issue to coordinate efforts.
Good news! We've officially added #Cloudflare #Workers support to the #Fedify roadmap. We've created a detailed issue to track our implementation plan: https://github.com/fedify-dev/fedify/issues/233.
The effort will be tackled in phases, including compatibility assessment, core adaptations for Workers' environment, KV store and message queue implementations, and finally integration with Cloudflare's ecosystem. This will be a substantial project that we'll break down into several sub-issues.
If you're interested in contributing to any specific aspect of Workers support, please comment on the main issue to coordinate efforts.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
Just wrote the Why Fedify? section in the #Fedify docs.
Just wrote the Why Fedify? section in the #Fedify docs.
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
Okay, I've just deployed a bleeding edge #Fedify, which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
Okay, I've just deployed a bleeding edge #Fedify, which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
Okay, I've just deployed a bleeding edge #Fedify, which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)
Looking for #ActivityPub implementations with #RFC9421 support! 🔍
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
Looking for #ActivityPub implementations with #RFC9421 support! 🔍
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
Looking for #ActivityPub implementations with #RFC9421 support! 🔍
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
Looking for #ActivityPub implementations with #RFC9421 support! 🔍
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
We're pleased to announce that #Fedify has been included in the Nivenly Fediverse Security Fund program!
The @nivenly Foundation has launched a security bounty fund to support contributors who identify and help fix #security vulnerabilities in popular #fediverse software. Both Fedify and @hollo are among the selected projects that meet their responsible security disclosure requirements.
This program will run from April–September 2025, with bounties of $250–$500 USD for high and critical security vulnerabilities.
We're honored to be recognized alongside other established fediverse projects like Mastodon, Misskey, and Lemmy. This further encourages our commitment to maintaining strong security practices.
If you're interested in contributing to Fedify's security, please follow our responsible disclosure process outlined in our SECURITY.md file.
Learn more about the program:
https://nivenly.org/blog/2025/04/01/nivenly-fediverse-security-fund/
We're pleased to announce that #Fedify has been included in the Nivenly Fediverse Security Fund program!
The @nivenly Foundation has launched a security bounty fund to support contributors who identify and help fix #security vulnerabilities in popular #fediverse software. Both Fedify and @hollo are among the selected projects that meet their responsible security disclosure requirements.
This program will run from April–September 2025, with bounties of $250–$500 USD for high and critical security vulnerabilities.
We're honored to be recognized alongside other established fediverse projects like Mastodon, Misskey, and Lemmy. This further encourages our commitment to maintaining strong security practices.
If you're interested in contributing to Fedify's security, please follow our responsible disclosure process outlined in our SECURITY.md file.
Learn more about the program:
https://nivenly.org/blog/2025/04/01/nivenly-fediverse-security-fund/
We're pleased to announce that #Fedify has been included in the Nivenly Fediverse Security Fund program!
The @nivenly Foundation has launched a security bounty fund to support contributors who identify and help fix #security vulnerabilities in popular #fediverse software. Both Fedify and @hollo are among the selected projects that meet their responsible security disclosure requirements.
This program will run from April–September 2025, with bounties of $250–$500 USD for high and critical security vulnerabilities.
We're honored to be recognized alongside other established fediverse projects like Mastodon, Misskey, and Lemmy. This further encourages our commitment to maintaining strong security practices.
If you're interested in contributing to Fedify's security, please follow our responsible disclosure process outlined in our SECURITY.md file.
Learn more about the program:
https://nivenly.org/blog/2025/04/01/nivenly-fediverse-security-fund/
素晴らしい
新しい分散/連合型SNS「Pulsate」を開発している - /dev/sdR2 https://laminne.hatenablog.jp/entry/2025/01/17/190000
素晴らしい
新しい分散/連合型SNS「Pulsate」を開発している - /dev/sdR2 https://laminne.hatenablog.jp/entry/2025/01/17/190000
What to learn more about the #fediverse and #ActivityPub? This tutorial (https://fedify.dev/tutorial/microblog) from @fedify is a really good starter. It explains how to implement a really simple #federated server and see how communication exchange are done with AP.
What to learn more about the #fediverse and #ActivityPub? This tutorial (https://fedify.dev/tutorial/microblog) from @fedify is a really good starter. It explains how to implement a really simple #federated server and see how communication exchange are done with AP.
What to learn more about the #fediverse and #ActivityPub? This tutorial (https://fedify.dev/tutorial/microblog) from @fedify is a really good starter. It explains how to implement a really simple #federated server and see how communication exchange are done with AP.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
自分だけのActivityPubを作りたいけど、何から始めれば良いのか分からないですか?Fedifyの公式チュートリアル「自分だけのフェディバースのマイクロブログを作ろう!」を読んでみてください!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
자신만의 #ActivityPub 구현을 하고 싶지만, 어디서 시작해야 할지 모르겠나요? #Fedify 공식 튜토리얼인 〈나만의 연합우주 마이크로블로그 만들기〉를 읽고 따라해 보세요!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
혹시 모르고 계셨다면, Fedify는 Discord와 Matrix 커뮤니티를 운영하고 있습니다. 이곳에서 도움을 받거나, 기능에 대해 논의하거나, ActivityPub와 연합 소셜 네트워크에 대해 대화를 나눌 수 있습니다.
여러분의 선호도에 따라 어느 커뮤니티든 참여해 주세요. 두 채널 모두 Fedify와 연합 관련 주제에 대한 활발한 논의가 이루어지고 있습니다.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
もしかしたらご存じないかもしれませんが、Fedifyには DiscordとMatrixのコミュニティがあります。ここでは、サポートを受けたり、機能について議論したり、ActivityPubやフェデレーテッドソーシャルネットワークについて話し合うことができます。
お好みのコミュニティにご参加ください。どちらのチャンネルでも、Fedifyやフェデレーション関連のトピックについて活発な議論が行われています。
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
혹시 모르고 계셨다면, Fedify는 Discord와 Matrix 커뮤니티를 운영하고 있습니다. 이곳에서 도움을 받거나, 기능에 대해 논의하거나, ActivityPub와 연합 소셜 네트워크에 대해 대화를 나눌 수 있습니다.
여러분의 선호도에 따라 어느 커뮤니티든 참여해 주세요. 두 채널 모두 Fedify와 연합 관련 주제에 대한 활발한 논의가 이루어지고 있습니다.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
もしかしたらご存じないかもしれませんが、Fedifyには DiscordとMatrixのコミュニティがあります。ここでは、サポートを受けたり、機能について議論したり、ActivityPubやフェデレーテッドソーシャルネットワークについて話し合うことができます。
お好みのコミュニティにご参加ください。どちらのチャンネルでも、Fedifyやフェデレーション関連のトピックについて活発な議論が行われています。
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
혹시 모르고 계셨다면, Fedify는 Discord와 Matrix 커뮤니티를 운영하고 있습니다. 이곳에서 도움을 받거나, 기능에 대해 논의하거나, ActivityPub와 연합 소셜 네트워크에 대해 대화를 나눌 수 있습니다.
여러분의 선호도에 따라 어느 커뮤니티든 참여해 주세요. 두 채널 모두 Fedify와 연합 관련 주제에 대한 활발한 논의가 이루어지고 있습니다.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
自分だけのActivityPubを作りたいけど、何から始めれば良いのか分からないですか?Fedifyの公式チュートリアル「自分だけのフェディバースのマイクロブログを作ろう!」を読んでみてください!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
자신만의 #ActivityPub 구현을 하고 싶지만, 어디서 시작해야 할지 모르겠나요? #Fedify 공식 튜토리얼인 〈나만의 연합우주 마이크로블로그 만들기〉를 읽고 따라해 보세요!
Want to build your own #ActivityPub implementation, but don't know where to start? Read and follow #Fedify's official tutorial, Creating your own federated microblog, and get started!
📣 Exciting news! Fedify CLI is now available via Homebrew!
If you're using #Homebrew on macOS or #Linuxbrew on Linux, you can now install our CLI toolchain with a simple command:
brew install fedify
This makes it even easier to get started with building your federated server app. Try it out and let us know what you think!
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder
.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder
pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// inbox.ts
import { builder } from "./builder.ts";
import { Follow } from "@fedify/fedify";
builder.setInboxListeners("/users/{handle}/inbox", "/inbox")
.on(Follow, async (ctx, follow) => {
// Follow handling
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation
instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/[email protected]+1206cb01
# Node.js
npm add @fedify/[email protected]
# Bun
bun add @fedify/[email protected]
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder
.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder
pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// inbox.ts
import { builder } from "./builder.ts";
import { Follow } from "@fedify/fedify";
builder.setInboxListeners("/users/{handle}/inbox", "/inbox")
.on(Follow, async (ctx, follow) => {
// Follow handling
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation
instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/[email protected]+1206cb01
# Node.js
npm add @fedify/[email protected]
# Bun
bun add @fedify/[email protected]
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder
.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder
pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// inbox.ts
import { builder } from "./builder.ts";
import { Follow } from "@fedify/fedify";
builder.setInboxListeners("/users/{handle}/inbox", "/inbox")
.on(Follow, async (ctx, follow) => {
// Follow handling
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation
instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/[email protected]+1206cb01
# Node.js
npm add @fedify/[email protected]
# Bun
bun add @fedify/[email protected]
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder
.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder
pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// inbox.ts
import { builder } from "./builder.ts";
import { Follow } from "@fedify/fedify";
builder.setInboxListeners("/users/{handle}/inbox", "/inbox")
.on(Follow, async (ctx, follow) => {
// Follow handling
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation
instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/[email protected]+1206cb01
# Node.js
npm add @fedify/[email protected]
# Bun
bun add @fedify/[email protected]
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
もしかしたらご存じないかもしれませんが、Fedifyには DiscordとMatrixのコミュニティがあります。ここでは、サポートを受けたり、機能について議論したり、ActivityPubやフェデレーテッドソーシャルネットワークについて話し合うことができます。
お好みのコミュニティにご参加ください。どちらのチャンネルでも、Fedifyやフェデレーション関連のトピックについて活発な議論が行われています。
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
혹시 모르고 계셨다면, Fedify는 Discord와 Matrix 커뮤니티를 운영하고 있습니다. 이곳에서 도움을 받거나, 기능에 대해 논의하거나, ActivityPub와 연합 소셜 네트워크에 대해 대화를 나눌 수 있습니다.
여러분의 선호도에 따라 어느 커뮤니티든 참여해 주세요. 두 채널 모두 Fedify와 연합 관련 주제에 대한 활발한 논의가 이루어지고 있습니다.
In case you weren't aware, #Fedify has both #Discord and #Matrix communities where you can get help, discuss features, or just chat about #ActivityPub and federated social networks.
Feel free to join either community based on your preference. Both channels have active discussions about Fedify and federation topics.
In case you weren't aware, #Fedify has both #Discord and #Matrix communities where you can get help, discuss features, or just chat about #ActivityPub and federated social networks.
Feel free to join either community based on your preference. Both channels have active discussions about Fedify and federation topics.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note
, Article
), profiles (Person
, Organization
), actions (Create
, Follow
, Like
, Announce
)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Note
objects mean the same thing regarding the name
property:// No name property
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"content": "…"
}
// Equivalent to:
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"name": [],
"content": "…"
}
content
property here:// Single value
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"content": "Hello"
}
// Equivalent to:
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"content": ["Hello"]
}
Announce
activities are semantically equivalent (assuming the URIs resolve correctly):{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Announce",
// Embedded objects:
"actor": {
"type": "Person",
"id": "http://sally.example.org/",
"name": "Sally"
},
"object": {
"type": "Arrive",
"id": "https://sally.example.com/arrive",
/* ... */
}
}
// Equivalent to:
{
"@context":
"https://www.w3.org/ns/activitystreams",
"type": "Announce",
// URI references:
"actor": "http://sally.example.org/",
"object": "https://sally.example.com/arrive"
}
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags
) always return arrays, functional properties (like content
) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()
) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger
capable of parsing resource queries (like acct:
URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self
link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher()
method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle()
or mapAlias()
callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actors
federation.setActorDispatcher(
"/users/{username}",
async (ctx, username) => { /* ... */ }
);
// Now GET /.well-known/webfinger?resource=acct:[email protected] just works!
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json
) but HTML for browsers (Accept: text/html
). Handling incoming activities at the inbox endpoint involves validating POST
requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox
, followers
, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch()
or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher()
and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners()
lets you define handlers per activity type (e.g., .on(Follow, ...)
), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()
); you provide logic to fetch a page of data, and Fedify constructs the correct Collection
or CollectionPage
with pagination.
// Define inbox handlers
federation.setInboxListeners("/inbox", "/users/{handle}/inbox")
.on(Follow, async (ctx, follow) => { /* Handle follow */ })
.on(Undo, async (ctx, undo) => { /* Handle undo */ });
// Define followers collection logic
federation.setFollowersDispatcher(
"/users/{handle}/followers",
async (ctx, handle, cursor) => { /* ... */ }
);
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue
abstraction. When configured (highly recommended), Context.sendActivity()
enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy
). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)
const federation = createFederation({
queue: new DenoKvMessageQueue(/* ... */),
// ...
});
// Sending is now reliable and non-blocking
await ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Securing an ActivityPub server is critical. You need to implement HTTP Signatures (draft-cavage-http-signatures-12) for server-to-server authentication—a complex process. You might also need Linked Data Signatures (LDS) or Object Integrity Proofs (OIP) based on FEP-8b32 for data integrity and compatibility. Managing cryptographic keys securely is essential. Lastly, fetching remote resources risks Server-Side Request Forgery (SSRF) if not validated properly.
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher
. It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformer
s to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher
.
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify
CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init
.
For debugging interactions and verifying data, fedify lookup
is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
$ fedify lookup @[email protected]
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)
Person {
id: URL "https://fedify-blog.deno.dev/users/fedify-example",
name: "Fedify Example Blog",
published: 2024-03-03T13:18:11.857Z, // Simplified timestamp
summary: "This blog is powered by Fedify, a fediverse server framework.",
url: URL "https://fedify-blog.deno.dev/",
preferredUsername: "fedify-example",
publicKey: CryptographicKey {
id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key",
owner: URL "https://fedify-blog.deno.dev/users/fedify-example",
publicKey: CryptoKey { /* ... CryptoKey details ... */ }
},
// ... other properties like inbox, outbox, followers, endpoints ...
}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox
. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox
✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/
✔ Sent follow request to @<some_test_account>@activitypub.academy.
╭───────────────┬─────────────────────────────────────────╮
│ Actor handle: │ i@<unique_id>.lhr.life │
├───────────────┼─────────────────────────────────────────┤
│ Actor URI: │ https://<unique_id>.lhr.life/i │
├───────────────┼─────────────────────────────────────────┤
│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │
├───────────────┼─────────────────────────────────────────┤
│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │
╰───────────────┴─────────────────────────────────────────╯
Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox
or Shared inbox
URI provided. When an activity arrives, fedify inbox
only prints a summary table to your console indicating that a request was received:
╭────────────────┬─────────────────────────────────────╮
│ Request #: │ 2 │
├────────────────┼─────────────────────────────────────┤
│ Activity type: │ Follow │
├────────────────┼─────────────────────────────────────┤
│ HTTP request: │ POST /i/inbox │
├────────────────┼─────────────────────────────────────┤
│ HTTP response: │ 202 │
├────────────────┼─────────────────────────────────────┤
│ Details │ https://<unique_id>.lhr.life/r/2 │
╰────────────────┴─────────────────────────────────────╯
Crucially, the detailed information about the received request—including the full headers (like Signature
), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox
. This web UI allows you to thoroughly inspect incoming activities during development.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel
can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name
.
Check out the Fedify tutorials and Fedify manual to learn more. Happy federating!
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note
, Article
), profiles (Person
, Organization
), actions (Create
, Follow
, Like
, Announce
)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Note
objects mean the same thing regarding the name
property:// No name property
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"content": "…"
}
// Equivalent to:
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"name": [],
"content": "…"
}
content
property here:// Single value
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"content": "Hello"
}
// Equivalent to:
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"content": ["Hello"]
}
Announce
activities are semantically equivalent (assuming the URIs resolve correctly):{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Announce",
// Embedded objects:
"actor": {
"type": "Person",
"id": "http://sally.example.org/",
"name": "Sally"
},
"object": {
"type": "Arrive",
"id": "https://sally.example.com/arrive",
/* ... */
}
}
// Equivalent to:
{
"@context":
"https://www.w3.org/ns/activitystreams",
"type": "Announce",
// URI references:
"actor": "http://sally.example.org/",
"object": "https://sally.example.com/arrive"
}
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags
) always return arrays, functional properties (like content
) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()
) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger
capable of parsing resource queries (like acct:
URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self
link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher()
method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle()
or mapAlias()
callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actors
federation.setActorDispatcher(
"/users/{username}",
async (ctx, username) => { /* ... */ }
);
// Now GET /.well-known/webfinger?resource=acct:[email protected] just works!
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json
) but HTML for browsers (Accept: text/html
). Handling incoming activities at the inbox endpoint involves validating POST
requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox
, followers
, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch()
or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher()
and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners()
lets you define handlers per activity type (e.g., .on(Follow, ...)
), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()
); you provide logic to fetch a page of data, and Fedify constructs the correct Collection
or CollectionPage
with pagination.
// Define inbox handlers
federation.setInboxListeners("/inbox", "/users/{handle}/inbox")
.on(Follow, async (ctx, follow) => { /* Handle follow */ })
.on(Undo, async (ctx, undo) => { /* Handle undo */ });
// Define followers collection logic
federation.setFollowersDispatcher(
"/users/{handle}/followers",
async (ctx, handle, cursor) => { /* ... */ }
);
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue
abstraction. When configured (highly recommended), Context.sendActivity()
enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy
). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)
const federation = createFederation({
queue: new DenoKvMessageQueue(/* ... */),
// ...
});
// Sending is now reliable and non-blocking
await ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Securing an ActivityPub server is critical. You need to implement HTTP Signatures (draft-cavage-http-signatures-12) for server-to-server authentication—a complex process. You might also need Linked Data Signatures (LDS) or Object Integrity Proofs (OIP) based on FEP-8b32 for data integrity and compatibility. Managing cryptographic keys securely is essential. Lastly, fetching remote resources risks Server-Side Request Forgery (SSRF) if not validated properly.
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher
. It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformer
s to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher
.
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify
CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init
.
For debugging interactions and verifying data, fedify lookup
is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
$ fedify lookup @[email protected]
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)
Person {
id: URL "https://fedify-blog.deno.dev/users/fedify-example",
name: "Fedify Example Blog",
published: 2024-03-03T13:18:11.857Z, // Simplified timestamp
summary: "This blog is powered by Fedify, a fediverse server framework.",
url: URL "https://fedify-blog.deno.dev/",
preferredUsername: "fedify-example",
publicKey: CryptographicKey {
id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key",
owner: URL "https://fedify-blog.deno.dev/users/fedify-example",
publicKey: CryptoKey { /* ... CryptoKey details ... */ }
},
// ... other properties like inbox, outbox, followers, endpoints ...
}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox
. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox
✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/
✔ Sent follow request to @<some_test_account>@activitypub.academy.
╭───────────────┬─────────────────────────────────────────╮
│ Actor handle: │ i@<unique_id>.lhr.life │
├───────────────┼─────────────────────────────────────────┤
│ Actor URI: │ https://<unique_id>.lhr.life/i │
├───────────────┼─────────────────────────────────────────┤
│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │
├───────────────┼─────────────────────────────────────────┤
│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │
╰───────────────┴─────────────────────────────────────────╯
Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox
or Shared inbox
URI provided. When an activity arrives, fedify inbox
only prints a summary table to your console indicating that a request was received:
╭────────────────┬─────────────────────────────────────╮
│ Request #: │ 2 │
├────────────────┼─────────────────────────────────────┤
│ Activity type: │ Follow │
├────────────────┼─────────────────────────────────────┤
│ HTTP request: │ POST /i/inbox │
├────────────────┼─────────────────────────────────────┤
│ HTTP response: │ 202 │
├────────────────┼─────────────────────────────────────┤
│ Details │ https://<unique_id>.lhr.life/r/2 │
╰────────────────┴─────────────────────────────────────╯
Crucially, the detailed information about the received request—including the full headers (like Signature
), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox
. This web UI allows you to thoroughly inspect incoming activities during development.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel
can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name
.
Check out the Fedify tutorials and Fedify manual to learn more. Happy federating!
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note
, Article
), profiles (Person
, Organization
), actions (Create
, Follow
, Like
, Announce
)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Note
objects mean the same thing regarding the name
property:// No name property
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"content": "…"
}
// Equivalent to:
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"name": [],
"content": "…"
}
content
property here:// Single value
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"content": "Hello"
}
// Equivalent to:
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"content": ["Hello"]
}
Announce
activities are semantically equivalent (assuming the URIs resolve correctly):{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Announce",
// Embedded objects:
"actor": {
"type": "Person",
"id": "http://sally.example.org/",
"name": "Sally"
},
"object": {
"type": "Arrive",
"id": "https://sally.example.com/arrive",
/* ... */
}
}
// Equivalent to:
{
"@context":
"https://www.w3.org/ns/activitystreams",
"type": "Announce",
// URI references:
"actor": "http://sally.example.org/",
"object": "https://sally.example.com/arrive"
}
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags
) always return arrays, functional properties (like content
) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()
) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger
capable of parsing resource queries (like acct:
URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self
link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher()
method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle()
or mapAlias()
callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actors
federation.setActorDispatcher(
"/users/{username}",
async (ctx, username) => { /* ... */ }
);
// Now GET /.well-known/webfinger?resource=acct:[email protected] just works!
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json
) but HTML for browsers (Accept: text/html
). Handling incoming activities at the inbox endpoint involves validating POST
requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox
, followers
, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch()
or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher()
and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners()
lets you define handlers per activity type (e.g., .on(Follow, ...)
), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()
); you provide logic to fetch a page of data, and Fedify constructs the correct Collection
or CollectionPage
with pagination.
// Define inbox handlers
federation.setInboxListeners("/inbox", "/users/{handle}/inbox")
.on(Follow, async (ctx, follow) => { /* Handle follow */ })
.on(Undo, async (ctx, undo) => { /* Handle undo */ });
// Define followers collection logic
federation.setFollowersDispatcher(
"/users/{handle}/followers",
async (ctx, handle, cursor) => { /* ... */ }
);
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue
abstraction. When configured (highly recommended), Context.sendActivity()
enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy
). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)
const federation = createFederation({
queue: new DenoKvMessageQueue(/* ... */),
// ...
});
// Sending is now reliable and non-blocking
await ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Securing an ActivityPub server is critical. You need to implement HTTP Signatures (draft-cavage-http-signatures-12) for server-to-server authentication—a complex process. You might also need Linked Data Signatures (LDS) or Object Integrity Proofs (OIP) based on FEP-8b32 for data integrity and compatibility. Managing cryptographic keys securely is essential. Lastly, fetching remote resources risks Server-Side Request Forgery (SSRF) if not validated properly.
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher
. It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformer
s to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher
.
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify
CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init
.
For debugging interactions and verifying data, fedify lookup
is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
$ fedify lookup @[email protected]
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)
Person {
id: URL "https://fedify-blog.deno.dev/users/fedify-example",
name: "Fedify Example Blog",
published: 2024-03-03T13:18:11.857Z, // Simplified timestamp
summary: "This blog is powered by Fedify, a fediverse server framework.",
url: URL "https://fedify-blog.deno.dev/",
preferredUsername: "fedify-example",
publicKey: CryptographicKey {
id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key",
owner: URL "https://fedify-blog.deno.dev/users/fedify-example",
publicKey: CryptoKey { /* ... CryptoKey details ... */ }
},
// ... other properties like inbox, outbox, followers, endpoints ...
}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox
. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox
✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/
✔ Sent follow request to @<some_test_account>@activitypub.academy.
╭───────────────┬─────────────────────────────────────────╮
│ Actor handle: │ i@<unique_id>.lhr.life │
├───────────────┼─────────────────────────────────────────┤
│ Actor URI: │ https://<unique_id>.lhr.life/i │
├───────────────┼─────────────────────────────────────────┤
│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │
├───────────────┼─────────────────────────────────────────┤
│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │
╰───────────────┴─────────────────────────────────────────╯
Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox
or Shared inbox
URI provided. When an activity arrives, fedify inbox
only prints a summary table to your console indicating that a request was received:
╭────────────────┬─────────────────────────────────────╮
│ Request #: │ 2 │
├────────────────┼─────────────────────────────────────┤
│ Activity type: │ Follow │
├────────────────┼─────────────────────────────────────┤
│ HTTP request: │ POST /i/inbox │
├────────────────┼─────────────────────────────────────┤
│ HTTP response: │ 202 │
├────────────────┼─────────────────────────────────────┤
│ Details │ https://<unique_id>.lhr.life/r/2 │
╰────────────────┴─────────────────────────────────────╯
Crucially, the detailed information about the received request—including the full headers (like Signature
), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox
. This web UI allows you to thoroughly inspect incoming activities during development.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel
can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name
.
Check out the Fedify tutorials and Fedify manual to learn more. Happy federating!
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note
, Article
), profiles (Person
, Organization
), actions (Create
, Follow
, Like
, Announce
)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Note
objects mean the same thing regarding the name
property:// No name property
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"content": "…"
}
// Equivalent to:
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"name": [],
"content": "…"
}
content
property here:// Single value
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"content": "Hello"
}
// Equivalent to:
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"content": ["Hello"]
}
Announce
activities are semantically equivalent (assuming the URIs resolve correctly):{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Announce",
// Embedded objects:
"actor": {
"type": "Person",
"id": "http://sally.example.org/",
"name": "Sally"
},
"object": {
"type": "Arrive",
"id": "https://sally.example.com/arrive",
/* ... */
}
}
// Equivalent to:
{
"@context":
"https://www.w3.org/ns/activitystreams",
"type": "Announce",
// URI references:
"actor": "http://sally.example.org/",
"object": "https://sally.example.com/arrive"
}
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags
) always return arrays, functional properties (like content
) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()
) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger
capable of parsing resource queries (like acct:
URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self
link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher()
method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle()
or mapAlias()
callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actors
federation.setActorDispatcher(
"/users/{username}",
async (ctx, username) => { /* ... */ }
);
// Now GET /.well-known/webfinger?resource=acct:[email protected] just works!
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json
) but HTML for browsers (Accept: text/html
). Handling incoming activities at the inbox endpoint involves validating POST
requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox
, followers
, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch()
or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher()
and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners()
lets you define handlers per activity type (e.g., .on(Follow, ...)
), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()
); you provide logic to fetch a page of data, and Fedify constructs the correct Collection
or CollectionPage
with pagination.
// Define inbox handlers
federation.setInboxListeners("/inbox", "/users/{handle}/inbox")
.on(Follow, async (ctx, follow) => { /* Handle follow */ })
.on(Undo, async (ctx, undo) => { /* Handle undo */ });
// Define followers collection logic
federation.setFollowersDispatcher(
"/users/{handle}/followers",
async (ctx, handle, cursor) => { /* ... */ }
);
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue
abstraction. When configured (highly recommended), Context.sendActivity()
enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy
). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)
const federation = createFederation({
queue: new DenoKvMessageQueue(/* ... */),
// ...
});
// Sending is now reliable and non-blocking
await ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Securing an ActivityPub server is critical. You need to implement HTTP Signatures (draft-cavage-http-signatures-12) for server-to-server authentication—a complex process. You might also need Linked Data Signatures (LDS) or Object Integrity Proofs (OIP) based on FEP-8b32 for data integrity and compatibility. Managing cryptographic keys securely is essential. Lastly, fetching remote resources risks Server-Side Request Forgery (SSRF) if not validated properly.
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher
. It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformer
s to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher
.
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify
CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init
.
For debugging interactions and verifying data, fedify lookup
is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
$ fedify lookup @[email protected]
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)
Person {
id: URL "https://fedify-blog.deno.dev/users/fedify-example",
name: "Fedify Example Blog",
published: 2024-03-03T13:18:11.857Z, // Simplified timestamp
summary: "This blog is powered by Fedify, a fediverse server framework.",
url: URL "https://fedify-blog.deno.dev/",
preferredUsername: "fedify-example",
publicKey: CryptographicKey {
id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key",
owner: URL "https://fedify-blog.deno.dev/users/fedify-example",
publicKey: CryptoKey { /* ... CryptoKey details ... */ }
},
// ... other properties like inbox, outbox, followers, endpoints ...
}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox
. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox
✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/
✔ Sent follow request to @<some_test_account>@activitypub.academy.
╭───────────────┬─────────────────────────────────────────╮
│ Actor handle: │ i@<unique_id>.lhr.life │
├───────────────┼─────────────────────────────────────────┤
│ Actor URI: │ https://<unique_id>.lhr.life/i │
├───────────────┼─────────────────────────────────────────┤
│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │
├───────────────┼─────────────────────────────────────────┤
│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │
╰───────────────┴─────────────────────────────────────────╯
Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox
or Shared inbox
URI provided. When an activity arrives, fedify inbox
only prints a summary table to your console indicating that a request was received:
╭────────────────┬─────────────────────────────────────╮
│ Request #: │ 2 │
├────────────────┼─────────────────────────────────────┤
│ Activity type: │ Follow │
├────────────────┼─────────────────────────────────────┤
│ HTTP request: │ POST /i/inbox │
├────────────────┼─────────────────────────────────────┤
│ HTTP response: │ 202 │
├────────────────┼─────────────────────────────────────┤
│ Details │ https://<unique_id>.lhr.life/r/2 │
╰────────────────┴─────────────────────────────────────╯
Crucially, the detailed information about the received request—including the full headers (like Signature
), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox
. This web UI allows you to thoroughly inspect incoming activities during development.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel
can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name
.
Check out the Fedify tutorials and Fedify manual to learn more. Happy federating!
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject()
. Pass it a URI (e.g., https://instance.tld/users/alice
) or a handle (e.g., @[email protected]
), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor()
like this:
let actor = await ctx.lookupObject("@[email protected]");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
This is readily available in handlers where the Context
object is provided (like actor dispatchers or inbox listeners).
Focus on your app's logic, not protocol boilerplate!
Learn more: https://fedify.dev/manual/context#looking-up-remote-objects
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject()
. Pass it a URI (e.g., https://instance.tld/users/alice
) or a handle (e.g., @[email protected]
), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor()
like this:
let actor = await ctx.lookupObject("@[email protected]");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
This is readily available in handlers where the Context
object is provided (like actor dispatchers or inbox listeners).
Focus on your app's logic, not protocol boilerplate!
Learn more: https://fedify.dev/manual/context#looking-up-remote-objects
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject()
. Pass it a URI (e.g., https://instance.tld/users/alice
) or a handle (e.g., @[email protected]
), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor()
like this:
let actor = await ctx.lookupObject("@[email protected]");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
This is readily available in handlers where the Context
object is provided (like actor dispatchers or inbox listeners).
Focus on your app's logic, not protocol boilerplate!
Learn more: https://fedify.dev/manual/context#looking-up-remote-objects
📣 Exciting news! Fedify CLI is now available via Homebrew!
If you're using #Homebrew on macOS or #Linuxbrew on Linux, you can now install our CLI toolchain with a simple command:
brew install fedify
This makes it even easier to get started with building your federated server app. Try it out and let us know what you think!
📣 Exciting news! Fedify CLI is now available via Homebrew!
If you're using #Homebrew on macOS or #Linuxbrew on Linux, you can now install our CLI toolchain with a simple command:
brew install fedify
This makes it even easier to get started with building your federated server app. Try it out and let us know what you think!
📣 Exciting news! Fedify CLI is now available via Homebrew!
If you're using #Homebrew on macOS or #Linuxbrew on Linux, you can now install our CLI toolchain with a simple command:
brew install fedify
This makes it even easier to get started with building your federated server app. Try it out and let us know what you think!
📣 Exciting news! Fedify CLI is now available via Homebrew!
If you're using #Homebrew on macOS or #Linuxbrew on Linux, you can now install our CLI toolchain with a simple command:
brew install fedify
This makes it even easier to get started with building your federated server app. Try it out and let us know what you think!
📣 Exciting news! Fedify CLI is now available via Homebrew!
If you're using #Homebrew on macOS or #Linuxbrew on Linux, you can now install our CLI toolchain with a simple command:
brew install fedify
This makes it even easier to get started with building your federated server app. Try it out and let us know what you think!
📣 Exciting news! Fedify CLI is now available via Homebrew!
If you're using #Homebrew on macOS or #Linuxbrew on Linux, you can now install our CLI toolchain with a simple command:
brew install fedify
This makes it even easier to get started with building your federated server app. Try it out and let us know what you think!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
本日、第8回FediLUG勉強会で「国漢文混用体からHolloまで」というタイトルで発表をしてきました。
私がなぜActivityPubサーバーフレームワークのFedifyと、シングルユーザー向けActivityPubサーバーのHolloを開発する事に成ったのか、その旅路を共有しました。
実は全ての始まりは、韓国語の「国漢文混用体」(漢字ハングル混じり文)に「振りハングル」を付けたいという単純な願いからでした。この小さな目標が、最終的にFedifyとHolloという二つのプロジェクトへと発展したのです。
興味のある方は、発表スライドをご覧ください: 「国漢文混用体からHolloまで」(Speaker Deck)
#FediLUG #Fedify #Hollo #ActivityPub #フェディバース #fediverse #fedidev
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
本日、第8回FediLUG勉強会で「国漢文混用体からHolloまで」というタイトルで発表をしてきました。
私がなぜActivityPubサーバーフレームワークのFedifyと、シングルユーザー向けActivityPubサーバーのHolloを開発する事に成ったのか、その旅路を共有しました。
実は全ての始まりは、韓国語の「国漢文混用体」(漢字ハングル混じり文)に「振りハングル」を付けたいという単純な願いからでした。この小さな目標が、最終的にFedifyとHolloという二つのプロジェクトへと発展したのです。
興味のある方は、発表スライドをご覧ください: 「国漢文混用体からHolloまで」(Speaker Deck)
#FediLUG #Fedify #Hollo #ActivityPub #フェディバース #fediverse #fedidev
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
本日、第8回FediLUG勉強会で「国漢文混用体からHolloまで」というタイトルで発表をしてきました。
私がなぜActivityPubサーバーフレームワークのFedifyと、シングルユーザー向けActivityPubサーバーのHolloを開発する事に成ったのか、その旅路を共有しました。
実は全ての始まりは、韓国語の「国漢文混用体」(漢字ハングル混じり文)に「振りハングル」を付けたいという単純な願いからでした。この小さな目標が、最終的にFedifyとHolloという二つのプロジェクトへと発展したのです。
興味のある方は、発表スライドをご覧ください: 「国漢文混用体からHolloまで」(Speaker Deck)
#FediLUG #Fedify #Hollo #ActivityPub #フェディバース #fediverse #fedidev
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
本日、第8回FediLUG勉強会で「国漢文混用体からHolloまで」というタイトルで発表をしてきました。
私がなぜActivityPubサーバーフレームワークのFedifyと、シングルユーザー向けActivityPubサーバーのHolloを開発する事に成ったのか、その旅路を共有しました。
実は全ての始まりは、韓国語の「国漢文混用体」(漢字ハングル混じり文)に「振りハングル」を付けたいという単純な願いからでした。この小さな目標が、最終的にFedifyとHolloという二つのプロジェクトへと発展したのです。
興味のある方は、発表スライドをご覧ください: 「国漢文混用体からHolloまで」(Speaker Deck)
#FediLUG #Fedify #Hollo #ActivityPub #フェディバース #fediverse #fedidev
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
本日、第8回FediLUG勉強会で「国漢文混用体からHolloまで」というタイトルで発表をしてきました。
私がなぜActivityPubサーバーフレームワークのFedifyと、シングルユーザー向けActivityPubサーバーのHolloを開発する事に成ったのか、その旅路を共有しました。
実は全ての始まりは、韓国語の「国漢文混用体」(漢字ハングル混じり文)に「振りハングル」を付けたいという単純な願いからでした。この小さな目標が、最終的にFedifyとHolloという二つのプロジェクトへと発展したのです。
興味のある方は、発表スライドをご覧ください: 「国漢文混用体からHolloまで」(Speaker Deck)
#FediLUG #Fedify #Hollo #ActivityPub #フェディバース #fediverse #fedidev
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
本日、第8回FediLUG勉強会で「国漢文混用体からHolloまで」というタイトルで発表をしてきました。
私がなぜActivityPubサーバーフレームワークのFedifyと、シングルユーザー向けActivityPubサーバーのHolloを開発する事に成ったのか、その旅路を共有しました。
実は全ての始まりは、韓国語の「国漢文混用体」(漢字ハングル混じり文)に「振りハングル」を付けたいという単純な願いからでした。この小さな目標が、最終的にFedifyとHolloという二つのプロジェクトへと発展したのです。
興味のある方は、発表スライドをご覧ください: 「国漢文混用体からHolloまで」(Speaker Deck)
#FediLUG #Fedify #Hollo #ActivityPub #フェディバース #fediverse #fedidev
We're incredibly honored to announce that #Ghost (@index) has become a formal sponsor of Fedify through Open Collective!
This is a significant milestone for our project, and we're deeply grateful to @johnonolan 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! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
We're incredibly honored to announce that #Ghost (@index) has become a formal sponsor of Fedify through Open Collective!
This is a significant milestone for our project, and we're deeply grateful to @johnonolan 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! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
We're incredibly honored to announce that #Ghost (@index) has become a formal sponsor of Fedify through Open Collective!
This is a significant milestone for our project, and we're deeply grateful to @johnonolan 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! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
I received a heartwarming #testimonial about #Fedify today!
@bgl shared in the FediDev KR Discord server:
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
They also posted on their Hackers' Pub:
If you want to learn ActivityPub efficiently, just read the Fedify docs from beginning to end.
This makes all the documentation work worthwhile. Glad our docs are helping people understand not just Fedify, but #ActivityPub itself.
ActivityPub 효율적으로 익히려면 그냥 fedify 문서 첨부터 끝까지 읽으면 되는듯요
We're incredibly honored to announce that #Ghost (@index) has become a formal sponsor of Fedify through Open Collective!
This is a significant milestone for our project, and we're deeply grateful to @johnonolan 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! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
We're incredibly honored to announce that #Ghost (@index) has become a formal sponsor of Fedify through Open Collective!
This is a significant milestone for our project, and we're deeply grateful to @johnonolan 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! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
We're incredibly honored to announce that #Ghost (@index) has become a formal sponsor of Fedify through Open Collective!
This is a significant milestone for our project, and we're deeply grateful to @johnonolan 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! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
We're incredibly honored to announce that #Ghost (@index) has become a formal sponsor of Fedify through Open Collective!
This is a significant milestone for our project, and we're deeply grateful to @johnonolan 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! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
We're incredibly honored to announce that #Ghost (@index) has become a formal sponsor of Fedify through Open Collective!
This is a significant milestone for our project, and we're deeply grateful to @johnonolan 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! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
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:
#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)
);
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...
});
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
}
);
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.
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.
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.
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:
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.
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.
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/[email protected]
# For npm
npm add @fedify/[email protected]
# For Bun
bun add @fedify/[email protected]
Thank you to all contributors who helped make this release possible!
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:
#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)
);
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...
});
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
}
);
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.
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.
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.
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:
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.
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.
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/[email protected]
# For npm
npm add @fedify/[email protected]
# For Bun
bun add @fedify/[email protected]
Thank you to all contributors who helped make this release possible!
I received a heartwarming #testimonial about #Fedify today!
@bgl shared in the FediDev KR Discord server:
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
They also posted on their Hackers' Pub:
If you want to learn ActivityPub efficiently, just read the Fedify docs from beginning to end.
This makes all the documentation work worthwhile. Glad our docs are helping people understand not just Fedify, but #ActivityPub itself.
ActivityPub 효율적으로 익히려면 그냥 fedify 문서 첨부터 끝까지 읽으면 되는듯요
I received a heartwarming #testimonial about #Fedify today!
@bgl shared in the FediDev KR Discord server:
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
They also posted on their Hackers' Pub:
If you want to learn ActivityPub efficiently, just read the Fedify docs from beginning to end.
This makes all the documentation work worthwhile. Glad our docs are helping people understand not just Fedify, but #ActivityPub itself.
ActivityPub 효율적으로 익히려면 그냥 fedify 문서 첨부터 끝까지 읽으면 되는듯요
I received a heartwarming #testimonial about #Fedify today!
@bgl shared in the FediDev KR Discord server:
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
They also posted on their Hackers' Pub:
If you want to learn ActivityPub efficiently, just read the Fedify docs from beginning to end.
This makes all the documentation work worthwhile. Glad our docs are helping people understand not just Fedify, but #ActivityPub itself.
ActivityPub 효율적으로 익히려면 그냥 fedify 문서 첨부터 끝까지 읽으면 되는듯요
I received a heartwarming #testimonial about #Fedify today!
@bgl shared in the FediDev KR Discord server:
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
They also posted on their Hackers' Pub:
If you want to learn ActivityPub efficiently, just read the Fedify docs from beginning to end.
This makes all the documentation work worthwhile. Glad our docs are helping people understand not just Fedify, but #ActivityPub itself.
ActivityPub 효율적으로 익히려면 그냥 fedify 문서 첨부터 끝까지 읽으면 되는듯요
I received a heartwarming #testimonial about #Fedify today!
@bgl shared in the FediDev KR Discord server:
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
They also posted on their Hackers' Pub:
If you want to learn ActivityPub efficiently, just read the Fedify docs from beginning to end.
This makes all the documentation work worthwhile. Glad our docs are helping people understand not just Fedify, but #ActivityPub itself.
ActivityPub 효율적으로 익히려면 그냥 fedify 문서 첨부터 끝까지 읽으면 되는듯요
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:
#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)
);
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...
});
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
}
);
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.
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.
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.
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:
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.
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.
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/[email protected]
# For npm
npm add @fedify/[email protected]
# For Bun
bun add @fedify/[email protected]
Thank you to all contributors who helped make this release possible!
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:
#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)
);
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...
});
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
}
);
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.
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.
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.
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:
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.
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.
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/[email protected]
# For npm
npm add @fedify/[email protected]
# For Bun
bun add @fedify/[email protected]
Thank you to all contributors who helped make this release possible!
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:
#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)
);
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...
});
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
}
);
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.
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.
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.
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:
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.
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.
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/[email protected]
# For npm
npm add @fedify/[email protected]
# For Bun
bun add @fedify/[email protected]
Thank you to all contributors who helped make this release possible!
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:
#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)
);
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...
});
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
}
);
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.
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.
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.
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:
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.
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.
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/[email protected]
# For npm
npm add @fedify/[email protected]
# For Bun
bun add @fedify/[email protected]
Thank you to all contributors who helped make this release possible!
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:
#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)
);
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...
});
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
}
);
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.
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.
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.
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:
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.
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.
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/[email protected]
# For npm
npm add @fedify/[email protected]
# For Bun
bun add @fedify/[email protected]
Thank you to all contributors who helped make this release possible!
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:
#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)
);
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...
});
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
}
);
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.
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.
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.
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:
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.
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.
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/[email protected]
# For npm
npm add @fedify/[email protected]
# For Bun
bun add @fedify/[email protected]
Thank you to all contributors who helped make this release possible!
며칠 늦었지만 … Viva #fedify
> Substack rival Ghost is now connected to the fediverse
https://techcrunch.com/2025/03/19/substack-rival-ghost-is-now-connected-to-the-fediverse/
며칠 늦었지만 … Viva #fedify
> Substack rival Ghost is now connected to the fediverse
https://techcrunch.com/2025/03/19/substack-rival-ghost-is-now-connected-to-the-fediverse/
I just discovered why some of my followers from larger #Mastodon instances (like mastodon.social) would mysteriously unfollow me after a while!
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
I just discovered why some of my followers from larger #Mastodon instances (like mastodon.social) would mysteriously unfollow me after a while!
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
I just discovered why some of my followers from larger #Mastodon instances (like mastodon.social) would mysteriously unfollow me after a while!
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
I just discovered why some of my followers from larger #Mastodon instances (like mastodon.social) would mysteriously unfollow me after a while!
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
I just discovered why some of my followers from larger #Mastodon instances (like mastodon.social) would mysteriously unfollow me after a while!
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
I just discovered why some of my followers from larger #Mastodon instances (like mastodon.social) would mysteriously unfollow me after a while!
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
I just discovered why some of my followers from larger #Mastodon instances (like mastodon.social) would mysteriously unfollow me after a while!
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
【輪読会試験開催のお知らせ】
本日、 #FediLUG :fedilug: 輪読会📖第0弾として
「〜自分でActivityPub対応SNSを作ってみよう〜『自分だけのフェディバースのマイクロブログを作ろう!』輪読会」
https://github.com/dahlia/fedify-microblog-tutorial-ja
を行います!申し込みは以下からできます!ぜひ参加してフィードバックをください!!
https://fedilug.connpass.com/event/348240/
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
【輪読会試験開催のお知らせ】
本日、 #FediLUG :fedilug: 輪読会📖第0弾として
「〜自分でActivityPub対応SNSを作ってみよう〜『自分だけのフェディバースのマイクロブログを作ろう!』輪読会」
https://github.com/dahlia/fedify-microblog-tutorial-ja
を行います!申し込みは以下からできます!ぜひ参加してフィードバックをください!!
https://fedilug.connpass.com/event/348240/
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
【輪読会試験開催のお知らせ】
本日、 #FediLUG :fedilug: 輪読会📖第0弾として
「〜自分でActivityPub対応SNSを作ってみよう〜『自分だけのフェディバースのマイクロブログを作ろう!』輪読会」
https://github.com/dahlia/fedify-microblog-tutorial-ja
を行います!申し込みは以下からできます!ぜひ参加してフィードバックをください!!
https://fedilug.connpass.com/event/348240/
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
【輪読会試験開催のお知らせ】
本日、 #FediLUG :fedilug: 輪読会📖第0弾として
「〜自分でActivityPub対応SNSを作ってみよう〜『自分だけのフェディバースのマイクロブログを作ろう!』輪読会」
https://github.com/dahlia/fedify-microblog-tutorial-ja
を行います!申し込みは以下からできます!ぜひ参加してフィードバックをください!!
https://fedilug.connpass.com/event/348240/
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
【輪読会試験開催のお知らせ】
本日、 #FediLUG :fedilug: 輪読会📖第0弾として
「〜自分でActivityPub対応SNSを作ってみよう〜『自分だけのフェディバースのマイクロブログを作ろう!』輪読会」
https://github.com/dahlia/fedify-microblog-tutorial-ja
を行います!申し込みは以下からできます!ぜひ参加してフィードバックをください!!
https://fedilug.connpass.com/event/348240/
이番에 @lqez 님의 《우리의 코드를 찾아서》에 出演하여 #페디버스, #ActivityPub, #Fedify, #Hollo에 關해 이야기를 나눴습니다. Fedify와 Hollo의 開發 祕話 같은 게 궁금하시다면 한 番 보셔도 재밌을지도 모르겠습니다. ㅎㅎㅎ
이番에 @lqez 님의 《우리의 코드를 찾아서》에 出演하여 #페디버스, #ActivityPub, #Fedify, #Hollo에 關해 이야기를 나눴습니다. Fedify와 Hollo의 開發 祕話 같은 게 궁금하시다면 한 番 보셔도 재밌을지도 모르겠습니다. ㅎㅎㅎ
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
今回、@lqez さんの『我々のコードを求めて』というYouTubeに出演させていただき、#フェディバース、#ActivityPub、#Fedify、#Hollo 等についてお話させていただきました。日本語字幕が用意されていますので、FedifyやHolloの開発秘話などが気になる方はぜひご覧ください!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
今回、@lqez さんの『我々のコードを求めて』というYouTubeに出演させていただき、#フェディバース、#ActivityPub、#Fedify、#Hollo 等についてお話させていただきました。日本語字幕が用意されていますので、FedifyやHolloの開発秘話などが気になる方はぜひご覧ください!
이番에 @lqez 님의 《우리의 코드를 찾아서》에 出演하여 #페디버스, #ActivityPub, #Fedify, #Hollo에 關해 이야기를 나눴습니다. Fedify와 Hollo의 開發 祕話 같은 게 궁금하시다면 한 番 보셔도 재밌을지도 모르겠습니다. ㅎㅎㅎ
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!
After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.
As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.
Our solution? A new two-stage “fan-out” approach:
Context.sendActivity()
, we'll now enqueue just one consolidated message containing your activity payload and recipient listThe benefits are substantial:
Context.sendActivity()
returns almost instantly, even for massive follower countsFor developers with specific needs, we're adding a fanout
option with three settings:
"auto"
(default): Uses fanout for large recipient lists, direct delivery for small ones"skip"
: Bypasses fanout when you need different payload per recipient"force"
: Always uses fanout even with few recipients// Example with custom fanout setting
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "skip" } // Directly enqueues individual messages
);
This change represents months of performance testing and should make Fedify work beautifully even for extremely popular accounts!
For more details, check out our docs.
What other #performance optimizations would you like to see in future Fedify releases?
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!
After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.
As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.
Our solution? A new two-stage “fan-out” approach:
Context.sendActivity()
, we'll now enqueue just one consolidated message containing your activity payload and recipient listThe benefits are substantial:
Context.sendActivity()
returns almost instantly, even for massive follower countsFor developers with specific needs, we're adding a fanout
option with three settings:
"auto"
(default): Uses fanout for large recipient lists, direct delivery for small ones"skip"
: Bypasses fanout when you need different payload per recipient"force"
: Always uses fanout even with few recipients// Example with custom fanout setting
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "skip" } // Directly enqueues individual messages
);
This change represents months of performance testing and should make Fedify work beautifully even for extremely popular accounts!
For more details, check out our docs.
What other #performance optimizations would you like to see in future Fedify releases?
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!
After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.
As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.
Our solution? A new two-stage “fan-out” approach:
Context.sendActivity()
, we'll now enqueue just one consolidated message containing your activity payload and recipient listThe benefits are substantial:
Context.sendActivity()
returns almost instantly, even for massive follower countsFor developers with specific needs, we're adding a fanout
option with three settings:
"auto"
(default): Uses fanout for large recipient lists, direct delivery for small ones"skip"
: Bypasses fanout when you need different payload per recipient"force"
: Always uses fanout even with few recipients// Example with custom fanout setting
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "skip" } // Directly enqueues individual messages
);
This change represents months of performance testing and should make Fedify work beautifully even for extremely popular accounts!
For more details, check out our docs.
What other #performance optimizations would you like to see in future Fedify releases?
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!
After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.
As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.
Our solution? A new two-stage “fan-out” approach:
Context.sendActivity()
, we'll now enqueue just one consolidated message containing your activity payload and recipient listThe benefits are substantial:
Context.sendActivity()
returns almost instantly, even for massive follower countsFor developers with specific needs, we're adding a fanout
option with three settings:
"auto"
(default): Uses fanout for large recipient lists, direct delivery for small ones"skip"
: Bypasses fanout when you need different payload per recipient"force"
: Always uses fanout even with few recipients// Example with custom fanout setting
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "skip" } // Directly enqueues individual messages
);
This change represents months of performance testing and should make Fedify work beautifully even for extremely popular accounts!
For more details, check out our docs.
What other #performance optimizations would you like to see in future Fedify releases?
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!
After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.
As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.
Our solution? A new two-stage “fan-out” approach:
Context.sendActivity()
, we'll now enqueue just one consolidated message containing your activity payload and recipient listThe benefits are substantial:
Context.sendActivity()
returns almost instantly, even for massive follower countsFor developers with specific needs, we're adding a fanout
option with three settings:
"auto"
(default): Uses fanout for large recipient lists, direct delivery for small ones"skip"
: Bypasses fanout when you need different payload per recipient"force"
: Always uses fanout even with few recipients// Example with custom fanout setting
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "skip" } // Directly enqueues individual messages
);
This change represents months of performance testing and should make Fedify work beautifully even for extremely popular accounts!
For more details, check out our docs.
What other #performance optimizations would you like to see in future Fedify releases?
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
Finished the #Fedify queue optimization work. Tests written, docs completed. Should make activity delivery much faster for high-follower accounts.
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
Finished the #Fedify queue optimization work. Tests written, docs completed. Should make activity delivery much faster for high-follower accounts.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
ActivityPub 구현을 고려 중이시거나, Fedify 프로젝트와 협력하고 싶으시다면 연락 주세요:
귀사의 요구사항과 목표에 맞는 맞춤형 협력 방안을 함께 모색하겠습니다.
Is the world in need of a federated Craigslist/Kleinanzeigen platform? I am currently thinking about a project to dig into #fediverse development and learning #golang or stay with #deno and using #fedify.
Is the world in need of a federated Craigslist/Kleinanzeigen platform? I am currently thinking about a project to dig into #fediverse development and learning #golang or stay with #deno and using #fedify.
We'd like to introduce the #Fedify project family—a set of related tools that make building #ActivityPub applications more accessible:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedifyの関連プロジェクトをご紹介したいと思います。ActivityPubアプリケーション開発をより簡単にするツール群です:
Fedify(@fedify)はActivityPubやその他のフェディバース標準を活用する連合型サーバーアプリケーションを構築するためのTypeScriptライブラリです。Activity Vocabularyの型安全なオブジェクト、WebFingerクライアント・サーバー、HTTP Signaturesなどを提供し、ボイラープレートコードを削減してアプリケーションロジックに集中できるようにします。
Hollo(@hollo)はFedifyで動作するお一人様用マイクロブログサーバーです。個人向けに設計されていますが、ActivityPubを通じて完全に連合化されており、フェディバース全体のユーザーと交流することができます。HolloはMastodon互換APIを実装しているため、独自のウェブインターフェースがなくても、ほとんどのMastodonクライアントと互換性があります。
Holloはまた、正式リリース前の最新Fedify機能をテストする実験場としても活用されています。
BotKit(@botkit)は私たちの最も新しいメンバーで、ActivityPubボットを作成するために特別に設計されたフレームワークです。従来のMastodonボットとは異なり、BotKitはプラットフォーム固有の制限(文字数制限など)に縛られない独立したActivityPubサーバーを作成します。
BotKitのAPIは意図的にシンプルに設計されており、単一のTypeScriptファイルで完全なボットを作成できます!
これら三つのプロジェクトはすべて@fedify-dev GitHubオーガニゼーションでオープンソースとして公開されています。それぞれ異なる目的を持っていますが、ActivityPub開発をより身近にし、フェディバースのエコシステムを拡大するという共通の目標を共有しています。
これらのプロジェクトを試してみたり、開発に貢献したりすることに興味がある場合は、以下をご覧ください:
#Fedify #ActivityPub #フェディバース #fediverse #Hollo #BotKit #fedidev
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
#Fedify 자매 프로젝트들을 소개해 드리고자 합니다. #ActivityPub 애플리케이션 개발을 더 쉽게 만들어주는 관련 도구들입니다:
Fedify(@fedify)는 ActivityPub와 다른 #연합우주(#fediverse) 표준을 기반으로 연합 서버 애플리케이션을 구축하기 위한 #TypeScript 라이브러리입니다. Activity Vocabulary를 위한 타입 안전한 객체, WebFinger 클라이언트·서버, HTTP Signatures 등를 제공하여 반복적인 코드를 줄이고 애플리케이션 로직에 집중할 수 있게 해줍니다.
Hollo(@hollo)는 Fedify로 구동되는 1인 사용자용 마이크로블로깅 서버입니다. 1인 사용자를 위해 설계되었지만, ActivityPub를 통해 완전히 연합되어 연합우주 전체의 사용자들과 상호작용할 수 있습니다. Hollo는 Mastodon 호환 API를 구현하여 자체 웹 인터페이스 없이도 대부분의 Mastodon 클라이언트와 호환됩니다.
Hollo는 또한 정식 출시 전에 최신 Fedify 기능을 테스트하는 실험장으로도 활용되고 있습니다.
BotKit(@botkit)은 저희의 가장 새로운 구성원으로, ActivityPub 봇을 만들기 위해 특별히 설계된 프레임워크입니다. 전통적인 Mastodon 봇과 달리, BotKit은 플랫폼별 제한(글자 수 제한 등)에 구애받지 않는 독립적인 ActivityPub 서버를 만듭니다.
BotKit의 API는 의도적으로 단순하게 설계되어 단일 TypeScript 파일로 완전한 봇을 만들 수 있습니다!
세 프로젝트 모두 @fedify-dev GitHub 조직에서 오픈 소스로 공개되어 있습니다. 각기 다른 목적을 가지고 있지만, ActivityPub 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedifyの関連プロジェクトをご紹介したいと思います。ActivityPubアプリケーション開発をより簡単にするツール群です:
Fedify(@fedify)はActivityPubやその他のフェディバース標準を活用する連合型サーバーアプリケーションを構築するためのTypeScriptライブラリです。Activity Vocabularyの型安全なオブジェクト、WebFingerクライアント・サーバー、HTTP Signaturesなどを提供し、ボイラープレートコードを削減してアプリケーションロジックに集中できるようにします。
Hollo(@hollo)はFedifyで動作するお一人様用マイクロブログサーバーです。個人向けに設計されていますが、ActivityPubを通じて完全に連合化されており、フェディバース全体のユーザーと交流することができます。HolloはMastodon互換APIを実装しているため、独自のウェブインターフェースがなくても、ほとんどのMastodonクライアントと互換性があります。
Holloはまた、正式リリース前の最新Fedify機能をテストする実験場としても活用されています。
BotKit(@botkit)は私たちの最も新しいメンバーで、ActivityPubボットを作成するために特別に設計されたフレームワークです。従来のMastodonボットとは異なり、BotKitはプラットフォーム固有の制限(文字数制限など)に縛られない独立したActivityPubサーバーを作成します。
BotKitのAPIは意図的にシンプルに設計されており、単一のTypeScriptファイルで完全なボットを作成できます!
これら三つのプロジェクトはすべて@fedify-dev GitHubオーガニゼーションでオープンソースとして公開されています。それぞれ異なる目的を持っていますが、ActivityPub開発をより身近にし、フェディバースのエコシステムを拡大するという共通の目標を共有しています。
これらのプロジェクトを試してみたり、開発に貢献したりすることに興味がある場合は、以下をご覧ください:
#Fedify #ActivityPub #フェディバース #fediverse #Hollo #BotKit #fedidev
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
#Fedify 자매 프로젝트들을 소개해 드리고자 합니다. #ActivityPub 애플리케이션 개발을 더 쉽게 만들어주는 관련 도구들입니다:
Fedify(@fedify)는 ActivityPub와 다른 #연합우주(#fediverse) 표준을 기반으로 연합 서버 애플리케이션을 구축하기 위한 #TypeScript 라이브러리입니다. Activity Vocabulary를 위한 타입 안전한 객체, WebFinger 클라이언트·서버, HTTP Signatures 등를 제공하여 반복적인 코드를 줄이고 애플리케이션 로직에 집중할 수 있게 해줍니다.
Hollo(@hollo)는 Fedify로 구동되는 1인 사용자용 마이크로블로깅 서버입니다. 1인 사용자를 위해 설계되었지만, ActivityPub를 통해 완전히 연합되어 연합우주 전체의 사용자들과 상호작용할 수 있습니다. Hollo는 Mastodon 호환 API를 구현하여 자체 웹 인터페이스 없이도 대부분의 Mastodon 클라이언트와 호환됩니다.
Hollo는 또한 정식 출시 전에 최신 Fedify 기능을 테스트하는 실험장으로도 활용되고 있습니다.
BotKit(@botkit)은 저희의 가장 새로운 구성원으로, ActivityPub 봇을 만들기 위해 특별히 설계된 프레임워크입니다. 전통적인 Mastodon 봇과 달리, BotKit은 플랫폼별 제한(글자 수 제한 등)에 구애받지 않는 독립적인 ActivityPub 서버를 만듭니다.
BotKit의 API는 의도적으로 단순하게 설계되어 단일 TypeScript 파일로 완전한 봇을 만들 수 있습니다!
세 프로젝트 모두 @fedify-dev GitHub 조직에서 오픈 소스로 공개되어 있습니다. 각기 다른 목적을 가지고 있지만, ActivityPub 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
We'd like to introduce the #Fedify project family—a set of related tools that make building #ActivityPub applications more accessible:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Getting back to #Fedify development today! Working on optimizing the outgoing activity queue to improve response times. Currently focusing on reducing latency when sending posts to large follower counts—should make the whole publishing experience feel much snappier.
Getting back to #Fedify development today! Working on optimizing the outgoing activity queue to improve response times. Currently focusing on reducing latency when sending posts to large follower counts—should make the whole publishing experience feel much snappier.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've been working on adding custom background task support to #Fedify as planned for version 1.5.0. After diving deeper into implementation, we've realized this is a more substantial undertaking than initially anticipated.
The feature would require significant API changes that would be too disruptive for a minor version update. Therefore, we've decided to postpone this feature to Fedify 2.0.0.
This allows us to:
We believe this decision will result in a more stable and well-designed feature that better serves your needs. However, some smaller improvements from our work that don't require API changes will still be included in Fedify 1.5.0 or subsequent minor updates.
We appreciate your understanding and continued support.
If you have specific use cases or requirements for background task support, please share them in our GitHub issue. Your input will help shape this feature for 2.0.0.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've been working on adding custom background task support to #Fedify as planned for version 1.5.0. After diving deeper into implementation, we've realized this is a more substantial undertaking than initially anticipated.
The feature would require significant API changes that would be too disruptive for a minor version update. Therefore, we've decided to postpone this feature to Fedify 2.0.0.
This allows us to:
We believe this decision will result in a more stable and well-designed feature that better serves your needs. However, some smaller improvements from our work that don't require API changes will still be included in Fedify 1.5.0 or subsequent minor updates.
We appreciate your understanding and continued support.
If you have specific use cases or requirements for background task support, please share them in our GitHub issue. Your input will help shape this feature for 2.0.0.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've been working on adding custom background task support to #Fedify as planned for version 1.5.0. After diving deeper into implementation, we've realized this is a more substantial undertaking than initially anticipated.
The feature would require significant API changes that would be too disruptive for a minor version update. Therefore, we've decided to postpone this feature to Fedify 2.0.0.
This allows us to:
We believe this decision will result in a more stable and well-designed feature that better serves your needs. However, some smaller improvements from our work that don't require API changes will still be included in Fedify 1.5.0 or subsequent minor updates.
We appreciate your understanding and continued support.
If you have specific use cases or requirements for background task support, please share them in our GitHub issue. Your input will help shape this feature for 2.0.0.
Patch releases for #Fedify versions 1.0.21, 1.1.18, 1.2.18, 1.3.14, and 1.4.7 are now available. These updates address two important bugs across all supported release lines:
acct:
URIs with port numbers in the host. Thanks to @revathskumar for reporting and debugging the bug!base-url
parameter of followers collections.We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.
Patch releases for #Fedify versions 1.0.21, 1.1.18, 1.2.18, 1.3.14, and 1.4.7 are now available. These updates address two important bugs across all supported release lines:
acct:
URIs with port numbers in the host. Thanks to @revathskumar for reporting and debugging the bug!base-url
parameter of followers collections.We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.
Patch releases for #Fedify versions 1.0.21, 1.1.18, 1.2.18, 1.3.14, and 1.4.7 are now available. These updates address two important bugs across all supported release lines:
acct:
URIs with port numbers in the host. Thanks to @revathskumar for reporting and debugging the bug!base-url
parameter of followers collections.We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
今回、@lqez さんの『我々のコードを求めて』というYouTubeに出演させていただき、#フェディバース、#ActivityPub、#Fedify、#Hollo 等についてお話させていただきました。日本語字幕が用意されていますので、FedifyやHolloの開発秘話などが気になる方はぜひご覧ください!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
今回、@lqez さんの『我々のコードを求めて』というYouTubeに出演させていただき、#フェディバース、#ActivityPub、#Fedify、#Hollo 等についてお話させていただきました。日本語字幕が用意されていますので、FedifyやHolloの開発秘話などが気になる方はぜひご覧ください!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
今回、@lqez さんの『我々のコードを求めて』というYouTubeに出演させていただき、#フェディバース、#ActivityPub、#Fedify、#Hollo 等についてお話させていただきました。日本語字幕が用意されていますので、FedifyやHolloの開発秘話などが気になる方はぜひご覧ください!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
今回、@lqez さんの『我々のコードを求めて』というYouTubeに出演させていただき、#フェディバース、#ActivityPub、#Fedify、#Hollo 等についてお話させていただきました。日本語字幕が用意されていますので、FedifyやHolloの開発秘話などが気になる方はぜひご覧ください!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
今回、@lqez さんの『我々のコードを求めて』というYouTubeに出演させていただき、#フェディバース、#ActivityPub、#Fedify、#Hollo 等についてお話させていただきました。日本語字幕が用意されていますので、FedifyやHolloの開発秘話などが気になる方はぜひご覧ください!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
今回、@lqez さんの『我々のコードを求めて』というYouTubeに出演させていただき、#フェディバース、#ActivityPub、#Fedify、#Hollo 等についてお話させていただきました。日本語字幕が用意されていますので、FedifyやHolloの開発秘話などが気になる方はぜひご覧ください!
이番에 @lqez 님의 《우리의 코드를 찾아서》에 出演하여 #페디버스, #ActivityPub, #Fedify, #Hollo에 關해 이야기를 나눴습니다. Fedify와 Hollo의 開發 祕話 같은 게 궁금하시다면 한 番 보셔도 재밌을지도 모르겠습니다. ㅎㅎㅎ
Is the world in need of a federated Craigslist/Kleinanzeigen platform? I am currently thinking about a project to dig into #fediverse development and learning #golang or stay with #deno and using #fedify.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
BotKit by Fedify
Simple ActivityPub bot framework. A framework for creating your fediverse bots. Using @botkit, you can create standalone ActivityPub bots rather than Mastodon/Misskey bots. Hence, you are free from the constraints of the existing platforms. BotKit is powered by @fedify, a lower-level rock-solid ActivityPub framework.
#activitypub #fediverse #botkit #fedify #bot #web #typescript #webdev #ts #dev #followfriday #freetoolfriday
BotKit by Fedify
Simple ActivityPub bot framework. A framework for creating your fediverse bots. Using @botkit, you can create standalone ActivityPub bots rather than Mastodon/Misskey bots. Hence, you are free from the constraints of the existing platforms. BotKit is powered by @fedify, a lower-level rock-solid ActivityPub framework.
#activitypub #fediverse #botkit #fedify #bot #web #typescript #webdev #ts #dev #followfriday #freetoolfriday
【輪読会やってみます!】
#FediLUG 輪読会📖第零弾として #fedify の開発者である
Hong Minhee (洪 民憙) @hongminhee さんの著書『自分だけのフェディバースのマイクロブログを作ろう!』の輪読会を行います!
この機会に #Fedify を使用して皆さんで #ActivityPub や #TypeScript などの知識を強化しませんか?
本はGitHubから無料で読むことができます:
https://github.com/dahlia/fedify-microblog-tutorial-ja
参加:
https://fedilug.connpass.com/event/348240/
【輪読会やってみます!】
#FediLUG 輪読会📖第零弾として #fedify の開発者である
Hong Minhee (洪 民憙) @hongminhee さんの著書『自分だけのフェディバースのマイクロブログを作ろう!』の輪読会を行います!
この機会に #Fedify を使用して皆さんで #ActivityPub や #TypeScript などの知識を強化しませんか?
本はGitHubから無料で読むことができます:
https://github.com/dahlia/fedify-microblog-tutorial-ja
参加:
https://fedilug.connpass.com/event/348240/
【輪読会やってみます!】
#FediLUG 輪読会📖第零弾として #fedify の開発者である
Hong Minhee (洪 民憙) @hongminhee さんの著書『自分だけのフェディバースのマイクロブログを作ろう!』の輪読会を行います!
この機会に #Fedify を使用して皆さんで #ActivityPub や #TypeScript などの知識を強化しませんか?
本はGitHubから無料で読むことができます:
https://github.com/dahlia/fedify-microblog-tutorial-ja
参加:
https://fedilug.connpass.com/event/348240/
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
Various projects are already leveraging Fedify:
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
We're excited to explore customized collaboration opportunities that align with your requirements and goals.
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
Various projects are already leveraging Fedify:
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
We're excited to explore customized collaboration opportunities that align with your requirements and goals.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
ActivityPub 구현을 고려 중이시거나, Fedify 프로젝트와 협력하고 싶으시다면 연락 주세요:
귀사의 요구사항과 목표에 맞는 맞춤형 협력 방안을 함께 모색하겠습니다.
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
Various projects are already leveraging Fedify:
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
We're excited to explore customized collaboration opportunities that align with your requirements and goals.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
ActivityPub 구현을 고려 중이시거나, Fedify 프로젝트와 협력하고 싶으시다면 연락 주세요:
귀사의 요구사항과 목표에 맞는 맞춤형 협력 방안을 함께 모색하겠습니다.
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
Various projects are already leveraging Fedify:
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
We're excited to explore customized collaboration opportunities that align with your requirements and goals.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
If you answered “No”, which installation method do you prefer?
Your feedback helps us prioritize distribution channels! Thanks for contributing to the Fedify ecosystem.
Option | Voters |
---|---|
npm | 3 (25%) |
Deno | 3 (25%) |
Manual download | 5 (42%) |
Other (please specify in replies) | 1 (8%) |
We're considering packaging the Fedify CLI for Homebrew to make installation easier on macOS and Linux (via Linuxbrew).
Option | Voters |
---|---|
Yes, I'd definitely use it on macOS. | 0 (0%) |
Yes, I'd definitely use it on Linux. | 0 (0%) |
Maybe, depending on the implementation. | 0 (0%) |
No, I prefer other installation methods. | 0 (0%) |
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
If you answered “No”, which installation method do you prefer?
Your feedback helps us prioritize distribution channels! Thanks for contributing to the Fedify ecosystem.
Option | Voters |
---|---|
npm | 3 (25%) |
Deno | 3 (25%) |
Manual download | 5 (42%) |
Other (please specify in replies) | 1 (8%) |
We're considering packaging the Fedify CLI for Homebrew to make installation easier on macOS and Linux (via Linuxbrew).
Option | Voters |
---|---|
Yes, I'd definitely use it on macOS. | 0 (0%) |
Yes, I'd definitely use it on Linux. | 0 (0%) |
Maybe, depending on the implementation. | 0 (0%) |
No, I prefer other installation methods. | 0 (0%) |
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I spoke with @hongminhee about ActivityPub, the Fediverse, and his experience implementing the specification!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I spoke with @hongminhee about ActivityPub, the Fediverse, and his experience implementing the specification!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I spoke with @hongminhee about ActivityPub, the Fediverse, and his experience implementing the specification!
Love building federated apps with #Fedify? Consider supporting its development! We have tiers starting from just $5/month, and every contribution helps keep the project sustainable.
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify
. One more way to get started with #ActivityPub development!
We'd like to introduce the #Fedify project family—a set of related tools that make building #ActivityPub applications more accessible:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedifyの関連プロジェクトをご紹介したいと思います。ActivityPubアプリケーション開発をより簡単にするツール群です:
Fedify(@fedify)はActivityPubやその他のフェディバース標準を活用する連合型サーバーアプリケーションを構築するためのTypeScriptライブラリです。Activity Vocabularyの型安全なオブジェクト、WebFingerクライアント・サーバー、HTTP Signaturesなどを提供し、ボイラープレートコードを削減してアプリケーションロジックに集中できるようにします。
Hollo(@hollo)はFedifyで動作するお一人様用マイクロブログサーバーです。個人向けに設計されていますが、ActivityPubを通じて完全に連合化されており、フェディバース全体のユーザーと交流することができます。HolloはMastodon互換APIを実装しているため、独自のウェブインターフェースがなくても、ほとんどのMastodonクライアントと互換性があります。
Holloはまた、正式リリース前の最新Fedify機能をテストする実験場としても活用されています。
BotKit(@botkit)は私たちの最も新しいメンバーで、ActivityPubボットを作成するために特別に設計されたフレームワークです。従来のMastodonボットとは異なり、BotKitはプラットフォーム固有の制限(文字数制限など)に縛られない独立したActivityPubサーバーを作成します。
BotKitのAPIは意図的にシンプルに設計されており、単一のTypeScriptファイルで完全なボットを作成できます!
これら三つのプロジェクトはすべて@fedify-dev GitHubオーガニゼーションでオープンソースとして公開されています。それぞれ異なる目的を持っていますが、ActivityPub開発をより身近にし、フェディバースのエコシステムを拡大するという共通の目標を共有しています。
これらのプロジェクトを試してみたり、開発に貢献したりすることに興味がある場合は、以下をご覧ください:
#Fedify #ActivityPub #フェディバース #fediverse #Hollo #BotKit #fedidev
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
#Fedify 자매 프로젝트들을 소개해 드리고자 합니다. #ActivityPub 애플리케이션 개발을 더 쉽게 만들어주는 관련 도구들입니다:
Fedify(@fedify)는 ActivityPub와 다른 #연합우주(#fediverse) 표준을 기반으로 연합 서버 애플리케이션을 구축하기 위한 #TypeScript 라이브러리입니다. Activity Vocabulary를 위한 타입 안전한 객체, WebFinger 클라이언트·서버, HTTP Signatures 등를 제공하여 반복적인 코드를 줄이고 애플리케이션 로직에 집중할 수 있게 해줍니다.
Hollo(@hollo)는 Fedify로 구동되는 1인 사용자용 마이크로블로깅 서버입니다. 1인 사용자를 위해 설계되었지만, ActivityPub를 통해 완전히 연합되어 연합우주 전체의 사용자들과 상호작용할 수 있습니다. Hollo는 Mastodon 호환 API를 구현하여 자체 웹 인터페이스 없이도 대부분의 Mastodon 클라이언트와 호환됩니다.
Hollo는 또한 정식 출시 전에 최신 Fedify 기능을 테스트하는 실험장으로도 활용되고 있습니다.
BotKit(@botkit)은 저희의 가장 새로운 구성원으로, ActivityPub 봇을 만들기 위해 특별히 설계된 프레임워크입니다. 전통적인 Mastodon 봇과 달리, BotKit은 플랫폼별 제한(글자 수 제한 등)에 구애받지 않는 독립적인 ActivityPub 서버를 만듭니다.
BotKit의 API는 의도적으로 단순하게 설계되어 단일 TypeScript 파일로 완전한 봇을 만들 수 있습니다!
세 프로젝트 모두 @fedify-dev GitHub 조직에서 오픈 소스로 공개되어 있습니다. 각기 다른 목적을 가지고 있지만, ActivityPub 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
We'd like to introduce the #Fedify project family—a set of related tools that make building #ActivityPub applications more accessible:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Two new features are coming to #Fedify! Both have to do with controls over domain names:
https://hollo.social/@fedify/01953693-1afd-7430-988a-23d649099e1c
Two new features are coming to #Fedify! Both have to do with controls over domain names:
https://hollo.social/@fedify/01953693-1afd-7430-988a-23d649099e1c
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
#Fedify 자매 프로젝트들을 소개해 드리고자 합니다. #ActivityPub 애플리케이션 개발을 더 쉽게 만들어주는 관련 도구들입니다:
Fedify(@fedify)는 ActivityPub와 다른 #연합우주(#fediverse) 표준을 기반으로 연합 서버 애플리케이션을 구축하기 위한 #TypeScript 라이브러리입니다. Activity Vocabulary를 위한 타입 안전한 객체, WebFinger 클라이언트·서버, HTTP Signatures 등를 제공하여 반복적인 코드를 줄이고 애플리케이션 로직에 집중할 수 있게 해줍니다.
Hollo(@hollo)는 Fedify로 구동되는 1인 사용자용 마이크로블로깅 서버입니다. 1인 사용자를 위해 설계되었지만, ActivityPub를 통해 완전히 연합되어 연합우주 전체의 사용자들과 상호작용할 수 있습니다. Hollo는 Mastodon 호환 API를 구현하여 자체 웹 인터페이스 없이도 대부분의 Mastodon 클라이언트와 호환됩니다.
Hollo는 또한 정식 출시 전에 최신 Fedify 기능을 테스트하는 실험장으로도 활용되고 있습니다.
BotKit(@botkit)은 저희의 가장 새로운 구성원으로, ActivityPub 봇을 만들기 위해 특별히 설계된 프레임워크입니다. 전통적인 Mastodon 봇과 달리, BotKit은 플랫폼별 제한(글자 수 제한 등)에 구애받지 않는 독립적인 ActivityPub 서버를 만듭니다.
BotKit의 API는 의도적으로 단순하게 설계되어 단일 TypeScript 파일로 완전한 봇을 만들 수 있습니다!
세 프로젝트 모두 @fedify-dev GitHub 조직에서 오픈 소스로 공개되어 있습니다. 각기 다른 목적을 가지고 있지만, ActivityPub 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedifyの関連プロジェクトをご紹介したいと思います。ActivityPubアプリケーション開発をより簡単にするツール群です:
Fedify(@fedify)はActivityPubやその他のフェディバース標準を活用する連合型サーバーアプリケーションを構築するためのTypeScriptライブラリです。Activity Vocabularyの型安全なオブジェクト、WebFingerクライアント・サーバー、HTTP Signaturesなどを提供し、ボイラープレートコードを削減してアプリケーションロジックに集中できるようにします。
Hollo(@hollo)はFedifyで動作するお一人様用マイクロブログサーバーです。個人向けに設計されていますが、ActivityPubを通じて完全に連合化されており、フェディバース全体のユーザーと交流することができます。HolloはMastodon互換APIを実装しているため、独自のウェブインターフェースがなくても、ほとんどのMastodonクライアントと互換性があります。
Holloはまた、正式リリース前の最新Fedify機能をテストする実験場としても活用されています。
BotKit(@botkit)は私たちの最も新しいメンバーで、ActivityPubボットを作成するために特別に設計されたフレームワークです。従来のMastodonボットとは異なり、BotKitはプラットフォーム固有の制限(文字数制限など)に縛られない独立したActivityPubサーバーを作成します。
BotKitのAPIは意図的にシンプルに設計されており、単一のTypeScriptファイルで完全なボットを作成できます!
これら三つのプロジェクトはすべて@fedify-dev GitHubオーガニゼーションでオープンソースとして公開されています。それぞれ異なる目的を持っていますが、ActivityPub開発をより身近にし、フェディバースのエコシステムを拡大するという共通の目標を共有しています。
これらのプロジェクトを試してみたり、開発に貢献したりすることに興味がある場合は、以下をご覧ください:
#Fedify #ActivityPub #フェディバース #fediverse #Hollo #BotKit #fedidev
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedifyの関連プロジェクトをご紹介したいと思います。ActivityPubアプリケーション開発をより簡単にするツール群です:
Fedify(@fedify)はActivityPubやその他のフェディバース標準を活用する連合型サーバーアプリケーションを構築するためのTypeScriptライブラリです。Activity Vocabularyの型安全なオブジェクト、WebFingerクライアント・サーバー、HTTP Signaturesなどを提供し、ボイラープレートコードを削減してアプリケーションロジックに集中できるようにします。
Hollo(@hollo)はFedifyで動作するお一人様用マイクロブログサーバーです。個人向けに設計されていますが、ActivityPubを通じて完全に連合化されており、フェディバース全体のユーザーと交流することができます。HolloはMastodon互換APIを実装しているため、独自のウェブインターフェースがなくても、ほとんどのMastodonクライアントと互換性があります。
Holloはまた、正式リリース前の最新Fedify機能をテストする実験場としても活用されています。
BotKit(@botkit)は私たちの最も新しいメンバーで、ActivityPubボットを作成するために特別に設計されたフレームワークです。従来のMastodonボットとは異なり、BotKitはプラットフォーム固有の制限(文字数制限など)に縛られない独立したActivityPubサーバーを作成します。
BotKitのAPIは意図的にシンプルに設計されており、単一のTypeScriptファイルで完全なボットを作成できます!
これら三つのプロジェクトはすべて@fedify-dev GitHubオーガニゼーションでオープンソースとして公開されています。それぞれ異なる目的を持っていますが、ActivityPub開発をより身近にし、フェディバースのエコシステムを拡大するという共通の目標を共有しています。
これらのプロジェクトを試してみたり、開発に貢献したりすることに興味がある場合は、以下をご覧ください:
#Fedify #ActivityPub #フェディバース #fediverse #Hollo #BotKit #fedidev
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
#Fedify 자매 프로젝트들을 소개해 드리고자 합니다. #ActivityPub 애플리케이션 개발을 더 쉽게 만들어주는 관련 도구들입니다:
Fedify(@fedify)는 ActivityPub와 다른 #연합우주(#fediverse) 표준을 기반으로 연합 서버 애플리케이션을 구축하기 위한 #TypeScript 라이브러리입니다. Activity Vocabulary를 위한 타입 안전한 객체, WebFinger 클라이언트·서버, HTTP Signatures 등를 제공하여 반복적인 코드를 줄이고 애플리케이션 로직에 집중할 수 있게 해줍니다.
Hollo(@hollo)는 Fedify로 구동되는 1인 사용자용 마이크로블로깅 서버입니다. 1인 사용자를 위해 설계되었지만, ActivityPub를 통해 완전히 연합되어 연합우주 전체의 사용자들과 상호작용할 수 있습니다. Hollo는 Mastodon 호환 API를 구현하여 자체 웹 인터페이스 없이도 대부분의 Mastodon 클라이언트와 호환됩니다.
Hollo는 또한 정식 출시 전에 최신 Fedify 기능을 테스트하는 실험장으로도 활용되고 있습니다.
BotKit(@botkit)은 저희의 가장 새로운 구성원으로, ActivityPub 봇을 만들기 위해 특별히 설계된 프레임워크입니다. 전통적인 Mastodon 봇과 달리, BotKit은 플랫폼별 제한(글자 수 제한 등)에 구애받지 않는 독립적인 ActivityPub 서버를 만듭니다.
BotKit의 API는 의도적으로 단순하게 설계되어 단일 TypeScript 파일로 완전한 봇을 만들 수 있습니다!
세 프로젝트 모두 @fedify-dev GitHub 조직에서 오픈 소스로 공개되어 있습니다. 각기 다른 목적을 가지고 있지만, ActivityPub 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
We'd like to introduce the #Fedify project family—a set of related tools that make building #ActivityPub applications more accessible:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Two new features are coming to #Fedify! Both have to do with controls over domain names:
https://hollo.social/@fedify/01953693-1afd-7430-988a-23d649099e1c
Yes, we probably should have had this sooner… but hey, proper domain handling is coming to #Fedify 1.5.0!
https://hollo.social/@fedify/01953693-1afd-7430-988a-23d649099e1c
We're excited to announce two major features coming in #Fedify 1.5.0, focused on giving you more control over domain names in your federated apps:
Want different domains for your WebFinger handles and server URIs? Fedify 1.5.0 will let you use domains like @[email protected]
as fediverse handles while serving content from https://ap.example.com
. This gives you more flexibility in how you structure your federated services.
Need to ensure consistent URLs across your infrastructure? The new canonical origin support lets you explicitly set your server's authoritative domain. This is particularly useful when running behind reverse proxies or load balancers—no more unexpected URLs generated from internal hostnames.
These features represent our ongoing commitment to making Fedify more flexible and production-ready.
Can't wait to try these features? You can experiment with them today using our unstable release v1.5.0-dev.680+562e3dc0 (JSR & npm). Keep in mind that this is an unstable release intended for testing—use it in production at your own risk.
Otherwise, stay tuned for the stable Fedify 1.5.0 release!
We're excited to announce two major features coming in #Fedify 1.5.0, focused on giving you more control over domain names in your federated apps:
Want different domains for your WebFinger handles and server URIs? Fedify 1.5.0 will let you use domains like @[email protected]
as fediverse handles while serving content from https://ap.example.com
. This gives you more flexibility in how you structure your federated services.
Need to ensure consistent URLs across your infrastructure? The new canonical origin support lets you explicitly set your server's authoritative domain. This is particularly useful when running behind reverse proxies or load balancers—no more unexpected URLs generated from internal hostnames.
These features represent our ongoing commitment to making Fedify more flexible and production-ready.
Can't wait to try these features? You can experiment with them today using our unstable release v1.5.0-dev.680+562e3dc0 (JSR & npm). Keep in mind that this is an unstable release intended for testing—use it in production at your own risk.
Otherwise, stay tuned for the stable Fedify 1.5.0 release!
We're excited to announce two major features coming in #Fedify 1.5.0, focused on giving you more control over domain names in your federated apps:
Want different domains for your WebFinger handles and server URIs? Fedify 1.5.0 will let you use domains like @[email protected]
as fediverse handles while serving content from https://ap.example.com
. This gives you more flexibility in how you structure your federated services.
Need to ensure consistent URLs across your infrastructure? The new canonical origin support lets you explicitly set your server's authoritative domain. This is particularly useful when running behind reverse proxies or load balancers—no more unexpected URLs generated from internal hostnames.
These features represent our ongoing commitment to making Fedify more flexible and production-ready.
Can't wait to try these features? You can experiment with them today using our unstable release v1.5.0-dev.680+562e3dc0 (JSR & npm). Keep in mind that this is an unstable release intended for testing—use it in production at your own risk.
Otherwise, stay tuned for the stable Fedify 1.5.0 release!
I set up a fedi bot that creates Severance "facts about your outie" after I saw some amusing ones floating around this morning. Good opportunity to get familiar with #fedify and #botkit https://outiebot.jamesravey.me/message/01952eb5-81f4-709f-95fc-44d2d3be86fc
I set up a fedi bot that creates Severance "facts about your outie" after I saw some amusing ones floating around this morning. Good opportunity to get familiar with #fedify and #botkit https://outiebot.jamesravey.me/message/01952eb5-81f4-709f-95fc-44d2d3be86fc
Today's my work on #Fedify: Support PEM-PKCS#1 besides PEM-SPKI for RSA public keys.
Although the vast majority of ActivityPub software encodes RSA public keys in PEM-SPKI format, some software encodes RSA public keys in PEM-PKCS#1 format (see: https://github.com/fedify-dev/hollo/pull/109#issuecomment-2662591619). Fedify currently only accepts PEM-SPKI format, so it needs to accept PEM-PKCS#1 format as well for better interoperability.
Today's my work on #Fedify: Support PEM-PKCS#1 besides PEM-SPKI for RSA public keys.
Although the vast majority of ActivityPub software encodes RSA public keys in PEM-SPKI format, some software encodes RSA public keys in PEM-PKCS#1 format (see: https://github.com/fedify-dev/hollo/pull/109#issuecomment-2662591619). Fedify currently only accepts PEM-SPKI format, so it needs to accept PEM-PKCS#1 format as well for better interoperability.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
FedifyはActivityPubプロトコルの実装を簡単にするTypeScriptフレームワークです。連合プロトコルの複雑な実装に困っていませんか?Fedifyがお手伝いします!
MITライセンスで自由に利用可能なオープンソースプロジェクトです!
#Fedify #フェディバース #fediverse #fedidev #TypeScript #ActivityPub
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedify는 #ActivityPub 프로토콜 구현을 도와주는 #TypeScript 프레임워크입니다. 복잡한 연합 프로토콜을 쉽게 구현하고 싶으신가요? Fedify가 도와드립니다!
오픈소스 #MIT 라이선스로 누구나 자유롭게 사용할 수 있습니다!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Available under the #MIT license—free and open source!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
FedifyはActivityPubプロトコルの実装を簡単にするTypeScriptフレームワークです。連合プロトコルの複雑な実装に困っていませんか?Fedifyがお手伝いします!
MITライセンスで自由に利用可能なオープンソースプロジェクトです!
#Fedify #フェディバース #fediverse #fedidev #TypeScript #ActivityPub
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
FedifyはActivityPubプロトコルの実装を簡単にするTypeScriptフレームワークです。連合プロトコルの複雑な実装に困っていませんか?Fedifyがお手伝いします!
MITライセンスで自由に利用可能なオープンソースプロジェクトです!
#Fedify #フェディバース #fediverse #fedidev #TypeScript #ActivityPub
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
FedifyはActivityPubプロトコルの実装を簡単にするTypeScriptフレームワークです。連合プロトコルの複雑な実装に困っていませんか?Fedifyがお手伝いします!
MITライセンスで自由に利用可能なオープンソースプロジェクトです!
#Fedify #フェディバース #fediverse #fedidev #TypeScript #ActivityPub
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedify는 #ActivityPub 프로토콜 구현을 도와주는 #TypeScript 프레임워크입니다. 복잡한 연합 프로토콜을 쉽게 구현하고 싶으신가요? Fedify가 도와드립니다!
오픈소스 #MIT 라이선스로 누구나 자유롭게 사용할 수 있습니다!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Available under the #MIT license—free and open source!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
FedifyはActivityPubプロトコルの実装を簡単にするTypeScriptフレームワークです。連合プロトコルの複雑な実装に困っていませんか?Fedifyがお手伝いします!
MITライセンスで自由に利用可能なオープンソースプロジェクトです!
#Fedify #フェディバース #fediverse #fedidev #TypeScript #ActivityPub
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
Fedify는 #ActivityPub 프로토콜 구현을 도와주는 #TypeScript 프레임워크입니다. 복잡한 연합 프로토콜을 쉽게 구현하고 싶으신가요? Fedify가 도와드립니다!
오픈소스 #MIT 라이선스로 누구나 자유롭게 사용할 수 있습니다!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Available under the #MIT license—free and open source!
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify
. One more way to get started with #ActivityPub development!
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify
. One more way to get started with #ActivityPub development!
Just integrated #Deno's new workspaces feature into the #Fedify repository! This means we can now manage the main package, CLI tool, and examples all in one place. The best part? No more custom import map generators—everything's simpler and more intuitive for new contributors. Loving how Deno 2.0's workspace support makes managing monorepos so much cleaner.
Love building federated apps with #Fedify? Consider supporting its development! We have tiers starting from just $5/month, and every contribution helps keep the project sustainable.
Love building federated apps with #Fedify? Consider supporting its development! We have tiers starting from just $5/month, and every contribution helps keep the project sustainable.
We're considering adding custom background task support to #Fedify 1.5.0. Got thoughts on whether Fedify should support user-defined background tasks alongside ActivityPub operations? Check out the proposal and share your feedback: https://github.com/fedify-dev/fedify/issues/206.
https://hollo.social/@fedify/0194ea5a-9856-703f-b098-d4f52936b500
We're considering adding custom background task support to #Fedify 1.5.0.
Want to use Fedify's worker system for your own background tasks? We're exploring ways to let you register and process custom tasks alongside #ActivityPub jobs.
Check out the proposal: https://github.com/fedify-dev/fedify/issues/206.
Key considerations:
We'd love to hear your thoughts! Do you need this feature? How would you use it? Share your feedback in the issue thread.
Following Mastodon's plan to adopt HTTP Message Signatures (RFC 9421), we will implement the same standard in #Fedify. We'll use “double-knocking” to maintain compatibility with servers using older signature versions (draft-cavage-http-signatures-12).
@[email protected] · Reply to @reiver ⊼ (Charles) :batman:'s post
@reiver @andypiper @rwg @andresmh Re: which networks, I haven't personally done any academic research about social platforms. Pondering questions, yes, written anything down, no.
But my FOSS work has been centered on ActivityPub lately: https://fietkau.software/tag/fediverse
I have a project cooking that I think you'll like, for which I'm hoping to run a semi-public alpha test within the next few months. Join the @fedify Matrix room at #fedify-users:matrix.org to witness my implementation struggles. 👍
A milestone worth celebrating—#Fedify just hit 100+ releases! From day one, we've been committed to building a robust #ActivityPub framework, and each release has brought us closer to that goal. Here's to many more releases as we continue growing the #fediverse together! #fedidev
Following Mastodon's plan to adopt HTTP Message Signatures (RFC 9421), we will implement the same standard in #Fedify. We'll use “double-knocking” to maintain compatibility with servers using older signature versions (draft-cavage-http-signatures-12).
Following Mastodon's plan to adopt HTTP Message Signatures (RFC 9421), we will implement the same standard in #Fedify. We'll use “double-knocking” to maintain compatibility with servers using older signature versions (draft-cavage-http-signatures-12).
㊗️ #Fedify 總 릴리스 數 100番 넘다!
https://hollo.social/@fedify/0194efd6-a7c2-79f6-925b-737fc57138b8
A milestone worth celebrating—#Fedify just hit 100+ releases! From day one, we've been committed to building a robust #ActivityPub framework, and each release has brought us closer to that goal. Here's to many more releases as we continue growing the #fediverse together! #fedidev
A milestone worth celebrating—#Fedify just hit 100+ releases! From day one, we've been committed to building a robust #ActivityPub framework, and each release has brought us closer to that goal. Here's to many more releases as we continue growing the #fediverse together! #fedidev
We're considering adding custom background task support to #Fedify 1.5.0.
Want to use Fedify's worker system for your own background tasks? We're exploring ways to let you register and process custom tasks alongside #ActivityPub jobs.
Check out the proposal: https://github.com/fedify-dev/fedify/issues/206.
Key considerations:
We'd love to hear your thoughts! Do you need this feature? How would you use it? Share your feedback in the issue thread.
We're considering adding custom background task support to #Fedify 1.5.0. Got thoughts on whether Fedify should support user-defined background tasks alongside ActivityPub operations? Check out the proposal and share your feedback: https://github.com/fedify-dev/fedify/issues/206.
https://hollo.social/@fedify/0194ea5a-9856-703f-b098-d4f52936b500
We're considering adding custom background task support to #Fedify 1.5.0.
Want to use Fedify's worker system for your own background tasks? We're exploring ways to let you register and process custom tasks alongside #ActivityPub jobs.
Check out the proposal: https://github.com/fedify-dev/fedify/issues/206.
Key considerations:
We'd love to hear your thoughts! Do you need this feature? How would you use it? Share your feedback in the issue thread.
We're considering adding custom background task support to #Fedify 1.5.0.
Want to use Fedify's worker system for your own background tasks? We're exploring ways to let you register and process custom tasks alongside #ActivityPub jobs.
Check out the proposal: https://github.com/fedify-dev/fedify/issues/206.
Key considerations:
We'd love to hear your thoughts! Do you need this feature? How would you use it? Share your feedback in the issue thread.
We're considering adding custom background task support to #Fedify 1.5.0.
Want to use Fedify's worker system for your own background tasks? We're exploring ways to let you register and process custom tasks alongside #ActivityPub jobs.
Check out the proposal: https://github.com/fedify-dev/fedify/issues/206.
Key considerations:
We'd love to hear your thoughts! Do you need this feature? How would you use it? Share your feedback in the issue thread.
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
Added the ability to customize WebFinger responses through the new mapAlias()
API, giving you more control over how your actors are discovered.
Added support for shares
, likes
, and emojiReactions
properties to the Object
class, making it easier to access and traverse these interaction collections.
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
The fedify lookup
command now supports two new options:
-t/--traverse
: Traverse through collection objects-S/--suppress-errors
: Continue operation even when encountering errors during traversalContext.getNodeInfo()
method for easier NodeInfo accessUser-Agent
headers now automatically include your instance URL, making it easier for other servers to identify your instanceFor the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
#Fedify 1.4.0 has been released, and #BotKit 0.1.0 will be based on Fedify 1.4.0. BotKit 0.1.0 is also about to be released, so please stay tuned!
https://hollo.social/@fedify/0194d42d-ee82-7a21-b66e-f88702278099
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
Added the ability to customize WebFinger responses through the new mapAlias()
API, giving you more control over how your actors are discovered.
Added support for shares
, likes
, and emojiReactions
properties to the Object
class, making it easier to access and traverse these interaction collections.
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
The fedify lookup
command now supports two new options:
-t/--traverse
: Traverse through collection objects-S/--suppress-errors
: Continue operation even when encountering errors during traversalContext.getNodeInfo()
method for easier NodeInfo accessUser-Agent
headers now automatically include your instance URL, making it easier for other servers to identify your instanceFor the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
#Fedify 1.4.0 has been released, and #BotKit 0.1.0 will be based on Fedify 1.4.0. BotKit 0.1.0 is also about to be released, so please stay tuned!
https://hollo.social/@fedify/0194d42d-ee82-7a21-b66e-f88702278099
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
Added the ability to customize WebFinger responses through the new mapAlias()
API, giving you more control over how your actors are discovered.
Added support for shares
, likes
, and emojiReactions
properties to the Object
class, making it easier to access and traverse these interaction collections.
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
The fedify lookup
command now supports two new options:
-t/--traverse
: Traverse through collection objects-S/--suppress-errors
: Continue operation even when encountering errors during traversalContext.getNodeInfo()
method for easier NodeInfo accessUser-Agent
headers now automatically include your instance URL, making it easier for other servers to identify your instanceFor the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
#Fedify 1.4.0 has been released, and #BotKit 0.1.0 will be based on Fedify 1.4.0. BotKit 0.1.0 is also about to be released, so please stay tuned!
https://hollo.social/@fedify/0194d42d-ee82-7a21-b66e-f88702278099
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
Added the ability to customize WebFinger responses through the new mapAlias()
API, giving you more control over how your actors are discovered.
Added support for shares
, likes
, and emojiReactions
properties to the Object
class, making it easier to access and traverse these interaction collections.
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
The fedify lookup
command now supports two new options:
-t/--traverse
: Traverse through collection objects-S/--suppress-errors
: Continue operation even when encountering errors during traversalContext.getNodeInfo()
method for easier NodeInfo accessUser-Agent
headers now automatically include your instance URL, making it easier for other servers to identify your instanceFor the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
Added the ability to customize WebFinger responses through the new mapAlias()
API, giving you more control over how your actors are discovered.
Added support for shares
, likes
, and emojiReactions
properties to the Object
class, making it easier to access and traverse these interaction collections.
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
The fedify lookup
command now supports two new options:
-t/--traverse
: Traverse through collection objects-S/--suppress-errors
: Continue operation even when encountering errors during traversalContext.getNodeInfo()
method for easier NodeInfo accessUser-Agent
headers now automatically include your instance URL, making it easier for other servers to identify your instanceFor the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
Just released #Fedify 1.4.0!
https://hollo.social/@fedify/0194d42d-ee82-7a21-b66e-f88702278099
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
Added the ability to customize WebFinger responses through the new mapAlias()
API, giving you more control over how your actors are discovered.
Added support for shares
, likes
, and emojiReactions
properties to the Object
class, making it easier to access and traverse these interaction collections.
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
The fedify lookup
command now supports two new options:
-t/--traverse
: Traverse through collection objects-S/--suppress-errors
: Continue operation even when encountering errors during traversalContext.getNodeInfo()
method for easier NodeInfo accessUser-Agent
headers now automatically include your instance URL, making it easier for other servers to identify your instanceFor the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
Just released #Fedify 1.4.0!
https://hollo.social/@fedify/0194d42d-ee82-7a21-b66e-f88702278099
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
Added the ability to customize WebFinger responses through the new mapAlias()
API, giving you more control over how your actors are discovered.
Added support for shares
, likes
, and emojiReactions
properties to the Object
class, making it easier to access and traverse these interaction collections.
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
The fedify lookup
command now supports two new options:
-t/--traverse
: Traverse through collection objects-S/--suppress-errors
: Continue operation even when encountering errors during traversalContext.getNodeInfo()
method for easier NodeInfo accessUser-Agent
headers now automatically include your instance URL, making it easier for other servers to identify your instanceFor the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
Added the ability to customize WebFinger responses through the new mapAlias()
API, giving you more control over how your actors are discovered.
Added support for shares
, likes
, and emojiReactions
properties to the Object
class, making it easier to access and traverse these interaction collections.
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
The fedify lookup
command now supports two new options:
-t/--traverse
: Traverse through collection objects-S/--suppress-errors
: Continue operation even when encountering errors during traversalContext.getNodeInfo()
method for easier NodeInfo accessUser-Agent
headers now automatically include your instance URL, making it easier for other servers to identify your instanceFor the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
Added the ability to customize WebFinger responses through the new mapAlias()
API, giving you more control over how your actors are discovered.
Added support for shares
, likes
, and emojiReactions
properties to the Object
class, making it easier to access and traverse these interaction collections.
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
The fedify lookup
command now supports two new options:
-t/--traverse
: Traverse through collection objects-S/--suppress-errors
: Continue operation even when encountering errors during traversalContext.getNodeInfo()
method for easier NodeInfo accessUser-Agent
headers now automatically include your instance URL, making it easier for other servers to identify your instanceFor the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
Okay, I'm about to release #Fedify 1.4.0. Probably today or tomorrow?
Okay, I'm about to release #Fedify 1.4.0. Probably today or tomorrow?
Made a little bit of progress on my #Fedify project yesterday. Spun my wheels testing a few #TypeScript ORMs and running into compatibility problems with each of them. By the time I went to bed, the preferences page was capable of storing and loading account-local form data for the first time. 🥳
For this project, when progress looks slow from the outside, it's because I'm learning the ecosystem pretty much from scratch. Not letting myself get discouraged. 🙂
Made a little bit of progress on my #Fedify project yesterday. Spun my wheels testing a few #TypeScript ORMs and running into compatibility problems with each of them. By the time I went to bed, the preferences page was capable of storing and loading account-local form data for the first time. 🥳
For this project, when progress looks slow from the outside, it's because I'm learning the ecosystem pretty much from scratch. Not letting myself get discouraged. 🙂
Eg har nett støtta @fedify ! Dei har fleire kule prosjekt. @[email protected] køyrer på deira teneste @hollo.
English:
I've just contributed to #Fedify They have several cool projects. @[email protected] runs on their service #Hollo.
Eg har nett støtta @fedify ! Dei har fleire kule prosjekt. @[email protected] køyrer på deira teneste @hollo.
English:
I've just contributed to #Fedify They have several cool projects. @[email protected] runs on their service #Hollo.
Eg har nett støtta @fedify ! Dei har fleire kule prosjekt. @[email protected] køyrer på deira teneste @hollo.
English:
I've just contributed to #Fedify They have several cool projects. @[email protected] runs on their service #Hollo.
Eg har nett støtta @fedify ! Dei har fleire kule prosjekt. @[email protected] køyrer på deira teneste @hollo.
English:
I've just contributed to #Fedify They have several cool projects. @[email protected] runs on their service #Hollo.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've just set up our sponsors showcase! You can now find our wonderful sponsors:
These pages are automatically updated every hour. Thank you to all our sponsors for supporting #Fedify's development!
Want to be listed? Support us on Open Collective: https://opencollective.com/fedify.
As the maintainer of #Fedify, I'd be grateful for your support to help keep the project sustainable!
https://hollo.social/@fedify/0194b112-b604-7d03-84e0-4faaf4ab46cd
🎉 Excited to announce that #Fedify is now on Open Collective! Support the project's development starting at:
Your support will help us maintain and improve Fedify. Check it out here:
https://opencollective.com/fedify
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've just set up our sponsors showcase! You can now find our wonderful sponsors:
These pages are automatically updated every hour. Thank you to all our sponsors for supporting #Fedify's development!
Want to be listed? Support us on Open Collective: https://opencollective.com/fedify.
As the maintainer of #Fedify, I'd be grateful for your support to help keep the project sustainable!
https://hollo.social/@fedify/0194b112-b604-7d03-84e0-4faaf4ab46cd
🎉 Excited to announce that #Fedify is now on Open Collective! Support the project's development starting at:
Your support will help us maintain and improve Fedify. Check it out here:
https://opencollective.com/fedify
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've just set up our sponsors showcase! You can now find our wonderful sponsors:
These pages are automatically updated every hour. Thank you to all our sponsors for supporting #Fedify's development!
Want to be listed? Support us on Open Collective: https://opencollective.com/fedify.
As the maintainer of #Fedify, I'd be grateful for your support to help keep the project sustainable!
https://hollo.social/@fedify/0194b112-b604-7d03-84e0-4faaf4ab46cd
🎉 Excited to announce that #Fedify is now on Open Collective! Support the project's development starting at:
Your support will help us maintain and improve Fedify. Check it out here:
https://opencollective.com/fedify
🎉 Excited to announce that #Fedify is now on Open Collective! Support the project's development starting at:
Your support will help us maintain and improve Fedify. Check it out here:
https://opencollective.com/fedify
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've just set up our sponsors showcase! You can now find our wonderful sponsors:
These pages are automatically updated every hour. Thank you to all our sponsors for supporting #Fedify's development!
Want to be listed? Support us on Open Collective: https://opencollective.com/fedify.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've just set up our sponsors showcase! You can now find our wonderful sponsors:
These pages are automatically updated every hour. Thank you to all our sponsors for supporting #Fedify's development!
Want to be listed? Support us on Open Collective: https://opencollective.com/fedify.
I want to automatically list the names of people who have sponsored #Fedify with Open Collective in README.md. Is there a good way to do this? (I think I can use GitHub Actions or Open Collective's webhooks, but it's a bit of a hassle to create it myself.)
As the maintainer of #Fedify, I'd be grateful for your support to help keep the project sustainable!
https://hollo.social/@fedify/0194b112-b604-7d03-84e0-4faaf4ab46cd
🎉 Excited to announce that #Fedify is now on Open Collective! Support the project's development starting at:
Your support will help us maintain and improve Fedify. Check it out here:
https://opencollective.com/fedify
🎉 Excited to announce that #Fedify is now on Open Collective! Support the project's development starting at:
Your support will help us maintain and improve Fedify. Check it out here:
https://opencollective.com/fedify
As the maintainer of #Fedify, I'd be grateful for your support to help keep the project sustainable!
https://hollo.social/@fedify/0194b112-b604-7d03-84e0-4faaf4ab46cd
🎉 Excited to announce that #Fedify is now on Open Collective! Support the project's development starting at:
Your support will help us maintain and improve Fedify. Check it out here:
https://opencollective.com/fedify
🎉 Excited to announce that #Fedify is now on Open Collective! Support the project's development starting at:
Your support will help us maintain and improve Fedify. Check it out here:
https://opencollective.com/fedify
🎉 Excited to announce that #Fedify is now on Open Collective! Support the project's development starting at:
Your support will help us maintain and improve Fedify. Check it out here:
https://opencollective.com/fedify
Valtteri Laitinen (@valtlai) managed to get #Fedify running on #Cloudflare Workers!
@[email protected] · Reply to Valtteri Laitinen's post
@thisismissem @fedify I got this working with the JSR package by adding a Temporal polyfill and stripping import attributes (see https://github.com/fedify-dev/fedify/issues/161#issuecomment-2618947880).
Valtteri Laitinen (@valtlai) managed to get #Fedify running on #Cloudflare Workers!
@[email protected] · Reply to Valtteri Laitinen's post
@thisismissem @fedify I got this working with the JSR package by adding a Temporal polyfill and stripping import attributes (see https://github.com/fedify-dev/fedify/issues/161#issuecomment-2618947880).
I passed the review to open a #Fedify collective on Open Collective, and now I'm thinking about how to structure the contribution tiers. 🤔
I passed the review to open a #Fedify collective on Open Collective, and now I'm thinking about how to structure the contribution tiers. 🤔
📢 Important announcement! #BotKit's #GitHub repository has moved to a new home! 🏠
The repository is now located at @fedify-dev/botkit (previously @dahlia/botkit). All future development will continue at the new location.
Don't worry—everything's the same, just a new address! Please update your bookmarks and project references. Thanks for being part of our community!
#Fedify #ActivityPub #fediverse #fedidev
https://hollo.social/@fedify/0194a851-581d-779c-b777-dc39e753ef14
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've just moved the #Fedify project and related repositories to our new GitHub organization account, @fedify-dev! 🎉
Here's what moved:
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
New GitHub organization: https://github.com/fedify-dev.
📢 Important announcement! #BotKit's #GitHub repository has moved to a new home! 🏠
The repository is now located at @fedify-dev/botkit (previously @dahlia/botkit). All future development will continue at the new location.
Don't worry—everything's the same, just a new address! Please update your bookmarks and project references. Thanks for being part of our community!
#Fedify #ActivityPub #fediverse #fedidev
https://hollo.social/@fedify/0194a851-581d-779c-b777-dc39e753ef14
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've just moved the #Fedify project and related repositories to our new GitHub organization account, @fedify-dev! 🎉
Here's what moved:
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
New GitHub organization: https://github.com/fedify-dev.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've just moved the #Fedify project and related repositories to our new GitHub organization account, @fedify-dev! 🎉
Here's what moved:
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
New GitHub organization: https://github.com/fedify-dev.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've just moved the #Fedify project and related repositories to our new GitHub organization account, @fedify-dev! 🎉
Here's what moved:
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
New GitHub organization: https://github.com/fedify-dev.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've just moved the #Fedify project and related repositories to our new GitHub organization account, @fedify-dev! 🎉
Here's what moved:
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
New GitHub organization: https://github.com/fedify-dev.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've just moved the #Fedify project and related repositories to our new GitHub organization account, @fedify-dev! 🎉
Here's what moved:
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
New GitHub organization: https://github.com/fedify-dev.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've just moved the #Fedify project and related repositories to our new GitHub organization account, @fedify-dev! 🎉
Here's what moved:
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
New GitHub organization: https://github.com/fedify-dev.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've just moved the #Fedify project and related repositories to our new GitHub organization account, @fedify-dev! 🎉
Here's what moved:
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
New GitHub organization: https://github.com/fedify-dev.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
We've just moved the #Fedify project and related repositories to our new GitHub organization account, @fedify-dev! 🎉
Here's what moved:
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
New GitHub organization: https://github.com/fedify-dev.
Introducing #BotKit: A #TypeScript framework for creating truly standalone #ActivityPub bots!
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
#Fedify already uses the #Temporal API exclusively for representing temporal data.
https://developer.mozilla.org/en-US/blog/javascript-temporal-is-coming/
If you'd like to support the development of @fedify or @hollo or @botkit, you can sponsor me on GitHub!
If you'd like to support the development of @fedify or @hollo or @botkit, you can sponsor me on GitHub!
If you'd like to support the development of @fedify or @hollo or @botkit, you can sponsor me on GitHub!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
「@fedify」や「@hollo」や「@botkit」の開発を支援したい方は、GitHubでスポンサーになってください!
https://github.com/sponsors/dahlia
#ActivityPub #fediverse #フェディバース #Fedify #Hollo #BotKit #スポンサー
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
제 프로젝트인 @fedify, @hollo, @botkit 等의 開發을 後援하고 싶으신 분들께서는, GitHub에서 제 스폰서가 되어 주세요!
https://github.com/sponsors/dahlia
#ActivityPub #fediverse #페디버스 #聯合宇宙 #연합우주 #Fedify #Hollo #BotKit #스폰서 #후원
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
「@fedify」や「@hollo」や「@botkit」の開発を支援したい方は、GitHubでスポンサーになってください!
https://github.com/sponsors/dahlia
#ActivityPub #fediverse #フェディバース #Fedify #Hollo #BotKit #スポンサー
If you'd like to support the development of @fedify or @hollo or @botkit, you can sponsor me on GitHub!
If you are a #fediverse admin running libraries on #Fedify keep an eye on this: https://nvd.nist.gov/vuln/detail/CVE-2025-23221
If you are a #fediverse admin running libraries on #Fedify keep an eye on this: https://nvd.nist.gov/vuln/detail/CVE-2025-23221
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
FedifyのWebFinger実装における脆弱性CVE-2025-23221に対するセキュリティアップデート(1.0.14、1.1.11、1.2.11、1.3.4)をリリースいたしました。すべてのユーザー様におかれましては、お使いのバージョンに応じた最新版への速やかなアップデートを推奨いたします。
セキュリティ研究者により、FedifyのlookupWebFinger()
関数において以下のセキュリティ上の問題が発見されました:
本セキュリティアップデートでは、以下の修正が実施されました:
以下のコマンドで最新のセキュアバージョンにアップデートできます:
# npmユーザーの場合
npm update @fedify/fedify
# Denoユーザーの場合
deno add jsr:@fedify/fedify
この脆弱性を責任を持って報告していただいたセキュリティ研究者の方に感謝申し上げます。迅速な対応が可能となりました。
本脆弱性の詳細については、セキュリティ勧告をご参照ください。
ご質問やご懸念がございましたら、GitHub Discussions、Matrixチャットスペース、またはDiscordサーバーまでお気軽にご連絡ください。
If you are a #fediverse admin running libraries on #Fedify keep an eye on this: https://nvd.nist.gov/vuln/detail/CVE-2025-23221
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
FedifyのWebFinger実装における脆弱性CVE-2025-23221に対するセキュリティアップデート(1.0.14、1.1.11、1.2.11、1.3.4)をリリースいたしました。すべてのユーザー様におかれましては、お使いのバージョンに応じた最新版への速やかなアップデートを推奨いたします。
セキュリティ研究者により、FedifyのlookupWebFinger()
関数において以下のセキュリティ上の問題が発見されました:
本セキュリティアップデートでは、以下の修正が実施されました:
以下のコマンドで最新のセキュアバージョンにアップデートできます:
# npmユーザーの場合
npm update @fedify/fedify
# Denoユーザーの場合
deno add jsr:@fedify/fedify
この脆弱性を責任を持って報告していただいたセキュリティ研究者の方に感謝申し上げます。迅速な対応が可能となりました。
本脆弱性の詳細については、セキュリティ勧告をご参照ください。
ご質問やご懸念がございましたら、GitHub Discussions、Matrixチャットスペース、またはDiscordサーバーまでお気軽にご連絡ください。
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
FedifyのWebFinger実装における脆弱性CVE-2025-23221に対するセキュリティアップデート(1.0.14、1.1.11、1.2.11、1.3.4)をリリースいたしました。すべてのユーザー様におかれましては、お使いのバージョンに応じた最新版への速やかなアップデートを推奨いたします。
セキュリティ研究者により、FedifyのlookupWebFinger()
関数において以下のセキュリティ上の問題が発見されました:
本セキュリティアップデートでは、以下の修正が実施されました:
以下のコマンドで最新のセキュアバージョンにアップデートできます:
# npmユーザーの場合
npm update @fedify/fedify
# Denoユーザーの場合
deno add jsr:@fedify/fedify
この脆弱性を責任を持って報告していただいたセキュリティ研究者の方に感謝申し上げます。迅速な対応が可能となりました。
本脆弱性の詳細については、セキュリティ勧告をご参照ください。
ご質問やご懸念がございましたら、GitHub Discussions、Matrixチャットスペース、またはDiscordサーバーまでお気軽にご連絡ください。
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
#Fedify 프레임워크의 #WebFinger 구현에서 발견된 보안 취약점 CVE-2025-23221을 해결하기 위한 보안 업데이트(1.0.14, 1.1.11, 1.2.11, 1.3.4)를 배포했습니다. 모든 사용자께서는 각자 사용 중인 버전에 해당하는 최신 버전으로 즉시 업데이트하시기를 권장합니다.
보안 연구자가 Fedify의 lookupWebFinger()
함수에서 다음과 같은 보안 문제점들을 발견했습니다:
이번 보안 업데이트에는 다음과 같은 수정 사항이 포함되어 있습니다:
다음 명령어로 최신 보안 버전으로 업데이트하실 수 있습니다:
# npm 사용자의 경우
npm update @fedify/fedify
# Deno 사용자의 경우
deno add jsr:@fedify/fedify
이 취약점을 책임감 있게 보고해 주신 보안 연구자께 감사드립니다. 덕분에 신속하게 문제를 해결할 수 있었습니다.
이 취약점에 대한 자세한 내용은 보안 권고문을 참고해 주시기 바랍니다.
문의 사항이나 우려 사항이 있으시다면 GitHub Discussions나 Matrix 채팅방, 또는 Discord 서버를 통해 언제든 연락해 주시기 바랍니다.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
FedifyのWebFinger実装における脆弱性CVE-2025-23221に対するセキュリティアップデート(1.0.14、1.1.11、1.2.11、1.3.4)をリリースいたしました。すべてのユーザー様におかれましては、お使いのバージョンに応じた最新版への速やかなアップデートを推奨いたします。
セキュリティ研究者により、FedifyのlookupWebFinger()
関数において以下のセキュリティ上の問題が発見されました:
本セキュリティアップデートでは、以下の修正が実施されました:
以下のコマンドで最新のセキュアバージョンにアップデートできます:
# npmユーザーの場合
npm update @fedify/fedify
# Denoユーザーの場合
deno add jsr:@fedify/fedify
この脆弱性を責任を持って報告していただいたセキュリティ研究者の方に感謝申し上げます。迅速な対応が可能となりました。
本脆弱性の詳細については、セキュリティ勧告をご参照ください。
ご質問やご懸念がございましたら、GitHub Discussions、Matrixチャットスペース、またはDiscordサーバーまでお気軽にご連絡ください。
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
#Fedify 프레임워크의 #WebFinger 구현에서 발견된 보안 취약점 CVE-2025-23221을 해결하기 위한 보안 업데이트(1.0.14, 1.1.11, 1.2.11, 1.3.4)를 배포했습니다. 모든 사용자께서는 각자 사용 중인 버전에 해당하는 최신 버전으로 즉시 업데이트하시기를 권장합니다.
보안 연구자가 Fedify의 lookupWebFinger()
함수에서 다음과 같은 보안 문제점들을 발견했습니다:
이번 보안 업데이트에는 다음과 같은 수정 사항이 포함되어 있습니다:
다음 명령어로 최신 보안 버전으로 업데이트하실 수 있습니다:
# npm 사용자의 경우
npm update @fedify/fedify
# Deno 사용자의 경우
deno add jsr:@fedify/fedify
이 취약점을 책임감 있게 보고해 주신 보안 연구자께 감사드립니다. 덕분에 신속하게 문제를 해결할 수 있었습니다.
이 취약점에 대한 자세한 내용은 보안 권고문을 참고해 주시기 바랍니다.
문의 사항이나 우려 사항이 있으시다면 GitHub Discussions나 Matrix 채팅방, 또는 Discord 서버를 통해 언제든 연락해 주시기 바랍니다.
We have released #security updates (1.0.14, 1.1.11, 1.2.11, 1.3.4) to address CVE-2025-23221, a #vulnerability in #Fedify's #WebFinger implementation. We recommend all users update to the latest version of their respective release series immediately.
A security researcher identified multiple security issues in Fedify's lookupWebFinger()
function that could be exploited to:
The security updates implement the following fixes:
To update to the latest secure version:
# For npm users
npm update @fedify/fedify
# For Deno users
deno add jsr:@fedify/fedify
We thank the security researcher who responsibly disclosed this vulnerability, allowing us to address these issues promptly.
For more details about this vulnerability, please refer to our security advisory.
If you have any questions or concerns, please don't hesitate to reach out through our GitHub Discussions, join our Matrix chat space, or our Discord server.
We have released #security updates (1.0.14, 1.1.11, 1.2.11, 1.3.4) to address CVE-2025-23221, a #vulnerability in #Fedify's #WebFinger implementation. We recommend all users update to the latest version of their respective release series immediately.
A security researcher identified multiple security issues in Fedify's lookupWebFinger()
function that could be exploited to:
The security updates implement the following fixes:
To update to the latest secure version:
# For npm users
npm update @fedify/fedify
# For Deno users
deno add jsr:@fedify/fedify
We thank the security researcher who responsibly disclosed this vulnerability, allowing us to address these issues promptly.
For more details about this vulnerability, please refer to our security advisory.
If you have any questions or concerns, please don't hesitate to reach out through our GitHub Discussions, join our Matrix chat space, or our Discord server.
Want to build your own #ActivityPub implementation, but don't know where to start? Read and follow #Fedify's official tutorial, Creating your own federated microblog, and get started!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
自分だけのActivityPubを作りたいけど、何から始めれば良いのか分からないですか?Fedifyの公式チュートリアル「自分だけのフェディバースのマイクロブログを作ろう!」を読んでみてください!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
자신만의 #ActivityPub 구현을 하고 싶지만, 어디서 시작해야 할지 모르겠나요? #Fedify 공식 튜토리얼인 〈나만의 연합우주 마이크로블로그 만들기〉를 읽고 따라해 보세요!
Want to build your own #ActivityPub implementation, but don't know where to start? Read and follow #Fedify's official tutorial, Creating your own federated microblog, and get started!
私も微力ながら『Thinking Penguin Magazine Vol.0』に「国漢文混用体からHolloまで」という拙稿を寄稿しました。興味の有る方は、第十一回技術書同人誌博覧会で手に入れる事が出来ます。
【技術書同人誌博覧会まであと1週間‼️】
#FediLUG は来週の今日、2025年1月25日に横浜産貿ホール マリネリアで開催される第11回技術書同人誌博覧会( #技書博 )に出展します。
#FediLUG 新刊として『Thinkng Penguin Magazine vol.0』を頒布します!(124ページ・500円)
委託として @[email protected] さんの『さばかんライフ!』も頒布いたします!
皆さんのお越しを心待ちにしています!!!
詳しくは技術書博の公式サイトおよび、サークル概要をご覧ください!
https://gishohaku.dev/gishohaku11/circles/LOmokXEikphsDCEG9OEb
私も微力ながら『Thinking Penguin Magazine Vol.0』に「国漢文混用体からHolloまで」という拙稿を寄稿しました。興味の有る方は、第十一回技術書同人誌博覧会で手に入れる事が出来ます。
【技術書同人誌博覧会まであと1週間‼️】
#FediLUG は来週の今日、2025年1月25日に横浜産貿ホール マリネリアで開催される第11回技術書同人誌博覧会( #技書博 )に出展します。
#FediLUG 新刊として『Thinkng Penguin Magazine vol.0』を頒布します!(124ページ・500円)
委託として @[email protected] さんの『さばかんライフ!』も頒布いたします!
皆さんのお越しを心待ちにしています!!!
詳しくは技術書博の公式サイトおよび、サークル概要をご覧ください!
https://gishohaku.dev/gishohaku11/circles/LOmokXEikphsDCEG9OEb
私も微力ながら『Thinking Penguin Magazine Vol.0』に「国漢文混用体からHolloまで」という拙稿を寄稿しました。興味の有る方は、第十一回技術書同人誌博覧会で手に入れる事が出来ます。
【技術書同人誌博覧会まであと1週間‼️】
#FediLUG は来週の今日、2025年1月25日に横浜産貿ホール マリネリアで開催される第11回技術書同人誌博覧会( #技書博 )に出展します。
#FediLUG 新刊として『Thinkng Penguin Magazine vol.0』を頒布します!(124ページ・500円)
委託として @[email protected] さんの『さばかんライフ!』も頒布いたします!
皆さんのお越しを心待ちにしています!!!
詳しくは技術書博の公式サイトおよび、サークル概要をご覧ください!
https://gishohaku.dev/gishohaku11/circles/LOmokXEikphsDCEG9OEb
Key Points:
➡️ BotKit enables the creation of standalone ActivityPub bots, free from platform constraints.
➡️ It is user-friendly and written in TypeScript, ensuring type safety.
➡️ BotKit is easy to deploy with minimal dependencies on various virtual servers.
➡️ Powered by #Fedify, a robust #ActivityPub framework.
#ActivityPub #BotKit #Fediverse #TypeScript #Deno #OpenSource #Programming
One of #Fedify's long-term challenges is to get it to run on Cloudflare Workers as well.
One of #Fedify's long-term challenges is to get it to run on Cloudflare Workers as well.
Key Points:
➡️ BotKit enables the creation of standalone ActivityPub bots, free from platform constraints.
➡️ It is user-friendly and written in TypeScript, ensuring type safety.
➡️ BotKit is easy to deploy with minimal dependencies on various virtual servers.
➡️ Powered by #Fedify, a robust #ActivityPub framework.
#ActivityPub #BotKit #Fediverse #TypeScript #Deno #OpenSource #Programming
@[email protected] · Reply to FediChatBot's post
@FediChatBot The attached image is the logo for #Fedify (@fedify), let us know what you think of it.
Introducing #BotKit: A #TypeScript framework for creating truly standalone #ActivityPub bots!
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
Introducing #BotKit: A #TypeScript framework for creating truly standalone #ActivityPub bots!
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
Introducing #BotKit: A #TypeScript framework for creating truly standalone #ActivityPub bots!
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
Okay, I finished the groundwork of #BotKit today. It's #Deno-only yet though. It's on GitHub!
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
The last "big" code thing I need to get done before the alpha test of my current @fedify project is the task queue - make sure routine data updates happen, consider individual importance and urgency, respect external API rate limits, etc.
But that's super intimidating so I'm currently procrastinating by making it a cute lil home page instead. 🙃
The last "big" code thing I need to get done before the alpha test of my current @fedify project is the task queue - make sure routine data updates happen, consider individual importance and urgency, respect external API rate limits, etc.
But that's super intimidating so I'm currently procrastinating by making it a cute lil home page instead. 🙃
The last "big" code thing I need to get done before the alpha test of my current @fedify project is the task queue - make sure routine data updates happen, consider individual importance and urgency, respect external API rate limits, etc.
But that's super intimidating so I'm currently procrastinating by making it a cute lil home page instead. 🙃
Now that I got some fond memories of #typescript (read: Stockholm Syndrome), I sort of want to build stuff with #fedify. 😅
Though what I *really* want is an option like it for #ElixirLang. Maybe a project for the new year. 🤔
Not like we don't have #Akkoma, #Bonfire, #Pleroma, and #Mobilizon as examples of what could be a standard library. 😄
Hollo 0.4.0 released! #Hollo is a single-user federated microblogging software which is #ActivityPub-enabled and powered by #Fedify.
The key changes of this release include:
Hollo is now powered by Node.js 23+ instead of Bun for more efficient memory usage.
Added an experimental feature flag TIMELINE_INBOXES
to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
You can now make your profile discoverable
.
The profile page now shows an account's cover image if it has one.
Many bug fixes.
For the details, see also the full changelog.
You can upgrade to Hollo 0.4.0 using the following ways:
To Railway users: Just redeploy the Hollo service!
To Docker users: Switch your Hollo image to ghcr.io/dahlia/hollo:0.4.0
or simply latest
!
To manual installers:
Install Node.js 23 or higher.
Fetch the stable
branch and switch over to it.
Run pnpm install
.
Run pnpm run prod
to start the Hollo server.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
Are you interested in trying out the Node.js version of Hollo early? Try to pull ghcr.io/dahlia/hollo:0.4.0-dev.290
!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
I wrote a blog post to wrap up the year 2024: A year with the fediverse.
https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.en.html
Looking for a side project to do over the holidays? Why not create your own #ActivityPub server with #Fedify?
I'd like to translate #Fedify's docs into multiple languages, at least into Korean and Japanese, which are languages I speak, but I'm not sure how useful it would be compared to the cost. Fedify's docs are already pretty extensive, so translating them would be difficult, plus the cost of updating them would be quite high. 🤔
Since #Fedify 1.4.0, our next release, the fedify lookup
command will have the -t
/--traverse
option! It takes a URL of the collection, and traverse its items from the beginning to the end. Here's a demo:
I made a thing. You can put a Mastodon post URL in the search box and it will show the post.
https://fediverse.hayes.software
I was learning #Fedify and I wanted to make a minimal Next.js example of a "read-only" app that was for consuming the Fediverse and didn't mess with interactions. It started as a boilerplate to benefit other devs, but the act of making it forced me to learn a lot more about Fedify and ActivityPub.
#WebDev #Demo
I was looking at the properties on the Person #ActivityPub object implemented by #fedify, and wasn't expecting this one, haha!
I'm presuming this is #Misskey related? The quirks of having to implement many different versions of a spec!
#WIP - I'm learning ActivityPub for a larger project, but taking a moment to #design and code a minimal fediverse reader.
I found it tricky learning to make a read-only app with #Fedify, so wanted to make this example Next.js project available. Got a little carried away with the design.
Mockup in #Inkscape, it's a better prototyping tool than one might expect.
Hopefully @tamami doesn't mind me using her nice post in my mockup .
The #Fedify repository has reached 600 stars! Thank you everyone!
Hollo 0.3.0 released! #Hollo is a single-user federated microblogging software which is #ActivityPub-enabled and powered by #Fedify.
The key changes of this release include:
DRIVE_DISK=fs
and FS_ASSET_PATH
to store media files in the local filesystem. For users who've used S3, no further action is required—but, it's recommended to configure DRIVE_DISK=s3
as DRIVE_DISK
will be required in the future releases.SENTRY_DSN
.You can upgrade to Hollo 0.3.0 using the following ways:
ghcr.io/dahlia/hollo:0.3.0
or simply latest
!stable
branch and switch over to it!#Fedify 1.3.0이 릴리스되었습니다. #OpenTelemetry 서포트들 비롯해 많은 것이 바뀌었으니, 아래 릴리스 노트에서 살펴보세요!
The version 1.3.0 of #Fedify, an #ActivityPub server framework, released! The key changes include:
MessageQueue
s for incoming and outgoing activities.Activity
to the corresponding inbox listener. It is useful for invoking an inbox listener for an Activity
enclosed by another Activity
.Context.sendActivity()
and InboxContext.forwardActivity()
methods now reject when they fail to enqueue the task.User-Agent
header, e.g., User-Agent: Fedify/1.3.0 (Deno/2.1.2)
.For details, see the full changelog as well!
I would like to translate #Fedify's docs into Korean and Japanese, the languages I can speak, but the amount of the docs is quite much, so I can't even think of doing it. The maintenance costs for updating the docs also cannot be ignored.
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
#Fedify's @opentelemetry instrumentation works like a charm with @getsentry!
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
@opentelemetry instruments are being added one by one to #Fedify…!
Though we have OpenTelemetry Semantic Conventions 1.28.0, it does not yet define attributes related to the fediverse. So #Fedify is taking the initiative to define semantic attributes related to the ActivityPub protocol and its related protocols. If you have any ideas, please leave a comment!
https://gist.github.com/dahlia/7ad0f197a3a87072707996b2ee14a749
Thanks to @robin_maki, #SvelteKit integration support has been added to #Fedify! This feature will be included in Fedify 1.3.0.
Did you know the #Fedify CLI can help debug #ActivityPub federation?
Learn about hidden features like:
• Smart object lookup with content negotiation
• Interactive inbox testing with a web UI
• NodeInfo visualization
• Local development tunneling
• And more!
https://dev.to/hongminhee/hidden-gems-of-the-fedify-cli-tips-tricks-you-might-have-missed-54af
The #Hollo v0.2.3 has been released, which fixes a few bugs and brings #Fedify to the latest version, v1.2.7. If you are using the Docker image, you can upgrade by using the ghcr.io/dahlia/hollo:0.2.3
.
내일 서울 서초구 오픈업 플레이그라운드에서 이뤄지는 Open Contribution Jam 2024에 #Fedify 메인테이너(@hongminhee)가 참여합니다. Fedify에 기여해보고 싶은 분들은 와주시면 메인테이너가 성심껏 도와드리겠습니다! 자세한 행사 정보는 아래 링크를 참고하시면 됩니다.
We are going to add instrumentation support for #OpenTelemetry to #Fedify. What kind of spans or events would you like to be instrumented?
Starting with #Fedify 1.3.0, you'll be able to use different message queues for incoming and outgoing activities!
https://unstable.fedify.dev/manual/mq#using-different-message-queues-for-different-tasks
#Fedify 로 페디버스 포스트들 백업을 할 수 있을까.
Star History of #Fedify, #Hollo, and #LogTape:
https://star-history.com/#dahlia/fedify&dahlia/logtape&dahlia/hollo&Date
@hongminhee お疲れ様です。HolloとFedifyのチラシが無事届きました〜
KOFなどで配布しますね
Have you heard of Val Town? Val Town is a kind of code pastebin + serverless function.
Actually, #Fedify works just fine with Val Town. Here's a piece of ActivityPub software, implemented in about 170 lines of code, running on Val Town. Of course, it's built with Fedify!
Give it a follow @demo, and it will follow you back.
Curious to see how it was implemented? Check out the source code!
10月26日(土)に開催されるOSC 2024 Tokyo/FallにFedify/Hollo合同で出展します!可愛いFedifyのロゴのシールと『自分だけのフェディバースのマイクロブログを作ろう!』日本語版の紙の本を持って行く予定です。よろしくお願いします。
If you're on the fence about which driver to choose for #Fedify's message queue, here's a benchmark that just came out. In addition to no queue, we compare 5 drivers, for a total of 11 setups:
InProcessMessageQueue
DenoKvMessageQueue
RedisMessageQueue
PostgresMessageQueue
AmqpMessageQueue
InProcessMessageQueue
× 4DenoKvMessageQueue
× 4RedisMessageQueue
× 4PostgresMessageQueue
× 4AmqpMessageQueue
× 4Curious to see the results? Check out the GitHub repository!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
@thisismissem Here's the benchmark, and while it contains some questionable results, the overall conclusion is as following:
• Response times are much faster with queues than without.
• Overall throughput is better without queues.
• However, some queue setups can achieve throughput close to that of no queue.
This benchmark assumes communication within a single node, so the effect of queues may be greater in real-world networks.
日本語版Fedifyチュートリアル『自分だけのフェディバースのマイクロブログを作ろう!』をZennで公開しました!ActivityPubの実装に興味の有る方々は是非ご覧ください!
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
If you're curious, take a look at the #Fedify website! There's comprehensive docs, a demo, a tutorial, example code, and more:
Hello, #fediverse! It's the official fedi account of the Fedify, an #ActivityPub server framework!
If you'd like to support the development of #Fedify or #Hollo, you can sponsor me on GitHub!
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.