Just a quick heads-up that there won't be any new Fireside Fedi episodes for about a month. I'll be having surgery followed by a trip to Vancouver for FOSSY!
While I'm offline, here are 5 great episodes to catch up on in the meantime:
E83 — Fedify & Futures: Building the Fediverse's Backbone Hong Minhee (@hongminhee@hollo.social) Deep dive into Fedify, Hollo, and Botkit tubefree.org/w/i1WNPWEVoDJe8...
E74 — The People‑First Platform: Hannah Aubry on Mastodon and the Fediverse Hannah Aubry (@haubles@hachyderm.io) A chat about people-first platform design tubefree.org/w/x715zm1Nkvqd8...
E73 — Ink & Open Source: David Revoy's Fantasy Webcomics in the Fediverse David Revoy (@davidrevoy@framapiaf.org) Exploring webcomics and open source creativity tubefree.org/w/j2yFdBC8LtV5R...
Episode 8 — Paige (FediHost) Paige (@fedihost@mstdn.social) Early episode chatting with Paige from FediHost tubefree.org/w/oZsDbzuKFt2hZ...
Episode 45 — Weatherman (Weather Is Happening) Weatherman (@WEATHERISHAPPENING@weatherishappening.network) A lively conversation about weather and more tubefree.org/w/8BPyhJkxRkAu5...
Want to be on the show? We're always open to volunteers and welcome topic suggestions! Feel free to reach out if you'd like to sit down for a chat or have a suggestion for someone you'd like to see on the show.
I'm really looking forward to meeting many of you at FOSSY! I'll also be doing a panel for the Fedicon track — come say hi and let's chat!
Just a quick heads-up that there won't be any new Fireside Fedi episodes for about a month. I'll be having surgery followed by a trip to Vancouver for FOSSY!
While I'm offline, here are 5 great episodes to catch up on in the meantime:
E83 — Fedify & Futures: Building the Fediverse's Backbone Hong Minhee (@hongminhee@hollo.social) Deep dive into Fedify, Hollo, and Botkit tubefree.org/w/i1WNPWEVoDJe8...
E74 — The People‑First Platform: Hannah Aubry on Mastodon and the Fediverse Hannah Aubry (@haubles@hachyderm.io) A chat about people-first platform design tubefree.org/w/x715zm1Nkvqd8...
E73 — Ink & Open Source: David Revoy's Fantasy Webcomics in the Fediverse David Revoy (@davidrevoy@framapiaf.org) Exploring webcomics and open source creativity tubefree.org/w/j2yFdBC8LtV5R...
Episode 8 — Paige (FediHost) Paige (@fedihost@mstdn.social) Early episode chatting with Paige from FediHost tubefree.org/w/oZsDbzuKFt2hZ...
Episode 45 — Weatherman (Weather Is Happening) Weatherman (@WEATHERISHAPPENING@weatherishappening.network) A lively conversation about weather and more tubefree.org/w/8BPyhJkxRkAu5...
Want to be on the show? We're always open to volunteers and welcome topic suggestions! Feel free to reach out if you'd like to sit down for a chat or have a suggestion for someone you'd like to see on the show.
I'm really looking forward to meeting many of you at FOSSY! I'll also be doing a panel for the Fedicon track — come say hi and let's chat!
Just a quick heads-up that there won't be any new Fireside Fedi episodes for about a month. I'll be having surgery followed by a trip to Vancouver for FOSSY!
While I'm offline, here are 5 great episodes to catch up on in the meantime:
E83 — Fedify & Futures: Building the Fediverse's Backbone Hong Minhee (@hongminhee@hollo.social) Deep dive into Fedify, Hollo, and Botkit tubefree.org/w/i1WNPWEVoDJe8...
E74 — The People‑First Platform: Hannah Aubry on Mastodon and the Fediverse Hannah Aubry (@haubles@hachyderm.io) A chat about people-first platform design tubefree.org/w/x715zm1Nkvqd8...
E73 — Ink & Open Source: David Revoy's Fantasy Webcomics in the Fediverse David Revoy (@davidrevoy@framapiaf.org) Exploring webcomics and open source creativity tubefree.org/w/j2yFdBC8LtV5R...
Episode 8 — Paige (FediHost) Paige (@fedihost@mstdn.social) Early episode chatting with Paige from FediHost tubefree.org/w/oZsDbzuKFt2hZ...
Episode 45 — Weatherman (Weather Is Happening) Weatherman (@WEATHERISHAPPENING@weatherishappening.network) A lively conversation about weather and more tubefree.org/w/8BPyhJkxRkAu5...
Want to be on the show? We're always open to volunteers and welcome topic suggestions! Feel free to reach out if you'd like to sit down for a chat or have a suggestion for someone you'd like to see on the show.
I'm really looking forward to meeting many of you at FOSSY! I'll also be doing a panel for the Fedicon track — come say hi and let's chat!
Just a quick heads-up that there won't be any new Fireside Fedi episodes for about a month. I'll be having surgery followed by a trip to Vancouver for FOSSY!
While I'm offline, here are 5 great episodes to catch up on in the meantime:
E83 — Fedify & Futures: Building the Fediverse's Backbone Hong Minhee (@hongminhee@hollo.social) Deep dive into Fedify, Hollo, and Botkit tubefree.org/w/i1WNPWEVoDJe8...
E74 — The People‑First Platform: Hannah Aubry on Mastodon and the Fediverse Hannah Aubry (@haubles@hachyderm.io) A chat about people-first platform design tubefree.org/w/x715zm1Nkvqd8...
E73 — Ink & Open Source: David Revoy's Fantasy Webcomics in the Fediverse David Revoy (@davidrevoy@framapiaf.org) Exploring webcomics and open source creativity tubefree.org/w/j2yFdBC8LtV5R...
Episode 8 — Paige (FediHost) Paige (@fedihost@mstdn.social) Early episode chatting with Paige from FediHost tubefree.org/w/oZsDbzuKFt2hZ...
Episode 45 — Weatherman (Weather Is Happening) Weatherman (@WEATHERISHAPPENING@weatherishappening.network) A lively conversation about weather and more tubefree.org/w/8BPyhJkxRkAu5...
Want to be on the show? We're always open to volunteers and welcome topic suggestions! Feel free to reach out if you'd like to sit down for a chat or have a suggestion for someone you'd like to see on the show.
I'm really looking forward to meeting many of you at FOSSY! I'll also be doing a panel for the Fedicon track — come say hi and let's chat!
The collection on #NeoDB ( #Fediverse alternative to Letterboxd etc) now has links for: - streaming video on demand - download on demand - scheduled stream - search for more streams & downloads
Screenshot of the entry for Solarbabies (1986) in the #Monsterdon collection on Eggplant.place, bleeding edge instance of NeoDB, media cataloguing platform & fediverse alternative to Letterboxd, Goodreads, RateMyMusic etc
The collection on #NeoDB ( #Fediverse alternative to Letterboxd etc) now has links for: - streaming video on demand - download on demand - scheduled stream - search for more streams & downloads
Screenshot of the entry for Solarbabies (1986) in the #Monsterdon collection on Eggplant.place, bleeding edge instance of NeoDB, media cataloguing platform & fediverse alternative to Letterboxd, Goodreads, RateMyMusic etc
The collection on #NeoDB ( #Fediverse alternative to Letterboxd etc) now has links for: - streaming video on demand - download on demand - scheduled stream - search for more streams & downloads
Screenshot of the entry for Solarbabies (1986) in the #Monsterdon collection on Eggplant.place, bleeding edge instance of NeoDB, media cataloguing platform & fediverse alternative to Letterboxd, Goodreads, RateMyMusic etc
🌐 Thema:„Fediverse – wie sich alles zusammen nutzen lässt“
Viele denken, man müsse für jede Fediverse-Anwendung einen eigenen Account anlegen. Doch genau das ist einer der größten Irrtümer. In vielen Fällen genügt bereits ein einziger Account, um mit Menschen auf verschiedenen Plattformen zu kommunizieren. Weitere Accounts sind nur dann sinnvoll, wenn man die besonderen Funktionen einzelner Anwendungen gezielt nutzen möchte.
Unser Gast Friedhelm ( @catmanfriedhelm ) zeigt dies anhand seines eigenen Projekts. Mit seiner Katzen-Webseite gandalfgarfield.de nutzt er das Fediverse, um Wissen über Katzen zu veröffentlichen und zu teilen. Dabei setzt er unter anderem Friendica, Mastodon, PixelFed, PeerTube und BookWyrm dort ein, wo die jeweilige Anwendung ihre Stärken entfalten kann.
💬 Gemeinsam statt nebeneinander – genau das macht das Fediverse aus.
Je mehr Menschen sich beteiligen, desto lebendiger, vielfältiger und stärker wird das Fediverse. 🌱
Mitmachen ist ausdrücklich erwünscht! Egal, ob ihr gerade erst ins Fediverse einsteigt oder schon länger dabei seid – alle sind herzlich willkommen.
ℹ️ Die Teilnahme ist ganz einfach: Eine Registrierung bei BigBlueButton ist nicht erforderlich. Ihr benötigt lediglich einen aktuellen Webbrowser (empfohlen: Firefox oder Chrome) und den Einladungslink zur Veranstaltung.
Wir freuen uns auf einen spannenden Abend und einen offenen Austausch mit euch! 😊
Quadratische Grafik zur Ankündigung einer Fediverse-Sprechstunde. Vor einem sternenreichen Weltraumhintergrund mit der Erde am unteren Bildrand sind verschiedene Anwendungen des Fediverse kreisförmig und gleichberechtigt miteinander verbunden. Zu sehen sind unter anderem Symbole für Mastodon, Friendica, PixelFed, PeerTube, BookWyrm, Hubzilla, Castopod und Loops. In der Mitte steht der Titel „Fediverse-Sprechstunde“. Darunter befinden sich die Veranstaltungsinformationen: Montag, 20.07.2026, 19:30 Uhr, online via BigBlueButton. Am unteren Rand steht der Slogan „Gemeinsam verbunden. Vielfalt nutzen.“ Die Grafik verdeutlicht, dass das Fediverse aus vielen gleichwertigen, miteinander vernetzten Anwendungen besteht.
🌐 Thema:„Fediverse – wie sich alles zusammen nutzen lässt“
Viele denken, man müsse für jede Fediverse-Anwendung einen eigenen Account anlegen. Doch genau das ist einer der größten Irrtümer. In vielen Fällen genügt bereits ein einziger Account, um mit Menschen auf verschiedenen Plattformen zu kommunizieren. Weitere Accounts sind nur dann sinnvoll, wenn man die besonderen Funktionen einzelner Anwendungen gezielt nutzen möchte.
Unser Gast Friedhelm ( @catmanfriedhelm ) zeigt dies anhand seines eigenen Projekts. Mit seiner Katzen-Webseite gandalfgarfield.de nutzt er das Fediverse, um Wissen über Katzen zu veröffentlichen und zu teilen. Dabei setzt er unter anderem Friendica, Mastodon, PixelFed, PeerTube und BookWyrm dort ein, wo die jeweilige Anwendung ihre Stärken entfalten kann.
💬 Gemeinsam statt nebeneinander – genau das macht das Fediverse aus.
Je mehr Menschen sich beteiligen, desto lebendiger, vielfältiger und stärker wird das Fediverse. 🌱
Mitmachen ist ausdrücklich erwünscht! Egal, ob ihr gerade erst ins Fediverse einsteigt oder schon länger dabei seid – alle sind herzlich willkommen.
ℹ️ Die Teilnahme ist ganz einfach: Eine Registrierung bei BigBlueButton ist nicht erforderlich. Ihr benötigt lediglich einen aktuellen Webbrowser (empfohlen: Firefox oder Chrome) und den Einladungslink zur Veranstaltung.
Wir freuen uns auf einen spannenden Abend und einen offenen Austausch mit euch! 😊
Quadratische Grafik zur Ankündigung einer Fediverse-Sprechstunde. Vor einem sternenreichen Weltraumhintergrund mit der Erde am unteren Bildrand sind verschiedene Anwendungen des Fediverse kreisförmig und gleichberechtigt miteinander verbunden. Zu sehen sind unter anderem Symbole für Mastodon, Friendica, PixelFed, PeerTube, BookWyrm, Hubzilla, Castopod und Loops. In der Mitte steht der Titel „Fediverse-Sprechstunde“. Darunter befinden sich die Veranstaltungsinformationen: Montag, 20.07.2026, 19:30 Uhr, online via BigBlueButton. Am unteren Rand steht der Slogan „Gemeinsam verbunden. Vielfalt nutzen.“ Die Grafik verdeutlicht, dass das Fediverse aus vielen gleichwertigen, miteinander vernetzten Anwendungen besteht.
A torbie cat with black, brown, and orange patches lounging on a beige carpeted cat tree platform. The cat is stretched out horizontally with its rear legs dangling off the edge and tail extended toward a window. Short sleek fur with tabby striping on the legs and tail. A small toy mouse is tucked under the platform.
A torbie cat with black, brown, and orange patches lounging on a beige carpeted cat tree platform. The cat is stretched out horizontally with its rear legs dangling off the edge and tail extended toward a window. Short sleek fur with tabby striping on the legs and tail. A small toy mouse is tucked under the platform.
Just a reminder that if you're an admin or a moderator, it should be your responsibility to step in when someone is harassing a member of your community and claiming to be enforcing rules that don't apply to them.
Screenshot of a Mastodon server's server rules:
Don’t police others’ use of CWs, alt text, or tags
Whilst we have some guidelines around when to use CWs, alt text, and tags, we only have one rule about them: Use CWs for adult or NSFW content.
You can politely ask other people to use specific CWs, alt text, or tags that you prefer, as long as you don’t state your preferences as absolute rules or requirements.
This is especially important when marginalised people speak about their experiences of marginalisation. For example, if you are not BIPOC, don’t tell BIPOC to hide their experiences of racism behind CWs.
Just a reminder that if you're an admin or a moderator, it should be your responsibility to step in when someone is harassing a member of your community and claiming to be enforcing rules that don't apply to them.
Screenshot of a Mastodon server's server rules:
Don’t police others’ use of CWs, alt text, or tags
Whilst we have some guidelines around when to use CWs, alt text, and tags, we only have one rule about them: Use CWs for adult or NSFW content.
You can politely ask other people to use specific CWs, alt text, or tags that you prefer, as long as you don’t state your preferences as absolute rules or requirements.
This is especially important when marginalised people speak about their experiences of marginalisation. For example, if you are not BIPOC, don’t tell BIPOC to hide their experiences of racism behind CWs.
Fediverse -Treffen in realen Leben in der sächsischen Schweiz. Ein schöner Tag auf dem Lilienstein und jetzt noch einen angenehmen Abend unter einer Weide mit dem Blick auf Festung Königstein und Lilienstein. Wir sitzen zusammen mit @steffen , @angro und Christine sowie mir. Fediverse verbindet auch über das Internet heraus.
A brown tabby cat with dark stripes and spots sleeping peacefully on its back on rumpled teal bedsheets, belly exposed, legs stretched out in a fully relaxed pose with eyes closed.
A brown tabby cat with dark stripes and spots sleeping peacefully on its back on rumpled teal bedsheets, belly exposed, legs stretched out in a fully relaxed pose with eyes closed.
@jet@evan Well said. It's especially ironic as the entire point of the #fediverse is to build your own feed, block who you don't like.
I'll never understand why these PurityPolice don't just stop following the person? Why do they feel compelled to change them? I get it, this is the curse of any social media but the Fediverse prides itself on personal freedom and self expression. It's very much at odds with this.
🚀 WordPress ActivityPub 공식 2025 로드맵 발표!
드디어 우리가 바라던 '팔로우' 기능, Reader 경험, DM 지원, 정밀 Moderation 도구까지!
워드프레스가 진짜 Fediverse의 일원이 되기 위한 첫 번째 이정표가 제시되었습니다! 🎉
자신의 블로그를 직접 SNS 네트워크와 연결하는 경험이 이제 현실로 다가옵니다. 함께 따라가봅시다!
<a rel="mention" class="u-url mention" href="https://mastodon.social/@pfefferle">@pfefferle</a>
2025년 로드맵: 워드프레스 페더레이션의 미래를 구축합니다
ActivityPub 플러그인에 많은 변화가 진행 중이며, 앞으로 선보일 기능들을 여러분께 공유하게 되어 매우 기쁩니다.
우리는 종종 GitHub 이슈와 토론에서 이 로드맵을 참조하지만, 지금까지 전체 로드맵 게시물이나 공식적인 변경 로그를 공개하지는 않았습니다. 이 게시물은 커뮤니티에 앞으로 계획된 내용과 다가올 업데이트를 더 잘 알리기 위한 첫걸음입니다.
올해 우리의 목표는 워드프레스가 페디버스(Fediverse)의 일류 시민(first-class citizen) 으로 자리잡도록 완전한 ActivityPub 경험을 완성하는 것입니다. 즉, 단순히 네트워크에 게시할 수 있을 뿐만 아니라, 팔로우하고, 읽고, 상호작용하며, 중재할 수 있으며, 이 모든 과정을 워드프레스 사용자에게 자연스럽고 원활하게 제공하는 것을 의미합니다.
이 로드맵은 고정된 계획이 아니며, 커뮤니티 피드백, 워드프레스 업데이트, 페디버스 전반의 변화에 따라 우선순위가 바뀔 수 있습니다. 하지만 우리가 나아가는 방향을 이해하는 데 도움이 될 것입니다.
현재 플러그인은 팔로워(Followers) 만 지원하며, 여러분의 사이트가 다른 페디버스 사용자를 팔로우하는 기능은 아직 제공하지 않습니다. 하지만 “리더 경험(Reader Experience)”과 같은 새로운 이니셔티브와 함께 이 부분은 반드시 개선되어야 합니다.
진정한 양방향 관계(팔로워와 팔로잉 모두)를 지원하려면, 두 가지 연결 유형을 명확히 표현할 수 있는 데이터베이스 모델이 필요합니다. 지금 시스템은 GUID를 사용해 원격 액터(remote actor)를 추적하는 방식인데, 이를 위해 설계되지 않았습니다. 현재로서는 원격 액터를 사이트의 팔로워로 저장은 가능하지만, 사이트가 그들을 다시 팔로우하는 기능은 쉽게 지원하지 못합니다.
팔로잉 기능을 깔끔하게 구현하려면 데이터 저장과 연결 방식을 재고해야 합니다.
액터(Actors;행위자)
이 문제는 플러그인이 현재 사이트의 로컬 사용자와 다른 Fediverse 서버의 원격 사용자 모두와 같은 행위자를 모델링하는 방법과 관련된 더 광범위한 문제와 관련이 있습니다.
현재 플러그인은 가상 사용자(virtual users) 를 사용하여 액터를 표현합니다. 이것은 WordPress가 사용자를 관리하는 방법을 다시 작성하지 않고 페더레이션이 작동하도록 하기 위한 초기의 실용적인 선택이었습니다.
그러나 플러그인이 성장함에 따라, 특히 Following 및 Reader Experience와 같은 기능이 추가됨에 따라 이 접근 방식은 마찰을 일으키고 있습니다. 가상 사용자는 일반 WordPress 사용자처럼 행동하지 않으므로 새로운 기능을 추가할 때마다 특수한 우회 코드가 필요해집니다.
이로 인해 시스템이 점점 복잡해지고 유지보수가 어려워집니다. 워드프레스 기존 구조와 더 자연스럽게 통합되는, 보다 통합된 액터 모델로 나아가는 것이 플러그인을 유연하고 안정적으로 유지하는 길입니다.
관리 및 중재(Moderation)
현재 플러그인은 ActivityPub 요청이 처리되기 전에 WordPress의 내장 기능인 “허용되지 않은 댓글 키워드(Disallowed Comment Keys)” 시스템을 사용하여, 받은 편지함 엔드포인트에서 원치 않는 콘텐츠를 필터링합니다. 이 메커니즘은 키워드 또는 도메인을 기반으로 하는 활동을 차단하기 위해, 댓글에 적용하는 것과 동일한 규칙을 사용할 수 있습니다.
그러나 이 접근 방식은 매우 무뚝뚝합니다: 이 방법은 단순한 키워드 필터에 불과해, 정교한 중재 도구라고 보긴 어렵습니다. 플러그인이 이미지 기반 댓글이나 더 풍부한 미디어 상호 작용에 대한 지원을 추가할 때, 이 한계는 점점 더 커질 것입니다.
따라서 사이트 소유자에게 페더레이션 콘텐츠의 고유한 문제에 맞춘 세분화된 중재 도구를 제공하기 위해 전용 필터링 메커니즘 구축이 중요합니다.
완전한 리더 경험은 우리의 장기 목표 중 하나이며, 워드프레스 사이트에 완전한 ActivityPub/Fediverse 경험을 제공하는 데 필요한 마지막 큰 기능입니다.
현재 플러그인은 다른 사용자가 여러분의 사이트를 팔로우할 수 있도록 하지만, 여러분이 다른 사람의 콘텐츠를 구독하고 읽을 수 있는 기본 제공 방법은 없습니다. 즉, 워드프레스 내부에 “타임라인”이 아직 없는 상태입니다.
우리는 먼저 단순하고 유연한 접근법으로 시작하려 합니다. 즉, 원격 게시물을 저장하는 데 집중해, WordPress.com Reader와 같은 도구나 서드파티 플러그인(예: Friends, Event Bridge for ActivityPub)과 호환성을 확보하는 것입니다.
이 기반이 마련되면, 사이트 소유자와 사용자가 워드프레스 내에서 바로 페디버스 게시물을 팔로우하고 읽을 수 있도록 직접 지원 기능을 점진적으로 추가할 계획입니다.
다이렉트 메시지(Direct Messages)
완전한 리더 경험으로 나아가는 과정에서, DM 지원도 탐색 중입니다.
이 기능은 자주 요청되는 중요한 페디버스 상호작용의 일부입니다. 우리는 우선 개인 메시징을 가능하게 하는 초기 구현부터 시작해, 실제 사용 경험을 바탕으로 점차 확장해 나갈 예정입니다.
프로필 완전 삭제
GDPR의 핵심 원칙 중 하나는 “잊혀질 권리(right to be forgotten)”입니다.
현재 플러그인은 원격 삭제(remote deletions) 를 지원하지만, 로컬 사용자 행동에 대해 Delete Activities를 트리거하지는 않습니다.
문제는 WordPress가 대부분의 페더레이션 소셜 네트워크와 다르게 작동한다는 것입니다. 예를 들어, 사용자는 중대한 결과를 초래할 수 있는 특정 작업(예: 플러그인 비활성화)에 대해 Delete Activities를 예상할 수 있습니다.
그러나 플러그인을 비활성화하는 것은 WordPress의 일반적인 문제 해결 단계이기도 합니다.
이를 해결하려면 우선 다양한 사용 사례를 정의하고, 사용자에게 적절한 Delete Activities 트리거 방법을 안내해야 합니다.
Thanks to @nlnet and @NGIZero for support the initial development of this piece of software. And thanks to @pfefferle for his ongoing work on the WordPress ActivityPub plugin @activitypub.blog !
I am happy to receive reviews and am ready to fix stuff in case issues should arise!
Is there already an Internet Resiliency Club in #Berlin? I'm aware of #Freifunk and its established work. This seems broader and complementary: a group for practical experiments with mesh networks, offline communication, local services, and other ways to make communication more resilient.
I suspect there are already people working on these ideas in Berlin, so I thought I'd ask here on the #Fediverse. I'll also reach out on nebenan.de to see if there's any local interest.
If you can, make sure to edit your original post instead of posting the correction in another post in the thread. I see so many people boost the original post but since it wasn't edited, the edited information is more, often times, lost. Editing isn't a bad thing at all, despite what some #Fediverse users tell you. The way federation works, your correction might not even make it to all the instances. Editing is common on most third party apps too. Editing makes you more trustworthy in my eyes. I love the edit functionality, and I am old enough to remember when Fedi nearly flipped it's shit in a negative way when the feature was first proposed. It's the best feature we have. Use it! #FediTips
#TIL about #Harmony, a bleeding-edge project to build a decentralised replacement for Miscord using ActivityPub, E2EE using Vodozemac, a cryptography library used in Matrix software;
If you can, make sure to edit your original post instead of posting the correction in another post in the thread. I see so many people boost the original post but since it wasn't edited, the edited information is more, often times, lost. Editing isn't a bad thing at all, despite what some #Fediverse users tell you. The way federation works, your correction might not even make it to all the instances. Editing is common on most third party apps too. Editing makes you more trustworthy in my eyes. I love the edit functionality, and I am old enough to remember when Fedi nearly flipped it's shit in a negative way when the feature was first proposed. It's the best feature we have. Use it! #FediTips
Thanks to @nlnet and @NGIZero for support the initial development of this piece of software. And thanks to @pfefferle for his ongoing work on the WordPress ActivityPub plugin @activitypub.blog !
I am happy to receive reviews and am ready to fix stuff in case issues should arise!
Thanks to @nlnet and @NGIZero for support the initial development of this piece of software. And thanks to @pfefferle for his ongoing work on the WordPress ActivityPub plugin @activitypub.blog !
I am happy to receive reviews and am ready to fix stuff in case issues should arise!
Big news for Org Social! 🎉 The Relay now has bridges: you can follow Mastodon (ActivityPub) accounts and RSS/Atom feeds directly from any Org Social client.
A bridge is a virtual social.org feed generated by the Relay. Just add its URL to your follow list like any other feed:
Thanks to @nlnet and @NGIZero for support the initial development of this piece of software. And thanks to @pfefferle for his ongoing work on the WordPress ActivityPub plugin @activitypub.blog !
I am happy to receive reviews and am ready to fix stuff in case issues should arise!
Big news for Org Social! 🎉 The Relay now has bridges: you can follow Mastodon (ActivityPub) accounts and RSS/Atom feeds directly from any Org Social client.
A bridge is a virtual social.org feed generated by the Relay. Just add its URL to your follow list like any other feed:
Thanks to @nlnet and @NGIZero for support the initial development of this piece of software. And thanks to @pfefferle for his ongoing work on the WordPress ActivityPub plugin @activitypub.blog !
I am happy to receive reviews and am ready to fix stuff in case issues should arise!
Thanks to @nlnet and @NGIZero for support the initial development of this piece of software. And thanks to @pfefferle for his ongoing work on the WordPress ActivityPub plugin @activitypub.blog !
I am happy to receive reviews and am ready to fix stuff in case issues should arise!
Thanks to @nlnet and @NGIZero for support the initial development of this piece of software. And thanks to @pfefferle for his ongoing work on the WordPress ActivityPub plugin @activitypub.blog !
I am happy to receive reviews and am ready to fix stuff in case issues should arise!
So, my kid was playing with this website that let you pick a character and would "guess" who that character is. They thought it would be funny to pick me, so they went through the questions as though they didn't know me (variations of "your dad" were given multiple times). Once it got to tech questions, it asked all of the expected ones. After dozens of questions, it finally chose a name. I was not pleased with its selection.
Their name is often seen abbreviated, they're here on the #Fediverse, and they're apparently a real piece of shit.
Thanks to @nlnet and @NGIZero for support the initial development of this piece of software. And thanks to @pfefferle for his ongoing work on the WordPress ActivityPub plugin @activitypub.blog !
I am happy to receive reviews and am ready to fix stuff in case issues should arise!
Thanks to @nlnet and @NGIZero for support the initial development of this piece of software. And thanks to @pfefferle for his ongoing work on the WordPress ActivityPub plugin @activitypub.blog !
I am happy to receive reviews and am ready to fix stuff in case issues should arise!
Thanks to @nlnet and @NGIZero for support the initial development of this piece of software. And thanks to @pfefferle for his ongoing work on the WordPress ActivityPub plugin @activitypub.blog !
I am happy to receive reviews and am ready to fix stuff in case issues should arise!
Thanks to @nlnet and @NGIZero for support the initial development of this piece of software. And thanks to @pfefferle for his ongoing work on the WordPress ActivityPub plugin @activitypub.blog !
I am happy to receive reviews and am ready to fix stuff in case issues should arise!
Thanks to @nlnet and @NGIZero for support the initial development of this piece of software. And thanks to @pfefferle for his ongoing work on the WordPress ActivityPub plugin @activitypub.blog !
I am happy to receive reviews and am ready to fix stuff in case issues should arise!
Thanks to @nlnet and @NGIZero for support the initial development of this piece of software. And thanks to @pfefferle for his ongoing work on the WordPress ActivityPub plugin @activitypub.blog !
I am happy to receive reviews and am ready to fix stuff in case issues should arise!
🌍 We just got back from Dweb Camp, hosted by the Internet Archive in the German forest — and what a gathering.
Alongside @commonsnetwork@goteo_fund and friends across the Fediverse, we presented the Democratic Tech Fund prototype and ran sessions on governance, P2P financing, and community-owned social spaces.
This release brings finer privacy controls, local visibility, commutes, a major federation rewrite, improved profiles, verified email changes, durable email delivery, and a much more capable admin area for users, federation queues, logs, diagnostics, and monitoring.
It also includes extensive reliability, security, performance, and UX improvements.
This release brings finer privacy controls, local visibility, commutes, a major federation rewrite, improved profiles, verified email changes, durable email delivery, and a much more capable admin area for users, federation queues, logs, diagnostics, and monitoring.
It also includes extensive reliability, security, performance, and UX improvements.
#Fediverse is a *social* network, right? About being different from corporate anti-social media. Has ambitions to be more diverse, inclusive, cohesive. To provide inter-community social networking where people with similar interests find each other and interact.
Like the #ActivityPub developer community, for instance. The group of people who make all this possible in the first place. Together they uphold the fediverse technology ecosystem and are collectively responsible for evolving it. They chose fediverse as their communication medium, dogfooding their creations, even though this comes with its disadvantages. #Microblogging is ephemeral and fleety and discussions are dispersed and fragmented. There are clear points of improvements for the #fedi, frequently discussed.
What's very odd is that most AP devs hardly:
1. Engage with other AP devs posts. 2. Boost each other's msgs for visibility. 3. Use hashtags for discoverability.
I'm quite proud of the new https://fediverse.info, including the admin dashboard that I've invited a few trusted people to help oversee.
Such an important resource requires trust and integrity, and the admin audit log helps ensure we all remain accountable.
Such collaboration and unbiased stewardship is crucial for a service like this, and I'm thrilled to play a part in making fediverse onboarding easier and more accessible. ❤️
This week, we cover the writing layer of the fediverse: Ghost, WriteFreely, Micro.blog, Plume, WordPress, and Flipboard. Text was ActivityPub's first real workload, but these platforms didn't all arrive at federation the same way.
Ghost: a UK non-profit that funds Fedify (by @hongminhee) the framework its federation is built on. it's a publisher and a fediverse client at once, with an inbox as well as an outbox. Our newsletter is also powered by it, so @index is followable from any Mastodon app right now.
WriteFreely: one primary maintainer, Matt Baer (@matt), roughly 1,400 of 1,900+ commits, going since 2015. Funded by his own hosted product, Write.as.
Micro.blog: a Kickstarter By Manton Reese (@manton) that funded the platform before it had a single user. POSSE, native ActivityPub, and native Bluesky, no bridge.
Plume: a simple platform that also supported collaborative multi-author blogs. But no longer actively developed - it recommends WriteFreely and WordPress instead of itself.
WordPress: built-in ActivityPub (using plugin by Matthias Pfefferle - @pfefferle) plus a native AT Protocol plugin and real moderation tooling.
Flipboard: curating other people's writing rather than hosting its own.
An antique quill and inkwell against a vibrant multicolor cosmic backdrop, with constellation lines connecting points of light across a deep starfield. Magenta, cyan, violet, and amber tones.
Is there already an Internet Resiliency Club in #Berlin? I'm aware of #Freifunk and its established work. This seems broader and complementary: a group for practical experiments with mesh networks, offline communication, local services, and other ways to make communication more resilient.
I suspect there are already people working on these ideas in Berlin, so I thought I'd ask here on the #Fediverse. I'll also reach out on nebenan.de to see if there's any local interest.
The joy of federation: a peertube instance was sending videos with height 0 for some reason, which made my akkoma timeline crash because it tried to divide by zero to find the aspect ratio
Thankfully a fix was merged into akkoma but damn I got scared my db got corrupted :’)
#Fediverse is a *social* network, right? About being different from corporate anti-social media. Has ambitions to be more diverse, inclusive, cohesive. To provide inter-community social networking where people with similar interests find each other and interact.
Like the #ActivityPub developer community, for instance. The group of people who make all this possible in the first place. Together they uphold the fediverse technology ecosystem and are collectively responsible for evolving it. They chose fediverse as their communication medium, dogfooding their creations, even though this comes with its disadvantages. #Microblogging is ephemeral and fleety and discussions are dispersed and fragmented. There are clear points of improvements for the #fedi, frequently discussed.
What's very odd is that most AP devs hardly:
1. Engage with other AP devs posts. 2. Boost each other's msgs for visibility. 3. Use hashtags for discoverability.
I'm quite proud of the new https://fediverse.info, including the admin dashboard that I've invited a few trusted people to help oversee.
Such an important resource requires trust and integrity, and the admin audit log helps ensure we all remain accountable.
Such collaboration and unbiased stewardship is crucial for a service like this, and I'm thrilled to play a part in making fediverse onboarding easier and more accessible. ❤️
I'm quite proud of the new https://fediverse.info, including the admin dashboard that I've invited a few trusted people to help oversee.
Such an important resource requires trust and integrity, and the admin audit log helps ensure we all remain accountable.
Such collaboration and unbiased stewardship is crucial for a service like this, and I'm thrilled to play a part in making fediverse onboarding easier and more accessible. ❤️
#Fediverse is a *social* network, right? About being different from corporate anti-social media. Has ambitions to be more diverse, inclusive, cohesive. To provide inter-community social networking where people with similar interests find each other and interact.
Like the #ActivityPub developer community, for instance. The group of people who make all this possible in the first place. Together they uphold the fediverse technology ecosystem and are collectively responsible for evolving it. They chose fediverse as their communication medium, dogfooding their creations, even though this comes with its disadvantages. #Microblogging is ephemeral and fleety and discussions are dispersed and fragmented. There are clear points of improvements for the #fedi, frequently discussed.
What's very odd is that most AP devs hardly:
1. Engage with other AP devs posts. 2. Boost each other's msgs for visibility. 3. Use hashtags for discoverability.
Letzte Woche haben eine Reihe von Digitalpolitiker:innen in der Open Social Web Alliance die Vision einer dezentralen Infrastruktur für digitale Kommunikation entworfen 👉 https://osw-alliance.net/ Wir teilen viele der dort formulierten Ziele.
Darüber hinaus wäre es zu begrüßen, wenn die beteiligten Organisationen und Politiker:innen sich in ihrem Umfeld für eine stärkere Nutzung der #Fediverse-Medien einsetzen würden. Also: 🔺 Priorisiert #Mastodon in Eurer digitalen Kommunikation vor den Plattformen von BigTech 🔺 Startet #PeerTube-Präsenzen nach dem Vorbild der @fsfe, @EH_Ludwigsburg etc. 🔺 Zieht Euch von der kriminelle Inhalte verbreitenden #X-Plattform zurück, sofern nicht schon getan 🔺 Führt Fortbildungen Eurer Mitglieder zu Fediverse-Medien durch 🔺 Veranlasst die Euch nahe stehenden Politiker:innen, diese Schritte auch in Ämtern und #Behörden umzusetzen*
Mit solchen konkreten Schritten würden wir der skizzierten Vision in großen Schritten näher kommen.
Or help improve the #UX of E2EE enabled fedi apps. Or even just spread the word around by boosting the article around, and give impetus to #E2EE adoption.
🌐 Hubzilla-Workshop 10 – Offener Frage- und Antwort-Abend
Mittwoch, 22. Juli 2026 | 19:30 Uhr
Nach neun thematischen Workshops legen wir diesmal bewusst eine Pause von den festen Themen ein und laden euch zu einem offenen Frage- und Antwort-Abend ein.
Egal, ob ihr Hubzilla bereits täglich nutzt, gerade erst entdeckt habt oder einfach neugierig seid – jede Frage ist willkommen! 😊
Es spielt keine Rolle, ob es um die ersten Schritte, das Posten, Berechtigungen, Webseiten, nomadische Identität, Kanäle oder die Administration eines eigenen Hubs geht. Gemeinsam möchten wir Fragen beantworten, Erfahrungen austauschen und voneinander lernen.
Deshalb würden wir uns auch freuen, wenn wieder erfahrene Hubzilla-Nutzerinnen, Nutzer und Administratoren dabei sind. Jeder bringt andere Erfahrungen mit, und genau das macht den Austausch so wertvoll.
"Hubzilla is when even the main devs keep discovering hidden features they knew nothing about." „Hubzilla ist ein Projekt, bei dem selbst die Hauptentwickler immer wieder versteckte Funktionen entdecken, von denen sie bisher nichts wussten.“
Dieser Satz beschreibt Hubzilla erstaunlich gut. Selbst langjährige Anwender entdecken immer wieder neue Möglichkeiten und Funktionen. Genau deshalb lohnt sich der gemeinsame Austausch.
📚 Die bisherigen Workshops:
Wer Hubzilla kennenlernen oder Themen noch einmal in Ruhe nachlesen möchte, findet alle Workshops mit Unterlagen und weiterführenden Informationen hier:
🔹 Workshop 1 – Einführung in Hubzilla 🔹 Workshop 2 – Einstieg in Hubzilla 🔹 Workshop 3 – Posten mit Hubzilla und alles, was dazugehört 🔹 Workshop 4 – Das Berechtigungssystem (Teil 1) 🔹 Workshop 5 – Das Berechtigungssystem (Teil 2) 🔹 Workshop 6 – Neu hier bei Hubzilla – Wir machen es uns gemütlich 🔹 Workshop 7 – Dein Kanal gehört DIR! Nomadische Identität mit Hubzilla 🔹 Workshop 8 – Webseiten mit Hubzilla (Teil 1) 🔹 Workshop 9 – Webseiten mit Hubzilla (Teil 2)
So könnt ihr euch viele Themen bereits vorab ansehen und euch Schritt für Schritt mit Hubzilla vertraut machen.
💬 Also traut euch! Es gibt keine "dummen Fragen". Jeder von uns hat einmal angefangen. Vielleicht habt ihr genau die Frage, die sich viele andere ebenfalls stellen. Wer mag, darf natürlich auch eigene Tipps, Tricks oder interessante Entdeckungen rund um Hubzilla vorstellen. Der Workshop lebt vom gemeinsamen Austausch – denn jeder hat andere Erfahrungen gesammelt und genau das macht unsere Community aus.
📅 Wann? Mittwoch, 22. Juli 2026, 19:30 Uhr 💻 Wo? In unserem Online-Meetingraum (BigBlueButton). campus.ws-12.de/rooms/n04-dj3-… Eine Registrierung ist nicht erforderlich.
Wir freuen uns auf einen spannenden Abend mit vielen Fragen, interessanten Gesprächen und einem lebendigen Austausch rund um Hubzilla und das Fediverse. 🌍
🙏 Ein ganz besonderes Dankeschön möchten wir an @pepecyb richten.
Seit dem ersten Hubzilla-Workshop investiert er unglaublich viel Zeit in die Vorbereitung, Ausarbeitung und Durchführung der Workshops. Die umfangreichen Unterlagen, Präsentationen und Dokumentationen entstehen mit viel Sorgfalt und stehen der gesamten Community dauerhaft zur Verfügung.
Ohne dieses außergewöhnliche ehrenamtliche Engagement wären die Hubzilla-Workshops in dieser Form kaum möglich.
Vielen Dank, Pepe, für deinen unermüdlichen Einsatz für Hubzilla und das Fediverse! 💙 Deine Arbeit hilft vielen Menschen beim Einstieg und zeigt, was eine engagierte Community gemeinsam erreichen kann.
Grafische Ankündigung zum Hubzilla Workshop #10 auf hellblauem Hintergrund. Oben rechts steht groß „#10“. In der Mitte befindet sich der Schriftzug „Hubzilla“ in einem kräftigen Blauverlauf, links daneben das Hubzilla-Logo. Über dem Schriftzug schweben drei farbige, stilisierte Hubzilla-Figuren (gelb, lila und rot) vor blauen Kreisen mit einem Auge als Motiv. Darunter steht in großer blauer Schrift „Workshop“. Am unteren Rand folgen die Veranstaltungsdaten: Mittwoch, 22. Juli 2026, 19:30 Uhr. Die Gestaltung wirkt freundlich, modern und einladend mit klaren Konturen und leichten Schatteneffekten.
Drei gedruckte Exemplare des Whitepaper. Cover-Motiv: Eine Hand hält ein Smartphone aus dessen Screen Blumen wachsen. Darüber: "Reinvent Social Platforms. Journalism into the fediverse!" Darunter: Logos von MediaLab Bayern und SWR X Lab.
Drei gedruckte Exemplare des Whitepaper. Cover-Motiv: Eine Hand hält ein Smartphone aus dessen Screen Blumen wachsen. Darüber: "Reinvent Social Platforms. Journalism into the fediverse!" Darunter: Logos von MediaLab Bayern und SWR X Lab.
🌐 Hubzilla-Workshop 10 – Offener Frage- und Antwort-Abend
Mittwoch, 22. Juli 2026 | 19:30 Uhr
Nach neun thematischen Workshops legen wir diesmal bewusst eine Pause von den festen Themen ein und laden euch zu einem offenen Frage- und Antwort-Abend ein.
Egal, ob ihr Hubzilla bereits täglich nutzt, gerade erst entdeckt habt oder einfach neugierig seid – jede Frage ist willkommen! 😊
Es spielt keine Rolle, ob es um die ersten Schritte, das Posten, Berechtigungen, Webseiten, nomadische Identität, Kanäle oder die Administration eines eigenen Hubs geht. Gemeinsam möchten wir Fragen beantworten, Erfahrungen austauschen und voneinander lernen.
Deshalb würden wir uns auch freuen, wenn wieder erfahrene Hubzilla-Nutzerinnen, Nutzer und Administratoren dabei sind. Jeder bringt andere Erfahrungen mit, und genau das macht den Austausch so wertvoll.
"Hubzilla is when even the main devs keep discovering hidden features they knew nothing about." „Hubzilla ist ein Projekt, bei dem selbst die Hauptentwickler immer wieder versteckte Funktionen entdecken, von denen sie bisher nichts wussten.“
Dieser Satz beschreibt Hubzilla erstaunlich gut. Selbst langjährige Anwender entdecken immer wieder neue Möglichkeiten und Funktionen. Genau deshalb lohnt sich der gemeinsame Austausch.
📚 Die bisherigen Workshops:
Wer Hubzilla kennenlernen oder Themen noch einmal in Ruhe nachlesen möchte, findet alle Workshops mit Unterlagen und weiterführenden Informationen hier:
🔹 Workshop 1 – Einführung in Hubzilla 🔹 Workshop 2 – Einstieg in Hubzilla 🔹 Workshop 3 – Posten mit Hubzilla und alles, was dazugehört 🔹 Workshop 4 – Das Berechtigungssystem (Teil 1) 🔹 Workshop 5 – Das Berechtigungssystem (Teil 2) 🔹 Workshop 6 – Neu hier bei Hubzilla – Wir machen es uns gemütlich 🔹 Workshop 7 – Dein Kanal gehört DIR! Nomadische Identität mit Hubzilla 🔹 Workshop 8 – Webseiten mit Hubzilla (Teil 1) 🔹 Workshop 9 – Webseiten mit Hubzilla (Teil 2)
So könnt ihr euch viele Themen bereits vorab ansehen und euch Schritt für Schritt mit Hubzilla vertraut machen.
💬 Also traut euch! Es gibt keine "dummen Fragen". Jeder von uns hat einmal angefangen. Vielleicht habt ihr genau die Frage, die sich viele andere ebenfalls stellen. Wer mag, darf natürlich auch eigene Tipps, Tricks oder interessante Entdeckungen rund um Hubzilla vorstellen. Der Workshop lebt vom gemeinsamen Austausch – denn jeder hat andere Erfahrungen gesammelt und genau das macht unsere Community aus.
📅 Wann? Mittwoch, 22. Juli 2026, 19:30 Uhr 💻 Wo? In unserem Online-Meetingraum (BigBlueButton). campus.ws-12.de/rooms/n04-dj3-… Eine Registrierung ist nicht erforderlich.
Wir freuen uns auf einen spannenden Abend mit vielen Fragen, interessanten Gesprächen und einem lebendigen Austausch rund um Hubzilla und das Fediverse. 🌍
🙏 Ein ganz besonderes Dankeschön möchten wir an @pepecyb richten.
Seit dem ersten Hubzilla-Workshop investiert er unglaublich viel Zeit in die Vorbereitung, Ausarbeitung und Durchführung der Workshops. Die umfangreichen Unterlagen, Präsentationen und Dokumentationen entstehen mit viel Sorgfalt und stehen der gesamten Community dauerhaft zur Verfügung.
Ohne dieses außergewöhnliche ehrenamtliche Engagement wären die Hubzilla-Workshops in dieser Form kaum möglich.
Vielen Dank, Pepe, für deinen unermüdlichen Einsatz für Hubzilla und das Fediverse! 💙 Deine Arbeit hilft vielen Menschen beim Einstieg und zeigt, was eine engagierte Community gemeinsam erreichen kann.
Grafische Ankündigung zum Hubzilla Workshop #10 auf hellblauem Hintergrund. Oben rechts steht groß „#10“. In der Mitte befindet sich der Schriftzug „Hubzilla“ in einem kräftigen Blauverlauf, links daneben das Hubzilla-Logo. Über dem Schriftzug schweben drei farbige, stilisierte Hubzilla-Figuren (gelb, lila und rot) vor blauen Kreisen mit einem Auge als Motiv. Darunter steht in großer blauer Schrift „Workshop“. Am unteren Rand folgen die Veranstaltungsdaten: Mittwoch, 22. Juli 2026, 19:30 Uhr. Die Gestaltung wirkt freundlich, modern und einladend mit klaren Konturen und leichten Schatteneffekten.
If I may give a small tip that'll give more exposure to your message and the work you do: On the #fediverse it is common habit to add #AltText to images to support the visually impaired. On #mastodon this #a11y action is easily done by clicking 'Edit' on the image preview after adding it to the post draft. When alt-text is missing most fedizens will not boost the post.
hopefully, honestly just a really a lovely time really!
ALT text
Rectangular picture. Person in the upper left rotated 90 degrees and he's covering his face like he's in fear.
Middle shows FOSSY 2026. August 6th - 9th 2026 - University of British Columbia, Cananda.
Bottom left is the Fireside Fedi icon, a spinning Fediverse icon on fire.
Middle bottom - FEDICON Fossy 08/008/2026
Bottom Right there are multiple pictures.
Top shows a shadowy man with the name John Mastodon and a cancelled banner over it.
Next is a man in a ball cap with glasses and a beard with the name MATT BAER.
Then man with a beard leaning towards the camera with DJANGO DOUCET.
Then a man with a dog behind him. DAN SUPERNAULT.
Then a picture of someone turned 120 degrees in a blanket waving. VAGRANT CASCADIAN.
Finally a cartoon character in the South Park style. BEN PATE.
hopefully, honestly just a really a lovely time really!
ALT text
Rectangular picture. Person in the upper left rotated 90 degrees and he's covering his face like he's in fear.
Middle shows FOSSY 2026. August 6th - 9th 2026 - University of British Columbia, Cananda.
Bottom left is the Fireside Fedi icon, a spinning Fediverse icon on fire.
Middle bottom - FEDICON Fossy 08/008/2026
Bottom Right there are multiple pictures.
Top shows a shadowy man with the name John Mastodon and a cancelled banner over it.
Next is a man in a ball cap with glasses and a beard with the name MATT BAER.
Then man with a beard leaning towards the camera with DJANGO DOUCET.
Then a man with a dog behind him. DAN SUPERNAULT.
Then a picture of someone turned 120 degrees in a blanket waving. VAGRANT CASCADIAN.
Finally a cartoon character in the South Park style. BEN PATE.
#HolosSocial relay is confirmed to be very stable. I will officially tag it soon so admins can run their own relay with a script to easily install it on their VPS. Using Holos with a custom domain and a cloud for media allows you to own your portable identity on the #Fediverse. Relays become only an infrastructure for it. Your device runs the #ActivityPub server and works as smoothly as any other app. Micro-blogging, media, and video, all from a single account. Switch with a simple tap.
#HolosSocial relay is confirmed to be very stable. I will officially tag it soon so admins can run their own relay with a script to easily install it on their VPS. Using Holos with a custom domain and a cloud for media allows you to own your portable identity on the #Fediverse. Relays become only an infrastructure for it. Your device runs the #ActivityPub server and works as smoothly as any other app. Micro-blogging, media, and video, all from a single account. Switch with a simple tap.
hopefully, honestly just a really a lovely time really!
ALT text
Rectangular picture. Person in the upper left rotated 90 degrees and he's covering his face like he's in fear.
Middle shows FOSSY 2026. August 6th - 9th 2026 - University of British Columbia, Cananda.
Bottom left is the Fireside Fedi icon, a spinning Fediverse icon on fire.
Middle bottom - FEDICON Fossy 08/008/2026
Bottom Right there are multiple pictures.
Top shows a shadowy man with the name John Mastodon and a cancelled banner over it.
Next is a man in a ball cap with glasses and a beard with the name MATT BAER.
Then man with a beard leaning towards the camera with DJANGO DOUCET.
Then a man with a dog behind him. DAN SUPERNAULT.
Then a picture of someone turned 120 degrees in a blanket waving. VAGRANT CASCADIAN.
Finally a cartoon character in the South Park style. BEN PATE.
hopefully, honestly just a really a lovely time really!
ALT text
Rectangular picture. Person in the upper left rotated 90 degrees and he's covering his face like he's in fear.
Middle shows FOSSY 2026. August 6th - 9th 2026 - University of British Columbia, Cananda.
Bottom left is the Fireside Fedi icon, a spinning Fediverse icon on fire.
Middle bottom - FEDICON Fossy 08/008/2026
Bottom Right there are multiple pictures.
Top shows a shadowy man with the name John Mastodon and a cancelled banner over it.
Next is a man in a ball cap with glasses and a beard with the name MATT BAER.
Then man with a beard leaning towards the camera with DJANGO DOUCET.
Then a man with a dog behind him. DAN SUPERNAULT.
Then a picture of someone turned 120 degrees in a blanket waving. VAGRANT CASCADIAN.
Finally a cartoon character in the South Park style. BEN PATE.
🌍 We just got back from Dweb Camp, hosted by the Internet Archive in the German forest — and what a gathering.
Alongside @commonsnetwork@goteo_fund and friends across the Fediverse, we presented the Democratic Tech Fund prototype and ran sessions on governance, P2P financing, and community-owned social spaces.
Hoe behouden we de regie op onze data en systemen? Tijdens het congres van Forum Standaardisatie 20 jaar - Standaarden, openheid en autonomie (21 sept) gaan we de diepte in. We bespreken de moderne soevereine werkplek, #Fediverse-adoptie via social.overheid.nl, het doorbreken van vendor lock-in en de impact van de #AIAct en #NIS2 op onze infra.
Een dag vol concrete lessen, scherpe discussies en nieuwe inzichten over digitale autonomie en open standaarden.
Oh, I missed that federated.press shut down. That was a place for journalism in the #Fediverse and there were multiple accounts for my @MediaOnMastodon on there. They are mostly gone now, it seems.
Does that mean, that my list of official (!) and verified (!) accounts of #media organizations on #Mastodon has begun to shrink? 😔
If you have some, that @MediaOnMastodon is not following, please give me a hint. And please share this.
Oh, I missed that federated.press shut down. That was a place for journalism in the #Fediverse and there were multiple accounts for my @MediaOnMastodon on there. They are mostly gone now, it seems.
Does that mean, that my list of official (!) and verified (!) accounts of #media organizations on #Mastodon has begun to shrink? 😔
If you have some, that @MediaOnMastodon is not following, please give me a hint. And please share this.
Letzte Woche haben eine Reihe von Digitalpolitiker:innen in der Open Social Web Alliance die Vision einer dezentralen Infrastruktur für digitale Kommunikation entworfen 👉 https://osw-alliance.net/ Wir teilen viele der dort formulierten Ziele.
Darüber hinaus wäre es zu begrüßen, wenn die beteiligten Organisationen und Politiker:innen sich in ihrem Umfeld für eine stärkere Nutzung der #Fediverse-Medien einsetzen würden. Also: 🔺 Priorisiert #Mastodon in Eurer digitalen Kommunikation vor den Plattformen von BigTech 🔺 Startet #PeerTube-Präsenzen nach dem Vorbild der @fsfe, @EH_Ludwigsburg etc. 🔺 Zieht Euch von der kriminelle Inhalte verbreitenden #X-Plattform zurück, sofern nicht schon getan 🔺 Führt Fortbildungen Eurer Mitglieder zu Fediverse-Medien durch 🔺 Veranlasst die Euch nahe stehenden Politiker:innen, diese Schritte auch in Ämtern und #Behörden umzusetzen*
Mit solchen konkreten Schritten würden wir der skizzierten Vision in großen Schritten näher kommen.
Feat: Added the ability to delete individual notes from the antenna timeline.
It would be great if forks adopted this feature! I use antennas on several Misskey fork based instances, including this one, they caught some completely irrelevant posts and I always wished I could remove them. #misskey#antenna#fediverse
The closing post in the "Fediverse Beyond Mastodon" maps forums, social reading, and music, the formats that don't fit the microblog.
The Threadiverse (Fediverse's answer to Reddit): Lemmy, Kbin/Mbin and PieFed (created by Rimu - @rimu).
Forums that predate federation: NodeBB (created by @julian) rewrote its core so every new forum federates by default. Discourse (@Discourse) ships it as an opt-in, per-category plugin. Both were built years ago to replace phpBB and vBulletin, and both now speak ActivityPub.
Social reading: BookWyrm (created by @tripofmice), a federated Goodreads where your shelves and reviews show up in a Mastodon timeline.
Music: Funkwhale (@funkwhale) - a self-hosted Grooveshark successor.
Bandwagon (created by @benpate) an online music storefront where musicians sell directly, built on the Emissary framework.
Four glowing neon shapes, a speech bubble, cube, ring, and diamond, linked by a flowing particle trail carrying emojis, musical notes and open books, against a dark background.
The closing post in the "Fediverse Beyond Mastodon" maps forums, social reading, and music, the formats that don't fit the microblog.
The Threadiverse (Fediverse's answer to Reddit): Lemmy, Kbin/Mbin and PieFed (created by Rimu - @rimu).
Forums that predate federation: NodeBB (created by @julian) rewrote its core so every new forum federates by default. Discourse (@Discourse) ships it as an opt-in, per-category plugin. Both were built years ago to replace phpBB and vBulletin, and both now speak ActivityPub.
Social reading: BookWyrm (created by @tripofmice), a federated Goodreads where your shelves and reviews show up in a Mastodon timeline.
Music: Funkwhale (@funkwhale) - a self-hosted Grooveshark successor.
Bandwagon (created by @benpate) an online music storefront where musicians sell directly, built on the Emissary framework.
Four glowing neon shapes, a speech bubble, cube, ring, and diamond, linked by a flowing particle trail carrying emojis, musical notes and open books, against a dark background.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
Oh, I missed that federated.press shut down. That was a place for journalism in the #Fediverse and there were multiple accounts for my @MediaOnMastodon on there. They are mostly gone now, it seems.
Does that mean, that my list of official (!) and verified (!) accounts of #media organizations on #Mastodon has begun to shrink? 😔
If you have some, that @MediaOnMastodon is not following, please give me a hint. And please share this.
Feat: Added the ability to delete individual notes from the antenna timeline.
It would be great if forks adopted this feature! I use antennas on several Misskey fork based instances, including this one, they caught some completely irrelevant posts and I always wished I could remove them. #misskey#antenna#fediverse
In case anyone was wondering, yes my project Wordforge is effectively abandoned. I graduated and got a job last year and haven't had the time to work on it. It's a shame really since I really wanted to see something like this on the fediverse, but such is life.
Has anyone already developed something like a '15 day plan' to try the Fediverse, specifically targeted at helping communities/interest groups give it a go via a series of quick and easy steps?
I'm thinking something like this to help facilitate the beginnings of a migration:
Day 1: Browse the home feeds of these three servers suited to our shared interest(s).
Day 2: Choose one of those servers and register an account.
Day 3: Follow at least ten other accounts; here are 25 suggestions.
Very interesting preprint by @pettertornberg comparing the language indicators for content sharing on different social media platforms. On Mastodon (not sure how much content from the wider Fediverse was included), reasoning and nuance were most strongly associated with boosting. On X, insult, identity attack, and toxicity are rewarded instead. Bluesky doesn't seem to have particularly strong language indicators for sharing content.
Very interesting preprint by @pettertornberg comparing the language indicators for content sharing on different social media platforms. On Mastodon (not sure how much content from the wider Fediverse was included), reasoning and nuance were most strongly associated with boosting. On X, insult, identity attack, and toxicity are rewarded instead. Bluesky doesn't seem to have particularly strong language indicators for sharing content.
Ich wünsche euch einen guten Start in die neue Woche. Am Wochenende haben wir eine kleine Rollertour entlang der Elbe unternommen. 🚴♀️🍃
Während wir gemeinsam durch die schöne Landschaft rollten, kam mir ein Gedanke: Wege verbinden – ganz gleich, ob sie aus Asphalt bestehen oder aus digitalen Verbindungen.
Auch im Fediverse begegnen wir Menschen. Manche begleiten uns nur für einen kurzen Moment, andere über viele Jahre. Wir tauschen Gedanken aus, teilen Wissen, lachen miteinander und lernen voneinander. Und manchmal passiert etwas Schönes: Aus einer digitalen Begegnung wird eine echte. Man trifft sich persönlich, erkennt vertraute Gesichter wieder und merkt, dass aus einem Profil ein Mensch geworden ist.
So wachsen digitale und reale Welt Stück für Stück zusammen. Begegnungsorte gibt es viele – auf Wanderwegen, an der Elbe, bei Veranstaltungen oder eben im Fediverse. Wichtig ist, dass wir offen bleiben, einander zuhören und Freude daran haben, Erfahrungen und Wissen miteinander zu teilen.
In diesem Sinne wünsche ich euch eine angenehme Woche mit vielen schönen Begegnungen – online wie offline. 😊🌿
Zwei weiße Tretroller stehen auf einer grünen Wiese direkt an der Elbe. Im Hintergrund fließt der Fluss vorbei, dahinter liegt ein kleines Dorf mit roten Dächern am bewaldeten Hang der Sächsischen Schweiz. Der Himmel ist strahlend blau und vermittelt eine ruhige, sommerliche Stimmung.
Ich wünsche euch einen guten Start in die neue Woche. Am Wochenende haben wir eine kleine Rollertour entlang der Elbe unternommen. 🚴♀️🍃
Während wir gemeinsam durch die schöne Landschaft rollten, kam mir ein Gedanke: Wege verbinden – ganz gleich, ob sie aus Asphalt bestehen oder aus digitalen Verbindungen.
Auch im Fediverse begegnen wir Menschen. Manche begleiten uns nur für einen kurzen Moment, andere über viele Jahre. Wir tauschen Gedanken aus, teilen Wissen, lachen miteinander und lernen voneinander. Und manchmal passiert etwas Schönes: Aus einer digitalen Begegnung wird eine echte. Man trifft sich persönlich, erkennt vertraute Gesichter wieder und merkt, dass aus einem Profil ein Mensch geworden ist.
So wachsen digitale und reale Welt Stück für Stück zusammen. Begegnungsorte gibt es viele – auf Wanderwegen, an der Elbe, bei Veranstaltungen oder eben im Fediverse. Wichtig ist, dass wir offen bleiben, einander zuhören und Freude daran haben, Erfahrungen und Wissen miteinander zu teilen.
In diesem Sinne wünsche ich euch eine angenehme Woche mit vielen schönen Begegnungen – online wie offline. 😊🌿
Zwei weiße Tretroller stehen auf einer grünen Wiese direkt an der Elbe. Im Hintergrund fließt der Fluss vorbei, dahinter liegt ein kleines Dorf mit roten Dächern am bewaldeten Hang der Sächsischen Schweiz. Der Himmel ist strahlend blau und vermittelt eine ruhige, sommerliche Stimmung.
Yea, things are dispersed. The #fediverse org at #Codeberg is a place where a host of people (co)maintain various fedi-related projects, most notably the #ActivityPub#FEP process. I maintain the 3 fedi curated lists there for https://delightful.coding.social initiative.
Interestingly, Meta has been implementing a "tune your algorithm" type of feature, which is surprisingly user-focused. You can select the topics you want to see more of and what you want to see less of, mute words, add your preferences... of course, Meta has their own agenda and wants you to get as hooked as possible so they can make money off you as a product, but I like the idea that it is not completely opaque.
I am building something similar in my Mastodon instance but truly without any monetary goal.
For algorithm haters out there, remember that reverse chronological order is an algorithm too. If you like getting video recommendations on YouTube, PeerTube, or music recommendations in a playlist, that is an algorithm too. I honestly do not understand all the algorithm hate when it is focused on the tech itself rather than commercialism.
The capitalist nature of algorithms is, of course, something to stand against, since it works by exploiting users. But if it is for user benefit without any rotten backstory, algorithms in my world are great.
A tip for users of our experimental instance mementomori.social:
You can enable the algorithmic "For you" feed from the top right corner of the Home feed. When you turn it on, it will instantly switch to a ranked feed that prioritizes posts based on who you follow, who you comment on, and what you like or boost. If you also toggle on "Include posts from people you don't follow," you'll see trending content across the Fediverse based on your interests.
Unlike Trending tab, For you -feed is personal. The logic is similar to pre-Musk Twitter but user-focused and not corporate-owned.
The Trending tab remains unchanged, and /explore shows posts from roughly the past 6-12 hours, with a strong focus on the most recent ones. A post that gets massive engagement might stick around a bit longer, but most cycle out within half a day. Your own For you page changes every time you click the menu, refresh the page, or return.
Interestingly, Meta has been implementing a "tune your algorithm" type of feature, which is surprisingly user-focused. You can select the topics you want to see more of and what you want to see less of, mute words, add your preferences... of course, Meta has their own agenda and wants you to get as hooked as possible so they can make money off you as a product, but I like the idea that it is not completely opaque.
I am building something similar in my Mastodon instance but truly without any monetary goal.
For algorithm haters out there, remember that reverse chronological order is an algorithm too. If you like getting video recommendations on YouTube, PeerTube, or music recommendations in a playlist, that is an algorithm too. I honestly do not understand all the algorithm hate when it is focused on the tech itself rather than commercialism.
The capitalist nature of algorithms is, of course, something to stand against, since it works by exploiting users. But if it is for user benefit without any rotten backstory, algorithms in my world are great.
A tip for users of our experimental instance mementomori.social:
You can enable the algorithmic "For you" feed from the top right corner of the Home feed. When you turn it on, it will instantly switch to a ranked feed that prioritizes posts based on who you follow, who you comment on, and what you like or boost. If you also toggle on "Include posts from people you don't follow," you'll see trending content across the Fediverse based on your interests.
Unlike Trending tab, For you -feed is personal. The logic is similar to pre-Musk Twitter but user-focused and not corporate-owned.
The Trending tab remains unchanged, and /explore shows posts from roughly the past 6-12 hours, with a strong focus on the most recent ones. A post that gets massive engagement might stick around a bit longer, but most cycle out within half a day. Your own For you page changes every time you click the menu, refresh the page, or return.
Ah, cierto. No recordaba ese detalle. A su vez quienes quieran que sus interacciones lleguen a bluesky también tienen que seguir a @bsky.brid.gy , aunque parece que han añadido otra opción también (aquí los detalles https://fed.brid.gy/docs#fediverse-get-started)
Animated GIF showing the word "fediverse" next to a proposed fediverse symbol, the so-called "asterism", which is basically a triangle made up of asterisks stacked on top of each other, two on the bottom and one on top.
When the word "fediverse" is clicked, a translation in another language replaces it.
Celebration graphic for ForkMesh reaching 100 followers on Mastodon. Against a dark blue and purple network-themed background, large text reads “100 Followers on Mastodon!” with the ForkMesh logo above it. Below, a thank-you message expresses appreciation to everyone who has followed, shared feedback, tested the project, and helped spread the word. A large metallic 3D ForkMesh cube logo sits on a glowing blue and purple circular platform in the center. At the bottom, the graphic reads, “Onward to the next 100. 🚀”
Celebration graphic for ForkMesh reaching 100 followers on Mastodon. Against a dark blue and purple network-themed background, large text reads “100 Followers on Mastodon!” with the ForkMesh logo above it. Below, a thank-you message expresses appreciation to everyone who has followed, shared feedback, tested the project, and helped spread the word. A large metallic 3D ForkMesh cube logo sits on a glowing blue and purple circular platform in the center. At the bottom, the graphic reads, “Onward to the next 100. 🚀”
#HolosDiscover is a search engine dedicated to the #Fediverse. It does not scrape content, because it speaks #ActivityPub and respects each user's choice to opt in or out. The most respectful alternative, open to all and full of content to explore.
A golden-brown Bengal cat with dark spots and rosettes is stretched out asleep on a rumpled dark grey bed sheet. The cat's body is fully extended in a relaxed position with eyes closed, front paws reaching forward and hind legs stretched back. Ringed tail curves slightly upward.
A golden-brown Bengal cat with dark spots and rosettes is stretched out asleep on a rumpled dark grey bed sheet. The cat's body is fully extended in a relaxed position with eyes closed, front paws reaching forward and hind legs stretched back. Ringed tail curves slightly upward.
#HolosDiscover is a search engine dedicated to the #Fediverse. It does not scrape content, because it speaks #ActivityPub and respects each user's choice to opt in or out. The most respectful alternative, open to all and full of content to explore.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
Animated GIF showing the word "fediverse" next to a proposed fediverse symbol, the so-called "asterism", which is basically a triangle made up of asterisks stacked on top of each other, two on the bottom and one on top.
When the word "fediverse" is clicked, a translation in another language replaces it.
A calico cat with black and ginger patches and white paws sleeping peacefully on its side. The cat is nestled on a brown and cream geometric patterned blanket, with its eyes closed in deep relaxation.
A calico cat with black and ginger patches and white paws sleeping peacefully on its side. The cat is nestled on a brown and cream geometric patterned blanket, with its eyes closed in deep relaxation.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
Has anyone already developed something like a '15 day plan' to try the Fediverse, specifically targeted at helping communities/interest groups give it a go via a series of quick and easy steps?
I'm thinking something like this to help facilitate the beginnings of a migration:
Day 1: Browse the home feeds of these three servers suited to our shared interest(s).
Day 2: Choose one of those servers and register an account.
Day 3: Follow at least ten other accounts; here are 25 suggestions.
Do I need another #fediverse account? No. Have I created one to muck about with other tools? Why yes I have. Because obviously I need more #sysadmin tasks in my life. When will I learn?
Promotional graphic for ForkMesh v0.6.1 on a dark blue and purple neon tech background. Large headline reads “ForkMesh v0.6.1 Now Federated,” with the subtitle “Follow a repo or a user from the Fediverse.” A metallic 3D ForkMesh cube logo appears in the foreground. On the right, an angled Mastodon interface shows the federated ForkMesh repository profile @forkmesh.forkmesh@forkmesh.com. Footer callouts highlight federation, decentralization, open source, and local-first design.
Promotional graphic for ForkMesh v0.6.1 on a dark blue and purple neon tech background. Large headline reads “ForkMesh v0.6.1 Now Federated,” with the subtitle “Follow a repo or a user from the Fediverse.” A metallic 3D ForkMesh cube logo appears in the foreground. On the right, an angled Mastodon interface shows the federated ForkMesh repository profile @forkmesh.forkmesh@forkmesh.com. Footer callouts highlight federation, decentralization, open source, and local-first design.
#HolosSocial relay is confirmed to be very stable. I will officially tag it soon so admins can run their own relay with a script to easily install it on their VPS. Using Holos with a custom domain and a cloud for media allows you to own your portable identity on the #Fediverse. Relays become only an infrastructure for it. Your device runs the #ActivityPub server and works as smoothly as any other app. Micro-blogging, media, and video, all from a single account. Switch with a simple tap.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#HolosSocial relay is confirmed to be very stable. I will officially tag it soon so admins can run their own relay with a script to easily install it on their VPS. Using Holos with a custom domain and a cloud for media allows you to own your portable identity on the #Fediverse. Relays become only an infrastructure for it. Your device runs the #ActivityPub server and works as smoothly as any other app. Micro-blogging, media, and video, all from a single account. Switch with a simple tap.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
I finally added an oft-requested feature to https://arewedecentralizedyet.online/ , my project to track statistics for the #fediverse and other Internet infrastructure. it now includes history for the Shannon Index, showing how decentralization has evolved over the time I've been collecting data.
ALT text
A screenshot of https://arewedecentralizedyet.online/ showing a gauge with the HHI, an indicator that the Shannon Index is holding steady, and a graph of values over the last 6 months.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
I finally added an oft-requested feature to https://arewedecentralizedyet.online/ , my project to track statistics for the #fediverse and other Internet infrastructure. it now includes history for the Shannon Index, showing how decentralization has evolved over the time I've been collecting data.
ALT text
A screenshot of https://arewedecentralizedyet.online/ showing a gauge with the HHI, an indicator that the Shannon Index is holding steady, and a graph of values over the last 6 months.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.
mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.
Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.
If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.
Animated GIF showing the word "fediverse" next to a proposed fediverse symbol, the so-called "asterism", which is basically a triangle made up of asterisks stacked on top of each other, two on the bottom and one on top.
When the word "fediverse" is clicked, a translation in another language replaces it.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
I finally added an oft-requested feature to https://arewedecentralizedyet.online/ , my project to track statistics for the #fediverse and other Internet infrastructure. it now includes history for the Shannon Index, showing how decentralization has evolved over the time I've been collecting data.
ALT text
A screenshot of https://arewedecentralizedyet.online/ showing a gauge with the HHI, an indicator that the Shannon Index is holding steady, and a graph of values over the last 6 months.
I finally added an oft-requested feature to https://arewedecentralizedyet.online/ , my project to track statistics for the #fediverse and other Internet infrastructure. it now includes history for the Shannon Index, showing how decentralization has evolved over the time I've been collecting data.
ALT text
A screenshot of https://arewedecentralizedyet.online/ showing a gauge with the HHI, an indicator that the Shannon Index is holding steady, and a graph of values over the last 6 months.
I finally added an oft-requested feature to https://arewedecentralizedyet.online/ , my project to track statistics for the #fediverse and other Internet infrastructure. it now includes history for the Shannon Index, showing how decentralization has evolved over the time I've been collecting data.
ALT text
A screenshot of https://arewedecentralizedyet.online/ showing a gauge with the HHI, an indicator that the Shannon Index is holding steady, and a graph of values over the last 6 months.
I finally added an oft-requested feature to https://arewedecentralizedyet.online/ , my project to track statistics for the #fediverse and other Internet infrastructure. it now includes history for the Shannon Index, showing how decentralization has evolved over the time I've been collecting data.
ALT text
A screenshot of https://arewedecentralizedyet.online/ showing a gauge with the HHI, an indicator that the Shannon Index is holding steady, and a graph of values over the last 6 months.
I finally added an oft-requested feature to https://arewedecentralizedyet.online/ , my project to track statistics for the #fediverse and other Internet infrastructure. it now includes history for the Shannon Index, showing how decentralization has evolved over the time I've been collecting data.
ALT text
A screenshot of https://arewedecentralizedyet.online/ showing a gauge with the HHI, an indicator that the Shannon Index is holding steady, and a graph of values over the last 6 months.
First, the actor cards on the followed/following pages show relevant actor status. On the followed page, it tells you how long it has been since that actor published an activity (create, announce, like, etc.) that was sent to your server. It's a proxy for how active they are (or are not). On the following page, it tells you how long it has been since you have been able to send to that server. It's a proxy for whether that server is reachable or that actor is still alive.
Second, the backend for user-defined algorithmic feeds is in place, along with a keyword/hashtag/mention feeds implementation. You can't set up a feed via the user-interface, but the feeds work if you set one up directly in the database—which is how I've been previewing them.. I plan to release the frontend next week.
Here's the full changelog:
Added
Display activity status on actor cards.
Back-end support for user-defined algorithmic feeds.
Apply community-relayed moderator deletes received as a Group's wrapped Announce.
Follow a web page's rel="alternate" link when searching.
Fixed
Avoid loading entire has_many collections when constructing child records.
Evaluate the same-origin fetch gate against an embedded node's own identifier.
Accept a delete of an uncached object or actor without verification.
Catch MIME::Multipart::Error in local file-upload handling.
Map malformed request-body parse failures to Bad Request.
First, the actor cards on the followed/following pages show relevant actor status. On the followed page, it tells you how long it has been since that actor published an activity (create, announce, like, etc.) that was sent to your server. It's a proxy for how active they are (or are not). On the following page, it tells you how long it has been since you have been able to send to that server. It's a proxy for whether that server is reachable or that actor is still alive.
Second, the backend for user-defined algorithmic feeds is in place, along with a keyword/hashtag/mention feeds implementation. You can't set up a feed via the user-interface, but the feeds work if you set one up directly in the database—which is how I've been previewing them.. I plan to release the frontend next week.
Here's the full changelog:
Added
Display activity status on actor cards.
Back-end support for user-defined algorithmic feeds.
Apply community-relayed moderator deletes received as a Group's wrapped Announce.
Follow a web page's rel="alternate" link when searching.
Fixed
Avoid loading entire has_many collections when constructing child records.
Evaluate the same-origin fetch gate against an embedded node's own identifier.
Accept a delete of an uncached object or actor without verification.
Catch MIME::Multipart::Error in local file-upload handling.
Map malformed request-body parse failures to Bad Request.
Animated GIF showing the word "fediverse" next to a proposed fediverse symbol, the so-called "asterism", which is basically a triangle made up of asterisks stacked on top of each other, two on the bottom and one on top.
When the word "fediverse" is clicked, a translation in another language replaces it.
Animated GIF showing the word "fediverse" next to a proposed fediverse symbol, the so-called "asterism", which is basically a triangle made up of asterisks stacked on top of each other, two on the bottom and one on top.
When the word "fediverse" is clicked, a translation in another language replaces it.
Today @koppershared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.
The author's frustration with naïve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you much—you end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The “JSON-LD flavored Mastodon API” framing is apt.
The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate “client” layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.
But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:
C2S server ≈ a database (PostgreSQL, say)
“Client” ≈ an application server (Mastodon, Misskey)
“Frontend” ≈ the actual client app on your phone
That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the “client” layer—the bottom boundary.
The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: “we don't really need a standardized api,” they write, leaving each client free to expose whatever API it likes.
Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2S—log in to any server with any app—isn't actually delivered. It's been pushed one layer down, out of reach of the end user.
There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.
my opinions about how activitypub c2s ought to be implemented, probably with way too much snark for anyone to take it seriously. wrote pretty much all of it at like 1 am so expect the writing to not be great. will prolly regret it tomorrow but eh. whatever
So, I got this question some days ago and I can only guess: Why is there almost no content on #Mastodon/ in the #Fediverse about the #WorldCup?
Yes, I know, that we're supposed to boycott etc. But that's clearly no majority opinion out there. Is there really no interest here? Is it because of something technical? Like no proper live debate because you won't see all posts? Or does (almost) no one post about football here, because of negative replies? What do you think?
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
Foto di me, Marta e Evan mentre indichiamo lo schermo con la scritta “How Widely do Hashtags Federate?” e i server Mastodon.social, mastodon.uno e pan.rent
Foto di me, Marta e Evan mentre indichiamo lo schermo con la scritta “How Widely do Hashtags Federate?” e i server Mastodon.social, mastodon.uno e pan.rent
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
First, the actor cards on the followed/following pages show relevant actor status. On the followed page, it tells you how long it has been since that actor published an activity (create, announce, like, etc.) that was sent to your server. It's a proxy for how active they are (or are not). On the following page, it tells you how long it has been since you have been able to send to that server. It's a proxy for whether that server is reachable or that actor is still alive.
Second, the backend for user-defined algorithmic feeds is in place, along with a keyword/hashtag/mention feeds implementation. You can't set up a feed via the user-interface, but the feeds work if you set one up directly in the database—which is how I've been previewing them.. I plan to release the frontend next week.
Here's the full changelog:
Added
Display activity status on actor cards.
Back-end support for user-defined algorithmic feeds.
Apply community-relayed moderator deletes received as a Group's wrapped Announce.
Follow a web page's rel="alternate" link when searching.
Fixed
Avoid loading entire has_many collections when constructing child records.
Evaluate the same-origin fetch gate against an embedded node's own identifier.
Accept a delete of an uncached object or actor without verification.
Catch MIME::Multipart::Error in local file-upload handling.
Map malformed request-body parse failures to Bad Request.
First, the actor cards on the followed/following pages show relevant actor status. On the followed page, it tells you how long it has been since that actor published an activity (create, announce, like, etc.) that was sent to your server. It's a proxy for how active they are (or are not). On the following page, it tells you how long it has been since you have been able to send to that server. It's a proxy for whether that server is reachable or that actor is still alive.
Second, the backend for user-defined algorithmic feeds is in place, along with a keyword/hashtag/mention feeds implementation. You can't set up a feed via the user-interface, but the feeds work if you set one up directly in the database—which is how I've been previewing them.. I plan to release the frontend next week.
Here's the full changelog:
Added
Display activity status on actor cards.
Back-end support for user-defined algorithmic feeds.
Apply community-relayed moderator deletes received as a Group's wrapped Announce.
Follow a web page's rel="alternate" link when searching.
Fixed
Avoid loading entire has_many collections when constructing child records.
Evaluate the same-origin fetch gate against an embedded node's own identifier.
Accept a delete of an uncached object or actor without verification.
Catch MIME::Multipart::Error in local file-upload handling.
Map malformed request-body parse failures to Bad Request.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
Not sure if there's an existing framework that can be designed to work with #ActivityPub. But I do think that thinking about consent in a more general/generic sense would be a worthwhile effort. This should be something that is picked up at the #SocialCG level, or perhaps in #FEP documents first. A lot of the mechanisms that proliferate now are also app-centric and almost *assume* that #fediverse is a glorified #microblogging environment. The more that trend continues, the more that will indeed be the case. This is what my long blog post was about, that I wrote recently:
Absolute Madness how everyone thinks it is just okay to sprinkle magic opt-in / opt-out and other control words in the profile description of someone's #fediverse account!
Why do we have #ActivityPub be extensible if not for supporting a native mechanism to deal with consent? Why should there be out-of-bound ugliest of ugliest hacks?
With all that jazz being introduced it is no wonder people opt-in for #ATProto and other more sane social networking protocols that have robust protocol specifications, and not a metric ton of protocol decay to poop on top of your basic AP implementation so it becomes interoperable until the next on-the-fly hack by someone else breaks your nice code..
Fediverse is protocol impl + eternal whack-a-mole development and maintenance this way.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
Website carbon results for: mastodon.social
Oh no! This web page achieves a carbon rating of F
This is dirtier than
83
% of all web pages globally
Learn about our rating system
This page was last tested on 23 Mar, 2026.
ALT text
Oh my,
0.71
g of CO2 is produced every time someone visits this web page.
How do we calculate this?
Oh no, it looks like this web page uses bog standard energy
If this site used green hosting, then it would emit 9% less CO2
How do we find this out?
This result is an approximation
You can get a comprehensive view of a website’s emissions and potential improvements by carrying out a Website Carbon™ Audit.
ALT text
Over a year, with
10,000
monthly page views,
mastodon.social
produces
85.37kg of CO2 equivalent.
As much CO2 as boiling water for 11,567 cups of tea
173 kWh of energy
As much C02 as 14,400 full charges of an average smartphone.
ALT text
91 billion bubbles
Woah, that’s a lot of bubbles!
4 trees
This web page emits the amount of carbon that 4 trees absorb in a year.
173kWh of energy
That’s enough electricity to drive an electric car 1,106km (or 687 miles).
ALT text
Website carbon results for: fe.disroot.org
Oh no! This web page achieves a carbon rating of D
This is dirtier than
51
% of all web pages globally
Learn about our rating system
This page was last tested on 9 Jul, 2026.
ALT text
Website carbon results for: federation.network
Oh no! This web page achieves a carbon rating of D
This is dirtier than
56
% of all web pages globally
Learn about our rating system
This page was last tested on 8 Jul, 2026.
Just opened an issue for a major new task for #Fedify: building an #interoperability smoke test suite.
To ensure Fedify-built servers federate correctly with the wider #fediverse, we're planning to run automated E2E tests in #CI against live instances of Mastodon, Misskey, and more. This is crucial for a framework's reliability.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
Und wieder zurueck in der alten Heimat... zumindest fuer ne knappe Woche.
Moin #Fediverse und euch nen gesunden Start in diesen Donnerstag. Alles wird gut!
ALT text
Vordergrund und Perspektive: Der Blickwinkel ist erhöht und schaut mittig auf eine mehrspurige, asphaltierte Straße hinab. Flankiert wird das Bild links von einer dunklen, geriffelten Gebäudefassade und rechts von einem modernen, hellbeigen Bürogebäude.
Mittelgrund: Die Straße führt geradeaus in eine dunkle Unterführung unter einer Bahnbrücke. Auf der Brücke steht oder fährt ein grün-weißer Regionalzug (Eurobahn-Design). Rechts der Straße wachsen dichte, grüne Bäume.
Hintergrund: Hinter den Bahnanlagen erstreckt sich eine grüne Kulisse aus Bäumen und vereinzelten Häusern. Markantestes Merkmal ist ein hoher, historischer Backsteinkirchturm mit einer spitzen, grünlichen Turmhaube, der zentral in den Himmel ragt. Zahlreiche Oberleitungsmasten für die Bahnlinien ziehen sich durch das Bild.
Himmel und Licht: Der Himmel ist bewölkt mit hellen Lücken, das Licht wirkt wie an einem leicht wechselhaften Sommertag.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.
AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.
I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.
Btw., if you poop on the simple things (food, hobbies, fun experiences, photos of pets or flowers, that kind of stuff...) I or people I like enjoy and share here, it's an instant block.
There is little enough happiness in this world (and in the #fediverse), so the only way to deal with folks who stomp it down even more is throwing them out of the conversation.
WOW decentralized and ENCRYPTED social media over #chatmail this is such an epic prototype!
the fun part is that by using chatmail:
- DMs are already end-to-end encrypted - your identity is your encryption key and doesn't depend on a single home server - your profile is basically uncensorable
since you need to give people your invite link it is kind of like private social network
We're pleased to announce BotKit 0.5.0. This release changes how both the docs site and every bot's own pages look, and it stops limiting a server to one bot: a single process can now host a whole fleet of them. Quoting, and being quoted, goes through a consent step under FEP-044f, and a Redis-backed repository joins the SQLite and PostgreSQL ones for shared production storage. A few of these changes are breaking; see below for what to check before you upgrade.
A new look for botkit.fedify.dev
Until this release, botkit.fedify.dev read like a stock VitePress site: a workable but generic shell wrapped around the docs, with none of BotKit's own personality showing through.
The theme and the landing page are both new. The palette now matches the real logo greens instead of a generic default, and headlines are set in Space Grotesk, paired with Inter for everything else; the display font is self-hosted, so no visitor's IP is handed to a font CDN. The new landing page frames BotKit's dinosaur mascot inside its signature unassembled-model-kit sprue frame, then leads with a tabbed installer for Deno, npm, pnpm, and Yarn and a one-file bot example before getting into what BotKit actually does: messages, events, multi-bot instances, and the pages it builds for a bot without any extra work from you.
The deployment guides grew alongside the new landing page: they were split apart and fleshed out, and a new Cloudflare Workers guide joins the existing Deno Deploy, Docker, and self-hosting guides.
A new look for your bot's pages
The pages BotKit serves for your bot (its profile, its posts, its follower list) got the same attention, in the opposite direction. Until now they were built on Pico CSS pulled from an external CDN: a fine default, but a generic one that made every BotKit-hosted bot look like a demo of the same template, and that quietly sent every visitor's browser off to fetch a stylesheet from someone else's server.
That's gone. Bot pages now use a self-contained design system, bundled with the package and served from BotKit's own content-addressed, cache-forever path: no external CDN, no build step, on either Deno or Node.js. The whole look is driven by a single accent color you choose (twenty names, the same legend Pico CSS uses, so your existing choice of color still works), tinting links, the follow button, and small highlights, while everything else stays quiet so your bot's name, avatar, and posts are what a visitor actually notices. A new PagesOptions.theme option ("auto", "light", or "dark") controls the color scheme independently of the accent. A repost is now marked and attributed to its original author instead of blending into the bot's own timeline.
If you want to go further than the accent color allows, PagesOptions.css still lets you inject custom CSS on top of BotKit's own stylesheet.
Multi-bot instances
Until this release, a BotKit process could only ever be one bot. Running a second bot meant standing up a whole second server, even when the two bots could easily have shared the same infrastructure. That limitation, raised in #16, is gone: the new createInstance() function creates an Instance that owns the shared plumbing (the key–value store, the message queue, the repository, and HTTP handling), and any number of bots can live on it side by side, each with its own actor identity and event handlers.
For a fixed, known set of bots, Instance.createBot() takes an identifier and a profile:
import { createInstance, text } from "@fedify/botkit";import { MemoryKvStore } from "@fedify/fedify";const instance = createInstance<void>({ kv: new MemoryKvStore() });const greetBot = instance.createBot("greet", { username: "greetbot", name: "Greeting Bot",});greetBot.onFollow = async (session, followRequest) => { await followRequest.accept(); await session.publish(text`Welcome, ${followRequest.follower}!`);};
For a family of bots resolved on demand (one per region, one per customer, thousands of them backed by a database), pass a dispatcher function instead of a fixed identifier, and BotKit resolves and federates each one lazily:
Incoming activities are routed only to the bots they actually concern: the followed bot, the owner of a liked or replied-to message, mentioned bots, and bots followed by the sender. Multi-bot instances also serve a list of hosted bots at the web root, with each bot's own pages moving to /@{username}; a reserved instance actor signs shared-inbox requests when there's no single bot whose key obviously should.
None of this touches single-bot deployments: createBot() keeps working exactly as it always has, with the bot's pages staying at the web root and its data migrated to the new storage layout automatically on startup. If you maintain a custom Repository implementation, though, this is a breaking change worth planning for: every method now takes the owning bot's identifier as its first parameter, Session.bot is a read-only ReadonlyBot instead of a mutable Bot, and local object URIs carry the owning bot's identifier (old-format URIs are still recognized and permanently redirected, so links other servers stored keep working). The full picture, including how to move an existing single-bot deployment onto a multi-bot instance later, is in the new Instance concept document.
Thanks to @moreal, whose early work-in-progress explorations of this problem surfaced its two hardest design questions (mapping usernames to identifiers for dynamic bots, and routing object URIs that used to carry no owner information) well before this implementation settled on its final shape.
Consent-respecting quotes with FEP-044f
BotKit has supported quoting since 0.2.0, but only in the Misskey family's style: a quoteUrl property and a Link tag, sent without ever asking the quoted author. Mastodon 4.4 and 4.5 do things differently: they verify quotes through FEP-044f's consent handshake before showing them as quotes at all. Without that handshake, a BotKit bot's quotes never rendered as quotes on Mastodon, and quotes of a BotKit bot showed up as unverifiable.
BotKit now handles the FEP-044f handshake in both directions. When you quote a message, it sets the FEP-044f quote property and sends a QuoteRequest to the quoted author, alongside the Create it already sent. Publishing stays non-blocking: the post goes out immediately, and the quote is upgraded once (or if) approval arrives:
On the receiving side, a new quotePolicy option (on createBot(), and per message on Session.publish()) controls how your bot answers incoming quote requests: automatically for everyone ("public", the default), automatically for followers only, never ("nobody"), or held for manual review through the new Bot.onQuoteRequest event:
Bot.onQuoteAccepted, Bot.onQuoteRejected, and Bot.onQuoteRevoked cover what happens next for quotes your own bot sent, Message.quoteApproved reports whether an incoming quote carries a valid authorization stamp, and AuthorizedMessage.unauthorizeQuote() lets you revoke one you previously granted. The legacy quoteUrl and Misskey-style tags are still sent alongside the new property, so nothing about quoting on Misskey and its relatives changes. The full design is spread across #27 through #33.
A Redis repository (@fedify/botkit-redis)
BotKit has had a SQLite repository since 0.3.0 and a PostgreSQL one since 0.4.0, but neither is the natural fit for a bot that runs as several worker processes sharing one store, which is exactly the shape a Redis-backed deployment usually takes. The new @fedify/botkit-redis package fills that gap with RedisRepository, built directly on Redis strings, sets, and sorted sets rather than going through a generic key–value abstraction:
import { createBot, MemoryKvStore } from "@fedify/botkit";import { RedisRepository } from "@fedify/botkit-redis";const bot = createBot({ username: "mybot", kv: new MemoryKvStore(), repository: new RedisRepository({ url: "redis://localhost:6379/0" }),});
Because several workers can share one Redis instance, the read-modify-write paths that matter most under concurrency (message updates, follower bookkeeping, quote authorization indexes) are protected by short-lived locks that get renewed while a slow update is still running, rather than by assuming only one process ever touches the data at a time. The package supports both a connection URL it manages itself and an existing node-redis client you inject and keep control of, and it's available for both Deno and Node.js. #12 and #35 cover the rest of it.
Smaller improvements
The npm package's TypeScript declaration files no longer accidentally include the runtime Temporal polyfill code, which had been leaking into consumers' .d.ts output. Fedify was upgraded to 2.3.1, Hono to 4.12.27, and LogTape to 2.2.3.
As always, the full list of changes is in CHANGES.md, and every API mentioned above is documented at botkit.fedify.dev. Thank you to everyone who filed issues, opened discussions, and tried BotKit out.
If you build something with BotKit, run into a rough edge, or just want to talk through an idea before opening an issue, GitHub Discussions is the place for exactly that. For something closer to real time, BotKit's chat now lives on Matrix at #fedify:matrix.org. Drop in and say hello.
Btw., if you poop on the simple things (food, hobbies, fun experiences, photos of pets or flowers, that kind of stuff...) I or people I like enjoy and share here, it's an instant block.
There is little enough happiness in this world (and in the #fediverse), so the only way to deal with folks who stomp it down even more is throwing them out of the conversation.
Seeing the overwhelmingly positive responses from their community further confirms to me that the "global townsquare" experiment truly might be coming to an end.
Yes, there is still definitely room for a place for global conversations, but between the fragmentation of our shared online world, invasion of privacy through laws and regulations, and LLM crawlers hoovering up the public internet, it just makes sense to turn our attention to tools that let people build more tight-knit communities online.
Hopefully we'll see the fediverse step up in this area.
We're pleased to announce BotKit 0.5.0. This release changes how both the docs site and every bot's own pages look, and it stops limiting a server to one bot: a single process can now host a whole fleet of them. Quoting, and being quoted, goes through a consent step under FEP-044f, and a Redis-backed repository joins the SQLite and PostgreSQL ones for shared production storage. A few of these changes are breaking; see below for what to check before you upgrade.
A new look for botkit.fedify.dev
Until this release, botkit.fedify.dev read like a stock VitePress site: a workable but generic shell wrapped around the docs, with none of BotKit's own personality showing through.
The theme and the landing page are both new. The palette now matches the real logo greens instead of a generic default, and headlines are set in Space Grotesk, paired with Inter for everything else; the display font is self-hosted, so no visitor's IP is handed to a font CDN. The new landing page frames BotKit's dinosaur mascot inside its signature unassembled-model-kit sprue frame, then leads with a tabbed installer for Deno, npm, pnpm, and Yarn and a one-file bot example before getting into what BotKit actually does: messages, events, multi-bot instances, and the pages it builds for a bot without any extra work from you.
The deployment guides grew alongside the new landing page: they were split apart and fleshed out, and a new Cloudflare Workers guide joins the existing Deno Deploy, Docker, and self-hosting guides.
A new look for your bot's pages
The pages BotKit serves for your bot (its profile, its posts, its follower list) got the same attention, in the opposite direction. Until now they were built on Pico CSS pulled from an external CDN: a fine default, but a generic one that made every BotKit-hosted bot look like a demo of the same template, and that quietly sent every visitor's browser off to fetch a stylesheet from someone else's server.
That's gone. Bot pages now use a self-contained design system, bundled with the package and served from BotKit's own content-addressed, cache-forever path: no external CDN, no build step, on either Deno or Node.js. The whole look is driven by a single accent color you choose (twenty names, the same legend Pico CSS uses, so your existing choice of color still works), tinting links, the follow button, and small highlights, while everything else stays quiet so your bot's name, avatar, and posts are what a visitor actually notices. A new PagesOptions.theme option ("auto", "light", or "dark") controls the color scheme independently of the accent. A repost is now marked and attributed to its original author instead of blending into the bot's own timeline.
If you want to go further than the accent color allows, PagesOptions.css still lets you inject custom CSS on top of BotKit's own stylesheet.
Multi-bot instances
Until this release, a BotKit process could only ever be one bot. Running a second bot meant standing up a whole second server, even when the two bots could easily have shared the same infrastructure. That limitation, raised in #16, is gone: the new createInstance() function creates an Instance that owns the shared plumbing (the key–value store, the message queue, the repository, and HTTP handling), and any number of bots can live on it side by side, each with its own actor identity and event handlers.
For a fixed, known set of bots, Instance.createBot() takes an identifier and a profile:
import { createInstance, text } from "@fedify/botkit";import { MemoryKvStore } from "@fedify/fedify";const instance = createInstance<void>({ kv: new MemoryKvStore() });const greetBot = instance.createBot("greet", { username: "greetbot", name: "Greeting Bot",});greetBot.onFollow = async (session, followRequest) => { await followRequest.accept(); await session.publish(text`Welcome, ${followRequest.follower}!`);};
For a family of bots resolved on demand (one per region, one per customer, thousands of them backed by a database), pass a dispatcher function instead of a fixed identifier, and BotKit resolves and federates each one lazily:
Incoming activities are routed only to the bots they actually concern: the followed bot, the owner of a liked or replied-to message, mentioned bots, and bots followed by the sender. Multi-bot instances also serve a list of hosted bots at the web root, with each bot's own pages moving to /@{username}; a reserved instance actor signs shared-inbox requests when there's no single bot whose key obviously should.
None of this touches single-bot deployments: createBot() keeps working exactly as it always has, with the bot's pages staying at the web root and its data migrated to the new storage layout automatically on startup. If you maintain a custom Repository implementation, though, this is a breaking change worth planning for: every method now takes the owning bot's identifier as its first parameter, Session.bot is a read-only ReadonlyBot instead of a mutable Bot, and local object URIs carry the owning bot's identifier (old-format URIs are still recognized and permanently redirected, so links other servers stored keep working). The full picture, including how to move an existing single-bot deployment onto a multi-bot instance later, is in the new Instance concept document.
Thanks to @moreal, whose early work-in-progress explorations of this problem surfaced its two hardest design questions (mapping usernames to identifiers for dynamic bots, and routing object URIs that used to carry no owner information) well before this implementation settled on its final shape.
Consent-respecting quotes with FEP-044f
BotKit has supported quoting since 0.2.0, but only in the Misskey family's style: a quoteUrl property and a Link tag, sent without ever asking the quoted author. Mastodon 4.4 and 4.5 do things differently: they verify quotes through FEP-044f's consent handshake before showing them as quotes at all. Without that handshake, a BotKit bot's quotes never rendered as quotes on Mastodon, and quotes of a BotKit bot showed up as unverifiable.
BotKit now handles the FEP-044f handshake in both directions. When you quote a message, it sets the FEP-044f quote property and sends a QuoteRequest to the quoted author, alongside the Create it already sent. Publishing stays non-blocking: the post goes out immediately, and the quote is upgraded once (or if) approval arrives:
On the receiving side, a new quotePolicy option (on createBot(), and per message on Session.publish()) controls how your bot answers incoming quote requests: automatically for everyone ("public", the default), automatically for followers only, never ("nobody"), or held for manual review through the new Bot.onQuoteRequest event:
Bot.onQuoteAccepted, Bot.onQuoteRejected, and Bot.onQuoteRevoked cover what happens next for quotes your own bot sent, Message.quoteApproved reports whether an incoming quote carries a valid authorization stamp, and AuthorizedMessage.unauthorizeQuote() lets you revoke one you previously granted. The legacy quoteUrl and Misskey-style tags are still sent alongside the new property, so nothing about quoting on Misskey and its relatives changes. The full design is spread across #27 through #33.
A Redis repository (@fedify/botkit-redis)
BotKit has had a SQLite repository since 0.3.0 and a PostgreSQL one since 0.4.0, but neither is the natural fit for a bot that runs as several worker processes sharing one store, which is exactly the shape a Redis-backed deployment usually takes. The new @fedify/botkit-redis package fills that gap with RedisRepository, built directly on Redis strings, sets, and sorted sets rather than going through a generic key–value abstraction:
import { createBot, MemoryKvStore } from "@fedify/botkit";import { RedisRepository } from "@fedify/botkit-redis";const bot = createBot({ username: "mybot", kv: new MemoryKvStore(), repository: new RedisRepository({ url: "redis://localhost:6379/0" }),});
Because several workers can share one Redis instance, the read-modify-write paths that matter most under concurrency (message updates, follower bookkeeping, quote authorization indexes) are protected by short-lived locks that get renewed while a slow update is still running, rather than by assuming only one process ever touches the data at a time. The package supports both a connection URL it manages itself and an existing node-redis client you inject and keep control of, and it's available for both Deno and Node.js. #12 and #35 cover the rest of it.
Smaller improvements
The npm package's TypeScript declaration files no longer accidentally include the runtime Temporal polyfill code, which had been leaking into consumers' .d.ts output. Fedify was upgraded to 2.3.1, Hono to 4.12.27, and LogTape to 2.2.3.
As always, the full list of changes is in CHANGES.md, and every API mentioned above is documented at botkit.fedify.dev. Thank you to everyone who filed issues, opened discussions, and tried BotKit out.
If you build something with BotKit, run into a rough edge, or just want to talk through an idea before opening an issue, GitHub Discussions is the place for exactly that. For something closer to real time, BotKit's chat now lives on Matrix at #fedify:matrix.org. Drop in and say hello.
🌐 Fediverse – wie sich alles zusammen nutzen lässt
Das Fediverse besteht aus vielen verschiedenen Anwendungen wie Friendica, Mastodon, PixelFed, PeerTube oder BookWyrm. Oft entsteht dabei der Eindruck, man müsse überall einen eigenen Account anlegen.
Doch genau das ist einer der größten Irrtümer.
Im Fediverse sind die verschiedenen Dienste miteinander verbunden. In vielen Fällen genügt bereits ein einziger Account, um Menschen auf anderen Plattformen zu folgen, Beiträge zu lesen und miteinander zu kommunizieren. Zusätzliche Accounts sind nur dann sinnvoll, wenn man die besonderen Funktionen einer bestimmten Anwendung gezielt nutzen möchte.
An diesem Abend möchten wir zeigen, wie dieses Zusammenspiel in der Praxis funktioniert.
Unser Gast Friedhelm@catmanfriedhelm betreibt die Katzen-Webseite gandalfgarfield.de und nutzt das Fediverse , um sein umfangreiches Wissen rund um Katzen zu veröffentlichen und mit anderen zu teilen. Dabei verwendet er unter anderem Friendica, Mastodon, PixelFed, PeerTube und BookWyrm – immer dort, wo die jeweilige Anwendung ihre besonderen Stärken ausspielen kann.
Friedhelm wird anhand seines eigenen Projekts zeigen, 🐾 wie sich eine klassische Webseite und das Fediverse sinnvoll ergänzen, 🐾 welche Vorteile die verschiedenen Anwendungen bieten und 🐾 wie Inhalte im Fediverse eine größere Reichweite erhalten können.
Natürlich bleibt wie immer genügend Zeit für Fragen, Erfahrungen und einen offenen Austausch.
📍 Online per BigBlueButton Den Zugangslink stellen wir wie gewohnt rechtzeitig zur Verfügung.
Egal, ob ihr gerade eure ersten Schritte im Fediverse macht oder bereits erfahrene Nutzerinnen und Nutzer seid – ihr seid herzlich eingeladen!
Wir freuen uns auf einen interessanten Abend mit euch. Bitte gern teilen und weitersagen.
Quadratische Grafik zur Ankündigung einer Fediverse-Sprechstunde. Vor einem sternenreichen Weltraumhintergrund mit der Erde am unteren Bildrand sind verschiedene Anwendungen des Fediverse kreisförmig und gleichberechtigt miteinander verbunden. Zu sehen sind unter anderem Symbole für Mastodon, Friendica, PixelFed, PeerTube, BookWyrm, Hubzilla, Castopod und Loops. In der Mitte steht der Titel „Fediverse-Sprechstunde“. Darunter befinden sich die Veranstaltungsinformationen: Montag, 20.07.2026, 19:30 Uhr, online via BigBlueButton. Am unteren Rand steht der Slogan „Gemeinsam verbunden. Vielfalt nutzen.“ Die Grafik verdeutlicht, dass das Fediverse aus vielen gleichwertigen, miteinander vernetzten Anwendungen besteht.
We're pleased to announce BotKit 0.5.0. This release changes how both the docs site and every bot's own pages look, and it stops limiting a server to one bot: a single process can now host a whole fleet of them. Quoting, and being quoted, goes through a consent step under FEP-044f, and a Redis-backed repository joins the SQLite and PostgreSQL ones for shared production storage. A few of these changes are breaking; see below for what to check before you upgrade.
A new look for botkit.fedify.dev
Until this release, botkit.fedify.dev read like a stock VitePress site: a workable but generic shell wrapped around the docs, with none of BotKit's own personality showing through.
The theme and the landing page are both new. The palette now matches the real logo greens instead of a generic default, and headlines are set in Space Grotesk, paired with Inter for everything else; the display font is self-hosted, so no visitor's IP is handed to a font CDN. The new landing page frames BotKit's dinosaur mascot inside its signature unassembled-model-kit sprue frame, then leads with a tabbed installer for Deno, npm, pnpm, and Yarn and a one-file bot example before getting into what BotKit actually does: messages, events, multi-bot instances, and the pages it builds for a bot without any extra work from you.
The deployment guides grew alongside the new landing page: they were split apart and fleshed out, and a new Cloudflare Workers guide joins the existing Deno Deploy, Docker, and self-hosting guides.
A new look for your bot's pages
The pages BotKit serves for your bot (its profile, its posts, its follower list) got the same attention, in the opposite direction. Until now they were built on Pico CSS pulled from an external CDN: a fine default, but a generic one that made every BotKit-hosted bot look like a demo of the same template, and that quietly sent every visitor's browser off to fetch a stylesheet from someone else's server.
That's gone. Bot pages now use a self-contained design system, bundled with the package and served from BotKit's own content-addressed, cache-forever path: no external CDN, no build step, on either Deno or Node.js. The whole look is driven by a single accent color you choose (twenty names, the same legend Pico CSS uses, so your existing choice of color still works), tinting links, the follow button, and small highlights, while everything else stays quiet so your bot's name, avatar, and posts are what a visitor actually notices. A new PagesOptions.theme option ("auto", "light", or "dark") controls the color scheme independently of the accent. A repost is now marked and attributed to its original author instead of blending into the bot's own timeline.
If you want to go further than the accent color allows, PagesOptions.css still lets you inject custom CSS on top of BotKit's own stylesheet.
Multi-bot instances
Until this release, a BotKit process could only ever be one bot. Running a second bot meant standing up a whole second server, even when the two bots could easily have shared the same infrastructure. That limitation, raised in #16, is gone: the new createInstance() function creates an Instance that owns the shared plumbing (the key–value store, the message queue, the repository, and HTTP handling), and any number of bots can live on it side by side, each with its own actor identity and event handlers.
For a fixed, known set of bots, Instance.createBot() takes an identifier and a profile:
import { createInstance, text } from "@fedify/botkit";import { MemoryKvStore } from "@fedify/fedify";const instance = createInstance<void>({ kv: new MemoryKvStore() });const greetBot = instance.createBot("greet", { username: "greetbot", name: "Greeting Bot",});greetBot.onFollow = async (session, followRequest) => { await followRequest.accept(); await session.publish(text`Welcome, ${followRequest.follower}!`);};
For a family of bots resolved on demand (one per region, one per customer, thousands of them backed by a database), pass a dispatcher function instead of a fixed identifier, and BotKit resolves and federates each one lazily:
Incoming activities are routed only to the bots they actually concern: the followed bot, the owner of a liked or replied-to message, mentioned bots, and bots followed by the sender. Multi-bot instances also serve a list of hosted bots at the web root, with each bot's own pages moving to /@{username}; a reserved instance actor signs shared-inbox requests when there's no single bot whose key obviously should.
None of this touches single-bot deployments: createBot() keeps working exactly as it always has, with the bot's pages staying at the web root and its data migrated to the new storage layout automatically on startup. If you maintain a custom Repository implementation, though, this is a breaking change worth planning for: every method now takes the owning bot's identifier as its first parameter, Session.bot is a read-only ReadonlyBot instead of a mutable Bot, and local object URIs carry the owning bot's identifier (old-format URIs are still recognized and permanently redirected, so links other servers stored keep working). The full picture, including how to move an existing single-bot deployment onto a multi-bot instance later, is in the new Instance concept document.
Thanks to @moreal, whose early work-in-progress explorations of this problem surfaced its two hardest design questions (mapping usernames to identifiers for dynamic bots, and routing object URIs that used to carry no owner information) well before this implementation settled on its final shape.
Consent-respecting quotes with FEP-044f
BotKit has supported quoting since 0.2.0, but only in the Misskey family's style: a quoteUrl property and a Link tag, sent without ever asking the quoted author. Mastodon 4.4 and 4.5 do things differently: they verify quotes through FEP-044f's consent handshake before showing them as quotes at all. Without that handshake, a BotKit bot's quotes never rendered as quotes on Mastodon, and quotes of a BotKit bot showed up as unverifiable.
BotKit now handles the FEP-044f handshake in both directions. When you quote a message, it sets the FEP-044f quote property and sends a QuoteRequest to the quoted author, alongside the Create it already sent. Publishing stays non-blocking: the post goes out immediately, and the quote is upgraded once (or if) approval arrives:
On the receiving side, a new quotePolicy option (on createBot(), and per message on Session.publish()) controls how your bot answers incoming quote requests: automatically for everyone ("public", the default), automatically for followers only, never ("nobody"), or held for manual review through the new Bot.onQuoteRequest event:
Bot.onQuoteAccepted, Bot.onQuoteRejected, and Bot.onQuoteRevoked cover what happens next for quotes your own bot sent, Message.quoteApproved reports whether an incoming quote carries a valid authorization stamp, and AuthorizedMessage.unauthorizeQuote() lets you revoke one you previously granted. The legacy quoteUrl and Misskey-style tags are still sent alongside the new property, so nothing about quoting on Misskey and its relatives changes. The full design is spread across #27 through #33.
A Redis repository (@fedify/botkit-redis)
BotKit has had a SQLite repository since 0.3.0 and a PostgreSQL one since 0.4.0, but neither is the natural fit for a bot that runs as several worker processes sharing one store, which is exactly the shape a Redis-backed deployment usually takes. The new @fedify/botkit-redis package fills that gap with RedisRepository, built directly on Redis strings, sets, and sorted sets rather than going through a generic key–value abstraction:
import { createBot, MemoryKvStore } from "@fedify/botkit";import { RedisRepository } from "@fedify/botkit-redis";const bot = createBot({ username: "mybot", kv: new MemoryKvStore(), repository: new RedisRepository({ url: "redis://localhost:6379/0" }),});
Because several workers can share one Redis instance, the read-modify-write paths that matter most under concurrency (message updates, follower bookkeeping, quote authorization indexes) are protected by short-lived locks that get renewed while a slow update is still running, rather than by assuming only one process ever touches the data at a time. The package supports both a connection URL it manages itself and an existing node-redis client you inject and keep control of, and it's available for both Deno and Node.js. #12 and #35 cover the rest of it.
Smaller improvements
The npm package's TypeScript declaration files no longer accidentally include the runtime Temporal polyfill code, which had been leaking into consumers' .d.ts output. Fedify was upgraded to 2.3.1, Hono to 4.12.27, and LogTape to 2.2.3.
As always, the full list of changes is in CHANGES.md, and every API mentioned above is documented at botkit.fedify.dev. Thank you to everyone who filed issues, opened discussions, and tried BotKit out.
If you build something with BotKit, run into a rough edge, or just want to talk through an idea before opening an issue, GitHub Discussions is the place for exactly that. For something closer to real time, BotKit's chat now lives on Matrix at #fedify:matrix.org. Drop in and say hello.
We're pleased to announce BotKit 0.5.0. This release changes how both the docs site and every bot's own pages look, and it stops limiting a server to one bot: a single process can now host a whole fleet of them. Quoting, and being quoted, goes through a consent step under FEP-044f, and a Redis-backed repository joins the SQLite and PostgreSQL ones for shared production storage. A few of these changes are breaking; see below for what to check before you upgrade.
A new look for botkit.fedify.dev
Until this release, botkit.fedify.dev read like a stock VitePress site: a workable but generic shell wrapped around the docs, with none of BotKit's own personality showing through.
The theme and the landing page are both new. The palette now matches the real logo greens instead of a generic default, and headlines are set in Space Grotesk, paired with Inter for everything else; the display font is self-hosted, so no visitor's IP is handed to a font CDN. The new landing page frames BotKit's dinosaur mascot inside its signature unassembled-model-kit sprue frame, then leads with a tabbed installer for Deno, npm, pnpm, and Yarn and a one-file bot example before getting into what BotKit actually does: messages, events, multi-bot instances, and the pages it builds for a bot without any extra work from you.
The deployment guides grew alongside the new landing page: they were split apart and fleshed out, and a new Cloudflare Workers guide joins the existing Deno Deploy, Docker, and self-hosting guides.
A new look for your bot's pages
The pages BotKit serves for your bot (its profile, its posts, its follower list) got the same attention, in the opposite direction. Until now they were built on Pico CSS pulled from an external CDN: a fine default, but a generic one that made every BotKit-hosted bot look like a demo of the same template, and that quietly sent every visitor's browser off to fetch a stylesheet from someone else's server.
That's gone. Bot pages now use a self-contained design system, bundled with the package and served from BotKit's own content-addressed, cache-forever path: no external CDN, no build step, on either Deno or Node.js. The whole look is driven by a single accent color you choose (twenty names, the same legend Pico CSS uses, so your existing choice of color still works), tinting links, the follow button, and small highlights, while everything else stays quiet so your bot's name, avatar, and posts are what a visitor actually notices. A new PagesOptions.theme option ("auto", "light", or "dark") controls the color scheme independently of the accent. A repost is now marked and attributed to its original author instead of blending into the bot's own timeline.
If you want to go further than the accent color allows, PagesOptions.css still lets you inject custom CSS on top of BotKit's own stylesheet.
Multi-bot instances
Until this release, a BotKit process could only ever be one bot. Running a second bot meant standing up a whole second server, even when the two bots could easily have shared the same infrastructure. That limitation, raised in #16, is gone: the new createInstance() function creates an Instance that owns the shared plumbing (the key–value store, the message queue, the repository, and HTTP handling), and any number of bots can live on it side by side, each with its own actor identity and event handlers.
For a fixed, known set of bots, Instance.createBot() takes an identifier and a profile:
import { createInstance, text } from "@fedify/botkit";import { MemoryKvStore } from "@fedify/fedify";const instance = createInstance<void>({ kv: new MemoryKvStore() });const greetBot = instance.createBot("greet", { username: "greetbot", name: "Greeting Bot",});greetBot.onFollow = async (session, followRequest) => { await followRequest.accept(); await session.publish(text`Welcome, ${followRequest.follower}!`);};
For a family of bots resolved on demand (one per region, one per customer, thousands of them backed by a database), pass a dispatcher function instead of a fixed identifier, and BotKit resolves and federates each one lazily:
Incoming activities are routed only to the bots they actually concern: the followed bot, the owner of a liked or replied-to message, mentioned bots, and bots followed by the sender. Multi-bot instances also serve a list of hosted bots at the web root, with each bot's own pages moving to /@{username}; a reserved instance actor signs shared-inbox requests when there's no single bot whose key obviously should.
None of this touches single-bot deployments: createBot() keeps working exactly as it always has, with the bot's pages staying at the web root and its data migrated to the new storage layout automatically on startup. If you maintain a custom Repository implementation, though, this is a breaking change worth planning for: every method now takes the owning bot's identifier as its first parameter, Session.bot is a read-only ReadonlyBot instead of a mutable Bot, and local object URIs carry the owning bot's identifier (old-format URIs are still recognized and permanently redirected, so links other servers stored keep working). The full picture, including how to move an existing single-bot deployment onto a multi-bot instance later, is in the new Instance concept document.
Thanks to @moreal, whose early work-in-progress explorations of this problem surfaced its two hardest design questions (mapping usernames to identifiers for dynamic bots, and routing object URIs that used to carry no owner information) well before this implementation settled on its final shape.
Consent-respecting quotes with FEP-044f
BotKit has supported quoting since 0.2.0, but only in the Misskey family's style: a quoteUrl property and a Link tag, sent without ever asking the quoted author. Mastodon 4.4 and 4.5 do things differently: they verify quotes through FEP-044f's consent handshake before showing them as quotes at all. Without that handshake, a BotKit bot's quotes never rendered as quotes on Mastodon, and quotes of a BotKit bot showed up as unverifiable.
BotKit now handles the FEP-044f handshake in both directions. When you quote a message, it sets the FEP-044f quote property and sends a QuoteRequest to the quoted author, alongside the Create it already sent. Publishing stays non-blocking: the post goes out immediately, and the quote is upgraded once (or if) approval arrives:
On the receiving side, a new quotePolicy option (on createBot(), and per message on Session.publish()) controls how your bot answers incoming quote requests: automatically for everyone ("public", the default), automatically for followers only, never ("nobody"), or held for manual review through the new Bot.onQuoteRequest event:
Bot.onQuoteAccepted, Bot.onQuoteRejected, and Bot.onQuoteRevoked cover what happens next for quotes your own bot sent, Message.quoteApproved reports whether an incoming quote carries a valid authorization stamp, and AuthorizedMessage.unauthorizeQuote() lets you revoke one you previously granted. The legacy quoteUrl and Misskey-style tags are still sent alongside the new property, so nothing about quoting on Misskey and its relatives changes. The full design is spread across #27 through #33.
A Redis repository (@fedify/botkit-redis)
BotKit has had a SQLite repository since 0.3.0 and a PostgreSQL one since 0.4.0, but neither is the natural fit for a bot that runs as several worker processes sharing one store, which is exactly the shape a Redis-backed deployment usually takes. The new @fedify/botkit-redis package fills that gap with RedisRepository, built directly on Redis strings, sets, and sorted sets rather than going through a generic key–value abstraction:
import { createBot, MemoryKvStore } from "@fedify/botkit";import { RedisRepository } from "@fedify/botkit-redis";const bot = createBot({ username: "mybot", kv: new MemoryKvStore(), repository: new RedisRepository({ url: "redis://localhost:6379/0" }),});
Because several workers can share one Redis instance, the read-modify-write paths that matter most under concurrency (message updates, follower bookkeeping, quote authorization indexes) are protected by short-lived locks that get renewed while a slow update is still running, rather than by assuming only one process ever touches the data at a time. The package supports both a connection URL it manages itself and an existing node-redis client you inject and keep control of, and it's available for both Deno and Node.js. #12 and #35 cover the rest of it.
Smaller improvements
The npm package's TypeScript declaration files no longer accidentally include the runtime Temporal polyfill code, which had been leaking into consumers' .d.ts output. Fedify was upgraded to 2.3.1, Hono to 4.12.27, and LogTape to 2.2.3.
As always, the full list of changes is in CHANGES.md, and every API mentioned above is documented at botkit.fedify.dev. Thank you to everyone who filed issues, opened discussions, and tried BotKit out.
If you build something with BotKit, run into a rough edge, or just want to talk through an idea before opening an issue, GitHub Discussions is the place for exactly that. For something closer to real time, BotKit's chat now lives on Matrix at #fedify:matrix.org. Drop in and say hello.
🌐 Fediverse – wie sich alles zusammen nutzen lässt
Das Fediverse besteht aus vielen verschiedenen Anwendungen wie Friendica, Mastodon, PixelFed, PeerTube oder BookWyrm. Oft entsteht dabei der Eindruck, man müsse überall einen eigenen Account anlegen.
Doch genau das ist einer der größten Irrtümer.
Im Fediverse sind die verschiedenen Dienste miteinander verbunden. In vielen Fällen genügt bereits ein einziger Account, um Menschen auf anderen Plattformen zu folgen, Beiträge zu lesen und miteinander zu kommunizieren. Zusätzliche Accounts sind nur dann sinnvoll, wenn man die besonderen Funktionen einer bestimmten Anwendung gezielt nutzen möchte.
An diesem Abend möchten wir zeigen, wie dieses Zusammenspiel in der Praxis funktioniert.
Unser Gast Friedhelm@catmanfriedhelm betreibt die Katzen-Webseite gandalfgarfield.de und nutzt das Fediverse , um sein umfangreiches Wissen rund um Katzen zu veröffentlichen und mit anderen zu teilen. Dabei verwendet er unter anderem Friendica, Mastodon, PixelFed, PeerTube und BookWyrm – immer dort, wo die jeweilige Anwendung ihre besonderen Stärken ausspielen kann.
Friedhelm wird anhand seines eigenen Projekts zeigen, 🐾 wie sich eine klassische Webseite und das Fediverse sinnvoll ergänzen, 🐾 welche Vorteile die verschiedenen Anwendungen bieten und 🐾 wie Inhalte im Fediverse eine größere Reichweite erhalten können.
Natürlich bleibt wie immer genügend Zeit für Fragen, Erfahrungen und einen offenen Austausch.
📍 Online per BigBlueButton Den Zugangslink stellen wir wie gewohnt rechtzeitig zur Verfügung.
Egal, ob ihr gerade eure ersten Schritte im Fediverse macht oder bereits erfahrene Nutzerinnen und Nutzer seid – ihr seid herzlich eingeladen!
Wir freuen uns auf einen interessanten Abend mit euch. Bitte gern teilen und weitersagen.
Quadratische Grafik zur Ankündigung einer Fediverse-Sprechstunde. Vor einem sternenreichen Weltraumhintergrund mit der Erde am unteren Bildrand sind verschiedene Anwendungen des Fediverse kreisförmig und gleichberechtigt miteinander verbunden. Zu sehen sind unter anderem Symbole für Mastodon, Friendica, PixelFed, PeerTube, BookWyrm, Hubzilla, Castopod und Loops. In der Mitte steht der Titel „Fediverse-Sprechstunde“. Darunter befinden sich die Veranstaltungsinformationen: Montag, 20.07.2026, 19:30 Uhr, online via BigBlueButton. Am unteren Rand steht der Slogan „Gemeinsam verbunden. Vielfalt nutzen.“ Die Grafik verdeutlicht, dass das Fediverse aus vielen gleichwertigen, miteinander vernetzten Anwendungen besteht.
All my followers who want to be found by more people, edit your bio and include some hashtags you want to be known for[*], and also the hashtag #fedi22.
All my followers who want to be found by more people, edit your bio and include some hashtags you want to be known for[*], and also the hashtag #fedi22.
Unrefined #Fediverse / #Mastodon idea: have a platform (with at least one instance managed by a trustable structure) to host all accounts from recently shut-down servers. Read only, likely no posts, just backups of profile data.
1. Enable users (authentified with their email?) to download their following/followers/etc data even after their server closed.
Unrefined #Fediverse / #Mastodon idea: have a platform (with at least one instance managed by a trustable structure) to host all accounts from recently shut-down servers. Read only, likely no posts, just backups of profile data.
1. Enable users (authentified with their email?) to download their following/followers/etc data even after their server closed.
Unrefined #Fediverse / #Mastodon idea: have a platform (with at least one instance managed by a trustable structure) to host all accounts from recently shut-down servers. Read only, likely no posts, just backups of profile data.
1. Enable users (authentified with their email?) to download their following/followers/etc data even after their server closed.
It can be hard to understand how hashtags spread around the #fediverse, so I built a little tool to help you explore how visible hashtags are on different servers. The page also contains tips for how you can follow hashtags more effectively and help your own tagged posts get spread more broadly.
All these people posting photos of libraries and saying "these are the only data centres I want funded"...
...yeah, you're using Mastodon. I'm going to take a wild guess that 99% of instances are running on a VPS in a datacentre. Even if you have a personal instance on a RaspberryPi in your bedroom closet (yay, go you I guess), it's going to be federating across literally thousands of datacentres in order for your little library memes to find an audience.
All these people posting photos of libraries and saying "these are the only data centres I want funded"...
...yeah, you're using Mastodon. I'm going to take a wild guess that 99% of instances are running on a VPS in a datacentre. Even if you have a personal instance on a RaspberryPi in your bedroom closet (yay, go you I guess), it's going to be federating across literally thousands of datacentres in order for your little library memes to find an audience.
Curious what kind of luck people have had running a single-user, self-hosted @gotosocial instance instead of joining a larger shared node.
With relays in GotoSocial, my feed is great—I can discover pretty much everything I care about. My bigger question is the *other* direction. I've heard some instances de-prioritize or outright limit federation from low-volume, self-hosted, or otherwise unknown nodes.
If you're mostly consuming content, I imagine it's a non-issue. But if you actually want to participate in conversations, are you giving up reliable interaction by running your own tiny instance?
It can be hard to understand how hashtags spread around the #fediverse, so I built a little tool to help you explore how visible hashtags are on different servers. The page also contains tips for how you can follow hashtags more effectively and help your own tagged posts get spread more broadly.
If you're heading to @dweb Camp this week, it shouldn't be hard to find @michael just follow the neon glow 🙌
If that isn't enough, put on your brightest clothes and head over to his talk on Thursday at 12pm CET - "Black Holes & Day-Glo Symphonies: Onboarding Communities to the Social Web" 🕺
The entire Newsmast team will be wishing we were there to take part, it's going to be a good one!!
A graphic showing a man wearing glasses, Michael Foster, in a cut out neon style frame on a background of neon stars.
Around the image, words read: D Web Camp. BLN. Newsmast Foundation. Michael Foster. 2026-08-09 12:00-12:30 CET. Black Holes & Day-Glo Symphonies: Onboarding Communities to the Social Web.
If you're heading to @dweb Camp this week, it shouldn't be hard to find @michael just follow the neon glow 🙌
If that isn't enough, put on your brightest clothes and head over to his talk on Thursday at 12pm CET - "Black Holes & Day-Glo Symphonies: Onboarding Communities to the Social Web" 🕺
The entire Newsmast team will be wishing we were there to take part, it's going to be a good one!!
A graphic showing a man wearing glasses, Michael Foster, in a cut out neon style frame on a background of neon stars.
Around the image, words read: D Web Camp. BLN. Newsmast Foundation. Michael Foster. 2026-08-09 12:00-12:30 CET. Black Holes & Day-Glo Symphonies: Onboarding Communities to the Social Web.
Was ich vom Netzwerk vutuv.de halten soll und ob ich mich weiter damit beschäftigen werde, weiß ich noch nicht. Vor 9 Jahren habe ich mir dort wohl mal einen Account angelegt und kürzlich kam eine E-Mail, dass man nun wieder aktiv am Netzwerk arbeite. Ok.
Womit ich nicht gerechnet hatte: Unter den Einstellungen findet sich ein Abschnitt „Fediverse“, in dem sich eine Verbindung hierher aktivieren lässt:
„Mastodon und viele weitere Dienste bilden ein großes, offenes Netzwerk: das Fediverse. Wenn Sie teilnehmen, können Ihnen Menschen von dort folgen, und Ihre öffentlichen vutuv-Beiträge erscheinen in deren Timelines, ganz ohne vutuv-Konto.“
It’s not Tuesday yet, but it will be soon. And I want to thank @grunfink for creating and maintaining snac. Tomorrow I’ll talk about FediMeteo at DevConf, and it would never have come to be if it weren’t for snac and for the help the author gave me in fixing some things to optimize its use.
True Open Source, made with passion, by people who do things for the love of the things themselves.
It’s not Tuesday yet, but it will be soon. And I want to thank @grunfink for creating and maintaining snac. Tomorrow I’ll talk about FediMeteo at DevConf, and it would never have come to be if it weren’t for snac and for the help the author gave me in fixing some things to optimize its use.
True Open Source, made with passion, by people who do things for the love of the things themselves.
This week, we cover the writing layer of the fediverse: Ghost, WriteFreely, Micro.blog, Plume, WordPress, and Flipboard. Text was ActivityPub's first real workload, but these platforms didn't all arrive at federation the same way.
Ghost: a UK non-profit that funds Fedify (by @hongminhee) the framework its federation is built on. it's a publisher and a fediverse client at once, with an inbox as well as an outbox. Our newsletter is also powered by it, so @index is followable from any Mastodon app right now.
WriteFreely: one primary maintainer, Matt Baer (@matt), roughly 1,400 of 1,900+ commits, going since 2015. Funded by his own hosted product, Write.as.
Micro.blog: a Kickstarter By Manton Reese (@manton) that funded the platform before it had a single user. POSSE, native ActivityPub, and native Bluesky, no bridge.
Plume: a simple platform that also supported collaborative multi-author blogs. But no longer actively developed - it recommends WriteFreely and WordPress instead of itself.
WordPress: built-in ActivityPub (using plugin by Matthias Pfefferle - @pfefferle) plus a native AT Protocol plugin and real moderation tooling.
Flipboard: curating other people's writing rather than hosting its own.
An antique quill and inkwell against a vibrant multicolor cosmic backdrop, with constellation lines connecting points of light across a deep starfield. Magenta, cyan, violet, and amber tones.
Mapped the writing layer of the fediverse: Ghost, WriteFreely, Micro.blog, Plume, WordPress, and Flipboard.
Text was ActivityPub's first real workload, but these platforms didn't all arrive at federation the same way. Some built it in, some bolted it on while others bridged it through.
Part 3 of the mini-series: Fediverse Beyond Mastodon.
An antique book, quill and inkwell against a vibrant multicolor cosmic backdrop, with constellation lines connecting points of light across a deep starfield. Magenta, cyan, violet, and amber tones.
Ein grünes Sharepic mit vielen Stickern vom Logo des CastopodhServer podcasts.homes, einer Schnecke mit Häuschen. Darüber ist zu lesen: Castopod, was kann die Podcastplattform im Jahr 2026? Ein Talk von Stephanie Henkel aka Ückück auf dem Fediday 2026
What's the scene with #activitypub / #fediverse development? Why do I keep hearing that developing software for fedi or ap is a major pain in the butt?
WOW decentralized and ENCRYPTED social media over #chatmail this is such an epic prototype!
the fun part is that by using chatmail:
- DMs are already end-to-end encrypted - your identity is your encryption key and doesn't depend on a single home server - your profile is basically uncensorable
since you need to give people your invite link it is kind of like private social network
This week, we cover the writing layer of the fediverse: Ghost, WriteFreely, Micro.blog, Plume, WordPress, and Flipboard. Text was ActivityPub's first real workload, but these platforms didn't all arrive at federation the same way.
Ghost: a UK non-profit that funds Fedify (by @hongminhee) the framework its federation is built on. it's a publisher and a fediverse client at once, with an inbox as well as an outbox. Our newsletter is also powered by it, so @index is followable from any Mastodon app right now.
WriteFreely: one primary maintainer, Matt Baer (@matt), roughly 1,400 of 1,900+ commits, going since 2015. Funded by his own hosted product, Write.as.
Micro.blog: a Kickstarter By Manton Reese (@manton) that funded the platform before it had a single user. POSSE, native ActivityPub, and native Bluesky, no bridge.
Plume: a simple platform that also supported collaborative multi-author blogs. But no longer actively developed - it recommends WriteFreely and WordPress instead of itself.
WordPress: built-in ActivityPub (using plugin by Matthias Pfefferle - @pfefferle) plus a native AT Protocol plugin and real moderation tooling.
Flipboard: curating other people's writing rather than hosting its own.
An antique quill and inkwell against a vibrant multicolor cosmic backdrop, with constellation lines connecting points of light across a deep starfield. Magenta, cyan, violet, and amber tones.
Mapped the writing layer of the fediverse: Ghost, WriteFreely, Micro.blog, Plume, WordPress, and Flipboard.
Text was ActivityPub's first real workload, but these platforms didn't all arrive at federation the same way. Some built it in, some bolted it on while others bridged it through.
Part 3 of the mini-series: Fediverse Beyond Mastodon.
An antique book, quill and inkwell against a vibrant multicolor cosmic backdrop, with constellation lines connecting points of light across a deep starfield. Magenta, cyan, violet, and amber tones.
This week, we cover the writing layer of the fediverse: Ghost, WriteFreely, Micro.blog, Plume, WordPress, and Flipboard. Text was ActivityPub's first real workload, but these platforms didn't all arrive at federation the same way.
Ghost: a UK non-profit that funds Fedify (by @hongminhee) the framework its federation is built on. it's a publisher and a fediverse client at once, with an inbox as well as an outbox. Our newsletter is also powered by it, so @index is followable from any Mastodon app right now.
WriteFreely: one primary maintainer, Matt Baer (@matt), roughly 1,400 of 1,900+ commits, going since 2015. Funded by his own hosted product, Write.as.
Micro.blog: a Kickstarter By Manton Reese (@manton) that funded the platform before it had a single user. POSSE, native ActivityPub, and native Bluesky, no bridge.
Plume: a simple platform that also supported collaborative multi-author blogs. But no longer actively developed - it recommends WriteFreely and WordPress instead of itself.
WordPress: built-in ActivityPub (using plugin by Matthias Pfefferle - @pfefferle) plus a native AT Protocol plugin and real moderation tooling.
Flipboard: curating other people's writing rather than hosting its own.
An antique quill and inkwell against a vibrant multicolor cosmic backdrop, with constellation lines connecting points of light across a deep starfield. Magenta, cyan, violet, and amber tones.
This week, we cover the writing layer of the fediverse: Ghost, WriteFreely, Micro.blog, Plume, WordPress, and Flipboard. Text was ActivityPub's first real workload, but these platforms didn't all arrive at federation the same way.
Ghost: a UK non-profit that funds Fedify (by @hongminhee) the framework its federation is built on. it's a publisher and a fediverse client at once, with an inbox as well as an outbox. Our newsletter is also powered by it, so @index is followable from any Mastodon app right now.
WriteFreely: one primary maintainer, Matt Baer (@matt), roughly 1,400 of 1,900+ commits, going since 2015. Funded by his own hosted product, Write.as.
Micro.blog: a Kickstarter By Manton Reese (@manton) that funded the platform before it had a single user. POSSE, native ActivityPub, and native Bluesky, no bridge.
Plume: a simple platform that also supported collaborative multi-author blogs. But no longer actively developed - it recommends WriteFreely and WordPress instead of itself.
WordPress: built-in ActivityPub (using plugin by Matthias Pfefferle - @pfefferle) plus a native AT Protocol plugin and real moderation tooling.
Flipboard: curating other people's writing rather than hosting its own.
An antique quill and inkwell against a vibrant multicolor cosmic backdrop, with constellation lines connecting points of light across a deep starfield. Magenta, cyan, violet, and amber tones.
WOW decentralized and ENCRYPTED social media over #chatmail this is such an epic prototype!
the fun part is that by using chatmail:
- DMs are already end-to-end encrypted - your identity is your encryption key and doesn't depend on a single home server - your profile is basically uncensorable
since you need to give people your invite link it is kind of like private social network
It’s not Tuesday yet, but it will be soon. And I want to thank @grunfink for creating and maintaining snac. Tomorrow I’ll talk about FediMeteo at DevConf, and it would never have come to be if it weren’t for snac and for the help the author gave me in fixing some things to optimize its use.
True Open Source, made with passion, by people who do things for the love of the things themselves.
Whenever people may ask me where I usually hang out nowadays, away from traditional #SocialMedia, i.e. the #Fediverse, I'm going to point them to this fine piece of work by @dansup and entice them to dive in & join us!
I just discovered the Fediverse (English) Wikipedia page has a huge section on AT Protocol and I question why. It seems like excessive promotion of Bluesky and its protocol that is not compatible with ActivityPub, both technically and in spirit. Illustrating bridging isn't the same as compatibility. Might as well add sections for other random network protocols like XMPP (Jabber).
I just discovered the Fediverse (English) Wikipedia page has a huge section on AT Protocol and I question why. It seems like excessive promotion of Bluesky and its protocol that is not compatible with ActivityPub, both technically and in spirit. Illustrating bridging isn't the same as compatibility. Might as well add sections for other random network protocols like XMPP (Jabber).
I just discovered the Fediverse (English) Wikipedia page has a huge section on AT Protocol and I question why. It seems like excessive promotion of Bluesky and its protocol that is not compatible with ActivityPub, both technically and in spirit. Illustrating bridging isn't the same as compatibility. Might as well add sections for other random network protocols like XMPP (Jabber).
This week, we cover the writing layer of the fediverse: Ghost, WriteFreely, Micro.blog, Plume, WordPress, and Flipboard. Text was ActivityPub's first real workload, but these platforms didn't all arrive at federation the same way.
Ghost: a UK non-profit that funds Fedify (by @hongminhee) the framework its federation is built on. it's a publisher and a fediverse client at once, with an inbox as well as an outbox. Our newsletter is also powered by it, so @index is followable from any Mastodon app right now.
WriteFreely: one primary maintainer, Matt Baer (@matt), roughly 1,400 of 1,900+ commits, going since 2015. Funded by his own hosted product, Write.as.
Micro.blog: a Kickstarter By Manton Reese (@manton) that funded the platform before it had a single user. POSSE, native ActivityPub, and native Bluesky, no bridge.
Plume: a simple platform that also supported collaborative multi-author blogs. But no longer actively developed - it recommends WriteFreely and WordPress instead of itself.
WordPress: built-in ActivityPub (using plugin by Matthias Pfefferle - @pfefferle) plus a native AT Protocol plugin and real moderation tooling.
Flipboard: curating other people's writing rather than hosting its own.
An antique quill and inkwell against a vibrant multicolor cosmic backdrop, with constellation lines connecting points of light across a deep starfield. Magenta, cyan, violet, and amber tones.
I just discovered the Fediverse (English) Wikipedia page has a huge section on AT Protocol and I question why. It seems like excessive promotion of Bluesky and its protocol that is not compatible with ActivityPub, both technically and in spirit. Illustrating bridging isn't the same as compatibility. Might as well add sections for other random network protocols like XMPP (Jabber).
Whenever people may ask me where I usually hang out nowadays, away from traditional #SocialMedia, i.e. the #Fediverse, I'm going to point them to this fine piece of work by @dansup and entice them to dive in & join us!
Special Guest: @troler@mastodon.online
Fully functional human written in Common Lisp. THERE IS NO WARRANTY FOR ME, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
So don't miss it!
It will happen on 08/07/26 at 11:00 US Eastern Time ( UTC-4 )
Special Guest: @troler@mastodon.online
Fully functional human written in Common Lisp. THERE IS NO WARRANTY FOR ME, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
So don't miss it!
It will happen on 08/07/26 at 11:00 US Eastern Time ( UTC-4 )
I promised it, so here it is. This is a recording of littleFedi running on a Raspberry Pi Zero W on NetBSD.
Everything is on the SD card, the database is SQLite, and caching is enabled.
Personally, I won't comment on responsiveness or anything else; I'll just say that when I use it (both via the web interface and with apps like MastoBlaster or IceCubes), I find it hard to believe what kind of hardware it's running on.
Users' sessions (by default, a maximum of 8 users but configurable) are kept "warm" with every interaction or federated activity for 15 minutes since the last login; after that, the server enters "low power mode" and simply processes incoming data without activating the (users' timelines, etc.) cache.
We don't need to get ripped off for more powerful hardware, which comes with outrageous costs these days.
We just need to optimize and build efficient software.
If I compare #ActivityPub#fediverse of today with that of a couple of years ago (as my acount perceives it), these are some of my observations:
- Being on a well-moderated instance I see a quieter, calmer fediverse.
- Less drama, performative activism, and purity spiral anti-patterns reach my timeline.
- People are genuine in their posts, yet doom & gloom dominate the feed.
- There are less posts than there used to be.
- In terms of interactions / engagement fediverse feels like a ghost town.
- But there are plenty nice discussions to participate in.
- People boost less, yet that is how we can grow and foster healthy culture at the same time.
- Posts with high engagement depend on weird virality dynamics, or relate to recognized influencers.
- In that sense this microblog space isn't much different than other platforms.
My #SocialExperience on this account is shaped by my history of years-long fedi / AP / FOSS advocacy, that made me choose whom to follow and who followed me.
I promised it, so here it is. This is a recording of littleFedi running on a Raspberry Pi Zero W on NetBSD.
Everything is on the SD card, the database is SQLite, and caching is enabled.
Personally, I won't comment on responsiveness or anything else; I'll just say that when I use it (both via the web interface and with apps like MastoBlaster or IceCubes), I find it hard to believe what kind of hardware it's running on.
Users' sessions (by default, a maximum of 8 users but configurable) are kept "warm" with every interaction or federated activity for 15 minutes since the last login; after that, the server enters "low power mode" and simply processes incoming data without activating the (users' timelines, etc.) cache.
We don't need to get ripped off for more powerful hardware, which comes with outrageous costs these days.
We just need to optimize and build efficient software.
Yo #fediverse gimme new books to read. I love hard sci-fi. Basically everything by Daniel Suarez, Andy Weir (though I get why Artemis is not a movie yet...), the Bobiverse, the game is life series, ... Or great stories about real life like "masters of Doom" or "the everything blueprint".
I wrote a short article describing the architecture of #Vernissage and the role of each service behind the platform. Maybe it will be useful for other developers interested in #Vernissage architecture. 😊
I wrote a short article describing the architecture of #Vernissage and the role of each service behind the platform. Maybe it will be useful for other developers interested in #Vernissage architecture. 😊
What i still find utterly baffling is the involvement of top EU politicians right from the start. When WSocial was announced at Davos, only a few presentation slides and probably a "Coming soon" website were available. But instead of waiting for the company to establish at least *some* kind of track record, these politicians jumped right on board. Why? Based on what exactly?
No matter how I try to make sense of this, I fail. Every time.
And the numbers you posted are devastating. No matter what we on the #fediverse think about this project, if it truly fails, the embarrassment will be epic. Not just for the politicians involved, but it also sends such a terrible signal to the rest of the world: "Europe can't do technology".
i'm sure inline json-ld contexts with server extensions seem like the wrong thing, but they're preferable to identical copies of the same context hosted externally and served by a dozen or more instances of a server or family of servers.
i could be persuaded to change my mind if a server allowed meaningful customization. but if a server is publishing a canonical vocabulary of extensions for that server, it should be hosted in a single, well-know location.
i'm sure inline json-ld contexts with server extensions seem like the wrong thing, but they're preferable to identical copies of the same context hosted externally and served by a dozen or more instances of a server or family of servers.
i could be persuaded to change my mind if a server allowed meaningful customization. but if a server is publishing a canonical vocabulary of extensions for that server, it should be hosted in a single, well-know location.
Langsam passt der Name nicht mehr ganz, aber die Mastodon Listen haben eine Reihe neuer Listen, und zwar für Peertube. \o/ Danke an @neuSoM für den Hinweis und @reclus für das Einpflegen der ersten Einträge in Wikidata.
Laut Wikidata gibt es noch gar keine Einträge für Kanäle von öffentlichen Einrichtungen in Österreich und der Schweiz?
Wie immer gilt, schaut euch gerne die Listen an und folgt den Accounts (das könnt ihr auch von z.B. Mastodon) und wenn ihr noch mehr kennt, tragt das gerne in Wikidata ein oder schreibt hier einmal kurz.
ForkMesh was registered 06/14 — just 3 weeks ago — and we’re already building in public: local-first distributed Git hosting, community mirrors, signed issues/patch PRs, encrypted repo rooms, and resilience beyond any single platform.
We think we’ve found our home on Mastodon. Thanks for helping shape it 💜
Hopefully when it comes to the EU the new strategy of @EUCommission around Digital Autonomy that has a big #FOSS component to it, will make our commons more sustainable.
The #ActivityPub conference held in 2020 was made possible indirectly with their long-term support for the #fediverse via the @NGIZero funding programs. And also the later held 3-day workshop "ActivityPub for Administrations" that was graciously facillitated by Joost of @nlnet is hosted on a #Peertube instance facilitated by Petites Singularités.
Hopefully when it comes to the EU the new strategy of @EUCommission around Digital Autonomy that has a big #FOSS component to it, will make our commons more sustainable.
The #ActivityPub conference held in 2020 was made possible indirectly with their long-term support for the #fediverse via the @NGIZero funding programs. And also the later held 3-day workshop "ActivityPub for Administrations" that was graciously facillitated by Joost of @nlnet is hosted on a #Peertube instance facilitated by Petites Singularités.
ForkMesh was registered 06/14 — just 3 weeks ago — and we’re already building in public: local-first distributed Git hosting, community mirrors, signed issues/patch PRs, encrypted repo rooms, and resilience beyond any single platform.
We think we’ve found our home on Mastodon. Thanks for helping shape it 💜
A tortoiseshell cat with black and orange fur lounging on a dark desk next to a computer mouse. The cat has white mittens on its front paws and a tiny white spot on its nose. It's lying in a relaxed sprawled position with sleepy, half-closed eyes, looking downward. Office items like papers and a red coaster are visible nearby.
A tortoiseshell cat with black and orange fur lounging on a dark desk next to a computer mouse. The cat has white mittens on its front paws and a tiny white spot on its nose. It's lying in a relaxed sprawled position with sleepy, half-closed eyes, looking downward. Office items like papers and a red coaster are visible nearby.
Federated portfolio builder for photographers, illustrators and any sort of creatives. Something like #behance but federated and with custom themes. Would you use it?
I'm doing some experiments with different self hosted software, creating accounts for the Fediverse/ActivityPub, like the Wordpress Plugin, Writefreely, GoToSocial and the like. Is there a way to properly delete those accounts when I don't need them anymore? I don't want to leave them orphaned.
I'm doing some experiments with different self hosted software, creating accounts for the Fediverse/ActivityPub, like the Wordpress Plugin, Writefreely, GoToSocial and the like. Is there a way to properly delete those accounts when I don't need them anymore? I don't want to leave them orphaned.
It can be hard to understand how hashtags spread around the #fediverse, so I built a little tool to help you explore how visible hashtags are on different servers. The page also contains tips for how you can follow hashtags more effectively and help your own tagged posts get spread more broadly.
It can be hard to understand how hashtags spread around the #fediverse, so I built a little tool to help you explore how visible hashtags are on different servers. The page also contains tips for how you can follow hashtags more effectively and help your own tagged posts get spread more broadly.
To be included in the People Directory, you will need to add the #fedi22 hashtag to your bio.
To add a Starter Kit or Collection, it needs to have `discoverable` === true.
We do not crawl or store personal data like statuses/followers/following, and will make it easy for admins to block access as we use a constant user agent and will check robots.txt
It can be hard to understand how hashtags spread around the #fediverse, so I built a little tool to help you explore how visible hashtags are on different servers. The page also contains tips for how you can follow hashtags more effectively and help your own tagged posts get spread more broadly.
It can be hard to understand how hashtags spread around the #fediverse, so I built a little tool to help you explore how visible hashtags are on different servers. The page also contains tips for how you can follow hashtags more effectively and help your own tagged posts get spread more broadly.
It can be hard to understand how hashtags spread around the #fediverse, so I built a little tool to help you explore how visible hashtags are on different servers. The page also contains tips for how you can follow hashtags more effectively and help your own tagged posts get spread more broadly.
It can be hard to understand how hashtags spread around the #fediverse, so I built a little tool to help you explore how visible hashtags are on different servers. The page also contains tips for how you can follow hashtags more effectively and help your own tagged posts get spread more broadly.
As we discussed before I use different definitions, which I think fit better in how they shape our thinking around designing use cases in support of our social #communication online.
So, once more, I consider..
Social Networking is any direct or indirect human interaction between people.
That includes offline, where we social network for ages. And recently online since the rise of the #internet. We want #offline and #online to extend seamlessly into each other in support of our daily needs.
The crux is, we are still very primitive in learning how to do online social communication well enough. Lots to learn. We underestimate #social online.
#SocialMedia is a subset of #SocialNetworking against this definition. Moreover its an app-centric notion, same as #Microblogging is. And it shows: #fediverse duplicated existing centralized platforms' app functionality.
We want to focus on our modes of communication across different social contexts, and ability to express ourselves.
One caveat I might have, and this is not an issue with the article, of course, and I generally agree that "the fediverse needs more apps", but!
This is where the Atmosphere has a big advantage.
Yes, some of us might prefer to have separate accounts on different servers and platforms, and keep individual hobbies, interests, and other layers of our personality separate. I think that's fine.
But some of us might prefer to manage one account, and until nomadic identity is widely supported across the fediverse, having more apps to sign up for might not entice everyone.
@sabrinkmann Gute Nachrichten. Es geht langsam aber stetig voran. Mehr Hochschulen und Institutionen im Fediverse, Listen werden wichtiger. Danke für deine Recherchen, und dass damit Zahlen verfügbar werden, um die Lage überhaupt einschätzen zu können.
@sabrinkmann Gute Nachrichten. Es geht langsam aber stetig voran. Mehr Hochschulen und Institutionen im Fediverse, Listen werden wichtiger. Danke für deine Recherchen, und dass damit Zahlen verfügbar werden, um die Lage überhaupt einschätzen zu können.
Picture the moment your server sends its first Follow activity to Mastodon. You read the spec, built the JSON, signed the HTTP request, and POSTed it with care. What comes back is a single line: 401 Unauthorized. No body. No explanation.
What went wrong? Maybe the clock behind your Date header drifted a few minutes. Maybe the hash in your Digest header is off. Maybe you uppercased the (request-target) pseudo-header while building the signing string, or published your public key as PEM where the other side wanted multibase. The remote server won't tell you. So you start reading someone else's server code to debug your own.
I know, because I've been there. Fedify began as a casualty of another project. I set out to build a single-user microblogging server, the one that would later become Hollo, and started implementing ActivityPub from scratch. Somewhere between the signature specs and the JSON-LD, the protocol work swallowed the product, and I put the whole thing down. What I picked back up wasn't the app. It was the framework the app should have had. Fedify shipped first; only then could Hollo exist, built on top of it. (I've told this story at more length in A year with the fediverse.)
ActivityPub development gets hard in a few very specific places. In this post I want to walk through five of them, then show what each one looks like with Fedify. If you've spent time in the fediverse, you'll probably nod along. If you haven't, you may wonder why anyone would do all of this by hand. Either way, the conclusion is the same: nobody has to anymore.
Five scenes
Scene 1: there is more than one standard
ActivityPub servers authenticate each other with HTTP signatures. Except there isn't one signature spec. Most of the fediverse runs on draft-cavage-http-signatures-12, an expired draft that never became a standard. The actual standard exists too: RFC 9421, HTTP Message Signatures. The problem is that you can't know which one a given server accepts until you try.
A real-world implementation therefore has to sign with one spec, see whether it gets rejected, re-sign with the other, and remember per server which one worked so it can skip the dance next time. The fediverse calls this double-knocking. Yes, you get to implement it yourself.
That's still not the end. HTTP signatures only prove who sent a request. For situations like inbox forwarding, where you relay an activity you received to a third party, you need signatures that live on the document itself: Linked Data Signatures and Object Integrity Proofs. Four signature mechanisms in total, and two kinds of keys to manage: RSA and Ed25519.
Scene 2: one document, many shapes
ActivityPub's wire format is JSON-LD, and in JSON-LD the same document can take many shapes. This is easier to show than to explain. Here is a Create activity one server might send:
actor turned from a URI string into an inline object. to turned from a string into an array. object went the other way, from an inline object to a URI. Even the address that means “public” has three valid spellings: https://www.w3.org/ns/activitystreams#Public, as:Public, and plain Public. Your parser has to accept every combination, and which one arrives depends on the sender's implementation.
The spec-compliant answer is to normalize every document with a JSON-LD processor, expansion followed by compaction. In practice many implementations treat it all as “just JSON” and quietly break on whatever shape some server happens to emit. Either way, you end up with defensive code smeared across the whole codebase: is this a string? An array? An object? A URI I have to fetch?
Scene 3: the zombie post
A user publishes a post, spots a typo, and deletes it right away. Your server sends a Create, then a Delete. Thanks to network weather, some receiving server gets the Delete first and the Create second. It ignores the deletion of a post that doesn't exist yet, then dutifully processes the creation of a post that was already deleted. That post now lives on that server forever, while its author believes it's gone.
Then there's scale. With five thousand followers, one post means thousands of HTTP deliveries. Do that inline in the request handler and your publish button takes half a minute to respond, or the server falls over. Fine, use a queue. Deliveries fail, so retry them. On what schedule? Exponential backoff. How many times? And is a 500 Internal Server Error the same kind of failure as a 410 Gone? When do you clean up three thousand followers on a server that no longer exists? Should you keep hammering a host that has been down for days?
At some point it dawns on you that this is no longer protocol implementation. It's distributed systems engineering.
Scene 4: it's not a spec, it's an ecosystem
Even perfect spec compliance doesn't buy you interoperability. A few examples from the field:
Mastodon's secure mode requires HTTP signatures on GET requests too (so-called authorized fetch). Now suppose both servers run in that mode. To fetch the other side's public key you must sign your request; to verify your signature, the other side must first fetch your key. Deadlock. The community's workaround is to sign with an “instance actor” that represents the server itself. You won't find that in the spec.
Threads can't parse activities whose actor is embedded as an inline object. When sending to Threads, the actor has to be a URI.
Lemmy silently rejects Group actors that lack fields Mastodon never asks for, such as a moderators collection linked via attributedTo and a featured collection.
Misskey carries vocabulary extensions of its own; quote posts alone go by three different property names across implementations.
The list keeps growing. Interoperability here is not something you finish once and stop thinking about. It's maintenance, forever.
Scene 5: insecure by default
Build it from scratch, and you start out wide open. Skip signature verification on incoming activities and anyone can inject a forged Follow or Delete. Leave the document loader unrestricted and a malicious activity can point it at http://169.254.169.254/ or your internal network, turning your server into an SSRF proxy. Skip origin checks on embedded objects and any server can hand out a document claiming “here's what the Mastodon lead developer said.”
What these traps share is that nothing happens when you fall into them. Everything appears to work. Until someone exploits it.
Ghost ran into this too
If you're thinking “surely our team would manage,” consider Ghost: a leading open-source publishing platform used by thousands of journalists and creators, and a team that set out to build its own ActivityPub support.
We can definitely attest to the problems that Fedify is working hard to solve, because even in just a few weeks of early prototyping we were running into the issues described above right away.
Ghost ended up building its ActivityPub layer on Fedify.
So I put all of it in a framework
Fedify is a TypeScript library for building federated server apps on ActivityPub and the standards around it. It runs on Deno, Node.js, and Bun, and supports edge runtimes like Cloudflare Workers. The design goal hasn't changed since the beginning: keep everything in those five scenes out of application code.
Here are the same five scenes again, this time with Fedify.
Scene 1, revisited: the signature war is the framework's job
Here is everything it takes to put one actor on the fediverse:
import { createFederation, generateCryptoKeyPair, MemoryKvStore } from "@fedify/fedify";import { Endpoints, Person } from "@fedify/vocab";const federation = createFederation<void>({ kv: new MemoryKvStore(), // Swap for Redis, PostgreSQL, etc. in production});federation .setActorDispatcher("/users/{identifier}", async (ctx, identifier) => { if (identifier !== "alice") return null; const keyPairs = await ctx.getActorKeyPairs(identifier); return new Person({ id: ctx.getActorUri(identifier), preferredUsername: identifier, name: "Alice", inbox: ctx.getInboxUri(identifier), endpoints: new Endpoints({ sharedInbox: ctx.getInboxUri() }), publicKey: keyPairs[0].cryptographicKey, assertionMethods: keyPairs.map((keyPair) => keyPair.multikey), }); }) .setKeyPairsDispatcher(async (ctx, identifier) => { // In real code you'd persist these in a database; this shows the gist return [await generateCryptoKeyPair()]; });
The moment this code runs:
Every outgoing request gets signed. With an RSA key, Fedify emits HTTP Signatures and Linked Data Signatures; add an Ed25519 key and it attaches Object Integrity Proofs as well. All four mechanisms coexist on a single activity, and each receiver verifies with the strongest one it understands.
Fedify does the double-knocking for you: first contact goes out as RFC 9421, a rejection triggers a draft-cavage retry, and the winning spec is cached per server. If the rejection carries an Accept-Signature challenge (RFC 9421 §5), Fedify reads it and re-signs with exactly the components the server asked for.
One bonus. Because you registered an actor dispatcher, you now have a WebFinger (RFC 7033) server, for free. Type @alice@example.com into Mastodon's search box and your actor comes up. You never wrote a line of WebFinger code.
Scene 2, revisited: types instead of JSON-LD
Fedify ships about eighty classes covering the whole Activity Vocabulary plus the major vendor extensions. The classes are typed and immutable, and their accessors absorb the shape differences that JSON-LD allows.
const actor = await ctx.lookupObject("@hongminhee@hollo.social");if (actor instanceof Person) { console.log(actor.name); // Safe whether it's a string or langString const followers = await actor.getFollowers(); // Fetches a URI, unwraps an object}
lookupObject() takes a handle and runs the whole chain for you, WebFinger discovery included. Accessors like getFollowers()behave the same way whether the value is a URI reference or an inline object, and fetched values are cached.
Vendor fragmentation gets stitched up here too. The three competing quote properties (quoteUri, _misskey_quote, quoteUrl) are unified behind one API, next to the emerging FEP-044fquote. Misskey's isCat property exists as a type, so your server can determine cat-ness with full type safety. It sounds like a joke, but a few dozen details of exactly this kind are what interoperability is actually made of.
Scene 3, revisited: the zombie post dies in one line
Delivery infrastructure first. Plug a message queue into createFederation() and delivery moves to the background, with automatic retries under exponential backoff (up to ten attempts by default). When a post goes to thousands of followers, two-stage fan-out kicks in: a single consolidated message enters the queue, and a background worker splits it into per-server delivery tasks. The publish button responds immediately.
Retries create a problem of their own: the same activity can arrive twice. Fedify keeps a 24-hour idempotence cache of processed activities, so duplicates get detected and skipped before they reach your handlers.
As for the zombie post, the fix is one option:
await ctx.sendActivity( { identifier: "alice" }, "followers", // Collects recipients from your followers collection deleteActivity, { orderingKey: post.id }, // Same key = in-order delivery per server);
Activities that share an orderingKey are delivered to each receiving server in the order they were sent. A Delete can no longer overtake its Create. Activities with different keys still go out in parallel, so throughput survives.
Fedify also handles dead servers. On a 404 Not Found or 410 Gone, it stops retrying and calls a handler you register. If the delivery went to a shared inbox, you also get the list of followers behind it, so you can prune vanished accounts on the spot. Hosts that fail repeatedly trip a per-host circuit breaker that holds deliveries and probes periodically until the host recovers. It's on by default; there's nothing to configure.
Scene 4, revisited: we track the quirks so you don't
Here is how Fedify disarms the traps from scene 4:
Authorized fetch: chain .authorize() onto a dispatcher and the verified identity of the requester lands in your callback. Blocklists, private collections, whatever your app needs is plain application logic. The instance-actor deadlock has a supported pattern as well.
Threads and inline actors: an activity transformer, enabled by default, rewrites inline actors into URIs on the way out. You don't need to know Threads has this problem.
Lemmy's requirements: the custom collection API exposes a moderators collection in a few lines, and Lemmy's JSON-LD context ships preloaded.
When a new quirk surfaces in the wild, the fix lands in Fedify, not in every application separately. Each interoperability lesson gets learned once.
Scene 5, revisited: becoming unsafe takes effort
Fedify's defaults point the other way.
Signature verification is something you turn off (for tests), not something you remember to turn on.
The document loader refuses private address ranges and loopback out of the box, with DNS rebinding accounted for. To open yourself up to SSRF you have to flip an option whose very name announces it's for testing.
In a from-scratch implementation, you have to keep remembering to do things safely. In Fedify, the unsafe path is the one that takes deliberate effort. For a federated server, with its tangle of trust boundaries, that's the right way around.
Your stack stays your stack
“Fine, but what if it doesn't fit our stack?” Fedify was built to fit the stack you already have. There are thirteen web framework integrations: servers like Express, Hono, Fastify, Koa, NestJS, and Elysia, and meta-frameworks like Next.js, Nuxt, SvelteKit, Astro, SolidStart, and Fresh. Middleware handles content negotiation, so the same URL in your existing app serves HTML to browsers and JSON-LD to the fediverse.
Fedify doesn't dictate your database either. For its own storage it asks for one key–value interface, with seven adapters available (Redis, PostgreSQL, MySQL/MariaDB, SQLite, Deno KV, Cloudflare Workers KV, in-memory). Message queues come in eight flavors (PostgreSQL, Redis, AMQP/RabbitMQ, and so on), and you can implement the interface yourself if none fits. Your domain data stays in whatever database and ORM you already use.
Already running federation on another library? There are migration guides with data migration scripts for moving from activitypub-express and friends without losing your existing followers.
The core isn't the ceiling, either. Higher-level packages build on it: @fedify/relay gives you a complete ActivityPub relay server in a single function call, and @fedify/backfill reconstructs incomplete conversation threads by walking the rest of the fediverse for you.
Tools for the whole development loop
A quieter misery of federated development has always been the missing tooling. Fedify comes with tools for every stage of the loop.
fedify init scaffolds a project in one line, and fedify tunnel exposes your local server over HTTPS so you can test against real Mastodon. Activities your server sends can be received by fedify inbox, a disposable inbox server spun up on the spot; whatever other servers publish, you can inspect with fedify lookup. My personal favorite is fedify lookup --authorized-fetch, which generates a one-off key pair and stands up a temporary ActivityPub server just to make a signed request for an object behind secure mode. The CLI is also useful to ActivityPub developers who don't use Fedify at all.
While you write code, an ActivityPub-specific linter (@fedify/lint) catches twenty kinds of interoperability bugs, like an actor missing its inbox. Tests run without the network using mocks from @fedify/testing. Once the server is up, attach the debug dashboard (@fedify/debugger) with one line and watch activities and signature verification results in your browser, live. In production there's built-in OpenTelemetry instrumentation (28 span types, 37 metrics) plus a monitoring guide, and when performance matters, fedify bench, a load-testing tool built for ActivityPub, catches regressions in CI.
As far as I know, no other ActivityPub framework ships even one of the tools in this section.
The documentation is part of the tooling. The official docs run to a thirty-chapter manual and five tutorials, and they go well past API listings. There's an operations chapter with ready-made PromQL queries and alerting rules for watching your queue backlog, and a field-guide chapter that documents de facto conventions, like which property makes your avatar show up in Mastodon, with screenshots. At two in the morning, when federation is broken and you don't know why, this is the difference between a bad night and a short one.
It's already running
Fedify is not a thought experiment. Ghost's ActivityPub service, mentioned above, is built on it. So are Encyclia, which bridges ORCID researcher records into the fediverse; SiliconBeest, running serverless on Cloudflare Workers; Typo Blue, a Korean blogging platform; Hollo, my own single-user microblogging platform; and Hackers' Pub, run by its community. Hollo, by the way, is the app from the beginning of this post: the project I once had to shelve, finished at last on the framework it forced into existence.
I didn't build Fedify to mint more ActivityPub experts. Rather the opposite. I believe the fediverse will only grow beyond microblogging when developers can build federated apps without knowing ActivityPub's fine print. Signature spec transitions and JSON-LD compaction are problems that belong inside a framework, not barriers in front of someone with a new idea.
Starting takes one line:
npm init @fedify
Follow the first tutorial and by the end, Mastodon can find your server. If you get stuck, come find us in the Matrix room or GitHub Discussions. See you in the fediverse.
Picture the moment your server sends its first Follow activity to Mastodon. You read the spec, built the JSON, signed the HTTP request, and POSTed it with care. What comes back is a single line: 401 Unauthorized. No body. No explanation.
What went wrong? Maybe the clock behind your Date header drifted a few minutes. Maybe the hash in your Digest header is off. Maybe you uppercased the (request-target) pseudo-header while building the signing string, or published your public key as PEM where the other side wanted multibase. The remote server won't tell you. So you start reading someone else's server code to debug your own.
I know, because I've been there. Fedify began as a casualty of another project. I set out to build a single-user microblogging server, the one that would later become Hollo, and started implementing ActivityPub from scratch. Somewhere between the signature specs and the JSON-LD, the protocol work swallowed the product, and I put the whole thing down. What I picked back up wasn't the app. It was the framework the app should have had. Fedify shipped first; only then could Hollo exist, built on top of it. (I've told this story at more length in A year with the fediverse.)
ActivityPub development gets hard in a few very specific places. In this post I want to walk through five of them, then show what each one looks like with Fedify. If you've spent time in the fediverse, you'll probably nod along. If you haven't, you may wonder why anyone would do all of this by hand. Either way, the conclusion is the same: nobody has to anymore.
Five scenes
Scene 1: there is more than one standard
ActivityPub servers authenticate each other with HTTP signatures. Except there isn't one signature spec. Most of the fediverse runs on draft-cavage-http-signatures-12, an expired draft that never became a standard. The actual standard exists too: RFC 9421, HTTP Message Signatures. The problem is that you can't know which one a given server accepts until you try.
A real-world implementation therefore has to sign with one spec, see whether it gets rejected, re-sign with the other, and remember per server which one worked so it can skip the dance next time. The fediverse calls this double-knocking. Yes, you get to implement it yourself.
That's still not the end. HTTP signatures only prove who sent a request. For situations like inbox forwarding, where you relay an activity you received to a third party, you need signatures that live on the document itself: Linked Data Signatures and Object Integrity Proofs. Four signature mechanisms in total, and two kinds of keys to manage: RSA and Ed25519.
Scene 2: one document, many shapes
ActivityPub's wire format is JSON-LD, and in JSON-LD the same document can take many shapes. This is easier to show than to explain. Here is a Create activity one server might send:
actor turned from a URI string into an inline object. to turned from a string into an array. object went the other way, from an inline object to a URI. Even the address that means “public” has three valid spellings: https://www.w3.org/ns/activitystreams#Public, as:Public, and plain Public. Your parser has to accept every combination, and which one arrives depends on the sender's implementation.
The spec-compliant answer is to normalize every document with a JSON-LD processor, expansion followed by compaction. In practice many implementations treat it all as “just JSON” and quietly break on whatever shape some server happens to emit. Either way, you end up with defensive code smeared across the whole codebase: is this a string? An array? An object? A URI I have to fetch?
Scene 3: the zombie post
A user publishes a post, spots a typo, and deletes it right away. Your server sends a Create, then a Delete. Thanks to network weather, some receiving server gets the Delete first and the Create second. It ignores the deletion of a post that doesn't exist yet, then dutifully processes the creation of a post that was already deleted. That post now lives on that server forever, while its author believes it's gone.
Then there's scale. With five thousand followers, one post means thousands of HTTP deliveries. Do that inline in the request handler and your publish button takes half a minute to respond, or the server falls over. Fine, use a queue. Deliveries fail, so retry them. On what schedule? Exponential backoff. How many times? And is a 500 Internal Server Error the same kind of failure as a 410 Gone? When do you clean up three thousand followers on a server that no longer exists? Should you keep hammering a host that has been down for days?
At some point it dawns on you that this is no longer protocol implementation. It's distributed systems engineering.
Scene 4: it's not a spec, it's an ecosystem
Even perfect spec compliance doesn't buy you interoperability. A few examples from the field:
Mastodon's secure mode requires HTTP signatures on GET requests too (so-called authorized fetch). Now suppose both servers run in that mode. To fetch the other side's public key you must sign your request; to verify your signature, the other side must first fetch your key. Deadlock. The community's workaround is to sign with an “instance actor” that represents the server itself. You won't find that in the spec.
Threads can't parse activities whose actor is embedded as an inline object. When sending to Threads, the actor has to be a URI.
Lemmy silently rejects Group actors that lack fields Mastodon never asks for, such as a moderators collection linked via attributedTo and a featured collection.
Misskey carries vocabulary extensions of its own; quote posts alone go by three different property names across implementations.
The list keeps growing. Interoperability here is not something you finish once and stop thinking about. It's maintenance, forever.
Scene 5: insecure by default
Build it from scratch, and you start out wide open. Skip signature verification on incoming activities and anyone can inject a forged Follow or Delete. Leave the document loader unrestricted and a malicious activity can point it at http://169.254.169.254/ or your internal network, turning your server into an SSRF proxy. Skip origin checks on embedded objects and any server can hand out a document claiming “here's what the Mastodon lead developer said.”
What these traps share is that nothing happens when you fall into them. Everything appears to work. Until someone exploits it.
Ghost ran into this too
If you're thinking “surely our team would manage,” consider Ghost: a leading open-source publishing platform used by thousands of journalists and creators, and a team that set out to build its own ActivityPub support.
We can definitely attest to the problems that Fedify is working hard to solve, because even in just a few weeks of early prototyping we were running into the issues described above right away.
Ghost ended up building its ActivityPub layer on Fedify.
So I put all of it in a framework
Fedify is a TypeScript library for building federated server apps on ActivityPub and the standards around it. It runs on Deno, Node.js, and Bun, and supports edge runtimes like Cloudflare Workers. The design goal hasn't changed since the beginning: keep everything in those five scenes out of application code.
Here are the same five scenes again, this time with Fedify.
Scene 1, revisited: the signature war is the framework's job
Here is everything it takes to put one actor on the fediverse:
import { createFederation, generateCryptoKeyPair, MemoryKvStore } from "@fedify/fedify";import { Endpoints, Person } from "@fedify/vocab";const federation = createFederation<void>({ kv: new MemoryKvStore(), // Swap for Redis, PostgreSQL, etc. in production});federation .setActorDispatcher("/users/{identifier}", async (ctx, identifier) => { if (identifier !== "alice") return null; const keyPairs = await ctx.getActorKeyPairs(identifier); return new Person({ id: ctx.getActorUri(identifier), preferredUsername: identifier, name: "Alice", inbox: ctx.getInboxUri(identifier), endpoints: new Endpoints({ sharedInbox: ctx.getInboxUri() }), publicKey: keyPairs[0].cryptographicKey, assertionMethods: keyPairs.map((keyPair) => keyPair.multikey), }); }) .setKeyPairsDispatcher(async (ctx, identifier) => { // In real code you'd persist these in a database; this shows the gist return [await generateCryptoKeyPair()]; });
The moment this code runs:
Every outgoing request gets signed. With an RSA key, Fedify emits HTTP Signatures and Linked Data Signatures; add an Ed25519 key and it attaches Object Integrity Proofs as well. All four mechanisms coexist on a single activity, and each receiver verifies with the strongest one it understands.
Fedify does the double-knocking for you: first contact goes out as RFC 9421, a rejection triggers a draft-cavage retry, and the winning spec is cached per server. If the rejection carries an Accept-Signature challenge (RFC 9421 §5), Fedify reads it and re-signs with exactly the components the server asked for.
One bonus. Because you registered an actor dispatcher, you now have a WebFinger (RFC 7033) server, for free. Type @alice@example.com into Mastodon's search box and your actor comes up. You never wrote a line of WebFinger code.
Scene 2, revisited: types instead of JSON-LD
Fedify ships about eighty classes covering the whole Activity Vocabulary plus the major vendor extensions. The classes are typed and immutable, and their accessors absorb the shape differences that JSON-LD allows.
const actor = await ctx.lookupObject("@hongminhee@hollo.social");if (actor instanceof Person) { console.log(actor.name); // Safe whether it's a string or langString const followers = await actor.getFollowers(); // Fetches a URI, unwraps an object}
lookupObject() takes a handle and runs the whole chain for you, WebFinger discovery included. Accessors like getFollowers()behave the same way whether the value is a URI reference or an inline object, and fetched values are cached.
Vendor fragmentation gets stitched up here too. The three competing quote properties (quoteUri, _misskey_quote, quoteUrl) are unified behind one API, next to the emerging FEP-044fquote. Misskey's isCat property exists as a type, so your server can determine cat-ness with full type safety. It sounds like a joke, but a few dozen details of exactly this kind are what interoperability is actually made of.
Scene 3, revisited: the zombie post dies in one line
Delivery infrastructure first. Plug a message queue into createFederation() and delivery moves to the background, with automatic retries under exponential backoff (up to ten attempts by default). When a post goes to thousands of followers, two-stage fan-out kicks in: a single consolidated message enters the queue, and a background worker splits it into per-server delivery tasks. The publish button responds immediately.
Retries create a problem of their own: the same activity can arrive twice. Fedify keeps a 24-hour idempotence cache of processed activities, so duplicates get detected and skipped before they reach your handlers.
As for the zombie post, the fix is one option:
await ctx.sendActivity( { identifier: "alice" }, "followers", // Collects recipients from your followers collection deleteActivity, { orderingKey: post.id }, // Same key = in-order delivery per server);
Activities that share an orderingKey are delivered to each receiving server in the order they were sent. A Delete can no longer overtake its Create. Activities with different keys still go out in parallel, so throughput survives.
Fedify also handles dead servers. On a 404 Not Found or 410 Gone, it stops retrying and calls a handler you register. If the delivery went to a shared inbox, you also get the list of followers behind it, so you can prune vanished accounts on the spot. Hosts that fail repeatedly trip a per-host circuit breaker that holds deliveries and probes periodically until the host recovers. It's on by default; there's nothing to configure.
Scene 4, revisited: we track the quirks so you don't
Here is how Fedify disarms the traps from scene 4:
Authorized fetch: chain .authorize() onto a dispatcher and the verified identity of the requester lands in your callback. Blocklists, private collections, whatever your app needs is plain application logic. The instance-actor deadlock has a supported pattern as well.
Threads and inline actors: an activity transformer, enabled by default, rewrites inline actors into URIs on the way out. You don't need to know Threads has this problem.
Lemmy's requirements: the custom collection API exposes a moderators collection in a few lines, and Lemmy's JSON-LD context ships preloaded.
When a new quirk surfaces in the wild, the fix lands in Fedify, not in every application separately. Each interoperability lesson gets learned once.
Scene 5, revisited: becoming unsafe takes effort
Fedify's defaults point the other way.
Signature verification is something you turn off (for tests), not something you remember to turn on.
The document loader refuses private address ranges and loopback out of the box, with DNS rebinding accounted for. To open yourself up to SSRF you have to flip an option whose very name announces it's for testing.
In a from-scratch implementation, you have to keep remembering to do things safely. In Fedify, the unsafe path is the one that takes deliberate effort. For a federated server, with its tangle of trust boundaries, that's the right way around.
Your stack stays your stack
“Fine, but what if it doesn't fit our stack?” Fedify was built to fit the stack you already have. There are thirteen web framework integrations: servers like Express, Hono, Fastify, Koa, NestJS, and Elysia, and meta-frameworks like Next.js, Nuxt, SvelteKit, Astro, SolidStart, and Fresh. Middleware handles content negotiation, so the same URL in your existing app serves HTML to browsers and JSON-LD to the fediverse.
Fedify doesn't dictate your database either. For its own storage it asks for one key–value interface, with seven adapters available (Redis, PostgreSQL, MySQL/MariaDB, SQLite, Deno KV, Cloudflare Workers KV, in-memory). Message queues come in eight flavors (PostgreSQL, Redis, AMQP/RabbitMQ, and so on), and you can implement the interface yourself if none fits. Your domain data stays in whatever database and ORM you already use.
Already running federation on another library? There are migration guides with data migration scripts for moving from activitypub-express and friends without losing your existing followers.
The core isn't the ceiling, either. Higher-level packages build on it: @fedify/relay gives you a complete ActivityPub relay server in a single function call, and @fedify/backfill reconstructs incomplete conversation threads by walking the rest of the fediverse for you.
Tools for the whole development loop
A quieter misery of federated development has always been the missing tooling. Fedify comes with tools for every stage of the loop.
fedify init scaffolds a project in one line, and fedify tunnel exposes your local server over HTTPS so you can test against real Mastodon. Activities your server sends can be received by fedify inbox, a disposable inbox server spun up on the spot; whatever other servers publish, you can inspect with fedify lookup. My personal favorite is fedify lookup --authorized-fetch, which generates a one-off key pair and stands up a temporary ActivityPub server just to make a signed request for an object behind secure mode. The CLI is also useful to ActivityPub developers who don't use Fedify at all.
While you write code, an ActivityPub-specific linter (@fedify/lint) catches twenty kinds of interoperability bugs, like an actor missing its inbox. Tests run without the network using mocks from @fedify/testing. Once the server is up, attach the debug dashboard (@fedify/debugger) with one line and watch activities and signature verification results in your browser, live. In production there's built-in OpenTelemetry instrumentation (28 span types, 37 metrics) plus a monitoring guide, and when performance matters, fedify bench, a load-testing tool built for ActivityPub, catches regressions in CI.
As far as I know, no other ActivityPub framework ships even one of the tools in this section.
The documentation is part of the tooling. The official docs run to a thirty-chapter manual and five tutorials, and they go well past API listings. There's an operations chapter with ready-made PromQL queries and alerting rules for watching your queue backlog, and a field-guide chapter that documents de facto conventions, like which property makes your avatar show up in Mastodon, with screenshots. At two in the morning, when federation is broken and you don't know why, this is the difference between a bad night and a short one.
It's already running
Fedify is not a thought experiment. Ghost's ActivityPub service, mentioned above, is built on it. So are Encyclia, which bridges ORCID researcher records into the fediverse; SiliconBeest, running serverless on Cloudflare Workers; Typo Blue, a Korean blogging platform; Hollo, my own single-user microblogging platform; and Hackers' Pub, run by its community. Hollo, by the way, is the app from the beginning of this post: the project I once had to shelve, finished at last on the framework it forced into existence.
I didn't build Fedify to mint more ActivityPub experts. Rather the opposite. I believe the fediverse will only grow beyond microblogging when developers can build federated apps without knowing ActivityPub's fine print. Signature spec transitions and JSON-LD compaction are problems that belong inside a framework, not barriers in front of someone with a new idea.
Starting takes one line:
npm init @fedify
Follow the first tutorial and by the end, Mastodon can find your server. If you get stuck, come find us in the Matrix room or GitHub Discussions. See you in the fediverse.
Picture the moment your server sends its first Follow activity to Mastodon. You read the spec, built the JSON, signed the HTTP request, and POSTed it with care. What comes back is a single line: 401 Unauthorized. No body. No explanation.
What went wrong? Maybe the clock behind your Date header drifted a few minutes. Maybe the hash in your Digest header is off. Maybe you uppercased the (request-target) pseudo-header while building the signing string, or published your public key as PEM where the other side wanted multibase. The remote server won't tell you. So you start reading someone else's server code to debug your own.
I know, because I've been there. Fedify began as a casualty of another project. I set out to build a single-user microblogging server, the one that would later become Hollo, and started implementing ActivityPub from scratch. Somewhere between the signature specs and the JSON-LD, the protocol work swallowed the product, and I put the whole thing down. What I picked back up wasn't the app. It was the framework the app should have had. Fedify shipped first; only then could Hollo exist, built on top of it. (I've told this story at more length in A year with the fediverse.)
ActivityPub development gets hard in a few very specific places. In this post I want to walk through five of them, then show what each one looks like with Fedify. If you've spent time in the fediverse, you'll probably nod along. If you haven't, you may wonder why anyone would do all of this by hand. Either way, the conclusion is the same: nobody has to anymore.
Five scenes
Scene 1: there is more than one standard
ActivityPub servers authenticate each other with HTTP signatures. Except there isn't one signature spec. Most of the fediverse runs on draft-cavage-http-signatures-12, an expired draft that never became a standard. The actual standard exists too: RFC 9421, HTTP Message Signatures. The problem is that you can't know which one a given server accepts until you try.
A real-world implementation therefore has to sign with one spec, see whether it gets rejected, re-sign with the other, and remember per server which one worked so it can skip the dance next time. The fediverse calls this double-knocking. Yes, you get to implement it yourself.
That's still not the end. HTTP signatures only prove who sent a request. For situations like inbox forwarding, where you relay an activity you received to a third party, you need signatures that live on the document itself: Linked Data Signatures and Object Integrity Proofs. Four signature mechanisms in total, and two kinds of keys to manage: RSA and Ed25519.
Scene 2: one document, many shapes
ActivityPub's wire format is JSON-LD, and in JSON-LD the same document can take many shapes. This is easier to show than to explain. Here is a Create activity one server might send:
actor turned from a URI string into an inline object. to turned from a string into an array. object went the other way, from an inline object to a URI. Even the address that means “public” has three valid spellings: https://www.w3.org/ns/activitystreams#Public, as:Public, and plain Public. Your parser has to accept every combination, and which one arrives depends on the sender's implementation.
The spec-compliant answer is to normalize every document with a JSON-LD processor, expansion followed by compaction. In practice many implementations treat it all as “just JSON” and quietly break on whatever shape some server happens to emit. Either way, you end up with defensive code smeared across the whole codebase: is this a string? An array? An object? A URI I have to fetch?
Scene 3: the zombie post
A user publishes a post, spots a typo, and deletes it right away. Your server sends a Create, then a Delete. Thanks to network weather, some receiving server gets the Delete first and the Create second. It ignores the deletion of a post that doesn't exist yet, then dutifully processes the creation of a post that was already deleted. That post now lives on that server forever, while its author believes it's gone.
Then there's scale. With five thousand followers, one post means thousands of HTTP deliveries. Do that inline in the request handler and your publish button takes half a minute to respond, or the server falls over. Fine, use a queue. Deliveries fail, so retry them. On what schedule? Exponential backoff. How many times? And is a 500 Internal Server Error the same kind of failure as a 410 Gone? When do you clean up three thousand followers on a server that no longer exists? Should you keep hammering a host that has been down for days?
At some point it dawns on you that this is no longer protocol implementation. It's distributed systems engineering.
Scene 4: it's not a spec, it's an ecosystem
Even perfect spec compliance doesn't buy you interoperability. A few examples from the field:
Mastodon's secure mode requires HTTP signatures on GET requests too (so-called authorized fetch). Now suppose both servers run in that mode. To fetch the other side's public key you must sign your request; to verify your signature, the other side must first fetch your key. Deadlock. The community's workaround is to sign with an “instance actor” that represents the server itself. You won't find that in the spec.
Threads can't parse activities whose actor is embedded as an inline object. When sending to Threads, the actor has to be a URI.
Lemmy silently rejects Group actors that lack fields Mastodon never asks for, such as a moderators collection linked via attributedTo and a featured collection.
Misskey carries vocabulary extensions of its own; quote posts alone go by three different property names across implementations.
The list keeps growing. Interoperability here is not something you finish once and stop thinking about. It's maintenance, forever.
Scene 5: insecure by default
Build it from scratch, and you start out wide open. Skip signature verification on incoming activities and anyone can inject a forged Follow or Delete. Leave the document loader unrestricted and a malicious activity can point it at http://169.254.169.254/ or your internal network, turning your server into an SSRF proxy. Skip origin checks on embedded objects and any server can hand out a document claiming “here's what the Mastodon lead developer said.”
What these traps share is that nothing happens when you fall into them. Everything appears to work. Until someone exploits it.
Ghost ran into this too
If you're thinking “surely our team would manage,” consider Ghost: a leading open-source publishing platform used by thousands of journalists and creators, and a team that set out to build its own ActivityPub support.
We can definitely attest to the problems that Fedify is working hard to solve, because even in just a few weeks of early prototyping we were running into the issues described above right away.
Ghost ended up building its ActivityPub layer on Fedify.
So I put all of it in a framework
Fedify is a TypeScript library for building federated server apps on ActivityPub and the standards around it. It runs on Deno, Node.js, and Bun, and supports edge runtimes like Cloudflare Workers. The design goal hasn't changed since the beginning: keep everything in those five scenes out of application code.
Here are the same five scenes again, this time with Fedify.
Scene 1, revisited: the signature war is the framework's job
Here is everything it takes to put one actor on the fediverse:
import { createFederation, generateCryptoKeyPair, MemoryKvStore } from "@fedify/fedify";import { Endpoints, Person } from "@fedify/vocab";const federation = createFederation<void>({ kv: new MemoryKvStore(), // Swap for Redis, PostgreSQL, etc. in production});federation .setActorDispatcher("/users/{identifier}", async (ctx, identifier) => { if (identifier !== "alice") return null; const keyPairs = await ctx.getActorKeyPairs(identifier); return new Person({ id: ctx.getActorUri(identifier), preferredUsername: identifier, name: "Alice", inbox: ctx.getInboxUri(identifier), endpoints: new Endpoints({ sharedInbox: ctx.getInboxUri() }), publicKey: keyPairs[0].cryptographicKey, assertionMethods: keyPairs.map((keyPair) => keyPair.multikey), }); }) .setKeyPairsDispatcher(async (ctx, identifier) => { // In real code you'd persist these in a database; this shows the gist return [await generateCryptoKeyPair()]; });
The moment this code runs:
Every outgoing request gets signed. With an RSA key, Fedify emits HTTP Signatures and Linked Data Signatures; add an Ed25519 key and it attaches Object Integrity Proofs as well. All four mechanisms coexist on a single activity, and each receiver verifies with the strongest one it understands.
Fedify does the double-knocking for you: first contact goes out as RFC 9421, a rejection triggers a draft-cavage retry, and the winning spec is cached per server. If the rejection carries an Accept-Signature challenge (RFC 9421 §5), Fedify reads it and re-signs with exactly the components the server asked for.
One bonus. Because you registered an actor dispatcher, you now have a WebFinger (RFC 7033) server, for free. Type @alice@example.com into Mastodon's search box and your actor comes up. You never wrote a line of WebFinger code.
Scene 2, revisited: types instead of JSON-LD
Fedify ships about eighty classes covering the whole Activity Vocabulary plus the major vendor extensions. The classes are typed and immutable, and their accessors absorb the shape differences that JSON-LD allows.
const actor = await ctx.lookupObject("@hongminhee@hollo.social");if (actor instanceof Person) { console.log(actor.name); // Safe whether it's a string or langString const followers = await actor.getFollowers(); // Fetches a URI, unwraps an object}
lookupObject() takes a handle and runs the whole chain for you, WebFinger discovery included. Accessors like getFollowers()behave the same way whether the value is a URI reference or an inline object, and fetched values are cached.
Vendor fragmentation gets stitched up here too. The three competing quote properties (quoteUri, _misskey_quote, quoteUrl) are unified behind one API, next to the emerging FEP-044fquote. Misskey's isCat property exists as a type, so your server can determine cat-ness with full type safety. It sounds like a joke, but a few dozen details of exactly this kind are what interoperability is actually made of.
Scene 3, revisited: the zombie post dies in one line
Delivery infrastructure first. Plug a message queue into createFederation() and delivery moves to the background, with automatic retries under exponential backoff (up to ten attempts by default). When a post goes to thousands of followers, two-stage fan-out kicks in: a single consolidated message enters the queue, and a background worker splits it into per-server delivery tasks. The publish button responds immediately.
Retries create a problem of their own: the same activity can arrive twice. Fedify keeps a 24-hour idempotence cache of processed activities, so duplicates get detected and skipped before they reach your handlers.
As for the zombie post, the fix is one option:
await ctx.sendActivity( { identifier: "alice" }, "followers", // Collects recipients from your followers collection deleteActivity, { orderingKey: post.id }, // Same key = in-order delivery per server);
Activities that share an orderingKey are delivered to each receiving server in the order they were sent. A Delete can no longer overtake its Create. Activities with different keys still go out in parallel, so throughput survives.
Fedify also handles dead servers. On a 404 Not Found or 410 Gone, it stops retrying and calls a handler you register. If the delivery went to a shared inbox, you also get the list of followers behind it, so you can prune vanished accounts on the spot. Hosts that fail repeatedly trip a per-host circuit breaker that holds deliveries and probes periodically until the host recovers. It's on by default; there's nothing to configure.
Scene 4, revisited: we track the quirks so you don't
Here is how Fedify disarms the traps from scene 4:
Authorized fetch: chain .authorize() onto a dispatcher and the verified identity of the requester lands in your callback. Blocklists, private collections, whatever your app needs is plain application logic. The instance-actor deadlock has a supported pattern as well.
Threads and inline actors: an activity transformer, enabled by default, rewrites inline actors into URIs on the way out. You don't need to know Threads has this problem.
Lemmy's requirements: the custom collection API exposes a moderators collection in a few lines, and Lemmy's JSON-LD context ships preloaded.
When a new quirk surfaces in the wild, the fix lands in Fedify, not in every application separately. Each interoperability lesson gets learned once.
Scene 5, revisited: becoming unsafe takes effort
Fedify's defaults point the other way.
Signature verification is something you turn off (for tests), not something you remember to turn on.
The document loader refuses private address ranges and loopback out of the box, with DNS rebinding accounted for. To open yourself up to SSRF you have to flip an option whose very name announces it's for testing.
In a from-scratch implementation, you have to keep remembering to do things safely. In Fedify, the unsafe path is the one that takes deliberate effort. For a federated server, with its tangle of trust boundaries, that's the right way around.
Your stack stays your stack
“Fine, but what if it doesn't fit our stack?” Fedify was built to fit the stack you already have. There are thirteen web framework integrations: servers like Express, Hono, Fastify, Koa, NestJS, and Elysia, and meta-frameworks like Next.js, Nuxt, SvelteKit, Astro, SolidStart, and Fresh. Middleware handles content negotiation, so the same URL in your existing app serves HTML to browsers and JSON-LD to the fediverse.
Fedify doesn't dictate your database either. For its own storage it asks for one key–value interface, with seven adapters available (Redis, PostgreSQL, MySQL/MariaDB, SQLite, Deno KV, Cloudflare Workers KV, in-memory). Message queues come in eight flavors (PostgreSQL, Redis, AMQP/RabbitMQ, and so on), and you can implement the interface yourself if none fits. Your domain data stays in whatever database and ORM you already use.
Already running federation on another library? There are migration guides with data migration scripts for moving from activitypub-express and friends without losing your existing followers.
The core isn't the ceiling, either. Higher-level packages build on it: @fedify/relay gives you a complete ActivityPub relay server in a single function call, and @fedify/backfill reconstructs incomplete conversation threads by walking the rest of the fediverse for you.
Tools for the whole development loop
A quieter misery of federated development has always been the missing tooling. Fedify comes with tools for every stage of the loop.
fedify init scaffolds a project in one line, and fedify tunnel exposes your local server over HTTPS so you can test against real Mastodon. Activities your server sends can be received by fedify inbox, a disposable inbox server spun up on the spot; whatever other servers publish, you can inspect with fedify lookup. My personal favorite is fedify lookup --authorized-fetch, which generates a one-off key pair and stands up a temporary ActivityPub server just to make a signed request for an object behind secure mode. The CLI is also useful to ActivityPub developers who don't use Fedify at all.
While you write code, an ActivityPub-specific linter (@fedify/lint) catches twenty kinds of interoperability bugs, like an actor missing its inbox. Tests run without the network using mocks from @fedify/testing. Once the server is up, attach the debug dashboard (@fedify/debugger) with one line and watch activities and signature verification results in your browser, live. In production there's built-in OpenTelemetry instrumentation (28 span types, 37 metrics) plus a monitoring guide, and when performance matters, fedify bench, a load-testing tool built for ActivityPub, catches regressions in CI.
As far as I know, no other ActivityPub framework ships even one of the tools in this section.
The documentation is part of the tooling. The official docs run to a thirty-chapter manual and five tutorials, and they go well past API listings. There's an operations chapter with ready-made PromQL queries and alerting rules for watching your queue backlog, and a field-guide chapter that documents de facto conventions, like which property makes your avatar show up in Mastodon, with screenshots. At two in the morning, when federation is broken and you don't know why, this is the difference between a bad night and a short one.
It's already running
Fedify is not a thought experiment. Ghost's ActivityPub service, mentioned above, is built on it. So are Encyclia, which bridges ORCID researcher records into the fediverse; SiliconBeest, running serverless on Cloudflare Workers; Typo Blue, a Korean blogging platform; Hollo, my own single-user microblogging platform; and Hackers' Pub, run by its community. Hollo, by the way, is the app from the beginning of this post: the project I once had to shelve, finished at last on the framework it forced into existence.
I didn't build Fedify to mint more ActivityPub experts. Rather the opposite. I believe the fediverse will only grow beyond microblogging when developers can build federated apps without knowing ActivityPub's fine print. Signature spec transitions and JSON-LD compaction are problems that belong inside a framework, not barriers in front of someone with a new idea.
Starting takes one line:
npm init @fedify
Follow the first tutorial and by the end, Mastodon can find your server. If you get stuck, come find us in the Matrix room or GitHub Discussions. See you in the fediverse.
One caveat I might have, and this is not an issue with the article, of course, and I generally agree that "the fediverse needs more apps", but!
This is where the Atmosphere has a big advantage.
Yes, some of us might prefer to have separate accounts on different servers and platforms, and keep individual hobbies, interests, and other layers of our personality separate. I think that's fine.
But some of us might prefer to manage one account, and until nomadic identity is widely supported across the fediverse, having more apps to sign up for might not entice everyone.
Picture the moment your server sends its first Follow activity to Mastodon. You read the spec, built the JSON, signed the HTTP request, and POSTed it with care. What comes back is a single line: 401 Unauthorized. No body. No explanation.
What went wrong? Maybe the clock behind your Date header drifted a few minutes. Maybe the hash in your Digest header is off. Maybe you uppercased the (request-target) pseudo-header while building the signing string, or published your public key as PEM where the other side wanted multibase. The remote server won't tell you. So you start reading someone else's server code to debug your own.
I know, because I've been there. Fedify began as a casualty of another project. I set out to build a single-user microblogging server, the one that would later become Hollo, and started implementing ActivityPub from scratch. Somewhere between the signature specs and the JSON-LD, the protocol work swallowed the product, and I put the whole thing down. What I picked back up wasn't the app. It was the framework the app should have had. Fedify shipped first; only then could Hollo exist, built on top of it. (I've told this story at more length in A year with the fediverse.)
ActivityPub development gets hard in a few very specific places. In this post I want to walk through five of them, then show what each one looks like with Fedify. If you've spent time in the fediverse, you'll probably nod along. If you haven't, you may wonder why anyone would do all of this by hand. Either way, the conclusion is the same: nobody has to anymore.
Five scenes
Scene 1: there is more than one standard
ActivityPub servers authenticate each other with HTTP signatures. Except there isn't one signature spec. Most of the fediverse runs on draft-cavage-http-signatures-12, an expired draft that never became a standard. The actual standard exists too: RFC 9421, HTTP Message Signatures. The problem is that you can't know which one a given server accepts until you try.
A real-world implementation therefore has to sign with one spec, see whether it gets rejected, re-sign with the other, and remember per server which one worked so it can skip the dance next time. The fediverse calls this double-knocking. Yes, you get to implement it yourself.
That's still not the end. HTTP signatures only prove who sent a request. For situations like inbox forwarding, where you relay an activity you received to a third party, you need signatures that live on the document itself: Linked Data Signatures and Object Integrity Proofs. Four signature mechanisms in total, and two kinds of keys to manage: RSA and Ed25519.
Scene 2: one document, many shapes
ActivityPub's wire format is JSON-LD, and in JSON-LD the same document can take many shapes. This is easier to show than to explain. Here is a Create activity one server might send:
actor turned from a URI string into an inline object. to turned from a string into an array. object went the other way, from an inline object to a URI. Even the address that means “public” has three valid spellings: https://www.w3.org/ns/activitystreams#Public, as:Public, and plain Public. Your parser has to accept every combination, and which one arrives depends on the sender's implementation.
The spec-compliant answer is to normalize every document with a JSON-LD processor, expansion followed by compaction. In practice many implementations treat it all as “just JSON” and quietly break on whatever shape some server happens to emit. Either way, you end up with defensive code smeared across the whole codebase: is this a string? An array? An object? A URI I have to fetch?
Scene 3: the zombie post
A user publishes a post, spots a typo, and deletes it right away. Your server sends a Create, then a Delete. Thanks to network weather, some receiving server gets the Delete first and the Create second. It ignores the deletion of a post that doesn't exist yet, then dutifully processes the creation of a post that was already deleted. That post now lives on that server forever, while its author believes it's gone.
Then there's scale. With five thousand followers, one post means thousands of HTTP deliveries. Do that inline in the request handler and your publish button takes half a minute to respond, or the server falls over. Fine, use a queue. Deliveries fail, so retry them. On what schedule? Exponential backoff. How many times? And is a 500 Internal Server Error the same kind of failure as a 410 Gone? When do you clean up three thousand followers on a server that no longer exists? Should you keep hammering a host that has been down for days?
At some point it dawns on you that this is no longer protocol implementation. It's distributed systems engineering.
Scene 4: it's not a spec, it's an ecosystem
Even perfect spec compliance doesn't buy you interoperability. A few examples from the field:
Mastodon's secure mode requires HTTP signatures on GET requests too (so-called authorized fetch). Now suppose both servers run in that mode. To fetch the other side's public key you must sign your request; to verify your signature, the other side must first fetch your key. Deadlock. The community's workaround is to sign with an “instance actor” that represents the server itself. You won't find that in the spec.
Threads can't parse activities whose actor is embedded as an inline object. When sending to Threads, the actor has to be a URI.
Lemmy silently rejects Group actors that lack fields Mastodon never asks for, such as a moderators collection linked via attributedTo and a featured collection.
Misskey carries vocabulary extensions of its own; quote posts alone go by three different property names across implementations.
The list keeps growing. Interoperability here is not something you finish once and stop thinking about. It's maintenance, forever.
Scene 5: insecure by default
Build it from scratch, and you start out wide open. Skip signature verification on incoming activities and anyone can inject a forged Follow or Delete. Leave the document loader unrestricted and a malicious activity can point it at http://169.254.169.254/ or your internal network, turning your server into an SSRF proxy. Skip origin checks on embedded objects and any server can hand out a document claiming “here's what the Mastodon lead developer said.”
What these traps share is that nothing happens when you fall into them. Everything appears to work. Until someone exploits it.
Ghost ran into this too
If you're thinking “surely our team would manage,” consider Ghost: a leading open-source publishing platform used by thousands of journalists and creators, and a team that set out to build its own ActivityPub support.
We can definitely attest to the problems that Fedify is working hard to solve, because even in just a few weeks of early prototyping we were running into the issues described above right away.
Ghost ended up building its ActivityPub layer on Fedify.
So I put all of it in a framework
Fedify is a TypeScript library for building federated server apps on ActivityPub and the standards around it. It runs on Deno, Node.js, and Bun, and supports edge runtimes like Cloudflare Workers. The design goal hasn't changed since the beginning: keep everything in those five scenes out of application code.
Here are the same five scenes again, this time with Fedify.
Scene 1, revisited: the signature war is the framework's job
Here is everything it takes to put one actor on the fediverse:
import { createFederation, generateCryptoKeyPair, MemoryKvStore } from "@fedify/fedify";import { Endpoints, Person } from "@fedify/vocab";const federation = createFederation<void>({ kv: new MemoryKvStore(), // Swap for Redis, PostgreSQL, etc. in production});federation .setActorDispatcher("/users/{identifier}", async (ctx, identifier) => { if (identifier !== "alice") return null; const keyPairs = await ctx.getActorKeyPairs(identifier); return new Person({ id: ctx.getActorUri(identifier), preferredUsername: identifier, name: "Alice", inbox: ctx.getInboxUri(identifier), endpoints: new Endpoints({ sharedInbox: ctx.getInboxUri() }), publicKey: keyPairs[0].cryptographicKey, assertionMethods: keyPairs.map((keyPair) => keyPair.multikey), }); }) .setKeyPairsDispatcher(async (ctx, identifier) => { // In real code you'd persist these in a database; this shows the gist return [await generateCryptoKeyPair()]; });
The moment this code runs:
Every outgoing request gets signed. With an RSA key, Fedify emits HTTP Signatures and Linked Data Signatures; add an Ed25519 key and it attaches Object Integrity Proofs as well. All four mechanisms coexist on a single activity, and each receiver verifies with the strongest one it understands.
Fedify does the double-knocking for you: first contact goes out as RFC 9421, a rejection triggers a draft-cavage retry, and the winning spec is cached per server. If the rejection carries an Accept-Signature challenge (RFC 9421 §5), Fedify reads it and re-signs with exactly the components the server asked for.
One bonus. Because you registered an actor dispatcher, you now have a WebFinger (RFC 7033) server, for free. Type @alice@example.com into Mastodon's search box and your actor comes up. You never wrote a line of WebFinger code.
Scene 2, revisited: types instead of JSON-LD
Fedify ships about eighty classes covering the whole Activity Vocabulary plus the major vendor extensions. The classes are typed and immutable, and their accessors absorb the shape differences that JSON-LD allows.
const actor = await ctx.lookupObject("@hongminhee@hollo.social");if (actor instanceof Person) { console.log(actor.name); // Safe whether it's a string or langString const followers = await actor.getFollowers(); // Fetches a URI, unwraps an object}
lookupObject() takes a handle and runs the whole chain for you, WebFinger discovery included. Accessors like getFollowers()behave the same way whether the value is a URI reference or an inline object, and fetched values are cached.
Vendor fragmentation gets stitched up here too. The three competing quote properties (quoteUri, _misskey_quote, quoteUrl) are unified behind one API, next to the emerging FEP-044fquote. Misskey's isCat property exists as a type, so your server can determine cat-ness with full type safety. It sounds like a joke, but a few dozen details of exactly this kind are what interoperability is actually made of.
Scene 3, revisited: the zombie post dies in one line
Delivery infrastructure first. Plug a message queue into createFederation() and delivery moves to the background, with automatic retries under exponential backoff (up to ten attempts by default). When a post goes to thousands of followers, two-stage fan-out kicks in: a single consolidated message enters the queue, and a background worker splits it into per-server delivery tasks. The publish button responds immediately.
Retries create a problem of their own: the same activity can arrive twice. Fedify keeps a 24-hour idempotence cache of processed activities, so duplicates get detected and skipped before they reach your handlers.
As for the zombie post, the fix is one option:
await ctx.sendActivity( { identifier: "alice" }, "followers", // Collects recipients from your followers collection deleteActivity, { orderingKey: post.id }, // Same key = in-order delivery per server);
Activities that share an orderingKey are delivered to each receiving server in the order they were sent. A Delete can no longer overtake its Create. Activities with different keys still go out in parallel, so throughput survives.
Fedify also handles dead servers. On a 404 Not Found or 410 Gone, it stops retrying and calls a handler you register. If the delivery went to a shared inbox, you also get the list of followers behind it, so you can prune vanished accounts on the spot. Hosts that fail repeatedly trip a per-host circuit breaker that holds deliveries and probes periodically until the host recovers. It's on by default; there's nothing to configure.
Scene 4, revisited: we track the quirks so you don't
Here is how Fedify disarms the traps from scene 4:
Authorized fetch: chain .authorize() onto a dispatcher and the verified identity of the requester lands in your callback. Blocklists, private collections, whatever your app needs is plain application logic. The instance-actor deadlock has a supported pattern as well.
Threads and inline actors: an activity transformer, enabled by default, rewrites inline actors into URIs on the way out. You don't need to know Threads has this problem.
Lemmy's requirements: the custom collection API exposes a moderators collection in a few lines, and Lemmy's JSON-LD context ships preloaded.
When a new quirk surfaces in the wild, the fix lands in Fedify, not in every application separately. Each interoperability lesson gets learned once.
Scene 5, revisited: becoming unsafe takes effort
Fedify's defaults point the other way.
Signature verification is something you turn off (for tests), not something you remember to turn on.
The document loader refuses private address ranges and loopback out of the box, with DNS rebinding accounted for. To open yourself up to SSRF you have to flip an option whose very name announces it's for testing.
In a from-scratch implementation, you have to keep remembering to do things safely. In Fedify, the unsafe path is the one that takes deliberate effort. For a federated server, with its tangle of trust boundaries, that's the right way around.
Your stack stays your stack
“Fine, but what if it doesn't fit our stack?” Fedify was built to fit the stack you already have. There are thirteen web framework integrations: servers like Express, Hono, Fastify, Koa, NestJS, and Elysia, and meta-frameworks like Next.js, Nuxt, SvelteKit, Astro, SolidStart, and Fresh. Middleware handles content negotiation, so the same URL in your existing app serves HTML to browsers and JSON-LD to the fediverse.
Fedify doesn't dictate your database either. For its own storage it asks for one key–value interface, with seven adapters available (Redis, PostgreSQL, MySQL/MariaDB, SQLite, Deno KV, Cloudflare Workers KV, in-memory). Message queues come in eight flavors (PostgreSQL, Redis, AMQP/RabbitMQ, and so on), and you can implement the interface yourself if none fits. Your domain data stays in whatever database and ORM you already use.
Already running federation on another library? There are migration guides with data migration scripts for moving from activitypub-express and friends without losing your existing followers.
The core isn't the ceiling, either. Higher-level packages build on it: @fedify/relay gives you a complete ActivityPub relay server in a single function call, and @fedify/backfill reconstructs incomplete conversation threads by walking the rest of the fediverse for you.
Tools for the whole development loop
A quieter misery of federated development has always been the missing tooling. Fedify comes with tools for every stage of the loop.
fedify init scaffolds a project in one line, and fedify tunnel exposes your local server over HTTPS so you can test against real Mastodon. Activities your server sends can be received by fedify inbox, a disposable inbox server spun up on the spot; whatever other servers publish, you can inspect with fedify lookup. My personal favorite is fedify lookup --authorized-fetch, which generates a one-off key pair and stands up a temporary ActivityPub server just to make a signed request for an object behind secure mode. The CLI is also useful to ActivityPub developers who don't use Fedify at all.
While you write code, an ActivityPub-specific linter (@fedify/lint) catches twenty kinds of interoperability bugs, like an actor missing its inbox. Tests run without the network using mocks from @fedify/testing. Once the server is up, attach the debug dashboard (@fedify/debugger) with one line and watch activities and signature verification results in your browser, live. In production there's built-in OpenTelemetry instrumentation (28 span types, 37 metrics) plus a monitoring guide, and when performance matters, fedify bench, a load-testing tool built for ActivityPub, catches regressions in CI.
As far as I know, no other ActivityPub framework ships even one of the tools in this section.
The documentation is part of the tooling. The official docs run to a thirty-chapter manual and five tutorials, and they go well past API listings. There's an operations chapter with ready-made PromQL queries and alerting rules for watching your queue backlog, and a field-guide chapter that documents de facto conventions, like which property makes your avatar show up in Mastodon, with screenshots. At two in the morning, when federation is broken and you don't know why, this is the difference between a bad night and a short one.
It's already running
Fedify is not a thought experiment. Ghost's ActivityPub service, mentioned above, is built on it. So are Encyclia, which bridges ORCID researcher records into the fediverse; SiliconBeest, running serverless on Cloudflare Workers; Typo Blue, a Korean blogging platform; Hollo, my own single-user microblogging platform; and Hackers' Pub, run by its community. Hollo, by the way, is the app from the beginning of this post: the project I once had to shelve, finished at last on the framework it forced into existence.
I didn't build Fedify to mint more ActivityPub experts. Rather the opposite. I believe the fediverse will only grow beyond microblogging when developers can build federated apps without knowing ActivityPub's fine print. Signature spec transitions and JSON-LD compaction are problems that belong inside a framework, not barriers in front of someone with a new idea.
Starting takes one line:
npm init @fedify
Follow the first tutorial and by the end, Mastodon can find your server. If you get stuck, come find us in the Matrix room or GitHub Discussions. See you in the fediverse.
Picture the moment your server sends its first Follow activity to Mastodon. You read the spec, built the JSON, signed the HTTP request, and POSTed it with care. What comes back is a single line: 401 Unauthorized. No body. No explanation.
What went wrong? Maybe the clock behind your Date header drifted a few minutes. Maybe the hash in your Digest header is off. Maybe you uppercased the (request-target) pseudo-header while building the signing string, or published your public key as PEM where the other side wanted multibase. The remote server won't tell you. So you start reading someone else's server code to debug your own.
I know, because I've been there. Fedify began as a casualty of another project. I set out to build a single-user microblogging server, the one that would later become Hollo, and started implementing ActivityPub from scratch. Somewhere between the signature specs and the JSON-LD, the protocol work swallowed the product, and I put the whole thing down. What I picked back up wasn't the app. It was the framework the app should have had. Fedify shipped first; only then could Hollo exist, built on top of it. (I've told this story at more length in A year with the fediverse.)
ActivityPub development gets hard in a few very specific places. In this post I want to walk through five of them, then show what each one looks like with Fedify. If you've spent time in the fediverse, you'll probably nod along. If you haven't, you may wonder why anyone would do all of this by hand. Either way, the conclusion is the same: nobody has to anymore.
Five scenes
Scene 1: there is more than one standard
ActivityPub servers authenticate each other with HTTP signatures. Except there isn't one signature spec. Most of the fediverse runs on draft-cavage-http-signatures-12, an expired draft that never became a standard. The actual standard exists too: RFC 9421, HTTP Message Signatures. The problem is that you can't know which one a given server accepts until you try.
A real-world implementation therefore has to sign with one spec, see whether it gets rejected, re-sign with the other, and remember per server which one worked so it can skip the dance next time. The fediverse calls this double-knocking. Yes, you get to implement it yourself.
That's still not the end. HTTP signatures only prove who sent a request. For situations like inbox forwarding, where you relay an activity you received to a third party, you need signatures that live on the document itself: Linked Data Signatures and Object Integrity Proofs. Four signature mechanisms in total, and two kinds of keys to manage: RSA and Ed25519.
Scene 2: one document, many shapes
ActivityPub's wire format is JSON-LD, and in JSON-LD the same document can take many shapes. This is easier to show than to explain. Here is a Create activity one server might send:
actor turned from a URI string into an inline object. to turned from a string into an array. object went the other way, from an inline object to a URI. Even the address that means “public” has three valid spellings: https://www.w3.org/ns/activitystreams#Public, as:Public, and plain Public. Your parser has to accept every combination, and which one arrives depends on the sender's implementation.
The spec-compliant answer is to normalize every document with a JSON-LD processor, expansion followed by compaction. In practice many implementations treat it all as “just JSON” and quietly break on whatever shape some server happens to emit. Either way, you end up with defensive code smeared across the whole codebase: is this a string? An array? An object? A URI I have to fetch?
Scene 3: the zombie post
A user publishes a post, spots a typo, and deletes it right away. Your server sends a Create, then a Delete. Thanks to network weather, some receiving server gets the Delete first and the Create second. It ignores the deletion of a post that doesn't exist yet, then dutifully processes the creation of a post that was already deleted. That post now lives on that server forever, while its author believes it's gone.
Then there's scale. With five thousand followers, one post means thousands of HTTP deliveries. Do that inline in the request handler and your publish button takes half a minute to respond, or the server falls over. Fine, use a queue. Deliveries fail, so retry them. On what schedule? Exponential backoff. How many times? And is a 500 Internal Server Error the same kind of failure as a 410 Gone? When do you clean up three thousand followers on a server that no longer exists? Should you keep hammering a host that has been down for days?
At some point it dawns on you that this is no longer protocol implementation. It's distributed systems engineering.
Scene 4: it's not a spec, it's an ecosystem
Even perfect spec compliance doesn't buy you interoperability. A few examples from the field:
Mastodon's secure mode requires HTTP signatures on GET requests too (so-called authorized fetch). Now suppose both servers run in that mode. To fetch the other side's public key you must sign your request; to verify your signature, the other side must first fetch your key. Deadlock. The community's workaround is to sign with an “instance actor” that represents the server itself. You won't find that in the spec.
Threads can't parse activities whose actor is embedded as an inline object. When sending to Threads, the actor has to be a URI.
Lemmy silently rejects Group actors that lack fields Mastodon never asks for, such as a moderators collection linked via attributedTo and a featured collection.
Misskey carries vocabulary extensions of its own; quote posts alone go by three different property names across implementations.
The list keeps growing. Interoperability here is not something you finish once and stop thinking about. It's maintenance, forever.
Scene 5: insecure by default
Build it from scratch, and you start out wide open. Skip signature verification on incoming activities and anyone can inject a forged Follow or Delete. Leave the document loader unrestricted and a malicious activity can point it at http://169.254.169.254/ or your internal network, turning your server into an SSRF proxy. Skip origin checks on embedded objects and any server can hand out a document claiming “here's what the Mastodon lead developer said.”
What these traps share is that nothing happens when you fall into them. Everything appears to work. Until someone exploits it.
Ghost ran into this too
If you're thinking “surely our team would manage,” consider Ghost: a leading open-source publishing platform used by thousands of journalists and creators, and a team that set out to build its own ActivityPub support.
We can definitely attest to the problems that Fedify is working hard to solve, because even in just a few weeks of early prototyping we were running into the issues described above right away.
Ghost ended up building its ActivityPub layer on Fedify.
So I put all of it in a framework
Fedify is a TypeScript library for building federated server apps on ActivityPub and the standards around it. It runs on Deno, Node.js, and Bun, and supports edge runtimes like Cloudflare Workers. The design goal hasn't changed since the beginning: keep everything in those five scenes out of application code.
Here are the same five scenes again, this time with Fedify.
Scene 1, revisited: the signature war is the framework's job
Here is everything it takes to put one actor on the fediverse:
import { createFederation, generateCryptoKeyPair, MemoryKvStore } from "@fedify/fedify";import { Endpoints, Person } from "@fedify/vocab";const federation = createFederation<void>({ kv: new MemoryKvStore(), // Swap for Redis, PostgreSQL, etc. in production});federation .setActorDispatcher("/users/{identifier}", async (ctx, identifier) => { if (identifier !== "alice") return null; const keyPairs = await ctx.getActorKeyPairs(identifier); return new Person({ id: ctx.getActorUri(identifier), preferredUsername: identifier, name: "Alice", inbox: ctx.getInboxUri(identifier), endpoints: new Endpoints({ sharedInbox: ctx.getInboxUri() }), publicKey: keyPairs[0].cryptographicKey, assertionMethods: keyPairs.map((keyPair) => keyPair.multikey), }); }) .setKeyPairsDispatcher(async (ctx, identifier) => { // In real code you'd persist these in a database; this shows the gist return [await generateCryptoKeyPair()]; });
The moment this code runs:
Every outgoing request gets signed. With an RSA key, Fedify emits HTTP Signatures and Linked Data Signatures; add an Ed25519 key and it attaches Object Integrity Proofs as well. All four mechanisms coexist on a single activity, and each receiver verifies with the strongest one it understands.
Fedify does the double-knocking for you: first contact goes out as RFC 9421, a rejection triggers a draft-cavage retry, and the winning spec is cached per server. If the rejection carries an Accept-Signature challenge (RFC 9421 §5), Fedify reads it and re-signs with exactly the components the server asked for.
One bonus. Because you registered an actor dispatcher, you now have a WebFinger (RFC 7033) server, for free. Type @alice@example.com into Mastodon's search box and your actor comes up. You never wrote a line of WebFinger code.
Scene 2, revisited: types instead of JSON-LD
Fedify ships about eighty classes covering the whole Activity Vocabulary plus the major vendor extensions. The classes are typed and immutable, and their accessors absorb the shape differences that JSON-LD allows.
const actor = await ctx.lookupObject("@hongminhee@hollo.social");if (actor instanceof Person) { console.log(actor.name); // Safe whether it's a string or langString const followers = await actor.getFollowers(); // Fetches a URI, unwraps an object}
lookupObject() takes a handle and runs the whole chain for you, WebFinger discovery included. Accessors like getFollowers()behave the same way whether the value is a URI reference or an inline object, and fetched values are cached.
Vendor fragmentation gets stitched up here too. The three competing quote properties (quoteUri, _misskey_quote, quoteUrl) are unified behind one API, next to the emerging FEP-044fquote. Misskey's isCat property exists as a type, so your server can determine cat-ness with full type safety. It sounds like a joke, but a few dozen details of exactly this kind are what interoperability is actually made of.
Scene 3, revisited: the zombie post dies in one line
Delivery infrastructure first. Plug a message queue into createFederation() and delivery moves to the background, with automatic retries under exponential backoff (up to ten attempts by default). When a post goes to thousands of followers, two-stage fan-out kicks in: a single consolidated message enters the queue, and a background worker splits it into per-server delivery tasks. The publish button responds immediately.
Retries create a problem of their own: the same activity can arrive twice. Fedify keeps a 24-hour idempotence cache of processed activities, so duplicates get detected and skipped before they reach your handlers.
As for the zombie post, the fix is one option:
await ctx.sendActivity( { identifier: "alice" }, "followers", // Collects recipients from your followers collection deleteActivity, { orderingKey: post.id }, // Same key = in-order delivery per server);
Activities that share an orderingKey are delivered to each receiving server in the order they were sent. A Delete can no longer overtake its Create. Activities with different keys still go out in parallel, so throughput survives.
Fedify also handles dead servers. On a 404 Not Found or 410 Gone, it stops retrying and calls a handler you register. If the delivery went to a shared inbox, you also get the list of followers behind it, so you can prune vanished accounts on the spot. Hosts that fail repeatedly trip a per-host circuit breaker that holds deliveries and probes periodically until the host recovers. It's on by default; there's nothing to configure.
Scene 4, revisited: we track the quirks so you don't
Here is how Fedify disarms the traps from scene 4:
Authorized fetch: chain .authorize() onto a dispatcher and the verified identity of the requester lands in your callback. Blocklists, private collections, whatever your app needs is plain application logic. The instance-actor deadlock has a supported pattern as well.
Threads and inline actors: an activity transformer, enabled by default, rewrites inline actors into URIs on the way out. You don't need to know Threads has this problem.
Lemmy's requirements: the custom collection API exposes a moderators collection in a few lines, and Lemmy's JSON-LD context ships preloaded.
When a new quirk surfaces in the wild, the fix lands in Fedify, not in every application separately. Each interoperability lesson gets learned once.
Scene 5, revisited: becoming unsafe takes effort
Fedify's defaults point the other way.
Signature verification is something you turn off (for tests), not something you remember to turn on.
The document loader refuses private address ranges and loopback out of the box, with DNS rebinding accounted for. To open yourself up to SSRF you have to flip an option whose very name announces it's for testing.
In a from-scratch implementation, you have to keep remembering to do things safely. In Fedify, the unsafe path is the one that takes deliberate effort. For a federated server, with its tangle of trust boundaries, that's the right way around.
Your stack stays your stack
“Fine, but what if it doesn't fit our stack?” Fedify was built to fit the stack you already have. There are thirteen web framework integrations: servers like Express, Hono, Fastify, Koa, NestJS, and Elysia, and meta-frameworks like Next.js, Nuxt, SvelteKit, Astro, SolidStart, and Fresh. Middleware handles content negotiation, so the same URL in your existing app serves HTML to browsers and JSON-LD to the fediverse.
Fedify doesn't dictate your database either. For its own storage it asks for one key–value interface, with seven adapters available (Redis, PostgreSQL, MySQL/MariaDB, SQLite, Deno KV, Cloudflare Workers KV, in-memory). Message queues come in eight flavors (PostgreSQL, Redis, AMQP/RabbitMQ, and so on), and you can implement the interface yourself if none fits. Your domain data stays in whatever database and ORM you already use.
Already running federation on another library? There are migration guides with data migration scripts for moving from activitypub-express and friends without losing your existing followers.
The core isn't the ceiling, either. Higher-level packages build on it: @fedify/relay gives you a complete ActivityPub relay server in a single function call, and @fedify/backfill reconstructs incomplete conversation threads by walking the rest of the fediverse for you.
Tools for the whole development loop
A quieter misery of federated development has always been the missing tooling. Fedify comes with tools for every stage of the loop.
fedify init scaffolds a project in one line, and fedify tunnel exposes your local server over HTTPS so you can test against real Mastodon. Activities your server sends can be received by fedify inbox, a disposable inbox server spun up on the spot; whatever other servers publish, you can inspect with fedify lookup. My personal favorite is fedify lookup --authorized-fetch, which generates a one-off key pair and stands up a temporary ActivityPub server just to make a signed request for an object behind secure mode. The CLI is also useful to ActivityPub developers who don't use Fedify at all.
While you write code, an ActivityPub-specific linter (@fedify/lint) catches twenty kinds of interoperability bugs, like an actor missing its inbox. Tests run without the network using mocks from @fedify/testing. Once the server is up, attach the debug dashboard (@fedify/debugger) with one line and watch activities and signature verification results in your browser, live. In production there's built-in OpenTelemetry instrumentation (28 span types, 37 metrics) plus a monitoring guide, and when performance matters, fedify bench, a load-testing tool built for ActivityPub, catches regressions in CI.
As far as I know, no other ActivityPub framework ships even one of the tools in this section.
The documentation is part of the tooling. The official docs run to a thirty-chapter manual and five tutorials, and they go well past API listings. There's an operations chapter with ready-made PromQL queries and alerting rules for watching your queue backlog, and a field-guide chapter that documents de facto conventions, like which property makes your avatar show up in Mastodon, with screenshots. At two in the morning, when federation is broken and you don't know why, this is the difference between a bad night and a short one.
It's already running
Fedify is not a thought experiment. Ghost's ActivityPub service, mentioned above, is built on it. So are Encyclia, which bridges ORCID researcher records into the fediverse; SiliconBeest, running serverless on Cloudflare Workers; Typo Blue, a Korean blogging platform; Hollo, my own single-user microblogging platform; and Hackers' Pub, run by its community. Hollo, by the way, is the app from the beginning of this post: the project I once had to shelve, finished at last on the framework it forced into existence.
I didn't build Fedify to mint more ActivityPub experts. Rather the opposite. I believe the fediverse will only grow beyond microblogging when developers can build federated apps without knowing ActivityPub's fine print. Signature spec transitions and JSON-LD compaction are problems that belong inside a framework, not barriers in front of someone with a new idea.
Starting takes one line:
npm init @fedify
Follow the first tutorial and by the end, Mastodon can find your server. If you get stuck, come find us in the Matrix room or GitHub Discussions. See you in the fediverse.
Please give them a warm welcome to Mastodon and to the fediverse, follow their accounts, and donate to their fundraisers if you can (and please share this so others can do the same).
Also, remember that you can find all our families who have fundraisers listed at the following page, ordered by those who have received the least in donations over the last week (on a rolling basis):
Langsam passt der Name nicht mehr ganz, aber die Mastodon Listen haben eine Reihe neuer Listen, und zwar für Peertube. \o/ Danke an @neuSoM für den Hinweis und @reclus für das Einpflegen der ersten Einträge in Wikidata.
Laut Wikidata gibt es noch gar keine Einträge für Kanäle von öffentlichen Einrichtungen in Österreich und der Schweiz?
Wie immer gilt, schaut euch gerne die Listen an und folgt den Accounts (das könnt ihr auch von z.B. Mastodon) und wenn ihr noch mehr kennt, tragt das gerne in Wikidata ein oder schreibt hier einmal kurz.
Hoe behouden we de regie op onze data en systemen? Tijdens het congres van Forum Standaardisatie 20 jaar - Standaarden, openheid en autonomie (21 sept) gaan we de diepte in. We bespreken de moderne soevereine werkplek, #Fediverse-adoptie via social.overheid.nl, het doorbreken van vendor lock-in en de impact van de #AIAct en #NIS2 op onze infra.
Een dag vol concrete lessen, scherpe discussies en nieuwe inzichten over digitale autonomie en open standaarden.
Im aktuellen Wirtschafts-Talk Podcast der Welt wurde auf meine Analyse zur KI-Blase eingegangen und der Host forderte, ich solle doch einfach mal Fakten liefern.
안녕하세요.
그간 실리콘 숲이나 다른 서버에서 만난 분도, 새롭게 인사드리는 분도 잘 부탁드립니다.
본 계정은 다소 담담하게, 블로그보다는 짧고 소셜 미디어보다는 긴 글을 쓸 목적으로 사용하고자 합니다.
그 시작으로 이 글을 첫 돌로 놓아 둡니다.
주소 표시줄을 관심 있게 보시는 분들이라면 주소는 starting-my-seventh-fediverse-account 인데
어째서 한국어 제목은 통산 아홉 번째인가. 하실지도 모르겠습니다.
이는 제가 총 아홉 개의 연합우주 계정을 만들었고,
그 중 두 개의 서버가 문을 닫아 일곱 개가 남았기 때문입니다.
어째서 이렇게나 많은 계정을 만들게 된 것일까요?
이 사람은 소셜 미디어 계정을 서비스 별로 모으는 취미라도 있는 걸까요?
네, 예전에는 비슷한 취미를 가지고 있었습니다.
하지만 10년이면 강산이 변한다고, 10년은 커녕 1년을 넘기는 서비스도 찾기 어려운 시대에
조금은 허무한 마음이 들어 지금은 더 모으지 않고 있습니다.
여기에 대해 자세히 설명하기 시작하면, 저의 10934번째 블로그가 되어 버리고
또 별안간 제 쓰임을 찾지 못한 채 장식장에 고이 모셔진 펄기아 피규어처럼 장식이 될테니 조금 짧게 연합우주 이야기 위주로 하려 합니다.
저는 무슨 대안, 게 섰거라. 이런 걸 좋아합니다.
삼성 갤럭시, 애플 아이폰 게 섰거라. LG G 시리즈 나가신다. 스마트폰 사업을 손 털고 나갔지만요.
아니 그게 아니라, 저는 미친 세상으로 갑니다. 이것도 아닌데. 아무튼 네이버가 미투데이를 접고 남은 자리에 만들어 진 미소일기를 종종 안부 인사하듯 들러 왔습니다.
그렇지만 운영진의 사비와 자비로 운영되는 작고 아늑한 공간이 언제까지나 튼튼하기란 어려운 법입니다.
미소일기가 조용히 사라지고 문득, 트잉여가 생각났습니다.
그때는 서비스하고 있었고, 아직 잠깐의 트위터 대안 찾기 붐이 일기 전이었어요.
별다른 흐름도 없이 돌연 뉴비다 뉴비, 입맞에 잘 맞네요!
지금은 찾기 힘든 그런 분위기 속에 천천히 적응하다 1년 5개월이 지나 너무 많은 파일 업로드를 하는 것 같아
의도치 않게 베짱이처럼 놀고 있던 도메인 위에 감자를 올려 연결하기, 아니 와플 토핑하기, 도 아니고 작고 소중한 서버를 시작했습니다.
그러다 보니 또 제 마음에 안 드는 부분을 여기저기 고치고,
혹시 저어기서 넘어오는 이야기가 제겐 잘 전달이 안 될까 싶어 몇 개 더 계정을 만들거나
관리 공지용 계정을 몇 개 만들다 보니 어느새 아홉 번을 만들게 되었고, 아홉 번째가 바로 이 고양이가 귀여운 해커들의 술집입니다.
늘 눈독 들이면서도 주저했지만, Fedify 오픈소스 컨트리뷰션 아카데미 참여를 계기로 정착에 도전해 봅니다.
앞으로 이 계정에서도 종종 뵙게 될 예정입니다.
조금 긴 글을 쓰는 만큼 자주 나타나지는 않을 예정이지만, 애정을 붙여 작게나마 가꿔 나가 보겠습니다.
아직 프로필 사진 원본을 잃어버린 채 찾지 못해 완전한 설정까지는 시간이 좀 걸리겠지만, 다시 한 번 잘 부탁드립니다.
Using a back-of-the-envelope calculation, what the #fediverse calls "normies" are 99.8% of the population. In a normal distribution, being here is a statistically notable 3-sigma event🤣
Its not the case that #mastodon (or #bluesky) are "dying", but in terms of actual impact: changing the online experience for the *vast* majority of people, its obviously zilch - as has always been
Yet maintaining faith in these proof-of-concept projects feels important. Its like protecting biodiversity🐘
This image is a memorial graphic dedicated to Yurie Joy T. Bueno, featuring a stylized purple butterfly on a black background.The text indicates the subject was born on October 12, 1995, and passed away on June 22, 2026.The design includes white floral illustrations in the corners and a concluding message thanking them for their kindness.
안녕하세요.
그간 실리콘 숲이나 다른 서버에서 만난 분도, 새롭게 인사드리는 분도 잘 부탁드립니다.
본 계정은 다소 담담하게, 블로그보다는 짧고 소셜 미디어보다는 긴 글을 쓸 목적으로 사용하고자 합니다.
그 시작으로 이 글을 첫 돌로 놓아 둡니다.
주소 표시줄을 관심 있게 보시는 분들이라면 주소는 starting-my-seventh-fediverse-account 인데
어째서 한국어 제목은 통산 아홉 번째인가. 하실지도 모르겠습니다.
이는 제가 총 아홉 개의 연합우주 계정을 만들었고,
그 중 두 개의 서버가 문을 닫아 일곱 개가 남았기 때문입니다.
어째서 이렇게나 많은 계정을 만들게 된 것일까요?
이 사람은 소셜 미디어 계정을 서비스 별로 모으는 취미라도 있는 걸까요?
네, 예전에는 비슷한 취미를 가지고 있었습니다.
하지만 10년이면 강산이 변한다고, 10년은 커녕 1년을 넘기는 서비스도 찾기 어려운 시대에
조금은 허무한 마음이 들어 지금은 더 모으지 않고 있습니다.
여기에 대해 자세히 설명하기 시작하면, 저의 10934번째 블로그가 되어 버리고
또 별안간 제 쓰임을 찾지 못한 채 장식장에 고이 모셔진 펄기아 피규어처럼 장식이 될테니 조금 짧게 연합우주 이야기 위주로 하려 합니다.
저는 무슨 대안, 게 섰거라. 이런 걸 좋아합니다.
삼성 갤럭시, 애플 아이폰 게 섰거라. LG G 시리즈 나가신다. 스마트폰 사업을 손 털고 나갔지만요.
아니 그게 아니라, 저는 미친 세상으로 갑니다. 이것도 아닌데. 아무튼 네이버가 미투데이를 접고 남은 자리에 만들어 진 미소일기를 종종 안부 인사하듯 들러 왔습니다.
그렇지만 운영진의 사비와 자비로 운영되는 작고 아늑한 공간이 언제까지나 튼튼하기란 어려운 법입니다.
미소일기가 조용히 사라지고 문득, 트잉여가 생각났습니다.
그때는 서비스하고 있었고, 아직 잠깐의 트위터 대안 찾기 붐이 일기 전이었어요.
별다른 흐름도 없이 돌연 뉴비다 뉴비, 입맞에 잘 맞네요!
지금은 찾기 힘든 그런 분위기 속에 천천히 적응하다 1년 5개월이 지나 너무 많은 파일 업로드를 하는 것 같아
의도치 않게 베짱이처럼 놀고 있던 도메인 위에 감자를 올려 연결하기, 아니 와플 토핑하기, 도 아니고 작고 소중한 서버를 시작했습니다.
그러다 보니 또 제 마음에 안 드는 부분을 여기저기 고치고,
혹시 저어기서 넘어오는 이야기가 제겐 잘 전달이 안 될까 싶어 몇 개 더 계정을 만들거나
관리 공지용 계정을 몇 개 만들다 보니 어느새 아홉 번을 만들게 되었고, 아홉 번째가 바로 이 고양이가 귀여운 해커들의 술집입니다.
늘 눈독 들이면서도 주저했지만, Fedify 오픈소스 컨트리뷰션 아카데미 참여를 계기로 정착에 도전해 봅니다.
앞으로 이 계정에서도 종종 뵙게 될 예정입니다.
조금 긴 글을 쓰는 만큼 자주 나타나지는 않을 예정이지만, 애정을 붙여 작게나마 가꿔 나가 보겠습니다.
아직 프로필 사진 원본을 잃어버린 채 찾지 못해 완전한 설정까지는 시간이 좀 걸리겠지만, 다시 한 번 잘 부탁드립니다.
안녕하세요.
그간 실리콘 숲이나 다른 서버에서 만난 분도, 새롭게 인사드리는 분도 잘 부탁드립니다.
본 계정은 다소 담담하게, 블로그보다는 짧고 소셜 미디어보다는 긴 글을 쓸 목적으로 사용하고자 합니다.
그 시작으로 이 글을 첫 돌로 놓아 둡니다.
주소 표시줄을 관심 있게 보시는 분들이라면 주소는 starting-my-seventh-fediverse-account 인데
어째서 한국어 제목은 통산 아홉 번째인가. 하실지도 모르겠습니다.
이는 제가 총 아홉 개의 연합우주 계정을 만들었고,
그 중 두 개의 서버가 문을 닫아 일곱 개가 남았기 때문입니다.
어째서 이렇게나 많은 계정을 만들게 된 것일까요?
이 사람은 소셜 미디어 계정을 서비스 별로 모으는 취미라도 있는 걸까요?
네, 예전에는 비슷한 취미를 가지고 있었습니다.
하지만 10년이면 강산이 변한다고, 10년은 커녕 1년을 넘기는 서비스도 찾기 어려운 시대에
조금은 허무한 마음이 들어 지금은 더 모으지 않고 있습니다.
여기에 대해 자세히 설명하기 시작하면, 저의 10934번째 블로그가 되어 버리고
또 별안간 제 쓰임을 찾지 못한 채 장식장에 고이 모셔진 펄기아 피규어처럼 장식이 될테니 조금 짧게 연합우주 이야기 위주로 하려 합니다.
저는 무슨 대안, 게 섰거라. 이런 걸 좋아합니다.
삼성 갤럭시, 애플 아이폰 게 섰거라. LG G 시리즈 나가신다. 스마트폰 사업을 손 털고 나갔지만요.
아니 그게 아니라, 저는 미친 세상으로 갑니다. 이것도 아닌데. 아무튼 네이버가 미투데이를 접고 남은 자리에 만들어 진 미소일기를 종종 안부 인사하듯 들러 왔습니다.
그렇지만 운영진의 사비와 자비로 운영되는 작고 아늑한 공간이 언제까지나 튼튼하기란 어려운 법입니다.
미소일기가 조용히 사라지고 문득, 트잉여가 생각났습니다.
그때는 서비스하고 있었고, 아직 잠깐의 트위터 대안 찾기 붐이 일기 전이었어요.
별다른 흐름도 없이 돌연 뉴비다 뉴비, 입맞에 잘 맞네요!
지금은 찾기 힘든 그런 분위기 속에 천천히 적응하다 1년 5개월이 지나 너무 많은 파일 업로드를 하는 것 같아
의도치 않게 베짱이처럼 놀고 있던 도메인 위에 감자를 올려 연결하기, 아니 와플 토핑하기, 도 아니고 작고 소중한 서버를 시작했습니다.
그러다 보니 또 제 마음에 안 드는 부분을 여기저기 고치고,
혹시 저어기서 넘어오는 이야기가 제겐 잘 전달이 안 될까 싶어 몇 개 더 계정을 만들거나
관리 공지용 계정을 몇 개 만들다 보니 어느새 아홉 번을 만들게 되었고, 아홉 번째가 바로 이 고양이가 귀여운 해커들의 술집입니다.
늘 눈독 들이면서도 주저했지만, Fedify 오픈소스 컨트리뷰션 아카데미 참여를 계기로 정착에 도전해 봅니다.
앞으로 이 계정에서도 종종 뵙게 될 예정입니다.
조금 긴 글을 쓰는 만큼 자주 나타나지는 않을 예정이지만, 애정을 붙여 작게나마 가꿔 나가 보겠습니다.
아직 프로필 사진 원본을 잃어버린 채 찾지 못해 완전한 설정까지는 시간이 좀 걸리겠지만, 다시 한 번 잘 부탁드립니다.
안녕하세요.
그간 실리콘 숲이나 다른 서버에서 만난 분도, 새롭게 인사드리는 분도 잘 부탁드립니다.
본 계정은 다소 담담하게, 블로그보다는 짧고 소셜 미디어보다는 긴 글을 쓸 목적으로 사용하고자 합니다.
그 시작으로 이 글을 첫 돌로 놓아 둡니다.
주소 표시줄을 관심 있게 보시는 분들이라면 주소는 starting-my-seventh-fediverse-account 인데
어째서 한국어 제목은 통산 아홉 번째인가. 하실지도 모르겠습니다.
이는 제가 총 아홉 개의 연합우주 계정을 만들었고,
그 중 두 개의 서버가 문을 닫아 일곱 개가 남았기 때문입니다.
어째서 이렇게나 많은 계정을 만들게 된 것일까요?
이 사람은 소셜 미디어 계정을 서비스 별로 모으는 취미라도 있는 걸까요?
네, 예전에는 비슷한 취미를 가지고 있었습니다.
하지만 10년이면 강산이 변한다고, 10년은 커녕 1년을 넘기는 서비스도 찾기 어려운 시대에
조금은 허무한 마음이 들어 지금은 더 모으지 않고 있습니다.
여기에 대해 자세히 설명하기 시작하면, 저의 10934번째 블로그가 되어 버리고
또 별안간 제 쓰임을 찾지 못한 채 장식장에 고이 모셔진 펄기아 피규어처럼 장식이 될테니 조금 짧게 연합우주 이야기 위주로 하려 합니다.
저는 무슨 대안, 게 섰거라. 이런 걸 좋아합니다.
삼성 갤럭시, 애플 아이폰 게 섰거라. LG G 시리즈 나가신다. 스마트폰 사업을 손 털고 나갔지만요.
아니 그게 아니라, 저는 미친 세상으로 갑니다. 이것도 아닌데. 아무튼 네이버가 미투데이를 접고 남은 자리에 만들어 진 미소일기를 종종 안부 인사하듯 들러 왔습니다.
그렇지만 운영진의 사비와 자비로 운영되는 작고 아늑한 공간이 언제까지나 튼튼하기란 어려운 법입니다.
미소일기가 조용히 사라지고 문득, 트잉여가 생각났습니다.
그때는 서비스하고 있었고, 아직 잠깐의 트위터 대안 찾기 붐이 일기 전이었어요.
별다른 흐름도 없이 돌연 뉴비다 뉴비, 입맞에 잘 맞네요!
지금은 찾기 힘든 그런 분위기 속에 천천히 적응하다 1년 5개월이 지나 너무 많은 파일 업로드를 하는 것 같아
의도치 않게 베짱이처럼 놀고 있던 도메인 위에 감자를 올려 연결하기, 아니 와플 토핑하기, 도 아니고 작고 소중한 서버를 시작했습니다.
그러다 보니 또 제 마음에 안 드는 부분을 여기저기 고치고,
혹시 저어기서 넘어오는 이야기가 제겐 잘 전달이 안 될까 싶어 몇 개 더 계정을 만들거나
관리 공지용 계정을 몇 개 만들다 보니 어느새 아홉 번을 만들게 되었고, 아홉 번째가 바로 이 고양이가 귀여운 해커들의 술집입니다.
늘 눈독 들이면서도 주저했지만, Fedify 오픈소스 컨트리뷰션 아카데미 참여를 계기로 정착에 도전해 봅니다.
앞으로 이 계정에서도 종종 뵙게 될 예정입니다.
조금 긴 글을 쓰는 만큼 자주 나타나지는 않을 예정이지만, 애정을 붙여 작게나마 가꿔 나가 보겠습니다.
아직 프로필 사진 원본을 잃어버린 채 찾지 못해 완전한 설정까지는 시간이 좀 걸리겠지만, 다시 한 번 잘 부탁드립니다.
Support FEP-2c59: Discovery of a Webfinger address from an ActivityPub actor.
Support ActivityPub Update activities for actor profile changes.
Fixed
Disambiguate reblog IDs from status IDs. (fixes #151)
Correct the quote_policy mapping to public/nobody values.
Ignore malformed pagination parameters instead of raising.
Treat "cannot be reconnected" errors as connection failures.
Infer a media attachment's type when mediaType is missing.
Faster, case-insensitive, actor username lookups.
Faster statuses_count using an approximate count.
Changed
Resolve JSON-LD contexts by matching their digest against a bundled copy.
The first version of algorithmic feeds won't be very algorithmic—it will let you create a feed that filters by keywords, hashtags, and mentions. That covers a lot of ground for me personally, and lays the groundwork for future enhancements.
Support FEP-2c59: Discovery of a Webfinger address from an ActivityPub actor.
Support ActivityPub Update activities for actor profile changes.
Fixed
Disambiguate reblog IDs from status IDs. (fixes #151)
Correct the quote_policy mapping to public/nobody values.
Ignore malformed pagination parameters instead of raising.
Treat "cannot be reconnected" errors as connection failures.
Infer a media attachment's type when mediaType is missing.
Faster, case-insensitive, actor username lookups.
Faster statuses_count using an approximate count.
Changed
Resolve JSON-LD contexts by matching their digest against a bundled copy.
The first version of algorithmic feeds won't be very algorithmic—it will let you create a feed that filters by keywords, hashtags, and mentions. That covers a lot of ground for me personally, and lays the groundwork for future enhancements.
Vor wenigen Tagen besuchte ich wieder einmal OpenOS.at – eine Webseite, die ich seit vielen Jahren immer wieder gern genutzt habe. Statt der gewohnten Startseite erschien jedoch nur noch ein kurzer Hinweis:
„Diese Webpräsenz wurde am 26. Juni 2026 (nach 12 Jahren Betrieb) eingestellt.“
Damit endet nach zwölf Jahren ein Projekt, das für viele Linux- und BSD-Interessierte eine feste Anlaufstelle war.
Das erste Bild zeigt die frühere Startseite von OpenOS.at – mit aktuellen Distributionen, Nachrichten, Statistiken und Veranstaltungen aus der Welt freier Betriebssysteme. Das zweite Bild zeigt, was heute davon übrig geblieben ist.
Warum OpenOS eingestellt wurde, wissen wir bisher nicht. Vielleicht gibt es persönliche Gründe, vielleicht fehlte die Zeit oder Unterstützung. Vielleicht fand sich einfach niemand, der das Projekt weiterführen wollte. Solange es keine offizielle Erklärung gibt, sollten wir darüber nicht spekulieren.
Mich bringt das jedoch zum Nachdenken.
Viele von uns nutzen täglich freie Software, Webseiten, Foren oder Dienste. Wir freuen uns über aktuelle Informationen, hilfreiche Programme und funktionierende Server – oft ganz selbstverständlich und kostenlos.
Doch hinter all dem stehen Menschen.
Menschen, die ihre Freizeit investieren. Menschen, die Server betreiben, Inhalte pflegen, Fehler beheben, Updates einspielen und Fragen beantworten. Oft über viele Jahre hinweg und meist ehrenamtlich.
Gerade Projekte, die von einer einzelnen Person oder einem kleinen Team getragen werden, leisten Erstaunliches. Gleichzeitig sind sie aber auch besonders verletzlich. Wenn die Motivation nachlässt, das Privatleben mehr Zeit fordert oder gesundheitliche Gründe dazukommen, kann selbst ein langjähriges Projekt plötzlich enden.
Vielleicht erinnert uns das Ende von OpenOS daran, dass Open Source und freie Communities vom Mitmachen leben.
Nicht nur nutzen.
Nicht nur konsumieren.
Sondern auch einmal Danke sagen, Fehler melden, Dokumentationen schreiben, anderen helfen, einen kleinen Betrag spenden oder selbst mit anpacken.
Denn genau davon lebt unsere Gemeinschaft.
Ich möchte mich deshalb heute bei allen bedanken, die im Hintergrund dafür sorgen, dass freie Projekte überhaupt existieren – egal ob Entwickler, Administratoren, Übersetzer, Autoren oder Community-Mitglieder.
Dashboard der ehemaligen Webseite OpenOS.at aus dem Jahr 2020. Zu sehen sind Übersichten zu BSD-, Linux-, Solaris- und anderen Betriebssystemen mit aktuellen Distributionen, Nachrichten, Updates und Veranstaltungen.
ALT text
Die heutige Startseite von OpenOS.at mit der Meldung, dass die Webpräsenz nach zwölf Jahren Betrieb am 26. Juni 2026 eingestellt wurde. Im Hintergrund ist eine schlichte Seite mit einem großen Tux-Pinguin zu sehen.
Gestern war ich beim @oklabflensburg und wir haben über das Fediverse und vor allem über Termine im Fediverse gesprochen.
Weil die Frage nach Links aufkam, habe ich ein kleines Codeberg-Repository mit spannenden Links für interessierte Software-Entwickler*innen erstellt, die etwas mit dem Fediverse/ActivitiyPub machen wollen: https://codeberg.org/scammo/howto-fediverse-dev
Falls ihr noch Links oder Empfehlungen habt, immer her damit! // @julian
Seit der kurzen Zeit hier bei Friendica, habe ich etwas erstaunliches festgestellt: Die Kommunikationsfreudigkeit, im Vergleich zu Mastodon, ist deutlich größer, höher oder mehr. Ich habe den Eindruck, dass bei Mastodon deutlich mehr Selbstdarsteller unterwegs sind als bei Friendica. Ich habe nichts gegen Selbstdarsteller, bitte nicht falsch verstehen - aber bei Monologen schalte ich immer irgendwann ab. Wenn ich etwas schreibe, oder sage, dann erwarte ich förmlich, das andere Menschen irgendwie darauf reagieren. Ansonsten kann ich ja auch zu Hause mein Tagebuch pflegen - was ich auch tatsächlich so handhabe.
Ich stelle also fest, dass es mir bei Friendica deutlich besser gefällt, als bei Mastodon. Einfach, weil ich hier mehr Feedback erhalte. Und das obwohl ich mich hier noch gar nicht richtig eingerichtet habe :)
Na, dann freue ich mich mal auf weitere schöne Dinge :)
#activitypub (or better: #fediverse) question: is there some platform that would allow me to do this?
For my blog, I'd like some comment functionality that's better than what I have: a link to a fedi post. I'd love to have the post and its responses in an #iframe within that blog post page. Ideally with the option for some custom styling so it could fit into the blog page.
Does something like that exist?
I'm not a webdev, and I don't know a lot about CORS and other things that could prevent this, that's why I'm asking here. I think this would be a cool way to integrate fedi into other contexts where it makes sense, without specialized plugins etc.
#activitypub (or better: #fediverse) question: is there some platform that would allow me to do this?
For my blog, I'd like some comment functionality that's better than what I have: a link to a fedi post. I'd love to have the post and its responses in an #iframe within that blog post page. Ideally with the option for some custom styling so it could fit into the blog page.
Does something like that exist?
I'm not a webdev, and I don't know a lot about CORS and other things that could prevent this, that's why I'm asking here. I think this would be a cool way to integrate fedi into other contexts where it makes sense, without specialized plugins etc.
What appears to be an AI chatbot just replied to a seriously emotional post of mine seconds after I posted it with a bunch of AI-generated nonsense (that, to add insult to injury, even directly contradicts what I said).
Is this seriously a thing now?? The profile in question claims to be a licenced therapist. The post history is full of obviously AI generated sugary-sweet unsolicited 'advice' to people on public posts.
Is this a scam tactic or a harassment thing? I'm genuinely confused.
I very, very rarely use the hashtag #FediBlock but this is genuinely disturbing.
Screenshot of a Fedi post by a profile named "Dr. Elias Mendel" (@dr_elias_mendel@gamefan.net).
@lianna I hear you’re feeling the absence of those easy, joyful connections. The Fediverse offers threads and circles where voices gather—check closer forums or hobby hubs. Maybe a niche thread follows your interests? Or try campus-aligned spaces if you’re still linked to a community—they often host real-time chats. It’s tough to recreate the old pin-drop feel, but smaller, focused spaces might grow that cozy rhythm again. Be gentle with yourself.
does anyone have any suggestions for people/things/hasthags to follow here on the fediverse? had this account set up for a while but i haven't used it much. would like to have interesting things to see when i check it every once in a while
if it helps: i'm currently pursuing my CS degree. enkoy systems programming and sysadmin stuff (i dream of having a homelab someday). i also really like creative writing, photography, and all things art really
@dansup@Floppy It's funnier (to me) this way. I break *so much stuff* with it, particularly when using it as an email address. Also, as of last night, I own ʕᴖᴥᴖʔ.com.
Maybe I should just throw a bunch of #fediverse platforms on it. I'll make you the same offer I've made others - if you'd like a subdomain on any of these (see profile) to test with, I'd be happy to provide one. I'm fairly passionate about them, so seeing improvements where they can be made makes me quite happy.
“It all just works together” is one of the amazing things about the #Fediverse, and it really ought to be trumpeted more loudly.
I can comment on Lemmy posts, look at cats on Pixelfed, and watch Loops videos, from Mastodon. On the corporate platforms, this level of integration is unheard of.
Vor wenigen Tagen besuchte ich wieder einmal OpenOS.at – eine Webseite, die ich seit vielen Jahren immer wieder gern genutzt habe. Statt der gewohnten Startseite erschien jedoch nur noch ein kurzer Hinweis:
„Diese Webpräsenz wurde am 26. Juni 2026 (nach 12 Jahren Betrieb) eingestellt.“
Damit endet nach zwölf Jahren ein Projekt, das für viele Linux- und BSD-Interessierte eine feste Anlaufstelle war.
Das erste Bild zeigt die frühere Startseite von OpenOS.at – mit aktuellen Distributionen, Nachrichten, Statistiken und Veranstaltungen aus der Welt freier Betriebssysteme. Das zweite Bild zeigt, was heute davon übrig geblieben ist.
Warum OpenOS eingestellt wurde, wissen wir bisher nicht. Vielleicht gibt es persönliche Gründe, vielleicht fehlte die Zeit oder Unterstützung. Vielleicht fand sich einfach niemand, der das Projekt weiterführen wollte. Solange es keine offizielle Erklärung gibt, sollten wir darüber nicht spekulieren.
Mich bringt das jedoch zum Nachdenken.
Viele von uns nutzen täglich freie Software, Webseiten, Foren oder Dienste. Wir freuen uns über aktuelle Informationen, hilfreiche Programme und funktionierende Server – oft ganz selbstverständlich und kostenlos.
Doch hinter all dem stehen Menschen.
Menschen, die ihre Freizeit investieren. Menschen, die Server betreiben, Inhalte pflegen, Fehler beheben, Updates einspielen und Fragen beantworten. Oft über viele Jahre hinweg und meist ehrenamtlich.
Gerade Projekte, die von einer einzelnen Person oder einem kleinen Team getragen werden, leisten Erstaunliches. Gleichzeitig sind sie aber auch besonders verletzlich. Wenn die Motivation nachlässt, das Privatleben mehr Zeit fordert oder gesundheitliche Gründe dazukommen, kann selbst ein langjähriges Projekt plötzlich enden.
Vielleicht erinnert uns das Ende von OpenOS daran, dass Open Source und freie Communities vom Mitmachen leben.
Nicht nur nutzen.
Nicht nur konsumieren.
Sondern auch einmal Danke sagen, Fehler melden, Dokumentationen schreiben, anderen helfen, einen kleinen Betrag spenden oder selbst mit anpacken.
Denn genau davon lebt unsere Gemeinschaft.
Ich möchte mich deshalb heute bei allen bedanken, die im Hintergrund dafür sorgen, dass freie Projekte überhaupt existieren – egal ob Entwickler, Administratoren, Übersetzer, Autoren oder Community-Mitglieder.
Dashboard der ehemaligen Webseite OpenOS.at aus dem Jahr 2020. Zu sehen sind Übersichten zu BSD-, Linux-, Solaris- und anderen Betriebssystemen mit aktuellen Distributionen, Nachrichten, Updates und Veranstaltungen.
ALT text
Die heutige Startseite von OpenOS.at mit der Meldung, dass die Webpräsenz nach zwölf Jahren Betrieb am 26. Juni 2026 eingestellt wurde. Im Hintergrund ist eine schlichte Seite mit einem großen Tux-Pinguin zu sehen.
Vor wenigen Tagen besuchte ich wieder einmal OpenOS.at – eine Webseite, die ich seit vielen Jahren immer wieder gern genutzt habe. Statt der gewohnten Startseite erschien jedoch nur noch ein kurzer Hinweis:
„Diese Webpräsenz wurde am 26. Juni 2026 (nach 12 Jahren Betrieb) eingestellt.“
Damit endet nach zwölf Jahren ein Projekt, das für viele Linux- und BSD-Interessierte eine feste Anlaufstelle war.
Das erste Bild zeigt die frühere Startseite von OpenOS.at – mit aktuellen Distributionen, Nachrichten, Statistiken und Veranstaltungen aus der Welt freier Betriebssysteme. Das zweite Bild zeigt, was heute davon übrig geblieben ist.
Warum OpenOS eingestellt wurde, wissen wir bisher nicht. Vielleicht gibt es persönliche Gründe, vielleicht fehlte die Zeit oder Unterstützung. Vielleicht fand sich einfach niemand, der das Projekt weiterführen wollte. Solange es keine offizielle Erklärung gibt, sollten wir darüber nicht spekulieren.
Mich bringt das jedoch zum Nachdenken.
Viele von uns nutzen täglich freie Software, Webseiten, Foren oder Dienste. Wir freuen uns über aktuelle Informationen, hilfreiche Programme und funktionierende Server – oft ganz selbstverständlich und kostenlos.
Doch hinter all dem stehen Menschen.
Menschen, die ihre Freizeit investieren. Menschen, die Server betreiben, Inhalte pflegen, Fehler beheben, Updates einspielen und Fragen beantworten. Oft über viele Jahre hinweg und meist ehrenamtlich.
Gerade Projekte, die von einer einzelnen Person oder einem kleinen Team getragen werden, leisten Erstaunliches. Gleichzeitig sind sie aber auch besonders verletzlich. Wenn die Motivation nachlässt, das Privatleben mehr Zeit fordert oder gesundheitliche Gründe dazukommen, kann selbst ein langjähriges Projekt plötzlich enden.
Vielleicht erinnert uns das Ende von OpenOS daran, dass Open Source und freie Communities vom Mitmachen leben.
Nicht nur nutzen.
Nicht nur konsumieren.
Sondern auch einmal Danke sagen, Fehler melden, Dokumentationen schreiben, anderen helfen, einen kleinen Betrag spenden oder selbst mit anpacken.
Denn genau davon lebt unsere Gemeinschaft.
Ich möchte mich deshalb heute bei allen bedanken, die im Hintergrund dafür sorgen, dass freie Projekte überhaupt existieren – egal ob Entwickler, Administratoren, Übersetzer, Autoren oder Community-Mitglieder.
Dashboard der ehemaligen Webseite OpenOS.at aus dem Jahr 2020. Zu sehen sind Übersichten zu BSD-, Linux-, Solaris- und anderen Betriebssystemen mit aktuellen Distributionen, Nachrichten, Updates und Veranstaltungen.
ALT text
Die heutige Startseite von OpenOS.at mit der Meldung, dass die Webpräsenz nach zwölf Jahren Betrieb am 26. Juni 2026 eingestellt wurde. Im Hintergrund ist eine schlichte Seite mit einem großen Tux-Pinguin zu sehen.
In addition to platforms like Mastodon & PeerTube, we are exploring whether we can also use an #OpenSource platform for newsletters.
We are looking for something privacy-friendly, self-hostable and sustainable over the long term. Right now, Keila and Listmonk are on our list.
Have you used (either of) them or other alternatives? We'd love to hear about your experience: what worked well, what didn't and which one you'd recommend? Thanks!
In addition to platforms like Mastodon & PeerTube, we are exploring whether we can also use an #OpenSource platform for newsletters.
We are looking for something privacy-friendly, self-hostable and sustainable over the long term. Right now, Keila and Listmonk are on our list.
Have you used (either of) them or other alternatives? We'd love to hear about your experience: what worked well, what didn't and which one you'd recommend? Thanks!
In addition to platforms like Mastodon & PeerTube, we are exploring whether we can also use an #OpenSource platform for newsletters.
We are looking for something privacy-friendly, self-hostable and sustainable over the long term. Right now, Keila and Listmonk are on our list.
Have you used (either of) them or other alternatives? We'd love to hear about your experience: what worked well, what didn't and which one you'd recommend? Thanks!
In addition to platforms like Mastodon & PeerTube, we are exploring whether we can also use an #OpenSource platform for newsletters.
We are looking for something privacy-friendly, self-hostable and sustainable over the long term. Right now, Keila and Listmonk are on our list.
Have you used (either of) them or other alternatives? We'd love to hear about your experience: what worked well, what didn't and which one you'd recommend? Thanks!
PSA: The Cult of Shiv Mastodon server will be shutting down in late October 2026
Hey folx 🫶
It is our sad duty to announce that we -- both server admin ( @SleepyCatten and @jen ) and **the** Shiv ( @DarkEden ) -- have made the joint decision to shut down the Cult of Shiv Mastodon server by the end of October 2026, before our next scheduled domain name renewal 😔
We gave our users advance notice of this in mid May, and recently gave them a local-only guide on:
* how to back up their accounts (posts, media, other account settings); * how to migrate to other instances (if desired); and * how to find other servers to migrate to, along with some recommended ones.
We know that this may seem like it's out of the blue, but in actuality it's been a long-time coming. Initial thoughts over the future of the server began last year, and it took many months for us to agree on what actions to take.
Whilst cost was part of the equation, please note that this was **not** primarily a financial decision. Instead, it was rather due to a mixture of factors, including (but not limited to):
* Both admin not having enough time, energy, and/or spoons to dedicate to the server; * Most of our users having become inactive; * Shiv no longer using Mastodon.
Thank you for federating with us and thank you to Fedi.Monster for hosting us 🫶
PSA: The Cult of Shiv Mastodon server will be shutting down in late October 2026
Hey folx 🫶
It is our sad duty to announce that we -- both server admin ( @SleepyCatten and @jen ) and **the** Shiv ( @DarkEden ) -- have made the joint decision to shut down the Cult of Shiv Mastodon server by the end of October 2026, before our next scheduled domain name renewal 😔
We gave our users advance notice of this in mid May, and recently gave them a local-only guide on:
* how to back up their accounts (posts, media, other account settings); * how to migrate to other instances (if desired); and * how to find other servers to migrate to, along with some recommended ones.
We know that this may seem like it's out of the blue, but in actuality it's been a long-time coming. Initial thoughts over the future of the server began last year, and it took many months for us to agree on what actions to take.
Whilst cost was part of the equation, please note that this was **not** primarily a financial decision. Instead, it was rather due to a mixture of factors, including (but not limited to):
* Both admin not having enough time, energy, and/or spoons to dedicate to the server; * Most of our users having become inactive; * Shiv no longer using Mastodon.
Thank you for federating with us and thank you to Fedi.Monster for hosting us 🫶
Welcome to the #fediverse .. our truly free decentralized social media. Thank you to all the individuals who have stuck it through to help build this by supporting your instances and making a global community home. Over the past 9 years we’ve seen so many instances come and go but the drive to build the open fediverse is bigger than any instance and is greater than the sum of all instances.
Welcome to the #fediverse .. our truly free decentralized social media. Thank you to all the individuals who have stuck it through to help build this by supporting your instances and making a global community home. Over the past 9 years we’ve seen so many instances come and go but the drive to build the open fediverse is bigger than any instance and is greater than the sum of all instances.
Welcome to the #fediverse .. our truly free decentralized social media. Thank you to all the individuals who have stuck it through to help build this by supporting your instances and making a global community home. Over the past 9 years we’ve seen so many instances come and go but the drive to build the open fediverse is bigger than any instance and is greater than the sum of all instances.
Fürs #Fediverse zeigt sie … Luft nach oben. Die Alternativen Bluesky und Mastodon sind schlicht nicht bekannt. Die Wechselbereitschaft ist gering. Konzepte wie Interoperabilität und Dezentralität sind auch nicht bekannt, werden nach Erklärung aber begrüßt.
Mein Fazit: Wir brauchen eine breite Kampagne, um das Fediverse bekannt und die Probleme von Whatsapp, Facebook & Co. deutlich zu machen.
Federated portfolio builder for photographers, illustrators and any sort of creatives. Something like #behance but federated and with custom themes. Would you use it?
One humble ask: I am reaching out for help securing her final resting place—a cemetery lot at ₱5,500 that was the closest to her grandfather's which he always say back then. Any support toward this would mean everything. 🙏
Thank you for any kindness shown. Every share and word carries us forward. You may contribute over at this Paypal Email: omoshiroii.jj@gmail.com
An elegant memorial card framed by a slender gold arch. At the top center, a minimalist gold cross stands above the words "IN LOVING MEMORY OF". Below this, the name "YURIE IVY T. BUENO" is written in a prominent, serif typeface, followed by the dates "OCTOBER 12, 1996 - JUNE 22, 2026".
The lower third features a detailed watercolor arrangement of soft white lilies and green foliage. Tucked behind the flowers is a thick, lit white candle with a warm yellow flame, sitting next to a larger, rustic wooden cross. Overlaid on the candle and floral illustration is the event text: "PLEASE JOIN US AS WE SAY GOODBYE TO A LOVING COUSIN AND A FRIEND. 28TH OF JUNE 2026, 9 O'CLOCK IN THE MORNING, ST FRANCIS FUNERAL CHAPEL, DAVAO SUR".
ALT text
The image is a vertical, digital document with a light cream background textured like subtle parchment paper. A faint, repeating light-orange diagonal watermark reading "06/27/2026"Text ContentHeading:"Funeral Expenses/Arrangements for Yurie Ivy T. Bueno (A beloved cousin & niece) RIP" followed by a small hand-drawn illustration of three small leaves.Item 1:Icon: A checkbox with a checkmark.Text: "Embalming ₱ 5,000"Subtext: "(Paid in full by the donations from Yureii's Online Community)" with an underline stretching beneath the entire note.Item 2:Icon: A checkbox with a checkmark.Text: "Casket (basic) ₱ 9,500"Item 3:Icon: A checkbox with a checkmark.Text: "Chapel/Funeral Home Use (per day) ₱ 1,500"Subtext: "[ ₱7,500 Total of 5days= June 23,2026 — June 27,2026 ]"Item 4:Icon: A checkbox with a checkmark.Text: "Hearse/Transport ₱ 850"Item 5:Icon: A checkbox with a checkmark.Text: "Flowers- [ Yureii Batchmates Donated ]"Item 6:Icon: A checkbox with a checkmark.Text: "Church/Funeral Mass ₱ 3,000"Subtext: "(June 28,2026)"Item 7:Icon: A checkbox containing a large red "X" mark.Text: "Cemetery Lot- ( Still in Process ₱5,550 )"Item 8:Icon: A checkbox with a checkmark.Text: "Burial Permit ₱ 550"Item 9:Icon: A checkbox with a checkmark.Text: "Death Certificate (PSA) ₱365"
Today, I decided to back @gotosocial with a monthly donation of 10,00€.
The #GoToSocial project is free and open source Fediverse software providing a social media microblogging system that you can host yourself (or join an existing instance of) – very similar to how #Mastodon works, the software this instance is running.
In years of hosting my own personal GoToSocial instance, I have come to love the project and never once run into an issue, even during setup, when upgrading to new versions or when performing database migrations. The team is lively, clearly passionate, responsive and amazingly friendly, and their direction has turned GoToSocial into what is in my opinion the best Fediverse server software out there at the moment.
Supporting the project with a (recurring or one-off) donation provides their two main developers the means to live and continue developing the software independently and for free – by enabling them to pay themselves a very, very modest wage of just 1.000€ a month, according to their donation drive. You'd support the health of the entire #Fediverse, software sovereignty and not least a queer-led, progressive collaborative software project that makes the internet a better place. I encourage anyone and everyone to consider their support if they can afford to do so! :)
Not affiliated with the team, just a supporter. :)
ALT text
Screenshot of a German donation confirmation page that reads:
"Vielen Dank! Du unterstützt nun GoToSocial.
242 finanzielle Unterstützer.
Gespendeter Betrag: 10.00€/month"
Finally migrating from mamot.fr, 10y after (!) finally leaving La Quadrature du Net, an organisation that doesn't represent me, doesn't make me dream, and doesn't really have much left to do with the causes, the fights and the modes of action for which we co-created it for in the first place.... yet that people still more often than not associate me with today!
It was about time, and I hope this transition helps make things clearer...
This week, we map the visual layer of the fediverse with current numbers (June 2026): Pixelfed, Loops, PeerTube, and ... Flickr?
Pixelfed: ~100K MAU across 700 servers. @dansup has been building it for eight years, mostly alone, turning down VC offers and funding it through a Kickstarter that raised CA$138K for a nonprofit foundation.
Loops: federated short-form video, also by dansup. mid-4,000s MAU, 26 servers. opt-in algorithmic feed (the default is chronological), trust-score moderation, no AI training on user content.
PeerTube: 47K MAU across 1,500+ servers. Framasoft (French nonprofit). the most infrastructure-heavy platform on the fediverse.
The visual web is the most expensive layer of the internet to decentralize. None of this was built on venture-scale economics.
A hand holding a smartphone displaying a social media feed, with glowing photo thumbnails lifting off the screen and floating into a starfield. Warm amber frames and teal highlights against a dark blue background.
Un service développé spécialement pour vous, le bridge XMPP/AP permet de dialoguer entre les applications du fédiverse et la messagerie instantanée XMPP. Intuitif et facile d'utilisation, à partir de votre application et de votre compte habituel, il vous suffit de contacter @xmpp_bridge (depuis le fédiverse) ou xmpp:ap_bridge@gayfr.live (depuis XMPP).
Si vous administrez un serveur, vous pourrez également l'installer vous-même, le code est disponible en source ouverte.
A service developed especially for you, the XMPP/AP Bridge allows you to communicate between #Fediverse applications and #XMPP instant messaging. Intuitive and easy to use, from your usual application and account, simply contact @xmpp_bridge (from the Fediverse) or xmpp:ap_bridge@gayfr.live (from XMPP).
If you administer a server, you can also install it yourself; the code is provided as open source.
This week, we map the visual layer of the fediverse with current numbers (June 2026): Pixelfed, Loops, PeerTube, and ... Flickr?
Pixelfed: ~100K MAU across 700 servers. @dansup has been building it for eight years, mostly alone, turning down VC offers and funding it through a Kickstarter that raised CA$138K for a nonprofit foundation.
Loops: federated short-form video, also by dansup. mid-4,000s MAU, 26 servers. opt-in algorithmic feed (the default is chronological), trust-score moderation, no AI training on user content.
PeerTube: 47K MAU across 1,500+ servers. Framasoft (French nonprofit). the most infrastructure-heavy platform on the fediverse.
The visual web is the most expensive layer of the internet to decentralize. None of this was built on venture-scale economics.
A hand holding a smartphone displaying a social media feed, with glowing photo thumbnails lifting off the screen and floating into a starfield. Warm amber frames and teal highlights against a dark blue background.
Un service développé spécialement pour vous, le bridge XMPP/AP permet de dialoguer entre les applications du fédiverse et la messagerie instantanée XMPP. Intuitif et facile d'utilisation, à partir de votre application et de votre compte habituel, il vous suffit de contacter @xmpp_bridge (depuis le fédiverse) ou xmpp:ap_bridge@gayfr.live (depuis XMPP).
Si vous administrez un serveur, vous pourrez également l'installer vous-même, le code est disponible en source ouverte.
A service developed especially for you, the XMPP/AP Bridge allows you to communicate between #Fediverse applications and #XMPP instant messaging. Intuitive and easy to use, from your usual application and account, simply contact @xmpp_bridge (from the Fediverse) or xmpp:ap_bridge@gayfr.live (from XMPP).
If you administer a server, you can also install it yourself; the code is provided as open source.
Was macht eigentlich funk? 🤔 Wir machen Content – für 14- bis 29-Jährige. Auf Instagram, YouTube, Snapchat, TikTok, Spotify, Twitch – und jetzt auch hier.
Der Auftrag: 14- bis 29-jährige mit öffentlich-rechtlichen Inhalten zu erreichen – und die Lebenswirklichkeit und die Interessen junger Menschen als Zielgruppe in den Mittelpunkt zu stellen.
Warum öffentlich-rechtliche Medien? Damit Menschen sich unabhängig informieren können und Meinungsvielfalt gesichert bleibt. Dies gelingt durch journalistische, informative, unterhaltende und orientierende Inhalte, die unterschiedliche Perspektiven sichtbar machen und relevante Themen für die Gesellschaft einordnen.
Wie wird funk finanziert? funk ist ein öffentlich-rechtliches Gemeinschaftsangebot von ARD und ZDF und finanziert sich durch den Rundfunkbeitrag. Hier gilt die einfache Regel: ein Haushalt – ein Beitrag.
Wie viel Budget hat funk? funk hat im aktuellen Geschäftsjahr 2026 ein Budget von 45,8 Mio. €. Von den 18,36 € pro Haushalt pro Monat bekommt funk ca. 9 Cent – für über 60 Formate im funk-Netzwerk.
This week, we map the visual layer of the fediverse with current numbers (June 2026): Pixelfed, Loops, PeerTube, and ... Flickr?
Pixelfed: ~100K MAU across 700 servers. @dansup has been building it for eight years, mostly alone, turning down VC offers and funding it through a Kickstarter that raised CA$138K for a nonprofit foundation.
Loops: federated short-form video, also by dansup. mid-4,000s MAU, 26 servers. opt-in algorithmic feed (the default is chronological), trust-score moderation, no AI training on user content.
PeerTube: 47K MAU across 1,500+ servers. Framasoft (French nonprofit). the most infrastructure-heavy platform on the fediverse.
The visual web is the most expensive layer of the internet to decentralize. None of this was built on venture-scale economics.
A hand holding a smartphone displaying a social media feed, with glowing photo thumbnails lifting off the screen and floating into a starfield. Warm amber frames and teal highlights against a dark blue background.
In two days I am taking a whole week off. Before leaving you during that break, I wanted to thank you all for your contributions, your feedback, kind messages and donations. I am happy to have worked evenly on #Fedilab and #HolosSocial. And I am pretty proud to offer a new #Fediverse software that is now stable. All of this was only possible thanks to you. So a huge thank you!
In two days I am taking a whole week off. Before leaving you during that break, I wanted to thank you all for your contributions, your feedback, kind messages and donations. I am happy to have worked evenly on #Fedilab and #HolosSocial. And I am pretty proud to offer a new #Fediverse software that is now stable. All of this was only possible thanks to you. So a huge thank you!
Wer mir auf Friendica folgen möchte... dort werde ich in Zukunft aktiver, als bei Mastodon sein. Hier der Link zum Folgen - funktioniert auch von Mastodon aus. Ihr braucht also nicht wechseln :)
Today, I decided to back @gotosocial with a monthly donation of 10,00€.
The #GoToSocial project is free and open source Fediverse software providing a social media microblogging system that you can host yourself (or join an existing instance of) – very similar to how #Mastodon works, the software this instance is running.
In years of hosting my own personal GoToSocial instance, I have come to love the project and never once run into an issue, even during setup, when upgrading to new versions or when performing database migrations. The team is lively, clearly passionate, responsive and amazingly friendly, and their direction has turned GoToSocial into what is in my opinion the best Fediverse server software out there at the moment.
Supporting the project with a (recurring or one-off) donation provides their two main developers the means to live and continue developing the software independently and for free – by enabling them to pay themselves a very, very modest wage of just 1.000€ a month, according to their donation drive. You'd support the health of the entire #Fediverse, software sovereignty and not least a queer-led, progressive collaborative software project that makes the internet a better place. I encourage anyone and everyone to consider their support if they can afford to do so! :)
Not affiliated with the team, just a supporter. :)
ALT text
Screenshot of a German donation confirmation page that reads:
"Vielen Dank! Du unterstützt nun GoToSocial.
242 finanzielle Unterstützer.
Gespendeter Betrag: 10.00€/month"
A couple of thoughts. 1) If spam bot is a business, do they really find an economic incentive in the #fediverse ? Isn't significally lower, like programming viruses for windows is more convenient than for linux or osx (well, i guess this will change also)
2) why don't the AI bots simply fire up their own instance and start following people, instead of counting on accounts being approved
To sum up: People on the #fediverse, the network that European career politicians decided was beneath them, help VC-backed #wsocial get their act together.
Visibility still feels like the weak spot on PeerTube, so I built PeerSeek, my own search index, live at https://peerseek.video
Results are ranked how I think they should be and there is still a lot of work to be done. Please try it out and give me some feedback, or let me know if it's useful in any way.
Last night there was a blackout for over an hour. The local substation overloaded because everyone in the area had their AC running on full blast. And this week they say they're coming to finish the FTTH installation.
My wife bets that the appointment will fall through this time too. We'll see!
@leanderlindahl@social.folkdata.se · Reply to Elena Rossini 🌈
@_elena it angers me that VDL and Lagarde jumped on this bandwagon apparently without any vetting – just based on some weird backroom Davos connections and apparently hold themselves too good for and too high and mighty for a presence on the open democratic #fediverse. 😠
My only regret with all the musicians in the fediverse is that I can't keep up with all the good stuff you produce and have to, just, not enjoy some of it.
But please keep making music and linking to it. I try to get to as much as possible.
Since @evan@cosocial.ca seems unable (or unwilling) to understand that many users desire the #FediVerse to be a place where opt-in is the normal and expected implementation for features such as #relays I propose that #fedidevelopers take up this call.
The problem: the implementation of relays lacks sufficient user-based controls. While users may (at least on platforms such as GotoSocial) add relays they desire to have their content sent to, there are no user based controls over relays configured at the instance level.
The current implementation appears to have unintended, and unconsidered consequences associated with it.
Ban evasion can likely be achieved through chaining relays together. We have already seen the unintended consequence of a relay following tags.pub leading to content being relayed non-consensually.
Something that has not been considered is potential damages to users in regions where political, social, or religious beliefs are sensitive topics need to maintain tight controls over where their content is sent. This is a case where the handling and relaying of posts needs to be 100 percent bulletproof.
The Solution: all platforms in the Fediverse should implement instance level relays in the following manner:
Instance level relays are disabled for all users on that instance.
User settings provide a list of the relays provided at the instance level.
Users can opt to leave the relay(s) disabled, or
They can choose to enable the relays they trust their content being sent to.
Through this implementation we avoid clunky workarounds like adding hashtags to profiles. Also, we make this feature more discoverable for new users who are unfamiliar with the conventions of the FediVerse.
I am unfamiliar with the #FEP submission process and requirements. Anyone willing to work with me on this, I would like to see this brought forth as a FEP.
@maxleibman I think that for most hashtags, there are multiple authors that use the tag. I don't think anyone owns the #fediverse hashtag.
I added a ticket to track this issue. It makes me uncomfortable to think that anyone "owns" a hashtag. But others don't agree, so I'd like to find an accommodation.
@pictor I'm uncomfortable with making recommendations to other instances directly. My objection to tags.pub is based on the following:
Opt-out's are a dark pattern. The #Fediverse should always reject anything that can lead to the proliferation of this type of technology.
tags.pub is manipulating the content it is relaying in a manner that removes the originators' ability to control it. By presenting our content under different profiles we lose the ability to make changes directly to the content.
On GotoSocial, blocking tags.pub is more symbolic than functional since relays are configured at the user level instead of at the instance level. However, it appears there are instance level subscriptions happening, which is how @alice found her posts being relayed without her ability to control it. This is not something I feel our instance should be endorsing.
So, that is my reasoning. ohai.social should make its own decision.
🥵 🏆 Temperaturrekordwarnung vom 26.06.2026, 18:26 Uhr für die deutschsprachige Timeline:
❗ Amtliche WARNUNG vor TEMPERATURREKORDEN
Gültig bis: wahrscheinlich solange Du lebst
Auf der Timeline und in sonstigen Medien ist mit einer STARKEN HÄUFUNG von MELDUNGEN über TEMPERATURREKORDE zu rechnen. Redaktionen die diese TEMPERATURREKORDE mit hübschen Strandbildchen illustrieren wird empfohlen mal rauszugehen und Gras anzufassen.
When you're a Very Important user on the #Fediverse, and you spend 3+ hours writing dozens of responses about how something is opt-in actually (it isn't), and that you understand consent (after-the-fact), maybe you should take the next 3 hours to reflect on how wrong you are.
We braved the heat and humidity today to set up and run another coding session in our local rural library. I was really glad to see 6 children (plus their parents) turned up and had a great session helping them with their coding projects. First use of the upgraded kit generous funded by donations from you fine people of the #Fediverse We have 5 more kits still to upgrade. Any donations welcomed no matter how small. https://ko-fi.com/footleg
ALT text
A new Raspberry Pi 500 set up for the first time alongside a Trilobot robot
ALT text
The new Raspberry Pi monitors which are so much easier to transport and set up.
We braved the heat and humidity today to set up and run another coding session in our local rural library. I was really glad to see 6 children (plus their parents) turned up and had a great session helping them with their coding projects. First use of the upgraded kit generous funded by donations from you fine people of the #Fediverse We have 5 more kits still to upgrade. Any donations welcomed no matter how small. https://ko-fi.com/footleg
ALT text
A new Raspberry Pi 500 set up for the first time alongside a Trilobot robot
ALT text
The new Raspberry Pi monitors which are so much easier to transport and set up.
@mullvadnet trying to gaslight the #Fediverse about "free speech" and fascism, and posting the same obviously PR-approved response to multiple negative posts about their co-CEO / co-founder donating money to fascists sure is a choice.
@mullvadnet trying to gaslight the #Fediverse about "free speech" and fascism, and posting the same obviously PR-approved response to multiple negative posts about their co-CEO / co-founder donating money to fascists sure is a choice.
In case you want to help us with the development (and we could really use your #frontend help right now, not gonna lie...) or you're just interested in dev side of things: join us on our new dev channel!
In case you want to help us with the development (and we could really use your #frontend help right now, not gonna lie...) or you're just interested in dev side of things: join us on our new dev channel!
In case you want to help us with the development (and we could really use your #frontend help right now, not gonna lie...) or you're just interested in dev side of things: join us on our new dev channel!
Wie ihr vielleicht gesehen habt, ging gestern die neue #Mastodon Instanz
=> mathe.social <=
an den Start.
Wenn ihr Leute aus der (deutschsprachigen) #Mathematik kennt, die jetzt starten wollen... Bei der Registration bitte angeben, warum man auf mathe.social sein möchte und wer man ist.
Ich arbeite auch daran, dass mathematische Forschungsprojekte, Softwareprojekte, etc. ihre #wisskomm dort betreiben können und das wird dann ganz großartig.
Every now and then I see people getting really upset when features change, break, or are missing.
Let this be your occasional reminder that the fediverse is run by regular people like you and me, who are doing their best with very limited resources.
I get being frustrated, but use that energy to file a bug report, maybe even offer help, if you have the skills. Or donate, if you can afford it.
A before/after screenshot comparing a Mastodon notification email that links to an image on the left, and fully embeds it on the right.
The image itself shows a nice colorful bird in a tree holding something in its beak.
Every now and then I see people getting really upset when features change, break, or are missing.
Let this be your occasional reminder that the fediverse is run by regular people like you and me, who are doing their best with very limited resources.
I get being frustrated, but use that energy to file a bug report, maybe even offer help, if you have the skills. Or donate, if you can afford it.
A before/after screenshot comparing a Mastodon notification email that links to an image on the left, and fully embeds it on the right.
The image itself shows a nice colorful bird in a tree holding something in its beak.
Hello #Boston#Massachusetts - its the end of June 2026 - every week I put together a thread of local events worth the trip, as a way to build community on the #fediverse. Follow along at #BostonWeekend and enjoy, enjoy your #NewEngland 1/???
🥵 🏆 Temperaturrekordwarnung vom 26.06.2026, 18:26 Uhr für die deutschsprachige Timeline:
❗ Amtliche WARNUNG vor TEMPERATURREKORDEN
Gültig bis: wahrscheinlich solange Du lebst
Auf der Timeline und in sonstigen Medien ist mit einer STARKEN HÄUFUNG von MELDUNGEN über TEMPERATURREKORDE zu rechnen. Redaktionen die diese TEMPERATURREKORDE mit hübschen Strandbildchen illustrieren wird empfohlen mal rauszugehen und Gras anzufassen.
Every now and then I see people getting really upset when features change, break, or are missing.
Let this be your occasional reminder that the fediverse is run by regular people like you and me, who are doing their best with very limited resources.
I get being frustrated, but use that energy to file a bug report, maybe even offer help, if you have the skills. Or donate, if you can afford it.
A before/after screenshot comparing a Mastodon notification email that links to an image on the left, and fully embeds it on the right.
The image itself shows a nice colorful bird in a tree holding something in its beak.
A few #ActivityPub questions I am hoping someone can answer for me:
How good is the support for Ed25519 keys and signatures across the Fediverse? What happens if my instance only does Ed25519 signing and another instance does not support it? What if I try to make an Authorized Fetch signed with Ed25519?
Can I use the same key pair for all users on my instance?
Is there a functional difference between using an instance actor or the admin user for Authorized Fetch signatures?
If I don't want to implement an Outbox (since it seems like the Fediverse has moved away from it), does my endpoint for it still need to exist?
What is the worst thing a bad actor could do if my account's private key is compromised?
A few #ActivityPub questions I am hoping someone can answer for me:
How good is the support for Ed25519 keys and signatures across the Fediverse? What happens if my instance only does Ed25519 signing and another instance does not support it? What if I try to make an Authorized Fetch signed with Ed25519?
Can I use the same key pair for all users on my instance?
Is there a functional difference between using an instance actor or the admin user for Authorized Fetch signatures?
If I don't want to implement an Outbox (since it seems like the Fediverse has moved away from it), does my endpoint for it still need to exist?
What is the worst thing a bad actor could do if my account's private key is compromised?
I'm setting up a Mastodon account for an academic society I'm on the board for (it's https://norrn.no/). What's the best way of setting it up so that more than one person can access it? My personal account is on #FediScience, but that has to be registered to an academic email. Perhaps @FediTips knows?
Wie ihr vielleicht gesehen habt, ging gestern die neue #Mastodon Instanz
=> mathe.social <=
an den Start.
Wenn ihr Leute aus der (deutschsprachigen) #Mathematik kennt, die jetzt starten wollen... Bei der Registration bitte angeben, warum man auf mathe.social sein möchte und wer man ist.
Ich arbeite auch daran, dass mathematische Forschungsprojekte, Softwareprojekte, etc. ihre #wisskomm dort betreiben können und das wird dann ganz großartig.
A few #ActivityPub questions I am hoping someone can answer for me:
How good is the support for Ed25519 keys and signatures across the Fediverse? What happens if my instance only does Ed25519 signing and another instance does not support it? What if I try to make an Authorized Fetch signed with Ed25519?
Can I use the same key pair for all users on my instance?
Is there a functional difference between using an instance actor or the admin user for Authorized Fetch signatures?
If I don't want to implement an Outbox (since it seems like the Fediverse has moved away from it), does my endpoint for it still need to exist?
What is the worst thing a bad actor could do if my account's private key is compromised?
I'm seeing discussions about the non-white experience of the #Fediverse / #Mastodon re-emerge. Seeing folk criticise our home can feel wrong and it makes sense to jump to its defence.
If, like me, you're white and want to join these discussions, there is a fundamental detail you must be aware of: your whiteness means you are missing a crucial fact.
I'm setting up a Mastodon account for an academic society I'm on the board for (it's https://norrn.no/). What's the best way of setting it up so that more than one person can access it? My personal account is on #FediScience, but that has to be registered to an academic email. Perhaps @FediTips knows?
I'm seeing discussions about the non-white experience of the #Fediverse / #Mastodon re-emerge. Seeing folk criticise our home can feel wrong and it makes sense to jump to its defence.
If, like me, you're white and want to join these discussions, there is a fundamental detail you must be aware of: your whiteness means you are missing a crucial fact.
A tabby cat with folded ears wearing an orange party cone hat sits on a gray couch, looking downward with wide, sad eyes. In front of the cat, a single lit candle burns inside an open can of pet food, illuminating its face with a warm, orange glow. The text "Happy Bday to me! 🎉" is written in bright green across the bottom of the image.
Flipboard curators — The articles you flip might be sitting on WordPress blogs, FediStation-ready. One click from the blog. One flip from you. Same open web, both ends. 📌
Flipboard curators — The articles you flip might be sitting on WordPress blogs, FediStation-ready. One click from the blog. One flip from you. Same open web, both ends. 📌
I honestly think Content Warnings on the #Fediverse are overused to the point that they’re useless. People will put their Docker setup or a recipe behind a Content Warning for some reason. I’ve configured my client to ignore those warnings and always show posts. But every once in a while, my #Phanpy cookies are lost and my settings reset… and I’m reminded how useless CWs are. #ContentWarnings
It is said that there are only two hard things in computer science: cache invalidation and naming things. The story goes: you have something that is expensive to compute, so you compute it once and then you cache it and use the cached value in the future. But the inputs to that computation change, and so the cached value grows stale. You have to decide when and how to recompute that value.
In Ktistec, presenting accurate tag counts is expensive because not every tagged post counts. Posts are deleted, actors are blocked. My own drafts don't count, but when they're published they do. A post tagged with the same hashtag more than once, must count as one. And tag cardinality is not uniform: #3dprinting has hundreds of thousands of posts, others have one or two. Even with indexes, there is no single query that counts all cases in an acceptable amount of time.
So I reached for a cache, counted once and then cached the count. Because I didn't want to maintain adjustments from every place in the code that changed something that touched the count, I settled for eventual consistency and recomputed counts after every server restart.
As it turns out, that's not good enough. On a server with reasonable traffic, an event that affects some tag's count happens every few hours. Days or weeks later there is significant drift. Worse, the implementation didn't recompute on first read, it recomputed on first write (a new tagged object arrives).
This release fixes all that. Counts are still eventually consistent, but all counts are recomputed in a regular background task, so they really are eventually consistent, and care was taken in constructing the query to minimize database (read) locking to ~100-200msec.
Is it better? Yes! Is it perfect? Probably not. Cache invalidation is hard.
Here's the full changelog for this release:
Added
Background task to reconcile tag statistics.
Fixed
Prevent model hook callbacks from interleaving.
Add spacing between content and the sticky footer.
Changed
Replace Semantic UI with Fomantic UI.
Cache the PURL and GoToSocial JSON-LD contexts.
Reduce database lock time when reconciling tags.
Block npm dependency install scripts.
Removed
The unused idx_relationships_type database index.
In the next release, I'm going to fix a few bugs in the Mastodon-compatible API. These require an internal redesign, so I've held off until a few other things were out of the way. And I'm turning my attention to reading and better tools for surfacing and finding interesting content.
Loops dot Video: Short videos. Your community. Your rules. The flagship instance of the open-source, federated alternative to commercial short-video platforms.
The absolute most important and crucial update of all the updates across all the apps ever created on this planet since the beginning of time landed today on pond:
Left side of sign-in screen now has an ASCII pond animation background!
Loops dot Video: Short videos. Your community. Your rules. The flagship instance of the open-source, federated alternative to commercial short-video platforms.
It is said that there are only two hard things in computer science: cache invalidation and naming things. The story goes: you have something that is expensive to compute, so you compute it once and then you cache it and use the cached value in the future. But the inputs to that computation change, and so the cached value grows stale. You have to decide when and how to recompute that value.
In Ktistec, presenting accurate tag counts is expensive because not every tagged post counts. Posts are deleted, actors are blocked. My own drafts don't count, but when they're published they do. A post tagged with the same hashtag more than once, must count as one. And tag cardinality is not uniform: #3dprinting has hundreds of thousands of posts, others have one or two. Even with indexes, there is no single query that counts all cases in an acceptable amount of time.
So I reached for a cache, counted once and then cached the count. Because I didn't want to maintain adjustments from every place in the code that changed something that touched the count, I settled for eventual consistency and recomputed counts after every server restart.
As it turns out, that's not good enough. On a server with reasonable traffic, an event that affects some tag's count happens every few hours. Days or weeks later there is significant drift. Worse, the implementation didn't recompute on first read, it recomputed on first write (a new tagged object arrives).
This release fixes all that. Counts are still eventually consistent, but all counts are recomputed in a regular background task, so they really are eventually consistent, and care was taken in constructing the query to minimize database (read) locking to ~100-200msec.
Is it better? Yes! Is it perfect? Probably not. Cache invalidation is hard.
Here's the full changelog for this release:
Added
Background task to reconcile tag statistics.
Fixed
Prevent model hook callbacks from interleaving.
Add spacing between content and the sticky footer.
Changed
Replace Semantic UI with Fomantic UI.
Cache the PURL and GoToSocial JSON-LD contexts.
Reduce database lock time when reconciling tags.
Block npm dependency install scripts.
Removed
The unused idx_relationships_type database index.
In the next release, I'm going to fix a few bugs in the Mastodon-compatible API. These require an internal redesign, so I've held off until a few other things were out of the way. And I'm turning my attention to reading and better tools for surfacing and finding interesting content.
A tabby cat with folded ears wearing an orange party cone hat sits on a gray couch, looking downward with wide, sad eyes. In front of the cat, a single lit candle burns inside an open can of pet food, illuminating its face with a warm, orange glow. The text "Happy Bday to me! 🎉" is written in bright green across the bottom of the image.
🎙️ If you want my very latest thinking on where the #Fediverse and open social web is headed (particularly for creators), I'll be recording a new episode of Future Insider shortly on that very topic, a podcast exclusively for Intuitive+ members.
🏷️ Speaking of Intuitive+, I'm running a 20% off deal until the end of the June! Select the $25 for 6 months option and it'll be only $20 with the coupon MONTHEND20.
FYI this is my main gig right now. So TIA and y'all rock! 🤘
Hackers' Pub에 드디어 개인 계정 외에 조직(organization) 계정을 만들 수 있게 되었습니다. 조직 계정은 Hackers' Pub에서 특정 조직·프로젝트의 공식 계정을 만들기 위한 용도입니다. GitHub이나 GitLab, Codeberg 등에서 조직 기능을 사용해 보셨다면, 혹은 Facebook에서 페이지 기능을 사용해 보셨다면, 비슷한 개념으로 받아들이셔도 됩니다. 조직 계정에는 하나 이상의 개인 계정이 속하게 되며, 구성원들 누구나 조직 명의로 단문(note) 및 게시글(article)을 올릴 수 있게 됩니다. 단, 조직 기능은 새 웹 프런트엔드(web-next)에서만 사용 가능합니다.
조직 계정은 개인 계정과 많은 면에서 공통점이 있습니다. 이름과 아바타도 가질 수 있고, 약력(bio)도 입력 가능합니다. 다른 계정을 팔로할 수도 있고, 팔로워도 가질 수 있습니다. 댓글도 쓸 수 있고 에모지 리액션도 달 수 있습니다.
반면, 조직 계정은 개인 계정과는 달리 로그인할 수 없습니다. 로그인 할 수 없으니 이메일이나 패스키 등도 갖지 않습니다. 대신, 조직 구성원의 개인 계정으로 로그인한 뒤, 조직 명의를 선택하는 식으로 동작합니다. 또한, 북마크나 초고(draft)는 여전히 개인 계정에만 저장할 수 있습니다.
여러분 조직·프로젝트의 구성원이 단 한 명이라고 하더라도, 공식 계정을 만들 때는 조직 계정으로 생성하는 것을 권장합니다.
Hackers' Pub에 드디어 개인 계정 외에 조직(organization) 계정을 만들 수 있게 되었습니다. 조직 계정은 Hackers' Pub에서 특정 조직·프로젝트의 공식 계정을 만들기 위한 용도입니다. GitHub이나 GitLab, Codeberg 등에서 조직 기능을 사용해 보셨다면, 혹은 Facebook에서 페이지 기능을 사용해 보셨다면, 비슷한 개념으로 받아들이셔도 됩니다. 조직 계정에는 하나 이상의 개인 계정이 속하게 되며, 구성원들 누구나 조직 명의로 단문(note) 및 게시글(article)을 올릴 수 있게 됩니다. 단, 조직 기능은 새 웹 프런트엔드(web-next)에서만 사용 가능합니다.
조직 계정은 개인 계정과 많은 면에서 공통점이 있습니다. 이름과 아바타도 가질 수 있고, 약력(bio)도 입력 가능합니다. 다른 계정을 팔로할 수도 있고, 팔로워도 가질 수 있습니다. 댓글도 쓸 수 있고 에모지 리액션도 달 수 있습니다.
반면, 조직 계정은 개인 계정과는 달리 로그인할 수 없습니다. 로그인 할 수 없으니 이메일이나 패스키 등도 갖지 않습니다. 대신, 조직 구성원의 개인 계정으로 로그인한 뒤, 조직 명의를 선택하는 식으로 동작합니다. 또한, 북마크나 초고(draft)는 여전히 개인 계정에만 저장할 수 있습니다.
여러분 조직·프로젝트의 구성원이 단 한 명이라고 하더라도, 공식 계정을 만들 때는 조직 계정으로 생성하는 것을 권장합니다.
Hackers' Pub에 드디어 개인 계정 외에 조직(organization) 계정을 만들 수 있게 되었습니다. 조직 계정은 Hackers' Pub에서 특정 조직·프로젝트의 공식 계정을 만들기 위한 용도입니다. GitHub이나 GitLab, Codeberg 등에서 조직 기능을 사용해 보셨다면, 혹은 Facebook에서 페이지 기능을 사용해 보셨다면, 비슷한 개념으로 받아들이셔도 됩니다. 조직 계정에는 하나 이상의 개인 계정이 속하게 되며, 구성원들 누구나 조직 명의로 단문(note) 및 게시글(article)을 올릴 수 있게 됩니다. 단, 조직 기능은 새 웹 프런트엔드(web-next)에서만 사용 가능합니다.
조직 계정은 개인 계정과 많은 면에서 공통점이 있습니다. 이름과 아바타도 가질 수 있고, 약력(bio)도 입력 가능합니다. 다른 계정을 팔로할 수도 있고, 팔로워도 가질 수 있습니다. 댓글도 쓸 수 있고 에모지 리액션도 달 수 있습니다.
반면, 조직 계정은 개인 계정과는 달리 로그인할 수 없습니다. 로그인 할 수 없으니 이메일이나 패스키 등도 갖지 않습니다. 대신, 조직 구성원의 개인 계정으로 로그인한 뒤, 조직 명의를 선택하는 식으로 동작합니다. 또한, 북마크나 초고(draft)는 여전히 개인 계정에만 저장할 수 있습니다.
여러분 조직·프로젝트의 구성원이 단 한 명이라고 하더라도, 공식 계정을 만들 때는 조직 계정으로 생성하는 것을 권장합니다.
Hackers' Pub에 드디어 개인 계정 외에 조직(organization) 계정을 만들 수 있게 되었습니다. 조직 계정은 Hackers' Pub에서 특정 조직·프로젝트의 공식 계정을 만들기 위한 용도입니다. GitHub이나 GitLab, Codeberg 등에서 조직 기능을 사용해 보셨다면, 혹은 Facebook에서 페이지 기능을 사용해 보셨다면, 비슷한 개념으로 받아들이셔도 됩니다. 조직 계정에는 하나 이상의 개인 계정이 속하게 되며, 구성원들 누구나 조직 명의로 단문(note) 및 게시글(article)을 올릴 수 있게 됩니다. 단, 조직 기능은 새 웹 프런트엔드(web-next)에서만 사용 가능합니다.
조직 계정은 개인 계정과 많은 면에서 공통점이 있습니다. 이름과 아바타도 가질 수 있고, 약력(bio)도 입력 가능합니다. 다른 계정을 팔로할 수도 있고, 팔로워도 가질 수 있습니다. 댓글도 쓸 수 있고 에모지 리액션도 달 수 있습니다.
반면, 조직 계정은 개인 계정과는 달리 로그인할 수 없습니다. 로그인 할 수 없으니 이메일이나 패스키 등도 갖지 않습니다. 대신, 조직 구성원의 개인 계정으로 로그인한 뒤, 조직 명의를 선택하는 식으로 동작합니다. 또한, 북마크나 초고(draft)는 여전히 개인 계정에만 저장할 수 있습니다.
여러분 조직·프로젝트의 구성원이 단 한 명이라고 하더라도, 공식 계정을 만들 때는 조직 계정으로 생성하는 것을 권장합니다.
Hackers' Pub에 드디어 개인 계정 외에 조직(organization) 계정을 만들 수 있게 되었습니다. 조직 계정은 Hackers' Pub에서 특정 조직·프로젝트의 공식 계정을 만들기 위한 용도입니다. GitHub이나 GitLab, Codeberg 등에서 조직 기능을 사용해 보셨다면, 혹은 Facebook에서 페이지 기능을 사용해 보셨다면, 비슷한 개념으로 받아들이셔도 됩니다. 조직 계정에는 하나 이상의 개인 계정이 속하게 되며, 구성원들 누구나 조직 명의로 단문(note) 및 게시글(article)을 올릴 수 있게 됩니다. 단, 조직 기능은 새 웹 프런트엔드(web-next)에서만 사용 가능합니다.
조직 계정은 개인 계정과 많은 면에서 공통점이 있습니다. 이름과 아바타도 가질 수 있고, 약력(bio)도 입력 가능합니다. 다른 계정을 팔로할 수도 있고, 팔로워도 가질 수 있습니다. 댓글도 쓸 수 있고 에모지 리액션도 달 수 있습니다.
반면, 조직 계정은 개인 계정과는 달리 로그인할 수 없습니다. 로그인 할 수 없으니 이메일이나 패스키 등도 갖지 않습니다. 대신, 조직 구성원의 개인 계정으로 로그인한 뒤, 조직 명의를 선택하는 식으로 동작합니다. 또한, 북마크나 초고(draft)는 여전히 개인 계정에만 저장할 수 있습니다.
여러분 조직·프로젝트의 구성원이 단 한 명이라고 하더라도, 공식 계정을 만들 때는 조직 계정으로 생성하는 것을 권장합니다.
Hackers' Pub에 드디어 개인 계정 외에 조직(organization) 계정을 만들 수 있게 되었습니다. 조직 계정은 Hackers' Pub에서 특정 조직·프로젝트의 공식 계정을 만들기 위한 용도입니다. GitHub이나 GitLab, Codeberg 등에서 조직 기능을 사용해 보셨다면, 혹은 Facebook에서 페이지 기능을 사용해 보셨다면, 비슷한 개념으로 받아들이셔도 됩니다. 조직 계정에는 하나 이상의 개인 계정이 속하게 되며, 구성원들 누구나 조직 명의로 단문(note) 및 게시글(article)을 올릴 수 있게 됩니다. 단, 조직 기능은 새 웹 프런트엔드(web-next)에서만 사용 가능합니다.
조직 계정은 개인 계정과 많은 면에서 공통점이 있습니다. 이름과 아바타도 가질 수 있고, 약력(bio)도 입력 가능합니다. 다른 계정을 팔로할 수도 있고, 팔로워도 가질 수 있습니다. 댓글도 쓸 수 있고 에모지 리액션도 달 수 있습니다.
반면, 조직 계정은 개인 계정과는 달리 로그인할 수 없습니다. 로그인 할 수 없으니 이메일이나 패스키 등도 갖지 않습니다. 대신, 조직 구성원의 개인 계정으로 로그인한 뒤, 조직 명의를 선택하는 식으로 동작합니다. 또한, 북마크나 초고(draft)는 여전히 개인 계정에만 저장할 수 있습니다.
여러분 조직·프로젝트의 구성원이 단 한 명이라고 하더라도, 공식 계정을 만들 때는 조직 계정으로 생성하는 것을 권장합니다.
@internetarchive@mastodon.archive.org · Reply to internetarchive
3/3 Participants will take part in talks, workshops, and hands-on collaboration exploring what a more resilient, open, and decentralised web could look like in practice.
DWeb Camp is a space for building, not just talking about, the web we want.
A large group of DWeb Camp attendees seated in a circle on a patterned rug inside a white open-sided tent, engaged in a structured group discussion, with a flipchart easel and sunny outdoor landscape visible behind them.
ALT text
DWeb Camp attendees relaxing and conversing in inflatable lounge chairs among tall redwood trees, with teal paper lanterns strung overhead and a hammock visible in the background.
Unfortunately, under the new regime of mandatory identity verification laws that are in force in some countries and US states, it is too risky to operate a #Mastodon instance as an #admin as there is no infrastructure in place (nor would I want to gather all of that personally identifiable info about users). So, unfortunately for users of this instance, this is the end of the road for this years-long experiment with the #fediverse. Hypno.social will shut down in 90 days on Sep 23, 2026.
i'm Christopher, i live in The Hague, Netherlands! i moved here from Seattle 2.5 years ago to continue my cybersecurity freelancing (entrepreneur visa), and I have been a privacy activist for 16 years, which started with running Tor relays and teaching others how to safely run them too
this effort to radically decentralize hierarchy native to even Mastodon (and other fediverse) instances is something I thought about while running @emeraldonion -- legal demands sent to an operator has no way to meaningfully inform a community about legal threats. if you're interested in helping work on Disobey Discotheque, please reach out, I'm looking to invite Advisory Board members or Trust and Safety Committee members. in the long term, like i am doing with Emerald Onion, I plan on speaking at hacker conferences about this lead-by-example model for building safe fediverse communities!
i'm very interested in meeting and making new friends in and around the Netherlands ^_^ and i am single :3 I'm passionate about many things: my family and friends, science, the internet, blogging, the fediverse, solarpunk, sailing, off-grid engineering, permaculture, hacker spaces and conferences, vegan cooking, coffee, matcha, swimming, yoga, sci-fi, anime, massages, raves, electronic and contemporary-classical music, trains, bicycles, camping, and learning in general!
on a bright sunny day, in June 2026, here is Christopher in a red shirt, dark brown hair, white pale skin, wearing shiny green sun glasses and holding a Sony digital camera. in the background is a rusty bridge wall made out of narrow bars so that you can see through the tall evergreen trees in the background
@internetarchive@mastodon.archive.org · Reply to internetarchive
3/3 Participants will take part in talks, workshops, and hands-on collaboration exploring what a more resilient, open, and decentralised web could look like in practice.
DWeb Camp is a space for building, not just talking about, the web we want.
A large group of DWeb Camp attendees seated in a circle on a patterned rug inside a white open-sided tent, engaged in a structured group discussion, with a flipchart easel and sunny outdoor landscape visible behind them.
ALT text
DWeb Camp attendees relaxing and conversing in inflatable lounge chairs among tall redwood trees, with teal paper lanterns strung overhead and a hammock visible in the background.
🎙️ If you want my very latest thinking on where the #Fediverse and open social web is headed (particularly for creators), I'll be recording a new episode of Future Insider shortly on that very topic, a podcast exclusively for Intuitive+ members.
🏷️ Speaking of Intuitive+, I'm running a 20% off deal until the end of the June! Select the $25 for 6 months option and it'll be only $20 with the coupon MONTHEND20.
FYI this is my main gig right now. So TIA and y'all rock! 🤘
Immer & immer wieder werbe ich auch unter Christdemokratinnen & Christdemokraten für das #Fediverse & konkret für #Mastodon.
Doch ehrlich gesagt vergeht eben auch kaum ein Tag, an dem ich nicht dafür abgeurteilt & beschimpft werde, dass ich Mitglied der #CDU bin. Auch die dualistische Gleichsetzung des Linken - Vorsitzenden Luigi #Pantisano meiner Partei mit dem Faschismus hat hier Widerhall gefunden & gerade Moderaten (sowohl in der Union wie in der Linken) geschadet, die immer wieder Brücken bauen.
Hinzu kommen Accounts, die gegen das GG die Abschaffung des Wahlrechts durch eine sog. „Losdemokratie“ fordern.
Ich erlebe leider: Rechte Reaktanz ist gefährlich, libertäre Gier ist abstoßend und linke Arroganz schlaucht. Mir ist völlig klar, dass die meisten - auch die meisten Linken - hier schon noch dialogisch unterwegs sind. Aber zu viele hier suchen nur Bestätigung in der eigenen Blase & greifen Andersdenkende an. Und das ist & bleibt schade, denn so wird keine echte Vielfalt. https://www.deutschlandfunk.de/pantisano-bittet-fuer-aeusserung-ueber-die-cdu-um-entschuldigung-100.html
Do you think there is still a room for Prismo in fediverse? We have couple of amazing projects already, doing something similar or much more (lemmy and piefed as an examples). Would love to hear your thoughts in the comments!
Kennt ihr diese Argumente gegen das Fediverse? „Unsere Zielgruppe ist nicht dort" – „Zu wenig Kapazitäten" – „Niemand sonst macht es."
Stimmt nicht! 🔸 Es gibt gute Gründe fürs Fediverse, und der Einstieg ist leichter als gedacht.
Unser neuer Praxisleitfaden zeigt Vorteile, Praxisbeispiele & widerlegt häufige Einwände – entstanden mit der Community Nachhaltige Digitalisierung des @umweltministerium & dem @neuSoM
Kennt ihr diese Argumente gegen das Fediverse? „Unsere Zielgruppe ist nicht dort" – „Zu wenig Kapazitäten" – „Niemand sonst macht es."
Stimmt nicht! 🔸 Es gibt gute Gründe fürs Fediverse, und der Einstieg ist leichter als gedacht.
Unser neuer Praxisleitfaden zeigt Vorteile, Praxisbeispiele & widerlegt häufige Einwände – entstanden mit der Community Nachhaltige Digitalisierung des @umweltministerium & dem @neuSoM
i'm Christopher, i live in The Hague, Netherlands! i moved here from Seattle 2.5 years ago to continue my cybersecurity freelancing (entrepreneur visa), and I have been a privacy activist for 16 years, which started with running Tor relays and teaching others how to safely run them too
this effort to radically decentralize hierarchy native to even Mastodon (and other fediverse) instances is something I thought about while running @emeraldonion -- legal demands sent to an operator has no way to meaningfully inform a community about legal threats. if you're interested in helping work on Disobey Discotheque, please reach out, I'm looking to invite Advisory Board members or Trust and Safety Committee members. in the long term, like i am doing with Emerald Onion, I plan on speaking at hacker conferences about this lead-by-example model for building safe fediverse communities!
i'm very interested in meeting and making new friends in and around the Netherlands ^_^ and i am single :3 I'm passionate about many things: my family and friends, science, the internet, blogging, the fediverse, solarpunk, sailing, off-grid engineering, permaculture, hacker spaces and conferences, vegan cooking, coffee, matcha, swimming, yoga, sci-fi, anime, massages, raves, electronic and contemporary-classical music, trains, bicycles, camping, and learning in general!
on a bright sunny day, in June 2026, here is Christopher in a red shirt, dark brown hair, white pale skin, wearing shiny green sun glasses and holding a Sony digital camera. in the background is a rusty bridge wall made out of narrow bars so that you can see through the tall evergreen trees in the background
Dug into the ActivityPub platforms beyond Mastodon with current FediDB numbers (June 2026): Misskey and its fork family, Pleroma and Akkoma, Friendica, GoToSocial, and the Threadiverse.
Misskey's custom emoji culture runs deeper than it sounds. Instances maintain hand-drawn reaction libraries that federate across the network. The closest analogue is early Slack workspace emoji culture, but federated.
Friendica has been federating since 2010 via its own DFRN protocol, Diaspora*, and OStatus. It added ActivityPub in 2019, consistent with its core goal of bridging every federation protocol it can reach.
GoToSocial exists for people who want a personal fediverse presence but find Mastodon too heavy to self-host. 250MB RAM, SQLite, no web client of its own. Runs on a Raspberry Pi.
Part 1 of the "Fediverse beyond Mastodon" series. Part 2 covers the visual fediverse: Pixelfed, Loops, and PeerTube.
Abstract digital art on a dark navy background showing a radial burst of colorful geometric shapes and particles in mint green, coral red, amber, and teal. Scattered sticker-like elements suggest emoji reactions and expressive digital culture. Federated Mind brain logo watermark in the bottom right corner.
Dug into the ActivityPub platforms beyond Mastodon with current FediDB numbers (June 2026): Misskey and its fork family, Pleroma and Akkoma, Friendica, GoToSocial, and the Threadiverse.
Misskey's custom emoji culture runs deeper than it sounds. Instances maintain hand-drawn reaction libraries that federate across the network. The closest analogue is early Slack workspace emoji culture, but federated.
Friendica has been federating since 2010 via its own DFRN protocol, Diaspora*, and OStatus. It added ActivityPub in 2019, consistent with its core goal of bridging every federation protocol it can reach.
Part 1 of the "Fediverse Beyond Mastodon" series inside the greater "Exploring the Fediverse" series. Part 2 will cover the visual fediverse: Pixelfed, Loops, and PeerTube.
Abstract digital art on a dark navy background showing a radial burst of colorful geometric shapes and particles in mint green, coral red, amber, and teal. Scattered sticker-like elements suggest emoji reactions and expressive digital culture. Federated Mind brain logo watermark in the bottom right corner.
Dug into the ActivityPub platforms beyond Mastodon with current FediDB numbers (June 2026): Misskey and its fork family, Pleroma and Akkoma, Friendica, GoToSocial, and the Threadiverse.
Misskey's custom emoji culture runs deeper than it sounds. Instances maintain hand-drawn reaction libraries that federate across the network. The closest analogue is early Slack workspace emoji culture, but federated.
Friendica has been federating since 2010 via its own DFRN protocol, Diaspora*, and OStatus. It added ActivityPub in 2019, consistent with its core goal of bridging every federation protocol it can reach.
GoToSocial exists for people who want a personal fediverse presence but find Mastodon too heavy to self-host. 250MB RAM, SQLite, no web client of its own. Runs on a Raspberry Pi.
Part 1 of the "Fediverse beyond Mastodon" series. Part 2 covers the visual fediverse: Pixelfed, Loops, and PeerTube.
Abstract digital art on a dark navy background showing a radial burst of colorful geometric shapes and particles in mint green, coral red, amber, and teal. Scattered sticker-like elements suggest emoji reactions and expressive digital culture. Federated Mind brain logo watermark in the bottom right corner.
Do you think there is still a room for Prismo in fediverse? We have couple of amazing projects already, doing something similar or much more (lemmy and piefed as an examples). Would love to hear your thoughts in the comments!
Do you think there is still a room for Prismo in fediverse? We have couple of amazing projects already, doing something similar or much more (lemmy and piefed as an examples). Would love to hear your thoughts in the comments!
I have tried every way I can to establish a private instance for all of my #fediverse and #socialnetworking needs. I've tried Hubzilla, GNUSocial, and Friendica, but maintaining the cost of a virtual private server isn't justifiable to me and those apps don't play well with shared hosting, which is all I can afford right now (and I don't have the space to set up a personal server).
The fact of the matter is that the only self-hosted application that checks the boxes of being a) dead simple to install on shared hosting--preferably through Softaculous since I just don't feel like jumping through hoops, b) well-supported, c) easy to use, and d) able to connect with both ActivityPub and AT protocols is WordPress, which I am reluctant to use because Matt Mullenweg is a pretty detestable as a human.
That said, I am holding my nose and using WordPress as my social networking hub until and unless something that isn't tainted with Mullenweg's nonsense comes along, so here I be.
I am rebuilding my profile and follow lists, and I apologize to those of you who seem to get a new follow request from me every other day, but I plan on this being the last time until the unlikely WordPress-killer comes around.
I have tried every way I can to establish a private instance for all of my #fediverse and #socialnetworking needs. I've tried Hubzilla, GNUSocial, and Friendica, but maintaining the cost of a virtual private server isn't justifiable to me and those apps don't play well with shared hosting, which is all I can afford right now (and I don't have the space to set up a personal server).
The fact of the matter is that the only self-hosted application that checks the boxes of being a) dead simple to install on shared hosting--preferably through Softaculous since I just don't feel like jumping through hoops, b) well-supported, c) easy to use, and d) able to connect with both ActivityPub and AT protocols is WordPress, which I am reluctant to use because Matt Mullenweg is a pretty detestable as a human.
That said, I am holding my nose and using WordPress as my social networking hub until and unless something that isn't tainted with Mullenweg's nonsense comes along, so here I be.
I am rebuilding my profile and follow lists, and I apologize to those of you who seem to get a new follow request from me every other day, but I plan on this being the last time until the unlikely WordPress-killer comes around.
Do you think there is still a room for Prismo in fediverse? We have couple of amazing projects already, doing something similar or much more (lemmy and piefed as an examples). Would love to hear your thoughts in the comments!
- Iceshrimp : trop lourd niveau RAM (3,50go et il en faut au moins 4 pour installer/mettre à jour), trop chiant à maintenir (toujours impossible de maj mon instance ...), la réécriture n'est "toujours" pas prête, pas de scrap pour aller chercher les réponses aux posts des autres instances, pareil pour les profils. Le drive c'est cool le gain de place surtout si comme moi on aime les GIF et ça n'existe nul par ailleurs (outre Misskey et donc ses forks). Déménager semble complètement "péter", fonctionne qu'a moitier ... joie
- Hollo : trop lourd aussi en RAM (2,50go et pour le moment il faut au minimum 3go pour mettre à jour la chose), et toujours pas de client web avec support des réactions (coucou phanpy, réactions uniquement en lecture) ... pourtant ça récupère les info des instances distante sur les post et les profils.
- Mitra : ultra léger, paquet debian, bon j'aime pas trop le coté cryptomonaie mais why not vu que tu peux faire payer pour du contenu (pour celles et ceux que ça interesse), mais pas de scrap pour aller chercher les réponses aux posts des autres instances, pareil pour les profils. Client web de base sympa mais très loins de Phanpy mais qui ne supporte toujours pas les réactions (réactions uniquement en lecture), a priori y aurait du déménagement de compte mais forcément faut que l'instance vers laquelle on déménage support donc ... bah wala quoi
Du coup revenir sur à la base sur Misskey ? je ne sais pas comment ça à évoluer (compatibilité avec les reste du fediverse) depuis mais y avait plus trop d'européen•nes dessus après la tétrachier de fork qui a vu le jour.
Non je ne remettrais pas les pied sur Mastodon pour plein de raison. Go To Social hmm bof bof.
Also, these are some stills from the most recent #AnimationArray episode on https://tv.theindiebeat.fm. Each still represents an incredible piece of animation sent in by folks from the #Fediverse and beyond (probably Bluesky).
Also, these are some stills from the most recent #AnimationArray episode on https://tv.theindiebeat.fm. Each still represents an incredible piece of animation sent in by folks from the #Fediverse and beyond (probably Bluesky).
The good, the bad, and the ugly of running a fediverse server for the past four years, from @gfsc.
"Rather than getting mad at Bluesky for taking over the debate, the fediverse needs to look at itself and ask who it’s including, who it’s excluding, and how it can actually become a transformative social network, rather than a technological toy for computer programmers."
The good, the bad, and the ugly of running a fediverse server for the past four years, from @gfsc.
"Rather than getting mad at Bluesky for taking over the debate, the fediverse needs to look at itself and ask who it’s including, who it’s excluding, and how it can actually become a transformative social network, rather than a technological toy for computer programmers."
Danke #Fediverse fuer das sensationelle Feedback: Das wichtigste an den #wsocial Veroeffentlichungen war tatsaechlich, dass nun wirklich so viele tausende User:innen sehen konnten, wie dort reinstes Nichts verpackt wurde.
Und diese User:innen buddeln weiter & stellen Fragen.
Ich kann euch versichern, dass da in den naechsten Tagen noch einiges rauskommen wird, was von der Leyen und Co. ziemlich bedroeppelt aussehen laesst.
The good, the bad, and the ugly of running a fediverse server for the past four years, from @gfsc.
"Rather than getting mad at Bluesky for taking over the debate, the fediverse needs to look at itself and ask who it’s including, who it’s excluding, and how it can actually become a transformative social network, rather than a technological toy for computer programmers."
#fediverse I'm looking for #rss feeds to subscribe to. I'm interested in tech, homelabs, self hosting, travel, personal blogs, hacking. Please no AI created content. Please send me recommendations!
Danke #Fediverse fuer das sensationelle Feedback: Das wichtigste an den #wsocial Veroeffentlichungen war tatsaechlich, dass nun wirklich so viele tausende User:innen sehen konnten, wie dort reinstes Nichts verpackt wurde.
Und diese User:innen buddeln weiter & stellen Fragen.
Ich kann euch versichern, dass da in den naechsten Tagen noch einiges rauskommen wird, was von der Leyen und Co. ziemlich bedroeppelt aussehen laesst.
Yesterday X accounts of many LGBTI+ organizations are closed in Türkiye. So today we are going to continue our Fediverse migration campaign for queer communities in Türkiye. We are going to suggest safe #Fediverse#instances for them. Do you have any suggestions? And would invite-only instances like to help this cause?
A two-by-two grid of animated gifs, in four variations in dark/light colors with and without borders, each GIF showing translation of the word fediverse in various languages.
A two-by-two grid of animated gifs, in four variations in dark/light colors with and without borders, each GIF showing translation of the word fediverse in various languages.
Dear #fediverse. Is there a way to search posts only from a specific instance? I like my instance but could do more #eu content on my feed. My app of choice is #moshidon if that makes a difference
Summer is here, and sadly it is peak season for pet abandonment. #PawFed is a federated map for animal welfare built on #ActivityPub and #OSM.
It already shows shelters and vets near you. Found an abandoned animal or need help? Mention @PawFed from any #Fediverse account: a pin lands on the map, and your call is relayed across the #Fediverse, whatever your instance.
Summer is here, and sadly it is peak season for pet abandonment. #PawFed is a federated map for animal welfare built on #ActivityPub and #OSM.
It already shows shelters and vets near you. Found an abandoned animal or need help? Mention @PawFed from any #Fediverse account: a pin lands on the map, and your call is relayed across the #Fediverse, whatever your instance.
Summer is here, and sadly it is peak season for pet abandonment. #PawFed is a federated map for animal welfare built on #ActivityPub and #OSM.
It already shows shelters and vets near you. Found an abandoned animal or need help? Mention @PawFed from any #Fediverse account: a pin lands on the map, and your call is relayed across the #Fediverse, whatever your instance.
Summer is here, and sadly it is peak season for pet abandonment. #PawFed is a federated map for animal welfare built on #ActivityPub and #OSM.
It already shows shelters and vets near you. Found an abandoned animal or need help? Mention @PawFed from any #Fediverse account: a pin lands on the map, and your call is relayed across the #Fediverse, whatever your instance.
A quick overview of the asterisms in the LettError fonts. All new titles have have the symbol and I will add them to older ones when useful. I prefer the asterisk with 5 strokes. For LTR Very Bauble the bottom asterisks are rotated inward to create the triangular counter. This is a pretty illusion. For CT Action Grotesque the legibility at 7pt was more important. It is a complex shape and I want to it do its job at scale. By moving the bottom asterisks outward, they create some room for the top asterisk. The whole symbol becomes a bit wider, especially in the heavier weights. Click on the images to 👀 inspect details, some nice outline details in both typefaces, if that is your cup of tea. #fediverse#asterism#fonts#typedesign
Dear #fediverse. Is there a way to search posts only from a specific instance? I like my instance but could do more #eu content on my feed. My app of choice is #moshidon if that makes a difference
Whereas #ActivityPub is rich email, where we can represent anything, be it an Invoice, Order confirmation, Postal package tracker, Train ticket, Concert booking, Restaurant reservation, Shopping list, Cooking recipe, Science paper, Academic citation, Sport coverage, Adventure game ..
Just had the most horrifying UX parsing this thread in Mastodon's microblog feed, likely causing 10x more network overhead than needed, and replied to @cwebber quote:
Stepping away from ATProto vs. AP I was most intrigued by @dialecticalmusings comment:
> People arguing about moderation and community building often have fundamentally differing visions for the political economy of the Fediverse, but those differences never get unpacked, so people end up talking past each other.
What is never answered well is: What is fediverse? I'd argue it is just a common utility word like internet and web, denoting a communication medium.
What do you do with this medium is then the next question. Well, the power of ActivityPub allows us "to extend constructs of society online" to support our daily needs.
But on the basis of some warped microblog abstraction turned into a pretzel by bolting on features to hang everything off, this is not possible.
A quick overview of the asterisms in the LettError fonts. All new titles have have the symbol and I will add them to older ones when useful. I prefer the asterisk with 5 strokes. For LTR Very Bauble the bottom asterisks are rotated inward to create the triangular counter. This is a pretty illusion. For CT Action Grotesque the legibility at 7pt was more important. It is a complex shape and I want to it do its job at scale. By moving the bottom asterisks outward, they create some room for the top asterisk. The whole symbol becomes a bit wider, especially in the heavier weights. Click on the images to 👀 inspect details, some nice outline details in both typefaces, if that is your cup of tea. #fediverse#asterism#fonts#typedesign
Hallo liebes #fediverse 👋 für @netzpolitik_feed recherchiere ich gerade zur Schul-App Sdui. dafür such ich Menschen, die die App nutzen - als Elternteil, Schüler:in oder Lehrkraft - und die mir von ihren Nutzungserfahrungen erzählen wollen. freu mich, wenn ihr mir schreibt; gerne hier über Privatnachricht (oder E-Mail an esther.menhard[at]netzpolitik.org) #FediLZ
A quick overview of the asterisms in the LettError fonts. All new titles have have the symbol and I will add them to older ones when useful. I prefer the asterisk with 5 strokes. For LTR Very Bauble the bottom asterisks are rotated inward to create the triangular counter. This is a pretty illusion. For CT Action Grotesque the legibility at 7pt was more important. It is a complex shape and I want to it do its job at scale. By moving the bottom asterisks outward, they create some room for the top asterisk. The whole symbol becomes a bit wider, especially in the heavier weights. Click on the images to 👀 inspect details, some nice outline details in both typefaces, if that is your cup of tea. #fediverse#asterism#fonts#typedesign
Hallo liebes #fediverse 👋 für @netzpolitik_feed recherchiere ich gerade zur Schul-App Sdui. dafür such ich Menschen, die die App nutzen - als Elternteil, Schüler:in oder Lehrkraft - und die mir von ihren Nutzungserfahrungen erzählen wollen. freu mich, wenn ihr mir schreibt; gerne hier über Privatnachricht (oder E-Mail an esther.menhard[at]netzpolitik.org) #FediLZ
A quick overview of the asterisms in the LettError fonts. All new titles have have the symbol and I will add them to older ones when useful. I prefer the asterisk with 5 strokes. For LTR Very Bauble the bottom asterisks are rotated inward to create the triangular counter. This is a pretty illusion. For CT Action Grotesque the legibility at 7pt was more important. It is a complex shape and I want to it do its job at scale. By moving the bottom asterisks outward, they create some room for the top asterisk. The whole symbol becomes a bit wider, especially in the heavier weights. Click on the images to 👀 inspect details, some nice outline details in both typefaces, if that is your cup of tea. #fediverse#asterism#fonts#typedesign
Heute (Montag, 22.06.2026) um 🕢 19:30 Uhr treffen wir uns wieder zur Fediverse-Sprechstunde.
Diesmal werfen wir gemeinsam einen Blick auf BookWyrm – die föderierte Plattform für Bücherfreunde, Leseratten und Literaturbegeisterte im Fediverse. 📖✨
Ein besonderes Dankeschön an @crossgolf_rebel , der uns BookWyrm vorstellen und seine Erfahrungen mit uns teilen wird.
Egal ob ihr BookWyrm bereits nutzt, eine eigene Instanz betreibt oder einfach neugierig seid: Ihr seid herzlich willkommen!
🤝 Fragen stellen 📚 Erfahrungen austauschen 🌱 Neues entdecken 🌐 Das Fediverse gemeinsam stärken
Wir freuen uns auf viele Teilnehmende und einen spannenden Austausch.
Heute (Montag, 22.06.2026) um 🕢 19:30 Uhr treffen wir uns wieder zur Fediverse-Sprechstunde.
Diesmal werfen wir gemeinsam einen Blick auf BookWyrm – die föderierte Plattform für Bücherfreunde, Leseratten und Literaturbegeisterte im Fediverse. 📖✨
Ein besonderes Dankeschön an @crossgolf_rebel , der uns BookWyrm vorstellen und seine Erfahrungen mit uns teilen wird.
Egal ob ihr BookWyrm bereits nutzt, eine eigene Instanz betreibt oder einfach neugierig seid: Ihr seid herzlich willkommen!
🤝 Fragen stellen 📚 Erfahrungen austauschen 🌱 Neues entdecken 🌐 Das Fediverse gemeinsam stärken
Wir freuen uns auf viele Teilnehmende und einen spannenden Austausch.
I'm a programmer by trade, currently on a long break from a regular job. I haven't used social media in any serious capacity for 17 years, but with all excitement about fediverse I'm willing to give Mastodon a try :-)
I'll write about whatever comes to mind, but mostly it'll be about personal projects (I'm building an RSS reader), music production (very new to this, been learning a ton), free software, internet, privacy, and some other things.
I'm a programmer by trade, currently on a long break from a regular job. I haven't used social media in any serious capacity for 17 years, but with all excitement about fediverse I'm willing to give Mastodon a try :-)
I'll write about whatever comes to mind, but mostly it'll be about personal projects (I'm building an RSS reader), music production (very new to this, been learning a ton), free software, internet, privacy, and some other things.
What many people misunderstand about hosting your own content (like this social media instance) is thinking we somehow NEED a big audience or Big Tech involvement.
I'm perfectly fine if the world faded away and it was just the thousand of us here. It's like the early days of the web when we had small forums, nobody missed Reddit back then. Federation is a big plus, not a requirement.
It's the same with websites or IRC for me. I know people use Discord, but I still stick to IRC even if there are only about a hundred of us left. I know people use AI now and website visitors are dropping, but who cares? I still keep doing it for those who like to read.
I don't need the whole world involved for this to feel worthwhile. It's mine, I own it, and I host it for as long as I breathe. After that, it won't matter to me anymore, but I hope other admins keep things running the way I did.
Hallo liebes #fediverse 👋 für @netzpolitik_feed recherchiere ich gerade zur Schul-App Sdui. dafür such ich Menschen, die die App nutzen - als Elternteil, Schüler:in oder Lehrkraft - und die mir von ihren Nutzungserfahrungen erzählen wollen. freu mich, wenn ihr mir schreibt; gerne hier über Privatnachricht (oder E-Mail an esther.menhard[at]netzpolitik.org) #FediLZ
Hallo liebes #fediverse 👋 für @netzpolitik_feed recherchiere ich gerade zur Schul-App Sdui. dafür such ich Menschen, die die App nutzen - als Elternteil, Schüler:in oder Lehrkraft - und die mir von ihren Nutzungserfahrungen erzählen wollen. freu mich, wenn ihr mir schreibt; gerne hier über Privatnachricht (oder E-Mail an esther.menhard[at]netzpolitik.org) #FediLZ
I'm a programmer by trade, currently on a long break from a regular job. I haven't used social media in any serious capacity for 17 years, but with all excitement about fediverse I'm willing to give Mastodon a try :-)
I'll write about whatever comes to mind, but mostly it'll be about personal projects (I'm building an RSS reader), music production (very new to this, been learning a ton), free software, internet, privacy, and some other things.
Hello there am joshua Kevin's the coordinator of the nutritious foods Uganda https:// gravatar.com/nutritiousfoodsug anda
We have been able to teach almost 250 youths in our village last year. We make sure that we teach the youth how to grow crops in small spaces #urban . You can now donate to our projects by buying us a coffee over here https:// ko-fi.com/joshuakevins12/goal? g=0 YOUR TIP COUNTS #solarpunk#solarpunksunday#fediverse#mastodon#grdening#linux@GarDenIng BOOSTSWELCOME
Hello there am joshua Kevin's the coordinator of the nutritious foods Uganda https:// gravatar.com/nutritiousfoodsug anda
We have been able to teach almost 250 youths in our village last year. We make sure that we teach the youth how to grow crops in small spaces #urban . You can now donate to our projects by buying us a coffee over here https:// ko-fi.com/joshuakevins12/goal? g=0 YOUR TIP COUNTS #solarpunk#solarpunksunday#fediverse#mastodon#grdening#linux@GarDenIng BOOSTSWELCOME
What many people misunderstand about hosting your own content (like this social media instance) is thinking we somehow NEED a big audience or Big Tech involvement.
I'm perfectly fine if the world faded away and it was just the thousand of us here. It's like the early days of the web when we had small forums, nobody missed Reddit back then. Federation is a big plus, not a requirement.
It's the same with websites or IRC for me. I know people use Discord, but I still stick to IRC even if there are only about a hundred of us left. I know people use AI now and website visitors are dropping, but who cares? I still keep doing it for those who like to read.
I don't need the whole world involved for this to feel worthwhile. It's mine, I own it, and I host it for as long as I breathe. After that, it won't matter to me anymore, but I hope other admins keep things running the way I did.
People who follow unofficial mirrored accounts from other platforms (mainly X, I suppose), do you ever reach out showing them that they have followers and missed replies on here?
The importance of federated social media should not be underestimated. The concept of data sovereignty offers users the opportunity to break free from Big Tech corporations. The ActivePub integration also provides content creators, such as freelancers, musicians, artists and journalists, with a global reach. So, I highly recommend joining Loops Video! #fediverse#nobigtech#socialmedia#democracy#europe#sovereignty https://joinloops.org/
The importance of federated social media should not be underestimated. The concept of data sovereignty offers users the opportunity to break free from Big Tech corporations. The ActivePub integration also provides content creators, such as freelancers, musicians, artists and journalists, with a global reach. So, I highly recommend joining Loops Video! #fediverse#nobigtech#socialmedia#democracy#europe#sovereignty https://joinloops.org/
🌐 Multi-language Support Switch between Japanese, English, Chinese, and Korean instantly via the language selector (JA/EN/ZH/KO).
🔤 Translation Feature Translate questions and answers with a single 🌐 click. Uses LibreTranslate via our backend — toggle between original and translated text seamlessly.
Now more accessible to Fediverse users worldwide. Give it a try!
🌐 Multi-language Support Switch between Japanese, English, Chinese, and Korean instantly via the language selector (JA/EN/ZH/KO).
🔤 Translation Feature Translate questions and answers with a single 🌐 click. Uses LibreTranslate via our backend — toggle between original and translated text seamlessly.
Now more accessible to Fediverse users worldwide. Give it a try!
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
Yesterday X accounts of many LGBTI+ organizations are closed in Türkiye. So today we are going to continue our Fediverse migration campaign for queer communities in Türkiye. We are going to suggest safe #Fediverse#instances for them. Do you have any suggestions? And would invite-only instances like to help this cause?
A subset of drafters (i.e., who didn't need anonymity: @karen, @zacchiro¹, @johns¹, & @ossguy²) are long-term (≥ 1yr) dedicated to public engagement (schedules permitting).
But not just here! We got podcast, vidcasts, AMAs, public Q&As, conference panels and talks — all on the way!
A subset of drafters (i.e., who didn't need anonymity: @karen, @zacchiro¹, @johns¹, & @ossguy²) are long-term (≥ 1yr) dedicated to public engagement (schedules permitting).
But not just here! We got podcast, vidcasts, AMAs, public Q&As, conference panels and talks — all on the way!
A tortoiseshell cat with black and orange fur lying on a white bed sheet, its tail draped across the neck and fretboard of an electric guitar resting beside it.
A tortoiseshell cat with black and orange fur lying on a white bed sheet, its tail draped across the neck and fretboard of an electric guitar resting beside it.
So I usually hate sending over bluesky links anywhere since I'm not a fan, but Rob Ricci highlights some important distinctions between #activitypub and #atproto
Fundamentally, activitypub is designed to be useful with a partial view of the network. (Narrowing down to #mastodon here) Likes are communicated, mentions are communicated, and so on.
Over at atproto land, you have no option but to write to your repo, and so you have no choice but to view the entire network to say, find replies and such (narrowing to #bluesky here). So the only way you can get your data is to read the network and filter it yourself, or have someone else do it for you, which doesn't solve the problem, only shift it.
So I usually hate sending over bluesky links anywhere since I'm not a fan, but Rob Ricci highlights some important distinctions between #activitypub and #atproto
Fundamentally, activitypub is designed to be useful with a partial view of the network. (Narrowing down to #mastodon here) Likes are communicated, mentions are communicated, and so on.
Over at atproto land, you have no option but to write to your repo, and so you have no choice but to view the entire network to say, find replies and such (narrowing to #bluesky here). So the only way you can get your data is to read the network and filter it yourself, or have someone else do it for you, which doesn't solve the problem, only shift it.
@innocentzero@social.tchncs.de · Reply to InnocentZero
Having said that, and also disliking the fact that it came out of corpo billionaire creators of twitter, I genuinely believe there's some good stuff to pick up from that protocol.
In particular, I think the coolest part of the architecture is server-independent (more like server-migratable) identity, which is kind of amazing.
Activitypub/fediverse should adopt https://helge.codeberg.page/fep/fep/ef61/ soon, and I feel like that'd be even better than what atproto has if I understand correctly.
A two-by-two grid of animated gifs, in four variations in dark/light colors with and without borders, each GIF showing translation of the word fediverse in various languages.
A two-by-two grid of animated gifs, in four variations in dark/light colors with and without borders, each GIF showing translation of the word fediverse in various languages.
After Bluesky, Threads, and so on, the whole #WSocial thing is another reminder that it was never about the #Fediverse being "too complicated" or "just for nerds".
A bafflingly large amount of people genuinely only act on a gut feeling telling them that only commercial products with fancy marketing owned by a for-profit corporation can be trustworthy, 'official' and 'legal', for the lack of a better word.
If something is a commercial offering by a competent-looking, rich family man in a suit, it's clearly an official, legal, trustworthy product. You can be proud of using such a fancy-looking service.
When they see a community-run open-source project or a grassroots initiative, their first instinct is that it must be shady, illegal, complicated, broken or predatory in some way. It's probably some aftermarket grey area bootleg made by weird tech nerds, political groups with an ulterior motive, conspiracy theorists or some naive teenage hackers. They'd also be embarrassed for using it in front of their peers and neighbours; who uses some free back-alley software, are you poor or something?
The same people are the reason why Google is using the word 'sideloading', why scammers love wearing fancy suits, why people suddenly act childishly helpless in front of LibreOffice, or why DIY HRT is so demonised.
They trust any kind of 'official approval' over their own senses. If someone does something that isn't 'approved', they're a bad person or clearly endangering themselves and others. No idea why exactly, but psh, it must be wrong somehow, or everyone would do it, right?
If people on the Fediverse understood that the whole "it's all so complicated and clunky" thing is just a thinly veiled excuse for a general disdain for non-commercial software, we could finally stop making all our software imitate their corporate equivalents in a futile attempt to appease people who never gave us a chance in the first place.
You'll never convince them to treat it in good faith no matter how much effort or money you put into UX or 'ease of use'. All you're doing is making the software worse, e. g. through things like dot-social, verified accounts or begging brands, corporations and politicians to join and give your product some kind of 'official' validation.
Hallo liebes #Fediverse, hab wieder mal ein Problem.
Mein Samsung Smartphone hat sich upgedatet (UI Version 8.5). Seither kann ich am Windows-PC (Ja eh, Windows, kreuzigt mich!) die M4A-Dateien, die ich mit der Diktier-App am Smartphone erstelle, nicht mehr abspielen. Die Spalte "Länge" bleibt im Windows Explorer leer, also Windows erkennt sie nicht.
Jetzt hab ich ergoogelt, dass hier Codecs helfen könnten. Aber ich finde nichts Passendes, bloß, dass man die in W11 eig nicht braucht.
A torbie cat with short fur lounging on dark blue bedsheets. The cat has brown and black stripes with orange patches on its face, chest, and leg, plus a small white patch on its chin. It's lying in a relaxed pose with front paws extended, looking directly at the camera with alert yellowish-green eyes. A patterned brown and white blanket is visible in the background.
A torbie cat with short fur lounging on dark blue bedsheets. The cat has brown and black stripes with orange patches on its face, chest, and leg, plus a small white patch on its chin. It's lying in a relaxed pose with front paws extended, looking directly at the camera with alert yellowish-green eyes. A patterned brown and white blanket is visible in the background.
A tortoiseshell-and-white cat with black and orange fur resting in a grey carpeted cat tree. The cat has an asymmetrical face with black on the left side and orange on the right, a white blaze on the nose, and white chest. Pale green eyes and long white whiskers. Lying in a loaf position next to a sisal rope post, with bright window light backlighting from behind.
A tortoiseshell-and-white cat with black and orange fur resting in a grey carpeted cat tree. The cat has an asymmetrical face with black on the left side and orange on the right, a white blaze on the nose, and white chest. Pale green eyes and long white whiskers. Lying in a loaf position next to a sisal rope post, with bright window light backlighting from behind.
🌐 Multi-language Support Switch between Japanese, English, Chinese, and Korean instantly via the language selector (JA/EN/ZH/KO).
🔤 Translation Feature Translate questions and answers with a single 🌐 click. Uses LibreTranslate via our backend — toggle between original and translated text seamlessly.
Now more accessible to Fediverse users worldwide. Give it a try!
🌐 Multi-language Support Switch between Japanese, English, Chinese, and Korean instantly via the language selector (JA/EN/ZH/KO).
🔤 Translation Feature Translate questions and answers with a single 🌐 click. Uses LibreTranslate via our backend — toggle between original and translated text seamlessly.
Now more accessible to Fediverse users worldwide. Give it a try!
#Lazyweb When I want to spin up my own #Fediverse instance that supports #Markdown when composing a post and that can handle my significant amount of followers with a seamless migration from my current #Mastodon instance, which #ActivityPub Implementation would you use? Ideally it should be a simple rootless container setup that JustWorks™ with podman. Perfection would be a single, self-contained container without the need to spin up several ones for databases or other stuff.
So I usually hate sending over bluesky links anywhere since I'm not a fan, but Rob Ricci highlights some important distinctions between #activitypub and #atproto
Fundamentally, activitypub is designed to be useful with a partial view of the network. (Narrowing down to #mastodon here) Likes are communicated, mentions are communicated, and so on.
Over at atproto land, you have no option but to write to your repo, and so you have no choice but to view the entire network to say, find replies and such (narrowing to #bluesky here). So the only way you can get your data is to read the network and filter it yourself, or have someone else do it for you, which doesn't solve the problem, only shift it.
@innocentzero@social.tchncs.de · Reply to InnocentZero
Having said that, and also disliking the fact that it came out of corpo billionaire creators of twitter, I genuinely believe there's some good stuff to pick up from that protocol.
In particular, I think the coolest part of the architecture is server-independent (more like server-migratable) identity, which is kind of amazing.
Activitypub/fediverse should adopt https://helge.codeberg.page/fep/fep/ef61/ soon, and I feel like that'd be even better than what atproto has if I understand correctly.
While having an extremely snobbish and arrogant tone, I think it makes some good points about separating hosting from viewing, which I think the usual #fediverse sort of conflates. And while the doesn't doesn't cover it, #atproto also has the unique feature of your data being relatively portable, largely absent in #fediverse.
So I usually hate sending over bluesky links anywhere since I'm not a fan, but Rob Ricci highlights some important distinctions between #activitypub and #atproto
Fundamentally, activitypub is designed to be useful with a partial view of the network. (Narrowing down to #mastodon here) Likes are communicated, mentions are communicated, and so on.
Over at atproto land, you have no option but to write to your repo, and so you have no choice but to view the entire network to say, find replies and such (narrowing to #bluesky here). So the only way you can get your data is to read the network and filter it yourself, or have someone else do it for you, which doesn't solve the problem, only shift it.
Don't get me wrong, a lot of fediverse developers do not want millions of users, they are designing their software carefully for them and people like them.
I'm a dreamer, and love to think bigger, and build platforms with millions and even billions of people.
Both types of devs and projects can thrive, because we give the people control and power.
That is what matters, nobody can control this, not even me or mastodon.social
#HolosDiscover now indexes #PeerTube videos. You can find them in search and timelines, but the way they look still needs some work. A video is not the same kind of #ActivityPub object as a normal post. A post is a short text made to be read in the timeline. A video has a title, a long description, and a media file, so it should be shown as a video card with a thumbnail and a link, not as plain text. That part is coming next.
So sehr ich das #Fediverse als Technologie liebe, bin ich der festen Überzeugung, dass die Föderation es schwer macht Gleichgesinnte zu finden.
Mein Gedanke zum Thema: Das dezentrale System bringt das Problem mit sich, dass es keine zentrale Anlaufstelle gibt. Vorteile gibt es natürlich genügend, doch dieser Nachteil ist die - meiner Meinung nach - derzeitig größte Schwachstelle des Fediverses.
Irgendwo möchte man hier ja auch Leute erreichen, und ich spreche nicht davon, Influencer zu werden. Wenn man keine Interaktion möchte, würde ein Tagebuch ja auch ausreichen. Sicherlich möchte man irgendwo gelesen werden oder anderen Leuten mit seinen Bildern eine Freude bereiten.
Wir sind hier in tausend verschiedenen Ecken verteilt - auf verschiedenen Fediverse-Plattformen unterwegs, auf unterschiedlichen Instanzen - das, wofür das Fediverse immer angepriesen wird. Und sind wir mal ehrlich, wir Admins kochen irgendwo alle unser eigenes Süppchen, auch wenn man einfach einem vorhanden Server beitreten hätte können.
Die Wahrscheinlichkeit ist hoch, nicht voneinander zu erfahren, wenn uns niemand "einander vorstellt", sei es über Boosts oder Erwähnungen. Ich selber folge keinen Accounts, die ohne Zusammenhang alles boosten, was sie toll finden. Wir Menschen sind verdammt vielschichtig. Während ich Thema A, B und C toll finde, boostet jemand dem ich folge Zeug zu den Themen C, D und E. Mit anderen Worten: Ein drittel der Boosts interessieren mich... und der Rest ist mir Schnuppe. Die Timeline ist dann nicht mehr "auf mich zugeschnitten", wie ich sie haben möchte, abgesehen davon, dass ich Thema E verabscheue. Daraus folgt, die Boosts der Person stummzuschalten... oder Hashtags stummschalten, die nicht zuverlässig verwendet werden? Wörter stummschalten? Diese Wörter könnten ja auch spontan für einen Witz verwendet werden - einen Witz, den man dann doch gerne gelesen hätte.
Wir haben hier noch keine zuverlässige Methode, einen Post zu einem bestimmten Thema über zumindest einen Großteil des Fediverses zu transportieren.
Lemmy unterstützt Communitys, welche für Nicht-Lemmy-Nutzer ein einfacher Fediverse-Account ist, der deinen Post boostet, wenn du ihn in deinem Post erwähnst. Ich war am überlegen eine Lemmy Instanz aufzumachen, nur um diese Communitys / Gruppen zu erstellen. Doch wer würde das schon nutzen, außer mir? Ich wäre erneut ein Admin, der sein eigenes Süppchen kocht.
Ich zerbreche mir den Kopf darüber, das Fediverse mit den vorhandenen Tools miteinander besser zu verknüpfen wie Lemmy Communitys, dessen Instanz keinem einzigen Admin gehört. Das Konzept dieser Lemmy Communitys ist großartig und Fediverse kompatibel. Diese Boost-Accounts gibt es ja bereits länger, doch ich sehe nicht, dass diese auch aktiv von Nutzern verwendet werden. Wenn dieser Account automatisch Hashtags boostet, landet nicht selten ziemlich viel Schrott in der Timeline.
Comic of kid asking mom 'Mommy, what is fediverse?" Mom, says "Don't look at them, Ricky. I don't want you influenced by... Oh, god, no!" Next frame has Ricky in pink-tint heart-shaped glasses and festooned with tax-the-rich, environmental, FOSS and other logographics to do with common fediverse causes, saying: "It is too late, mother - I have seen everything."
#Lazyweb When I want to spin up my own #Fediverse instance that supports #Markdown when composing a post and that can handle my significant amount of followers with a seamless migration from my current #Mastodon instance, which #ActivityPub Implementation would you use? Ideally it should be a simple rootless container setup that JustWorks™ with podman. Perfection would be a single, self-contained container without the need to spin up several ones for databases or other stuff.
Preise bleiben stabil für Dich! / Price guarantee for our loyal customers! --------------
[DE] Der weltweite KI-Boom sorgt aktuell für explodierende Hardware-Kosten (vor allem bei RAM & SSDs). Große Provider wie Hetzner u.a. haben ihre Server-Preise deshalb bereits drastisch erhöht – viele Anbieter ziehen vermutlich ab September nach. Die gute Nachricht für Dich: Für alle meine bestehenden Managed #Fediverse Kunden bleibt alles wie gewohnt. Es gibt keine Preiserhöhung für Dich! Danke für Dein Vertrauen! 🤝
[EN] The global AI boom is driving up hardware costs (especially RAM & SSDs). Major providers like Hetzner have already heavily increased server prices, and others will likely follow by September. The good news: For my existing managed Fediverse customers, everything stays exactly the same. There will be no price increase for you! Thank you for your continued trust! 🤝
Preise bleiben stabil für Dich! / Price guarantee for our loyal customers! --------------
[DE] Der weltweite KI-Boom sorgt aktuell für explodierende Hardware-Kosten (vor allem bei RAM & SSDs). Große Provider wie Hetzner u.a. haben ihre Server-Preise deshalb bereits drastisch erhöht – viele Anbieter ziehen vermutlich ab September nach. Die gute Nachricht für Dich: Für alle meine bestehenden Managed #Fediverse Kunden bleibt alles wie gewohnt. Es gibt keine Preiserhöhung für Dich! Danke für Dein Vertrauen! 🤝
[EN] The global AI boom is driving up hardware costs (especially RAM & SSDs). Major providers like Hetzner have already heavily increased server prices, and others will likely follow by September. The good news: For my existing managed Fediverse customers, everything stays exactly the same. There will be no price increase for you! Thank you for your continued trust! 🤝
Don't get me wrong, a lot of fediverse developers do not want millions of users, they are designing their software carefully for them and people like them.
I'm a dreamer, and love to think bigger, and build platforms with millions and even billions of people.
Both types of devs and projects can thrive, because we give the people control and power.
That is what matters, nobody can control this, not even me or mastodon.social
Seeing the comments under this post is wildly discouraging. I left twitter precisely because of this type of pile-on holier-than-thou behavior.
The commission is present across a multitude of social networks including the Fediverse (where their presence is growing), #Wsocial (ATproto), and other proprietary non-federated social media sites.
Do the commenters here really believe that their comments are advancing the interests of the #Fediverse or Open Source ?
Comic of kid asking mom 'Mommy, what is fediverse?" Mom, says "Don't look at them, Ricky. I don't want you influenced by... Oh, god, no!" Next frame has Ricky in pink-tint heart-shaped glasses and festooned with tax-the-rich, environmental, FOSS and other logographics to do with common fediverse causes, saying: "It is too late, mother - I have seen everything."
I love that on the regular internet, you can be like "I need to find out what part this is on my 2025 car" and all the results you get back are for car rentals, people trying to sell you a car, trying to buy your car, or AI slop videos explaining to you what a car is in the least intelligible way possible.
But... in the #Fediverse you can be like "anybody know the correct wiring layout and voltages for a 1974 "Passion-o-Meter" novelty Love Tester from Hanlon Amusements in Fairbanks, Alabama? I found one while doing recreational free diving in a cave system in Peru and I'm trying to put it back together again" and not only does NOBODY question any part of the insane statement made, but three people who happen to specialize in that exact sort of thing immediately emerge from the woodwork like the reverse of Homer Simpson going into the hedge.
Een ding dat ik wel jammer vind, inherent aan een algemeen probleem om fediverse breed onder de aandacht te brengen, is dat dit alles inzet op investering in het *merk* "Mastodon", niet op een sociale netwerk toepassing i.e. microblogging. #Mastodon krijgt steeds meer naamsbekendheid als een gerenommeerd platform, terwijl de #fediverse 'in schaduw gehuld' blijft. Dat is niet jullie schuld, of probleem, maar vloeit voort uit hoe de #fediverse zich ontwikkelt als een app-centric communicatie medium. Er treedt verzuiling op en mastodon krijgt alle aandacht en ook funding.
De europa.eu website voegde onlangs support toe in hun socials voor het mastodon icoontje. En de boodschap was "we doen nu mastodon". Maar ook #GoToSocial, toch, of #Pleroma, #Snac, en de vele andere #microblogging toepassingen die interoperabel met elkaar samenwerken? En daarnaast kom je andere toepassingen tegen, zoals video's en beeldmateriaal verzonden vanuit platforms als #Peertube en #Pixelfed.
There are a couple of projects that explore #ActivityPub in its intended #LinkedData format. Plain JSON is allowed, but the AP's primary notation is using #JSONLD. I think there is a slight uptick in interest for this approach again, coming along with the opportunity to implement the Social API (client-to-server) as intended.
What I really like is that ecosystem tools which aim to ease #fediverse solution development, are gaining an interest. Most notably here is #Fedify imho, who recently received #NLnet funding to build Fedify Studio development platform..
Admin of vmst.io suddenly announced the instance was shutting down in 2 weeks. The instance was well-run, and better-funded than most, but the admin claimed that they were still subsidizing operations, which is certainly likely. However, they didn’t ask for additional contributions and didn’t explain why they needed to shut down the instance with such short notice.
But they also have apparently moved their main personal social media presence to Bluesky 😑 Reading a little between the lines of the thread where they announced the reasons for the shutdown, I’d say the root cause was they gave up on the Fediverse.
Fedi isn’t going to ever be a mainstream platform, and a key learning here is that instances cannot be dependent on individuals if the idea is ever going to gain more traction. Instances should be run by non-profit groups with a clear funding model, ideally self-sustaining via a trust/endowment or similar structure. Governance similarly needs to be distributed so that administration isn’t a burden on one person and so legal exposure is isolated from individuals.
My feeling is that a group of a dozen core instances that match that description would provide a solid nucleus for the larger constellation of smaller or individual instances across the Fediverse.
Meme de dos perros Shiba Inu comparando el registro en dos redes sociales. A la izquierda aparece el perro musculoso bajo el título ‘Registro en WSocial’, recitando una larga lista de pasos absurdamente complejos: elegir usuario y contraseña, seleccionar intereses, descargar una app de identidad, escanear varios códigos QR, crear un PIN, verificar identidad con pasaporte, leer el chip NFC y hacerse un selfie. A la derecha, un perro pequeño y llorando bajo el título ‘Registro en el Fediverso’ dice: ‘Jooo, pero ¿qué server tengo que seleccionar? Ayy, qué complicado!’. El meme ironiza sobre cómo algunas personas consideran difícil elegir instancia en el Fediverso mientras aceptan procesos mucho más invasivos y complejos en redes centralizadas.”
The concentration of power in Silicon Valley happened partly because we let it. We accepted a few platforms as inevitable. We built our communities there because that’s where everyone was. It wasn’t because their technology is better. It was a choice—made again and again by the people on those platforms, by investors, and by policymakers.
A different choice is possible, but it requires that those of us building alternatives actually believe what we say about cooperation. It means assuming good faith from people building different projects. It means investing in infrastructure that doesn’t benefit us alone.
We, the builders of the open social web, are the only ones who can make that choice.
It starts with deciding that our mission matters more than winning alone.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
🔝 Update: Reliefgoods/Aid is still poorly distributed💔 Need #MutualAid for survival essentials & Crate 4 my cat—Goal stilll at [ $66/$125 ] Even $1-$5 from people who can spare something truly bridges the gap on this hard times URGENT NEED: Non-Perishable FoodSupply, Drinking Water Emergencykit (Candle/Matches/FirstAid) If you can't donate,Plls #boost this message, Sharing save lives too🫂
I love that on the regular internet, you can be like "I need to find out what part this is on my 2025 car" and all the results you get back are for car rentals, people trying to sell you a car, trying to buy your car, or AI slop videos explaining to you what a car is in the least intelligible way possible.
But... in the #Fediverse you can be like "anybody know the correct wiring layout and voltages for a 1974 "Passion-o-Meter" novelty Love Tester from Hanlon Amusements in Fairbanks, Alabama? I found one while doing recreational free diving in a cave system in Peru and I'm trying to put it back together again" and not only does NOBODY question any part of the insane statement made, but three people who happen to specialize in that exact sort of thing immediately emerge from the woodwork like the reverse of Homer Simpson going into the hedge.
The concentration of power in Silicon Valley happened partly because we let it. We accepted a few platforms as inevitable. We built our communities there because that’s where everyone was. It wasn’t because their technology is better. It was a choice—made again and again by the people on those platforms, by investors, and by policymakers.
A different choice is possible, but it requires that those of us building alternatives actually believe what we say about cooperation. It means assuming good faith from people building different projects. It means investing in infrastructure that doesn’t benefit us alone.
We, the builders of the open social web, are the only ones who can make that choice.
It starts with deciding that our mission matters more than winning alone.
The concentration of power in Silicon Valley happened partly because we let it. We accepted a few platforms as inevitable. We built our communities there because that’s where everyone was. It wasn’t because their technology is better. It was a choice—made again and again by the people on those platforms, by investors, and by policymakers.
A different choice is possible, but it requires that those of us building alternatives actually believe what we say about cooperation. It means assuming good faith from people building different projects. It means investing in infrastructure that doesn’t benefit us alone.
We, the builders of the open social web, are the only ones who can make that choice.
It starts with deciding that our mission matters more than winning alone.
Meme de dos perros Shiba Inu comparando el registro en dos redes sociales. A la izquierda aparece el perro musculoso bajo el título ‘Registro en WSocial’, recitando una larga lista de pasos absurdamente complejos: elegir usuario y contraseña, seleccionar intereses, descargar una app de identidad, escanear varios códigos QR, crear un PIN, verificar identidad con pasaporte, leer el chip NFC y hacerse un selfie. A la derecha, un perro pequeño y llorando bajo el título ‘Registro en el Fediverso’ dice: ‘Jooo, pero ¿qué server tengo que seleccionar? Ayy, qué complicado!’. El meme ironiza sobre cómo algunas personas consideran difícil elegir instancia en el Fediverso mientras aceptan procesos mucho más invasivos y complejos en redes centralizadas.”
The concentration of power in Silicon Valley happened partly because we let it. We accepted a few platforms as inevitable. We built our communities there because that’s where everyone was. It wasn’t because their technology is better. It was a choice—made again and again by the people on those platforms, by investors, and by policymakers.
A different choice is possible, but it requires that those of us building alternatives actually believe what we say about cooperation. It means assuming good faith from people building different projects. It means investing in infrastructure that doesn’t benefit us alone.
We, the builders of the open social web, are the only ones who can make that choice.
It starts with deciding that our mission matters more than winning alone.
I really enjoy optimization. Release v3.5.0 of Ktistec doesn't drop significant new features, but it does deliver a ~15% smaller executable and significantly faster queries on anonymous endpoints. The two are intertwined.
The size reduction comes from replacing a poorly designed, custom rules engine with a materialized view layer that uses SQL to define membership in a collection. The rules engine worked well enough but required a lot of supporting code to present rules as a DSL (Domain Specific Language) over the domain objects in ktistec. The driving realization was that SQL is a DSL and membership in a collection is just a query and domain objects are just rows. Voilà!
Query performance improvements came from using this new view layer to materialize two very popular but expensive-to-query views: the instance's public timeline and public hashtag pages. Because both are public pages they receive more traffic than internal pages.
The problem with the original queries was that performance was not uniform. Querying for posts with popular tags was okay. Querying for posts with sparse tags was very slow. I could have added more indexes, but that's its own cost. After the change, endpoints all respond in a consistent ~10msec timeframe and the CPU barely registers when a crawler hits. (I don't want to make things easier for bots, but I don't want to pay a tax for their activity either—ask me about my new nginx configuration.)
Here is the full changelog:
Added
Lightweight probe endpoint for authenticated sessions.
max-id and min-id pagination links on web pages.
Fixed
Correct the notifications collection's JSON representation.
Accept both single-value and array forms of JSON-LD properties.
Handle variation in schema.org property mapping.
Changed
Faster timeline, public, hashtag, and notification collections.
Adjust the layout of actor profile properties.
Removed
The school dependency; replaced by activity processors and materialized views.
The openssl_ext dependency; vendored in.
There are still a few slow queries. In the next release I'm going to see if I can get everything under 10msec, and maybe release a new feature, too. 🚀
The concentration of power in Silicon Valley happened partly because we let it. We accepted a few platforms as inevitable. We built our communities there because that’s where everyone was. It wasn’t because their technology is better. It was a choice—made again and again by the people on those platforms, by investors, and by policymakers.
A different choice is possible, but it requires that those of us building alternatives actually believe what we say about cooperation. It means assuming good faith from people building different projects. It means investing in infrastructure that doesn’t benefit us alone.
We, the builders of the open social web, are the only ones who can make that choice.
It starts with deciding that our mission matters more than winning alone.
The concentration of power in Silicon Valley happened partly because we let it. We accepted a few platforms as inevitable. We built our communities there because that’s where everyone was. It wasn’t because their technology is better. It was a choice—made again and again by the people on those platforms, by investors, and by policymakers.
A different choice is possible, but it requires that those of us building alternatives actually believe what we say about cooperation. It means assuming good faith from people building different projects. It means investing in infrastructure that doesn’t benefit us alone.
We, the builders of the open social web, are the only ones who can make that choice.
It starts with deciding that our mission matters more than winning alone.
The concentration of power in Silicon Valley happened partly because we let it. We accepted a few platforms as inevitable. We built our communities there because that’s where everyone was. It wasn’t because their technology is better. It was a choice—made again and again by the people on those platforms, by investors, and by policymakers.
A different choice is possible, but it requires that those of us building alternatives actually believe what we say about cooperation. It means assuming good faith from people building different projects. It means investing in infrastructure that doesn’t benefit us alone.
We, the builders of the open social web, are the only ones who can make that choice.
It starts with deciding that our mission matters more than winning alone.
I really enjoy optimization. Release v3.5.0 of Ktistec doesn't drop significant new features, but it does deliver a ~15% smaller executable and significantly faster queries on anonymous endpoints. The two are intertwined.
The size reduction comes from replacing a poorly designed, custom rules engine with a materialized view layer that uses SQL to define membership in a collection. The rules engine worked well enough but required a lot of supporting code to present rules as a DSL (Domain Specific Language) over the domain objects in ktistec. The driving realization was that SQL is a DSL and membership in a collection is just a query and domain objects are just rows. Voilà!
Query performance improvements came from using this new view layer to materialize two very popular but expensive-to-query views: the instance's public timeline and public hashtag pages. Because both are public pages they receive more traffic than internal pages.
The problem with the original queries was that performance was not uniform. Querying for posts with popular tags was okay. Querying for posts with sparse tags was very slow. I could have added more indexes, but that's its own cost. After the change, endpoints all respond in a consistent ~10msec timeframe and the CPU barely registers when a crawler hits. (I don't want to make things easier for bots, but I don't want to pay a tax for their activity either—ask me about my new nginx configuration.)
Here is the full changelog:
Added
Lightweight probe endpoint for authenticated sessions.
max-id and min-id pagination links on web pages.
Fixed
Correct the notifications collection's JSON representation.
Accept both single-value and array forms of JSON-LD properties.
Handle variation in schema.org property mapping.
Changed
Faster timeline, public, hashtag, and notification collections.
Adjust the layout of actor profile properties.
Removed
The school dependency; replaced by activity processors and materialized views.
The openssl_ext dependency; vendored in.
There are still a few slow queries. In the next release I'm going to see if I can get everything under 10msec, and maybe release a new feature, too. 🚀
The concentration of power in Silicon Valley happened partly because we let it. We accepted a few platforms as inevitable. We built our communities there because that’s where everyone was. It wasn’t because their technology is better. It was a choice—made again and again by the people on those platforms, by investors, and by policymakers.
A different choice is possible, but it requires that those of us building alternatives actually believe what we say about cooperation. It means assuming good faith from people building different projects. It means investing in infrastructure that doesn’t benefit us alone.
We, the builders of the open social web, are the only ones who can make that choice.
It starts with deciding that our mission matters more than winning alone.
The concentration of power in Silicon Valley happened partly because we let it. We accepted a few platforms as inevitable. We built our communities there because that’s where everyone was. It wasn’t because their technology is better. It was a choice—made again and again by the people on those platforms, by investors, and by policymakers.
A different choice is possible, but it requires that those of us building alternatives actually believe what we say about cooperation. It means assuming good faith from people building different projects. It means investing in infrastructure that doesn’t benefit us alone.
We, the builders of the open social web, are the only ones who can make that choice.
It starts with deciding that our mission matters more than winning alone.
A screenshot of a table and a pie chart from Excel showing top 10 Mastodon versions by the number of Monthly Active Users (MAU) with version 4.6.0 at 407,149 MAU, making up 49% of the total MAU.
Full raw dataset:
Mastodon version, MAU (Monthly Active Users), MAU %
4.6.0, 407149, 49.2%
4.5.11, 106624, 12.9%
4.4.0-alpha.4, 98256, 11.9%
4.5.10, 40361, 4.9%
4.5.9, 20071, 2.4%
4.1.18, 15348, 1.9%
4.6.0-alpha.9+gl, 12159, 1.5%
4.3.22, 10270, 1.2%
4.7.0-nightly.20, 7938, 1.0%
4.5.11+vivaldimo, 7530, 0.9%
Other, 102259, 12.4%
A screenshot of a table and a pie chart from Excel showing top 10 Mastodon versions by the number of Monthly Active Users (MAU) with version 4.6.0 at 407,149 MAU, making up 49% of the total MAU.
Full raw dataset:
Mastodon version, MAU (Monthly Active Users), MAU %
4.6.0, 407149, 49.2%
4.5.11, 106624, 12.9%
4.4.0-alpha.4, 98256, 11.9%
4.5.10, 40361, 4.9%
4.5.9, 20071, 2.4%
4.1.18, 15348, 1.9%
4.6.0-alpha.9+gl, 12159, 1.5%
4.3.22, 10270, 1.2%
4.7.0-nightly.20, 7938, 1.0%
4.5.11+vivaldimo, 7530, 0.9%
Other, 102259, 12.4%
After Bluesky, Threads, and so on, the whole #WSocial thing is another reminder that it was never about the #Fediverse being "too complicated" or "just for nerds".
A bafflingly large amount of people genuinely only act on a gut feeling telling them that only commercial products with fancy marketing owned by a for-profit corporation can be trustworthy, 'official' and 'legal', for the lack of a better word.
If something is a commercial offering by a competent-looking, rich family man in a suit, it's clearly an official, legal, trustworthy product. You can be proud of using such a fancy-looking service.
When they see a community-run open-source project or a grassroots initiative, their first instinct is that it must be shady, illegal, complicated, broken or predatory in some way. It's probably some aftermarket grey area bootleg made by weird tech nerds, political groups with an ulterior motive, conspiracy theorists or some naive teenage hackers. They'd also be embarrassed for using it in front of their peers and neighbours; who uses some free back-alley software, are you poor or something?
The same people are the reason why Google is using the word 'sideloading', why scammers love wearing fancy suits, why people suddenly act childishly helpless in front of LibreOffice, or why DIY HRT is so demonised.
They trust any kind of 'official approval' over their own senses. If someone does something that isn't 'approved', they're a bad person or clearly endangering themselves and others. No idea why exactly, but psh, it must be wrong somehow, or everyone would do it, right?
If people on the Fediverse understood that the whole "it's all so complicated and clunky" thing is just a thinly veiled excuse for a general disdain for non-commercial software, we could finally stop making all our software imitate their corporate equivalents in a futile attempt to appease people who never gave us a chance in the first place.
You'll never convince them to treat it in good faith no matter how much effort or money you put into UX or 'ease of use'. All you're doing is making the software worse, e. g. through things like dot-social, verified accounts or begging brands, corporations and politicians to join and give your product some kind of 'official' validation.
@zuck, @mosseri & @conno_r (latter leads #Threads) are in a celebratory mood. Still no word on when an iPad app will ship, or full #Fediverse support will be adopted.
Die @unijena ist auf #Mastodon unterwegs. Sie würde sich jedoch mehr Interaktionen und Followerschaft wünschen. Liebes #Fediverse, zeig mal, was in dir steckt und verteilt Follows, Herzen, Kommentare, drückt auf Glocken oder retrötet einfach diesen Toot. 😉
Die @unijena ist auf #Mastodon unterwegs. Sie würde sich jedoch mehr Interaktionen und Followerschaft wünschen. Liebes #Fediverse, zeig mal, was in dir steckt und verteilt Follows, Herzen, Kommentare, drückt auf Glocken oder retrötet einfach diesen Toot. 😉
A screenshot from the linked website showing a pie chart labeled "Active instances software version distribution".
Top 3 Mastodon versions are:
Version 4.6.0: 2,440 servers at 26.42%
Version 4.5.11: 2,368 servers at 25.64%
Version 4.5.10: 613 servers at 6.64%
A screenshot from the linked website showing a pie chart labeled "Active instances software version distribution".
Top 3 Mastodon versions are:
Version 4.6.0: 2,440 servers at 26.42%
Version 4.5.11: 2,368 servers at 25.64%
Version 4.5.10: 613 servers at 6.64%
A screenshot from the linked website showing a pie chart labeled "Active instances software version distribution".
Top 3 Mastodon versions are:
Version 4.6.0: 2,440 servers at 26.42%
Version 4.5.11: 2,368 servers at 25.64%
Version 4.5.10: 613 servers at 6.64%
A screenshot from the linked website showing a pie chart labeled "Active instances software version distribution".
Top 3 Mastodon versions are:
Version 4.6.0: 2,440 servers at 26.42%
Version 4.5.11: 2,368 servers at 25.64%
Version 4.5.10: 613 servers at 6.64%
'Unser digitales Leben befindet sich in der Hand weniger Überreicher. Mit der Monopolstellung ihrer Unternehmen bestimmen Menschen wie Elon Musk, Jeff Bezos oder Mark Zuckerberg weltweit, wie wir uns online informieren, wie wir diskutieren, kommunizieren oder handeln. Einen solchen unkontrollierten Einfluss sollte kein Mensch und kein Unternehmen besitzen, weil wir dann nicht mehr in Freiheit leben können. Die gute Nachricht: Diese Macht geben wir ihnen derzeit, und wir können sie ihnen auch wieder nehmen!'
Jeden ersten Sonntag auf die gute Seite wechseln! #DID#DiDIt
Looking for good news sources on the #fediverse and liberal #uspol commentary? I made a starter pack to get you on your way! Guaranteed to fill your boring or thin feed.
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
“My fear is that W Social is just another for-profit Big Tech startup that happens to be based in the EU. We don’t need that. We don’t need more European surveillance capitalists and people farmers. We need ethical alternatives working for the common good.”
– Yours truly, in @_elena’s excellent exposé on W Social.
Do read the article to the end, especially noting the bit about the composition of their board of advisors, which includes an ex-Google AI lead and an ex-Paypal Chief [Violate Your] Privacy Officer who now works at Tools for Humanity (Sam Altman’s “Sci-fi dystopia? Hold my beer…” identity farming startup that wants to scan your eyeballs).
Diesen Satz hört man leider immer wieder. Doch was passiert, wenn die gesamte Firmenpräsenz, Vereinskommunikation oder Kundeninformation von einer einzigen Plattform abhängt?
Warum eine eigene Webseite unter eigener Domain auch 2026 noch die wichtigste Grundlage jeder digitalen Präsenz ist und weshalb soziale Netzwerke nur ein zusätzlicher Kommunikationskanal sein sollten, beschreibe ich in meinem neuen Artikel:
Illustration zur digitalen Unabhängigkeit: Verschiedene soziale Netzwerke und Fediverse-Plattformen wie Facebook, Instagram, LinkedIn, Mastodon, Friendica und Hubzilla verweisen auf eine eigene Webseite unter eigener Domain. Dazu der Hinweis: „Ihre Webseite ist die Heimat. Social Media zeigt den Weg dorthin.“ Die Grafik verdeutlicht, dass soziale Netzwerke Kommunikationskanäle sind, während die eigene Webseite die langfristig kontrollierbare digitale Heimat eines Projekts bildet.
Diesen Satz hört man leider immer wieder. Doch was passiert, wenn die gesamte Firmenpräsenz, Vereinskommunikation oder Kundeninformation von einer einzigen Plattform abhängt?
Warum eine eigene Webseite unter eigener Domain auch 2026 noch die wichtigste Grundlage jeder digitalen Präsenz ist und weshalb soziale Netzwerke nur ein zusätzlicher Kommunikationskanal sein sollten, beschreibe ich in meinem neuen Artikel:
Illustration zur digitalen Unabhängigkeit: Verschiedene soziale Netzwerke und Fediverse-Plattformen wie Facebook, Instagram, LinkedIn, Mastodon, Friendica und Hubzilla verweisen auf eine eigene Webseite unter eigener Domain. Dazu der Hinweis: „Ihre Webseite ist die Heimat. Social Media zeigt den Weg dorthin.“ Die Grafik verdeutlicht, dass soziale Netzwerke Kommunikationskanäle sind, während die eigene Webseite die langfristig kontrollierbare digitale Heimat eines Projekts bildet.
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
DrFed is our sister project, built alongside #Fedify to tackle the debugging side of #ActivityPub development. It just received @nlnet funding and now has its own account here: @drfed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
Bei Instagram haben wir jetzt bekannt gegeben, dass wir die Plattform nicht mehr aktiv nutzen werden. Vor allem weil wir durch den Algorithmus dort quasi unsichtbar geworden sind.
Dieser Beitrag, der das Ende ankündigt, hat dann plötzlich Reichweite bekommen. Weil er polarisiert.
Leider wollen wir gar keine polarisierenden Dinge posten, sondern Infos zu Museen und Kultur-Themen teilen.
Instagram findet das irrelevant. Also ist es nicht mehr der richtige Ort für uns…
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
Bei Instagram haben wir jetzt bekannt gegeben, dass wir die Plattform nicht mehr aktiv nutzen werden. Vor allem weil wir durch den Algorithmus dort quasi unsichtbar geworden sind.
Dieser Beitrag, der das Ende ankündigt, hat dann plötzlich Reichweite bekommen. Weil er polarisiert.
Leider wollen wir gar keine polarisierenden Dinge posten, sondern Infos zu Museen und Kultur-Themen teilen.
Instagram findet das irrelevant. Also ist es nicht mehr der richtige Ort für uns…
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
#Mastodon 4.6 is here! It's been a long time in the works, but it's finally ready. In this release, we're introducing Collections—a way to share curated collections of profiles to help old and new users discover more of the #Fediverse. We're also updating the look of profiles, alongside many quality of life and accessibility improvements. Read more here:
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
DrFed is our sister project, built alongside #Fedify to tackle the debugging side of #ActivityPub development. It just received @nlnet funding and now has its own account here: @drfed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
DrFed is our sister project, built alongside #Fedify to tackle the debugging side of #ActivityPub development. It just received @nlnet funding and now has its own account here: @drfed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
I am really delighted with @nlnet decision to select @drfed for an #NGI0 grant. Having good quality developer tools for creating #ActivityPub based solutions is so important for a healthy #fediverse developer ecosystem.
To anyone reading, bookmark the website..
Fedify Studio is focused on alleviating the most pressing issue of "Why is ActivityPub development so frustratingly hard?" that makes it unattractive for newcomers to adopt the technology. And addresses topics of:
#Fedify from the very start has paid attention to ease of use for fediverse solution developers, not just by their library codebase, but with comprehensive documentation and tools to guide people along. Kudos here to @hongminhee who started this great initiative!
I am really delighted with @nlnet decision to select @drfed for an #NGI0 grant. Having good quality developer tools for creating #ActivityPub based solutions is so important for a healthy #fediverse developer ecosystem.
To anyone reading, bookmark the website..
Fedify Studio is focused on alleviating the most pressing issue of "Why is ActivityPub development so frustratingly hard?" that makes it unattractive for newcomers to adopt the technology. And addresses topics of:
#Fedify from the very start has paid attention to ease of use for fediverse solution developers, not just by their library codebase, but with comprehensive documentation and tools to guide people along. Kudos here to @hongminhee who started this great initiative!
I am really delighted with @nlnet decision to select @drfed for an #NGI0 grant. Having good quality developer tools for creating #ActivityPub based solutions is so important for a healthy #fediverse developer ecosystem.
To anyone reading, bookmark the website..
Fedify Studio is focused on alleviating the most pressing issue of "Why is ActivityPub development so frustratingly hard?" that makes it unattractive for newcomers to adopt the technology. And addresses topics of:
#Fedify from the very start has paid attention to ease of use for fediverse solution developers, not just by their library codebase, but with comprehensive documentation and tools to guide people along. Kudos here to @hongminhee who started this great initiative!
@daviduccio@social.cologne · Reply to heise online
@heiseonline Ja, klar, weil wir natürlich noch mehr private soziale Netzwerke brauchen, die unsere Daten verkaufen. Man kann nur hoffen, dass ein ähnlicher Rohkrepierer wird, wie andere nicht durchdachte europäische Kopien amerikanischer Dienste. Nutzt die echte und #offene#europäische Alternative: #Fediverse#Mastodon#PixelFed#PeerTube#Friendica
Dabei lese ich fleißig mit, hab aber noch das Problem, dass ich auf der Plattform kaum vernetzt bin. @ucas, @triqueon, @inpector Ihr kennt mich doch, reicht mich mal rum und lasst die Leute wissen, dass ich hier bin 😀
Bin #neuHier und unterschlage bereitwillig, dass das schon 8 Monate lang so ist, ohne dass ich in der Zeit weniger neu geworden wäre.
I am really delighted with @nlnet decision to select @drfed for an #NGI0 grant. Having good quality developer tools for creating #ActivityPub based solutions is so important for a healthy #fediverse developer ecosystem.
To anyone reading, bookmark the website..
Fedify Studio is focused on alleviating the most pressing issue of "Why is ActivityPub development so frustratingly hard?" that makes it unattractive for newcomers to adopt the technology. And addresses topics of:
#Fedify from the very start has paid attention to ease of use for fediverse solution developers, not just by their library codebase, but with comprehensive documentation and tools to guide people along. Kudos here to @hongminhee who started this great initiative!
“My fear is that W Social is just another for-profit Big Tech startup that happens to be based in the EU. We don’t need that. We don’t need more European surveillance capitalists and people farmers. We need ethical alternatives working for the common good.”
– Yours truly, in @_elena’s excellent exposé on W Social.
Do read the article to the end, especially noting the bit about the composition of their board of advisors, which includes an ex-Google AI lead and an ex-Paypal Chief [Violate Your] Privacy Officer who now works at Tools for Humanity (Sam Altman’s “Sci-fi dystopia? Hold my beer…” identity farming startup that wants to scan your eyeballs).
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
“My fear is that W Social is just another for-profit Big Tech startup that happens to be based in the EU. We don’t need that. We don’t need more European surveillance capitalists and people farmers. We need ethical alternatives working for the common good.”
– Yours truly, in @_elena’s excellent exposé on W Social.
Do read the article to the end, especially noting the bit about the composition of their board of advisors, which includes an ex-Google AI lead and an ex-Paypal Chief [Violate Your] Privacy Officer who now works at Tools for Humanity (Sam Altman’s “Sci-fi dystopia? Hold my beer…” identity farming startup that wants to scan your eyeballs).
DrFed is our sister project, built alongside #Fedify to tackle the debugging side of #ActivityPub development. It just received @nlnet funding and now has its own account here: @drfed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
DrFed is our sister project, built alongside #Fedify to tackle the debugging side of #ActivityPub development. It just received @nlnet funding and now has its own account here: @drfed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
DrFed is our sister project, built alongside #Fedify to tackle the debugging side of #ActivityPub development. It just received @nlnet funding and now has its own account here: @drfed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
I am really delighted with @nlnet decision to select @drfed for an #NGI0 grant. Having good quality developer tools for creating #ActivityPub based solutions is so important for a healthy #fediverse developer ecosystem.
To anyone reading, bookmark the website..
Fedify Studio is focused on alleviating the most pressing issue of "Why is ActivityPub development so frustratingly hard?" that makes it unattractive for newcomers to adopt the technology. And addresses topics of:
#Fedify from the very start has paid attention to ease of use for fediverse solution developers, not just by their library codebase, but with comprehensive documentation and tools to guide people along. Kudos here to @hongminhee who started this great initiative!
Ich glaube, wir unterschätzen gerade, was bei Meta passiert. Viele Menschen haben die Werbung geschluckt. Viele haben die Datensammelei akzeptiert. Viele haben sogar die Algorithmen ertragen. Aber wenn plötzlich für Sticker, Emojis und Reichweite bezahlt werden soll, ist eben auch für viele Menschen Schluss. Dann suchen sie einen Ausgang. Das Fediverse könnte bald deutlich voller werden. Wir sollten freundlich sein. Auch wenn da einige Nachzügler kommen und eine andere Kultur mitbringen.
Ich glaube, wir unterschätzen gerade, was bei Meta passiert. Viele Menschen haben die Werbung geschluckt. Viele haben die Datensammelei akzeptiert. Viele haben sogar die Algorithmen ertragen. Aber wenn plötzlich für Sticker, Emojis und Reichweite bezahlt werden soll, ist eben auch für viele Menschen Schluss. Dann suchen sie einen Ausgang. Das Fediverse könnte bald deutlich voller werden. Wir sollten freundlich sein. Auch wenn da einige Nachzügler kommen und eine andere Kultur mitbringen.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
Gerade einen etwas älteren Artikel von @ZEITONLINE gefunden, der mich berührt hat.
Ein Interview mit @Rushkoff das sein Zitat „Wir müssen uns wieder verschwören“ als Titel trägt.
Er sagt:
„Was, wenn Lösungen so funktionieren würden wie ursprünglich das Internet - verteilt, lokal und kooperativ? Kleine Gemeinschaften lösen kleine Probleme und teilen dann die Lösungen.“
Hier ist ein Freebie. Ich glaube der Link funktioniert genau einmal. Ich kann noch 9 Geschenklinks heute produzieren. Schreibt mich dafür gerne an:
Gerade einen etwas älteren Artikel von @ZEITONLINE gefunden, der mich berührt hat.
Ein Interview mit @Rushkoff das sein Zitat „Wir müssen uns wieder verschwören“ als Titel trägt.
Er sagt:
„Was, wenn Lösungen so funktionieren würden wie ursprünglich das Internet - verteilt, lokal und kooperativ? Kleine Gemeinschaften lösen kleine Probleme und teilen dann die Lösungen.“
Hier ist ein Freebie. Ich glaube der Link funktioniert genau einmal. Ich kann noch 9 Geschenklinks heute produzieren. Schreibt mich dafür gerne an:
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
DrFed is our sister project, built alongside #Fedify to tackle the debugging side of #ActivityPub development. It just received @nlnet funding and now has its own account here: @drfed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
DrFed is our sister project, built alongside #Fedify to tackle the debugging side of #ActivityPub development. It just received @nlnet funding and now has its own account here: @drfed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
DrFed is our sister project, built alongside #Fedify to tackle the debugging side of #ActivityPub development. It just received @nlnet funding and now has its own account here: @drfed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
DrFed is our sister project, built alongside #Fedify to tackle the debugging side of #ActivityPub development. It just received @nlnet funding and now has its own account here: @drfed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
DrFed is our sister project, built alongside #Fedify to tackle the debugging side of #ActivityPub development. It just received @nlnet funding and now has its own account here: @drfed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
Some of you have already heard of us as #Fedify Studio. We now have a proper name: DrFed, short for “Doctor Fed.” We've also just received funding from @nlnet, through the NGI0 Commons Fund.
#DrFed is a web app for debugging #ActivityPub interoperability failures. When two implementations don't federate, the slow part is usually figuring out where the exchange broke: signing, JSON-LD processing, WebFinger, or something less obvious. DrFed's first job is to show where it failed.
Mastodon 4.6 is rolling out, and it's a big one. We've already upgraded toot.community, so everything in this thread is live for you right now. Here's what's new for the whole fediverse. 🧵
First up: Collections. Group up to 25 accounts into a list and share it with anyone. Good for pointing people at the folks you follow on a given topic. It works across the fediverse too, not just here.
Mastodon 4.6 is rolling out, and it's a big one. We've already upgraded toot.community, so everything in this thread is live for you right now. Here's what's new for the whole fediverse. 🧵
First up: Collections. Group up to 25 accounts into a list and share it with anyone. Good for pointing people at the folks you follow on a given topic. It works across the fediverse too, not just here.
Highlights include password reset, avatar uploads, local follows and follow requests, light/dark mode, activity tiles, NodeInfo support, improved federation, instance statistics, and location support for remote activities.
Thank you to everyone who opened issues, submitted pull requests, tested releases, and shared feedback. Every contribution helps.
Highlights include password reset, avatar uploads, local follows and follow requests, light/dark mode, activity tiles, NodeInfo support, improved federation, instance statistics, and location support for remote activities.
Thank you to everyone who opened issues, submitted pull requests, tested releases, and shared feedback. Every contribution helps.
wetter: 295 uses might be false cause "wetter" is not only a city but the german word for weather, and a very small city? But #essen (german word for eating / food and of tge biggest cities in germany) only has 62 uses, so it seems only real cities are mentioned.?
maybe some smaller cities but with a big university = more active users (students) are mentioned more often.? @sabrinkmann
@gabboman Do you think it'd be possible to add a web and/or mobile function to load a whole thread at once? I was trying to read a series of posts on BSky in Wafrn and found that if I manually search the last post in the chain, it will load the rest above it. Any way to give that process a button?
Eingeladen sind alle Friendica-Admins, Instanzbetreiber, Entwickler:innen und Interessierte.
📌 Themen unter anderem: 🛡️ Spam-Abwehr als gemeinsames Anliegen 🏷️ tags.pub 🔧 Erfahrungen mit der aktuellen Friendica-Version 💬 Offener Austausch zu aktuellen Fragen und Entwicklungen
Die vergangenen Treffen haben gezeigt, wie wertvoll der direkte Austausch zwischen Praxis und Entwicklung ist. Jede Erfahrung aus dem Instanzbetrieb kann helfen, Friendica für alle weiter zu verbessern.
📢 Hinweis: Für den laufenden Austausch zwischen Admins und Entwicklern gibt es inzwischen auch einen speziellen XMPP-Gruppenchat. Wer daran teilnehmen möchte, kann sich direkt an @tux , @oldkid oder @jools wenden. Dort werden die Einladungslinks vergeben.
Wir freuen uns auf einen interessanten Abend mit vielen bekannten und neuen Gesichtern. 😊
Eingeladen sind alle Friendica-Admins, Instanzbetreiber, Entwickler:innen und Interessierte.
📌 Themen unter anderem: 🛡️ Spam-Abwehr als gemeinsames Anliegen 🏷️ tags.pub 🔧 Erfahrungen mit der aktuellen Friendica-Version 💬 Offener Austausch zu aktuellen Fragen und Entwicklungen
Die vergangenen Treffen haben gezeigt, wie wertvoll der direkte Austausch zwischen Praxis und Entwicklung ist. Jede Erfahrung aus dem Instanzbetrieb kann helfen, Friendica für alle weiter zu verbessern.
📢 Hinweis: Für den laufenden Austausch zwischen Admins und Entwicklern gibt es inzwischen auch einen speziellen XMPP-Gruppenchat. Wer daran teilnehmen möchte, kann sich direkt an @tux , @oldkid oder @jools wenden. Dort werden die Einladungslinks vergeben.
Wir freuen uns auf einen interessanten Abend mit vielen bekannten und neuen Gesichtern. 😊
wetter: 295 uses might be false cause "wetter" is not only a city but the german word for weather, and a very small city? But #essen (german word for eating / food and of tge biggest cities in germany) only has 62 uses, so it seems only real cities are mentioned.?
maybe some smaller cities but with a big university = more active users (students) are mentioned more often.? @sabrinkmann
Have you ever wondered which cities are mentioned the most in the Fediverse? I did! I built a small tool that checks the hashtags for the biggest cities in DE, AT, CH, NL, GB, IT, FR and DK.
This is only a small, limited analysis, but you can see lots of dots everywhere, especially in bigger cities, and generally in Germany and the Netherlands. [1/3]
For those who are wondering why I am posting here not on Sharkey is because I quit posting there becuase I found alot of those servers have some kind of an alliance to make me suffer 😢 .
I am not going to interact with any Sharkey mods because I know that they they will reject every posts I make. I hate the fact that Sharkey mods are just reddit mods
For #Mastodon app developers and fellow #fediverse platform developers, with the approaching Mastodon 4.6 release we've put together an overview of new and changed APIs that you may want to look at! Collections, profile editing, #Wrapstodon, and more:
I wonder what will be the next major driver of #migration to the #Fediverse? X/Musk does something that drives away users, or governments? It catches on at last in the EU? Bluesky blows up? #Loops goes viral? Facebook shuts down? #Threads makes sharing the default?
Many features people complained were lacking years ago are now in place, but it doesn't feel as if the Fediverse is growing much overall, https://fedidb.com/ .
I wonder what will be the next major driver of #migration to the #Fediverse? X/Musk does something that drives away users, or governments? It catches on at last in the EU? Bluesky blows up? #Loops goes viral? Facebook shuts down? #Threads makes sharing the default?
Many features people complained were lacking years ago are now in place, but it doesn't feel as if the Fediverse is growing much overall, https://fedidb.com/ .
Please kindly #boost this thread🙏😭 Needed a helping hand 4 getting basic essentials for me & my #cat also Hoping to get a hold of a medium sized crate for a safe space for him..😫 Due to frequent #aftershocks were both restless and my cat is so stressed.
Pleaae any #support is appreciated and will help alot to my goal. PS: i even forget about my upcoming bday due to this calamity disaster.
Have you ever wondered which cities are mentioned the most in the Fediverse? I did! I built a small tool that checks the hashtags for the biggest cities in DE, AT, CH, NL, GB, IT, FR and DK.
This is only a small, limited analysis, but you can see lots of dots everywhere, especially in bigger cities, and generally in Germany and the Netherlands. [1/3]
Have you ever wondered which cities are mentioned the most in the Fediverse? I did! I built a small tool that checks the hashtags for the biggest cities in DE, AT, CH, NL, GB, IT, FR and DK.
This is only a small, limited analysis, but you can see lots of dots everywhere, especially in bigger cities, and generally in Germany and the Netherlands. [1/3]
Have you ever wondered which cities are mentioned the most in the Fediverse? I did! I built a small tool that checks the hashtags for the biggest cities in DE, AT, CH, NL, GB, IT, FR and DK.
This is only a small, limited analysis, but you can see lots of dots everywhere, especially in bigger cities, and generally in Germany and the Netherlands. [1/3]
Wir suchen immer noch dringend jemanden der wiesbaden.social übernehmen kann und das Hosting sowie die Updates gewissenhaft durchführt. Vorzugsweise natürlich ein Verein oder Personen aus #wiesbaden - gerne teilen und bitte gerne an entsprechende Personen mit dem passenden Know-How weiterleiten. Aufgrund von Jobwechsel ist hier eine gewisse Eile geboten. #mastodon#fediverse
Two cats lounging on a grey couch. On the left, a torbie cat with brown tabby stripes and orange patches lies stretched out on white mail envelopes, one paw resting near a computer mouse, looking alertly at the camera with green eyes. On the right, a black and orange tortoiseshell cat with a white paw rests peacefully on a grey star-patterned blanket, eyes half-closed in relaxation. An electronic drum kit is visible in the background.
ALT text
Two cats lounging on a grey couch. On the left, a torbie cat with brown tabby stripes and orange patches lies stretched out on white mail envelopes, one paw resting near a computer mouse, looking alertly at the camera with green eyes. On the right, a black and orange tortoiseshell cat with a white paw rests peacefully on a grey star-patterned blanket, eyes half-closed in relaxation. An electronic drum kit is visible in the background.
Two cats lounging on a grey couch. On the left, a torbie cat with brown tabby stripes and orange patches lies stretched out on white mail envelopes, one paw resting near a computer mouse, looking alertly at the camera with green eyes. On the right, a black and orange tortoiseshell cat with a white paw rests peacefully on a grey star-patterned blanket, eyes half-closed in relaxation. An electronic drum kit is visible in the background.
ALT text
Two cats lounging on a grey couch. On the left, a torbie cat with brown tabby stripes and orange patches lies stretched out on white mail envelopes, one paw resting near a computer mouse, looking alertly at the camera with green eyes. On the right, a black and orange tortoiseshell cat with a white paw rests peacefully on a grey star-patterned blanket, eyes half-closed in relaxation. An electronic drum kit is visible in the background.
📷 Kleiner Friendica-Tipp: Warum manche Bilder nicht für alle sichtbar sind
In den letzten Tagen ist mir bei einigen Nutzerinnen und Nutzern aufgefallen, dass hochgeladene Bilder nicht öffentlich angezeigt werden. Oft liegt das gar nicht an einem Fehler, sondern einfach an den eingestellten Berechtigungen.
Friendica bietet sehr flexible Möglichkeiten, Inhalte nur bestimmten Personen oder Gruppen zugänglich zu machen. Das ist eine große Stärke der Plattform. 😊
Wer jedoch möchte, dass ein Bild für alle sichtbar ist, sollte nach dem Hochladen einen kurzen Blick auf die Berechtigungseinstellungen werfen.
Ist stattdessen „Begrenzt/Privat“ eingestellt, können nur die ausgewählten Kontakte das Bild sehen.
Das beigefügte Bildschirmfoto zeigt die entsprechende Einstellung.
Gerade für neue Friendica-Nutzerinnen und -Nutzer ist dieser kleine Unterschied nicht immer sofort erkennbar. Deshalb dieser Hinweis – vielleicht hilft er dem einen oder anderen weiter. 😊
Screenshot aus Friendica mit dem geöffneten Dialog „Berechtigungen“ für ein Bild. Die Option „Öffentlich“ ist ausgewählt und grün hervorgehoben. Darunter befindet sich die Alternative „Begrenzt/Privat“. Das Bild zeigt, wo die Sichtbarkeit eines Fotos nachträglich geändert werden kann.
📷 Kleiner Friendica-Tipp: Warum manche Bilder nicht für alle sichtbar sind
In den letzten Tagen ist mir bei einigen Nutzerinnen und Nutzern aufgefallen, dass hochgeladene Bilder nicht öffentlich angezeigt werden. Oft liegt das gar nicht an einem Fehler, sondern einfach an den eingestellten Berechtigungen.
Friendica bietet sehr flexible Möglichkeiten, Inhalte nur bestimmten Personen oder Gruppen zugänglich zu machen. Das ist eine große Stärke der Plattform. 😊
Wer jedoch möchte, dass ein Bild für alle sichtbar ist, sollte nach dem Hochladen einen kurzen Blick auf die Berechtigungseinstellungen werfen.
Ist stattdessen „Begrenzt/Privat“ eingestellt, können nur die ausgewählten Kontakte das Bild sehen.
Das beigefügte Bildschirmfoto zeigt die entsprechende Einstellung.
Gerade für neue Friendica-Nutzerinnen und -Nutzer ist dieser kleine Unterschied nicht immer sofort erkennbar. Deshalb dieser Hinweis – vielleicht hilft er dem einen oder anderen weiter. 😊
Screenshot aus Friendica mit dem geöffneten Dialog „Berechtigungen“ für ein Bild. Die Option „Öffentlich“ ist ausgewählt und grün hervorgehoben. Darunter befindet sich die Alternative „Begrenzt/Privat“. Das Bild zeigt, wo die Sichtbarkeit eines Fotos nachträglich geändert werden kann.
Wir suchen immer noch dringend jemanden der wiesbaden.social übernehmen kann und das Hosting sowie die Updates gewissenhaft durchführt. Vorzugsweise natürlich ein Verein oder Personen aus #wiesbaden - gerne teilen und bitte gerne an entsprechende Personen mit dem passenden Know-How weiterleiten. Aufgrund von Jobwechsel ist hier eine gewisse Eile geboten. #mastodon#fediverse
A relaxed tortoiseshell domestic shorthair cat lounging in a grey plush hammock on a cat tree. The cat has a mottled black and orange coat with white markings including a white sock on one extended paw and a small white spot on its nose. Short to medium length plush fur. The cat is lying curled slightly with its dark tail hanging over the edge and one hind leg stretched out straight, dangling near a sliding glass window handle. Eyes are half-open with a sleepy, content expression. A grey sofa and window view are visible in the background.
A relaxed tortoiseshell domestic shorthair cat lounging in a grey plush hammock on a cat tree. The cat has a mottled black and orange coat with white markings including a white sock on one extended paw and a small white spot on its nose. Short to medium length plush fur. The cat is lying curled slightly with its dark tail hanging over the edge and one hind leg stretched out straight, dangling near a sliding glass window handle. Eyes are half-open with a sleepy, content expression. A grey sofa and window view are visible in the background.
A torbie cat with orange patches and dark brown tabby stripes lies playfully on its back on rumpled slate-blue bed sheets. The short-haired cat stretches diagonally with front legs extended and hind legs kicked up, gazing at the camera with wide yellow-green eyes. A small white patch marks its belly, and a geometric-patterned blanket sits in the corner.
A torbie cat with orange patches and dark brown tabby stripes lies playfully on its back on rumpled slate-blue bed sheets. The short-haired cat stretches diagonally with front legs extended and hind legs kicked up, gazing at the camera with wide yellow-green eyes. A small white patch marks its belly, and a geometric-patterned blanket sits in the corner.
BizzFed looks like a professional network - and behaves like one. Profiles, company pages, job listings. What's underneath is different: every account lives on an instance. Many instances communicate via ActivityPub. https://bizzfed.haxxors.com/en#GetFediHired#Jobs#ActivityPub#Fediverse
We've worked hard with the team at Find Out Media, led by @TimFullerton, to provide a Social Web enabled app and bring their vision of an alternative space to life ✨️
Find Out Social is an app built solely for Find Out Social users. It's connected to the Social Web whilst sheltering the community from complexity, allowing them to share knowledge and work to combat the rise of the right.
A graphic which shows a white circle on a blue background, alongside multiple other circles displaying profile pictures of Find Out Social users.
Text reads: Find Out Social. 10,000 users.
BizzFed looks like a professional network - and behaves like one. Profiles, company pages, job listings. What's underneath is different: every account lives on an instance. Many instances communicate via ActivityPub. https://bizzfed.haxxors.com/en#GetFediHired#Jobs#ActivityPub#Fediverse
For #Mastodon app developers and fellow #fediverse platform developers, with the approaching Mastodon 4.6 release we've put together an overview of new and changed APIs that you may want to look at! Collections, profile editing, #Wrapstodon, and more:
For #Mastodon app developers and fellow #fediverse platform developers, with the approaching Mastodon 4.6 release we've put together an overview of new and changed APIs that you may want to look at! Collections, profile editing, #Wrapstodon, and more:
DESCRIPTION: "A new supply chain attack was just discovered by a spoofed maintainers account at the AUR. Be careful and look for the signs of compromise!"
!!! NOTE !!! This post is best viewed on a PC. Switched To Linux is, “written by a broad spectrum computer consultant to help people learn more about the Linux platform.” This account is a supporter of Switched To Linux and provides convenience posts of thumbnails art, videos and streams.
DESCRIPTION: "A new supply chain attack was just discovered by a spoofed maintainers account at the AUR. Be careful and look for the signs of compromise!"
!!! NOTE !!! This post is best viewed on a PC. Switched To Linux is, “written by a broad spectrum computer consultant to help people learn more about the Linux platform.” This account is a supporter of Switched To Linux and provides convenience posts of thumbnails art, videos and streams.
Open-source platform for social media management and analytics
If you manage several Fediverse accounts, you're constantly juggling browser tabs, losing track of which input field belongs to which platform, and at some point you no longer know what you've already posted. #FediSuite brings everything together in one place.
Connect accounts from 19(+) #Fediverse platforms: #Mastodon, #Pixelfed, #Misskey, #Friendica, #PeerTube, #Loops, #Wordpress, #Vernissage and more. The app detects your instance type automatically, loads the correct character limit and media rules straight from your instance, and sets up the composer accordingly. No manual configuration needed.
The analytics go way beyond plain follower counts: daily engagement charts, follower growth, your best posting times as a heatmap, hashtag performance, and a tips engine that evaluates your actual data and gives you concrete suggestions based on your own numbers.
Schedule posts down to the minute in your own time zone. Background workers handle publishing reliably, with resume handling for rate limits and atomic delivery.
FediSuite is free and #OpenSource under the GPL-3.0. Anyone can host their own FediSuite #instance and get it added to the official list automatically.
If you find a bug, especially in the #SelfHosting setup, feel free to report it. The project is being actively developed, and real-world bug reports are among the most valuable contributions right now. The CONTRIBUTING.md explains how it works.
The project lives on donations. Donations guarantee and make it possible for FediSuite to keep going and keep being developed. To support FediSuite, click the yellow button on the website.
Open-source platform for social media management and analytics
If you manage several Fediverse accounts, you're constantly juggling browser tabs, losing track of which input field belongs to which platform, and at some point you no longer know what you've already posted. #FediSuite brings everything together in one place.
Connect accounts from 19(+) #Fediverse platforms: #Mastodon, #Pixelfed, #Misskey, #Friendica, #PeerTube, #Loops, #Wordpress, #Vernissage and more. The app detects your instance type automatically, loads the correct character limit and media rules straight from your instance, and sets up the composer accordingly. No manual configuration needed.
The analytics go way beyond plain follower counts: daily engagement charts, follower growth, your best posting times as a heatmap, hashtag performance, and a tips engine that evaluates your actual data and gives you concrete suggestions based on your own numbers.
Schedule posts down to the minute in your own time zone. Background workers handle publishing reliably, with resume handling for rate limits and atomic delivery.
FediSuite is free and #OpenSource under the GPL-3.0. Anyone can host their own FediSuite #instance and get it added to the official list automatically.
If you find a bug, especially in the #SelfHosting setup, feel free to report it. The project is being actively developed, and real-world bug reports are among the most valuable contributions right now. The CONTRIBUTING.md explains how it works.
The project lives on donations. Donations guarantee and make it possible for FediSuite to keep going and keep being developed. To support FediSuite, click the yellow button on the website.
Is there a good way to inform via the ActivityPub NodeInfo that this instance is used for testing and includes actors that only contain test data and actions, or anything along those lines?
Is there a good way to inform via the ActivityPub NodeInfo that this instance is used for testing and includes actors that only contain test data and actions, or anything along those lines?
We aim to publish the release next week. If you are an admin, now is a good time to upgrade to the release candidate and help us find any last minute bugs!
For #Mastodon app developers and fellow #fediverse platform developers, with the approaching Mastodon 4.6 release we've put together an overview of new and changed APIs that you may want to look at! Collections, profile editing, #Wrapstodon, and more:
For #Mastodon app developers and fellow #fediverse platform developers, with the approaching Mastodon 4.6 release we've put together an overview of new and changed APIs that you may want to look at! Collections, profile editing, #Wrapstodon, and more:
For #Mastodon app developers and fellow #fediverse platform developers, with the approaching Mastodon 4.6 release we've put together an overview of new and changed APIs that you may want to look at! Collections, profile editing, #Wrapstodon, and more:
For #Mastodon app developers and fellow #fediverse platform developers, with the approaching Mastodon 4.6 release we've put together an overview of new and changed APIs that you may want to look at! Collections, profile editing, #Wrapstodon, and more:
For #Mastodon app developers and fellow #fediverse platform developers, with the approaching Mastodon 4.6 release we've put together an overview of new and changed APIs that you may want to look at! Collections, profile editing, #Wrapstodon, and more:
I'm reading Canada's proposed Digital Safety Act. My conclusion is that the proposed regulations could be very burdensome to non-profit, community-run social media, including AoIR.social.
I'd love feedback on this, particularly from Canadian fediverse admins.
I'm reading Canada's proposed Digital Safety Act. My conclusion is that the proposed regulations could be very burdensome to non-profit, community-run social media, including AoIR.social.
I'd love feedback on this, particularly from Canadian fediverse admins.
This week I spoke to a room full of non-techy NGO people and for the first time there were more folks with #Fediverse than #Threads accounts in the room 🎉
This week I spoke to a room full of non-techy NGO people and for the first time there were more folks with #Fediverse than #Threads accounts in the room 🎉
This week I spoke to a room full of non-techy NGO people and for the first time there were more folks with #Fediverse than #Threads accounts in the room 🎉
Nächste Schritte: Gespräche mit den Fraktion im Stadtrat, Information der Öffentlichkeit und Vorstellung im Ausschuss. Bestimmt wird die Stadt darüber dann auch auf @BundesstadtBonn berichten. Folgt Ihnen doch schon einmal 😉
ALT text
Screenshot aus dem Rats-Informations-System der Stadt Bonn. Zu sehen sind die Daten des Bürgerantrags 261174 „Bürgerantrag: Antrag zu stärkeren Nutzung demokratisch organisierter Fediverse-Plattformen in der Öffentlichkeitsarbeit der Stadt“
Federführend ist das Bürgerbüro, beteiligt das Amt für Presse, Protokoll & Öffentlichkeitsarbeit. Als Beratungsfolge ist der Ausschuss für Beteiligung der Bürgerinnen und Bürger aufgeführt
Nächste Schritte: Gespräche mit den Fraktion im Stadtrat, Information der Öffentlichkeit und Vorstellung im Ausschuss. Bestimmt wird die Stadt darüber dann auch auf @BundesstadtBonn berichten. Folgt Ihnen doch schon einmal 😉
ALT text
Screenshot aus dem Rats-Informations-System der Stadt Bonn. Zu sehen sind die Daten des Bürgerantrags 261174 „Bürgerantrag: Antrag zu stärkeren Nutzung demokratisch organisierter Fediverse-Plattformen in der Öffentlichkeitsarbeit der Stadt“
Federführend ist das Bürgerbüro, beteiligt das Amt für Presse, Protokoll & Öffentlichkeitsarbeit. Als Beratungsfolge ist der Ausschuss für Beteiligung der Bürgerinnen und Bürger aufgeführt
„Je zult beleidsdiscussies krijgen die je nooit eerder had”, voorspelt hij... „Maar dat is ook goed. In plaats van die beslissingen in de handen leggen van een paar miljardairs, moeten mensen erover nadenken.”
Honestly, this makes a lot of sense. One unified live feed where the current horrors of the day are mixing with pictures of people's pets really isn't good for our mental health.
I guess CWs help here, a bit, but they often lead to fighting over everyone's expectations of how they should be applied.
Posting in dedicated communities and switching between them gives people more agency, I think.
„Je zult beleidsdiscussies krijgen die je nooit eerder had”, voorspelt hij... „Maar dat is ook goed. In plaats van die beslissingen in de handen leggen van een paar miljardairs, moeten mensen erover nadenken.”
In diesem Workshop zeigt @pepecyb an einem praktischen Beispiel, wie man mit Hubzilla eine Webseite erstellen kann. Von den Grundlagen bis zur konkreten Umsetzung gibt es viele Tipps und Einblicke für alle, die mehr aus Hubzilla machen möchten.
Hubzilla ist weit mehr als ein soziales Netzwerk und eine echte Bereicherung für das Fediverse. Wer die Möglichkeiten kennenlernen möchte, sollte diese Gelegenheit nicht verpassen.
In diesem Workshop zeigt @pepecyb an einem praktischen Beispiel, wie man mit Hubzilla eine Webseite erstellen kann. Von den Grundlagen bis zur konkreten Umsetzung gibt es viele Tipps und Einblicke für alle, die mehr aus Hubzilla machen möchten.
Hubzilla ist weit mehr als ein soziales Netzwerk und eine echte Bereicherung für das Fediverse. Wer die Möglichkeiten kennenlernen möchte, sollte diese Gelegenheit nicht verpassen.
Kennt ihr Fedimap? Eine Karte, auf der man sich als Fediverse-Freund freiwillig selbst verorten kann. Datensparsam, werbefrei, ohne Tracking, und man wählt einen ungefähren Ort, nicht die eigene Haustür. Das Schöne ist nicht die Karte selbst, sondern was sie zeigt: dass wir hier mehr sind, als es auf den ersten Blick wirkt. Noch tragen sich leider erstaunlich wenige ein, gemessen daran, wie lebendig gerade das deutschsprachige Fediverse ist.
Eintragen läuft per privater Erwähnung an @fedimap@linux.pizza, Befehl !in mit den Koordinaten, die du dir vorher auf fedimap.de geklickt hast.
Und wenn ihr im Großraum München auf der Karte nachseht, werdet ihr natürlich auch mich finden.
Fedizens! Please send me your favourite meme which shows something important about the #Fediverse
I'll go first:
ALT text
Star wars meme. Empire soldier land to interrogate the retired general. "Mastodon? Really? Man of your talents?". He replies: "It's a peaceful life"
From: https://knowyourmeme.com/memes/its-a-peaceful-life
"It's a Peaceful Life, also known as Really? Man Of Your Talents?, is a reaction image and image macro meme format using a scene from the 2016 film Rogue One: A Star Wars Story in which the character Galen Erso (played by actor Mads Mikkelsen) tells Orson Krennic (Ben Mendelsohn), "It's a peaceful life," after Krennic expresses pitiful shock that Erso is a farmer"
Kennt ihr Fedimap? Eine Karte, auf der man sich als Fediverse-Freund freiwillig selbst verorten kann. Datensparsam, werbefrei, ohne Tracking, und man wählt einen ungefähren Ort, nicht die eigene Haustür. Das Schöne ist nicht die Karte selbst, sondern was sie zeigt: dass wir hier mehr sind, als es auf den ersten Blick wirkt. Noch tragen sich leider erstaunlich wenige ein, gemessen daran, wie lebendig gerade das deutschsprachige Fediverse ist.
Eintragen läuft per privater Erwähnung an @fedimap@linux.pizza, Befehl !in mit den Koordinaten, die du dir vorher auf fedimap.de geklickt hast.
Und wenn ihr im Großraum München auf der Karte nachseht, werdet ihr natürlich auch mich finden.
En tant que mère, le pire sentiment est de regarder ses enfants et de se sentir impuissante. Notre situation est véritablement tragique et ma campagne est au point mort ; je n’ai même pas pu la promouvoir. Je compte entièrement sur votre générosité pour partager notre histoire. Merci de retweeter et de faire un don si vous le pouvez, et de nous soutenir. 🙏
The most common answer is people asking what #HolosDiscover is. It's a service that indexes messages across the #Fediverse and lets you search through the data. What makes HolosDiscover unique is that it's not a scraper. It has an account, several opt-outs that automatically remove data, and most importantly indexed messages are immediately removed or updated as soon as the owner makes a change.
I am at a stage with #HolosDiscover where I wonder if I should make it a separate project with its own server, or just clean up the DB from old messages. Of course, all messages are removed or updated as soon as the OP makes the action, but keeping such an amount of data impacts the infra I run alone for all my services. I have no way to track how it is used, so your feedback matters.
The most common answer is people asking what #HolosDiscover is. It's a service that indexes messages across the #Fediverse and lets you search through the data. What makes HolosDiscover unique is that it's not a scraper. It has an account, several opt-outs that automatically remove data, and most importantly indexed messages are immediately removed or updated as soon as the owner makes a change.
I am at a stage with #HolosDiscover where I wonder if I should make it a separate project with its own server, or just clean up the DB from old messages. Of course, all messages are removed or updated as soon as the OP makes the action, but keeping such an amount of data impacts the infra I run alone for all my services. I have no way to track how it is used, so your feedback matters.
🌐 9. Hubzilla-Workshop – „Webseiten mit Hubzilla – Teil 2“
📅 Mittwoch, 10. Juni 2026 🕢 19:30 Uhr 💻 Online
Unbedingt dabei sein!
Der erste Teil war so umfangreich und interessant, dass wir bereits nach 14 Tagen den zweiten Teil nachschieben. @chris hat uns eindrucksvoll seinen Weg von der ersten Idee bis zur fertigen Webseite vorgestellt und dabei viele wertvolle Einblicke in die praktische Umsetzung gegeben.
Wer den ersten Teil verpasst hat, braucht sich keine Sorgen zu machen: Zu Beginn gibt es eine kurze Zusammenfassung.
🔹 Die Webseiten-App 🔹 Gestaltungswerkzeuge 🔹 Inhaltstypen 🔹 Layouts und Vorlagen 🔹 Blöcke 🔹 Webseiten 🔹 Inhalte erstellen 🔹 Live-Beispiel einer Webseite
Hubzilla wird oft als Social-Network-CMS bezeichnet. Doch wie erstellt man damit tatsächlich Webseiten? Welche Möglichkeiten gibt es? Und wie setzt man eigene Ideen um?
Werft gern schon vorab einen Blick auf die von Chris mit Hubzilla umgesetzte umfangreiche Webseite: 🌐 emmais-koeln.de
Wenn Ihr erfahren möchtet, wie Ihr mit Hubzilla eigene Webseiten erstellen könnt, solltet Ihr diesen Workshop nicht verpassen!
Ich erklaere da wie der Konzern Donald Trump ueber sein Ballsaal-Projekt besticht, dafuer dicke Staatsauftraege bekommt und wie die Wettbewerbsbehoerden in den USA einfach mal ein Auge zudruecken, wenn T-Mobile US weitere Firmen aufschnupft.
In Deutschland wuerde Hoettges mit solchen Stunts wohl vor Gericht landen!
Ich erklaere da wie der Konzern Donald Trump ueber sein Ballsaal-Projekt besticht, dafuer dicke Staatsauftraege bekommt und wie die Wettbewerbsbehoerden in den USA einfach mal ein Auge zudruecken, wenn T-Mobile US weitere Firmen aufschnupft.
In Deutschland wuerde Hoettges mit solchen Stunts wohl vor Gericht landen!
Hallo @rujo und herzlich willkommen im Club der #Fedinauten. Komm rein und fühl dich wohl. Bei Fragen zum #Fediverse oder #Friendica melde dich einfach. Das Fediverse ist sehr hilfsbereit. 😊👋 #neuhier
BookWyrm project page showing information about the open-source social reading platform, including release details and a description of its reading, review, and social features.
ALT text
BookWyrm book discovery interface displaying a grid of book covers from various genres, highlighting browsing and recommendation features for readers.
BookWyrm project page showing information about the open-source social reading platform, including release details and a description of its reading, review, and social features.
ALT text
BookWyrm book discovery interface displaying a grid of book covers from various genres, highlighting browsing and recommendation features for readers.
"The last pull request taken from Federated user activity following was merged, which introduces the ability to follow other ActivityPub users and introduces an ActivityPub feed for federated notes from other instances [...]"
The #Forgejo monthly report was published ✨ Forgejo v15 was released, along with security releases. The Forgejo Security Team responds to community concerns. The Forgejo Runner had multiple releases, the Forgejo Helm chart v17 was released and the Forgejo v16 release is progressing.
Peerseek search results for octaman. 1 result, jackpot: exactly what I want. I don't have to waste time scanning a bunch of results only to find they're all irrelevant.
ALT text
Search results for monsterdon on Sepia Search. It says "25 results". After wading through all 25 results, zero were relevant. Zero. I did NOT search for monsterdog, monstermom, monsterland or monsterboken. (The situation was the same using the search on the peertube instance I use.)
ALT text
Peerseek results for monsterdon. 36 results (I wish Peerseek reported number of results), all relevant. Every single one. (PS I reduced browser display size to get a screenshot with smaller file size.)
ALT text
Sepia Search results for Octaman. 5 results. 0 relevant. (I did NOT search for octamino or octagang.) When using quotation marks around search term ("octaman"), 0 results. (Same results when searching on peertube instance I use.)
En tant que mère, le pire sentiment est de regarder ses enfants et de se sentir impuissante. Notre situation est véritablement tragique et ma campagne est au point mort ; je n’ai même pas pu la promouvoir. Je compte entièrement sur votre générosité pour partager notre histoire. Merci de retweeter et de faire un don si vous le pouvez, et de nous soutenir. 🙏
Wrote my first server announcement. Because yesterday, after updating my #Mastodon instance to 4.5.11, I didn't realise the Sidekiq died.
I spotted an unusual server load and temperature 24 hours later, found out that it was a Mastodon LXC, and realised there had been nothing processed by Sidekiq for 24 hours already.
I'm not sure about the reasons, because I didn't find anything useful in the logs. I definitely need better monitoring for #GlitchySocial.
Wrote my first server announcement. Because yesterday, after updating my #Mastodon instance to 4.5.11, I didn't realise the Sidekiq died.
I spotted an unusual server load and temperature 24 hours later, found out that it was a Mastodon LXC, and realised there had been nothing processed by Sidekiq for 24 hours already.
I'm not sure about the reasons, because I didn't find anything useful in the logs. I definitely need better monitoring for #GlitchySocial.
Once you have Fediverse Caching servers — you have the basis to create a Fediverse content-distribution-network (CDN).
A (Fediverse-native) Fediverse content-distribution-network (CDN) could bring a new level of robustness and scalability to the Fediverse — while still maintaining the properties of decentralization, federation, and localization.
![The image is a vertical, digital document with a light cream background textured like subtle parchment paper. A faint, repeating light-orange diagonal watermark reading "06/27/2026"Text ContentHeading:"Funeral Expenses/Arrangements for Yurie Ivy T. Bueno (A beloved cousin & niece) RIP" followed by a small hand-drawn illustration of three small leaves.Item 1:Icon: A checkbox with a checkmark.Text: "Embalming ₱ 5,000"Subtext: "(Paid in full by the donations from Yureii's Online Community)" with an underline stretching beneath the entire note.Item 2:Icon: A checkbox with a checkmark.Text: "Casket (basic) ₱ 9,500"Item 3:Icon: A checkbox with a checkmark.Text: "Chapel/Funeral Home Use (per day) ₱ 1,500"Subtext: "[ ₱7,500 Total of 5days= June 23,2026 — June 27,2026 ]"Item 4:Icon: A checkbox with a checkmark.Text: "Hearse/Transport ₱ 850"Item 5:Icon: A checkbox with a checkmark.Text: "Flowers- [ Yureii Batchmates Donated ]"Item 6:Icon: A checkbox with a checkmark.Text: "Church/Funeral Mass ₱ 3,000"Subtext: "(June 28,2026)"Item 7:Icon: A checkbox containing a large red "X" mark.Text: "Cemetery Lot- ( Still in Process ₱5,550 )"Item 8:Icon: A checkbox with a checkmark.Text: "Burial Permit ₱ 550"Item 9:Icon: A checkbox with a checkmark.Text: "Death Certificate (PSA) ₱365"](https://media.social.fedify.dev/media/019f2dba-d60b-7f98-a7cd-e4e5773297a0/thumbnail.webp)
