What a surprise. A protocol that largely depends on centralized sections, gets focused on by federal agencies and ends up needing to identify individual users (and not just their age) and collect their privite information.
It's almost like decentralization was actually a good idea... 🤔
Vielleicht nutze ich ab 2026 eine zweite #WordPress Installation als meine hauptsächliche #Fediverse / #Microblogging Instanz. Vorteil: Ich könnte sie wirklich selbst hosten. Bin gespannt was 2025 noch so kommt.
Vielleicht nutze ich ab 2026 eine zweite #WordPress Installation als meine hauptsächliche #Fediverse / #Microblogging Instanz. Vorteil: Ich könnte sie wirklich selbst hosten. Bin gespannt was 2025 noch so kommt.
Been reading up on the #ActivityPub spec as I design my plan out. There's a lot of really nice proposals out there I'm interested in considering implementing. Also been pretty happy with the @fedify library it's pretty awesome for hitting the ground running.
A question for #Fediverse devs: I’m thinking about better ways to document development of the #ActivityPub stack. This would include explanations, demo code, example snippets, and various sections explaining how to build a fully working Fediverse server, with consideration for all of the FEP documents as well.
What do you, as a developer, feel is currently missing? What information would make your life a lot easier?
Hypothetically, let’s say I’m an admin. I don’t like "John Doe" (just a random example). Instead of simply blocking John Doe myself, I demand that "Billy Bob" — the admin of his instance — remove him entirely.
Billy Bob refuses, because John Doe hasn’t broken any rules. So, being an egotistical maniac, I blacklist Billy Bob’s entire instance — 5,000+ innocent users who had nothing to do with anything.
I also have 5,000+ users on my instance. Now you’ve got over 10,000 people who can’t communicate, all because of a personal disagreement.
This kind of thing happens far too often on the Fediverse. If you create more than one account (on different instances), you’ll likely discover people you didn’t even know existed — people you’d want to follow but previously couldn’t, due to the growing fragmentation across the network.
The scale of the problem becomes even more obvious when you move to a different instance. You’ll likely find that not everyone you currently follow can be followed from the new site.
The solution?
Right now, it means having more than one account just to keep in touch with everyone you want to follow.
Does anyone have experience with Key Event Receipt Infrastructure (KERI)?
> “Could there possibly be a unifying #DID method that covers the use cases of all others?” This is precisely what #KERI attempts to be. What makes KERI special is also the fact that it is not just another DID method. The KERI protocol has a grander vision of being the #identity overlay for the internet.
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
ALT text detailsSide-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.
A question for #Fediverse devs: I’m thinking about better ways to document development of the #ActivityPub stack. This would include explanations, demo code, example snippets, and various sections explaining how to build a fully working Fediverse server, with consideration for all of the FEP documents as well.
What do you, as a developer, feel is currently missing? What information would make your life a lot easier?
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
ALT text detailsSide-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
ALT text detailsSide-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
ALT text detailsSide-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
ALT text detailsSide-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
ALT text detailsSide-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
ALT text detailsSide-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
ALT text detailsSide-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.
A question for #Fediverse devs: I’m thinking about better ways to document development of the #ActivityPub stack. This would include explanations, demo code, example snippets, and various sections explaining how to build a fully working Fediverse server, with consideration for all of the FEP documents as well.
What do you, as a developer, feel is currently missing? What information would make your life a lot easier?
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
ALT text detailsSide-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
ALT text detailsSide-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
ALT text detailsSide-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
ALT text detailsSide-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
ALT text detailsSide-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
ALT text detailsSide-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.
A question for #Fediverse devs: I’m thinking about better ways to document development of the #ActivityPub stack. This would include explanations, demo code, example snippets, and various sections explaining how to build a fully working Fediverse server, with consideration for all of the FEP documents as well.
What do you, as a developer, feel is currently missing? What information would make your life a lot easier?
A question for #Fediverse devs: I’m thinking about better ways to document development of the #ActivityPub stack. This would include explanations, demo code, example snippets, and various sections explaining how to build a fully working Fediverse server, with consideration for all of the FEP documents as well.
What do you, as a developer, feel is currently missing? What information would make your life a lot easier?
I can’t know definitively yet…I have to babysit my server and keep an eye on logs. But, I think I may have found the culprit for why I get timeout issues with #ActivityPub and #WordPress.
It might be PHP-FPM. If you’re using Nginx, this is kind of a “glue layer” for making PHP stuff talk to Nginx.
I host most things with Nginx, which sometimes requires configuring workarounds with traditional PHP applications. I was digging around in my logs during the latest server slowdown, and I got some error messages about pm.max_children and pm.start_servers being way too low.
Anyway, raising the amount seems to be helping? More word on this as experiments continue.
Hypothetically, let’s say I’m an admin. I don’t like "John Doe" (just a random example). Instead of simply blocking John Doe myself, I demand that "Billy Bob" — the admin of his instance — remove him entirely.
Billy Bob refuses, because John Doe hasn’t broken any rules. So, being an egotistical maniac, I blacklist Billy Bob’s entire instance — 5,000+ innocent users who had nothing to do with anything.
I also have 5,000+ users on my instance. Now you’ve got over 10,000 people who can’t communicate, all because of a personal disagreement.
This kind of thing happens far too often on the Fediverse. If you create more than one account (on different instances), you’ll likely discover people you didn’t even know existed — people you’d want to follow but previously couldn’t, due to the growing fragmentation across the network.
The scale of the problem becomes even more obvious when you move to a different instance. You’ll likely find that not everyone you currently follow can be followed from the new site.
The solution?
Right now, it means having more than one account just to keep in touch with everyone you want to follow.
#AskFedi do you know anyone with a federated Wordpress site who uses it extensively? Not just for publishing straight to the Fediverse, but also in a social way (aka as a fedi profile)?
I've run into a few roadblocks with mine and I could really use some inspiration 😊
UPDATE: thank you for all the superb recommendations. I don't think I need any more, I got a clear picture of what I need to do. I'll share more about this soon... Now I need to take my little one to the park ❤️
#AskFedi do you know anyone with a federated Wordpress site who uses it extensively? Not just for publishing straight to the Fediverse, but also in a social way (aka as a fedi profile)?
I've run into a few roadblocks with mine and I could really use some inspiration 😊
UPDATE: thank you for all the superb recommendations. I don't think I need any more, I got a clear picture of what I need to do. I'll share more about this soon... Now I need to take my little one to the park ❤️
#AskFedi do you know anyone with a federated Wordpress site who uses it extensively? Not just for publishing straight to the Fediverse, but also in a social way (aka as a fedi profile)?
I've run into a few roadblocks with mine and I could really use some inspiration 😊
UPDATE: thank you for all the superb recommendations. I don't think I need any more, I got a clear picture of what I need to do. I'll share more about this soon... Now I need to take my little one to the park ❤️
This is the first checkin I've done with the #ActivityPub API using the new checkin tool I've been working on for the SocialCG geosocial task force (https://swicg.github.io/geosocial/).
It is pretty neat. I will share more info when the tool is working better, but it feels cool.
#AskFedi do you know anyone with a federated Wordpress site who uses it extensively? Not just for publishing straight to the Fediverse, but also in a social way (aka as a fedi profile)?
I've run into a few roadblocks with mine and I could really use some inspiration 😊
UPDATE: thank you for all the superb recommendations. I don't think I need any more, I got a clear picture of what I need to do. I'll share more about this soon... Now I need to take my little one to the park ❤️
#AskFedi do you know anyone with a federated Wordpress site who uses it extensively? Not just for publishing straight to the Fediverse, but also in a social way (aka as a fedi profile)?
I've run into a few roadblocks with mine and I could really use some inspiration 😊
UPDATE: thank you for all the superb recommendations. I don't think I need any more, I got a clear picture of what I need to do. I'll share more about this soon... Now I need to take my little one to the park ❤️
#AskFedi do you know anyone with a federated Wordpress site who uses it extensively? Not just for publishing straight to the Fediverse, but also in a social way (aka as a fedi profile)?
I've run into a few roadblocks with mine and I could really use some inspiration 😊
UPDATE: thank you for all the superb recommendations. I don't think I need any more, I got a clear picture of what I need to do. I'll share more about this soon... Now I need to take my little one to the park ❤️
#AskFedi do you know anyone with a federated Wordpress site who uses it extensively? Not just for publishing straight to the Fediverse, but also in a social way (aka as a fedi profile)?
I've run into a few roadblocks with mine and I could really use some inspiration 😊
UPDATE: thank you for all the superb recommendations. I don't think I need any more, I got a clear picture of what I need to do. I'll share more about this soon... Now I need to take my little one to the park ❤️
#AskFedi do you know anyone with a federated Wordpress site who uses it extensively? Not just for publishing straight to the Fediverse, but also in a social way (aka as a fedi profile)?
I've run into a few roadblocks with mine and I could really use some inspiration 😊
UPDATE: thank you for all the superb recommendations. I don't think I need any more, I got a clear picture of what I need to do. I'll share more about this soon... Now I need to take my little one to the park ❤️
@nyquildotorg#Mastodon and #ActivityPub needs a mechanism where domain names can be recycled. The fact that WordPress alone has no mechanism to allow a domain to exit the fediverse is reason enough. Sometimes servers get bricked and there is no way to go back and self-destruct.
Domains could be validated with a text record in the DNS by the owner of the domain name. If text record ActivityPubKill is true, then it should be trusted as so and defederated.
I'm not sure how this could be done, I don't know the ins and out. Maybe software packages could poll the DNS of failing federated servers and look for a universal or software specific kill tag or a file could be placed somewhere on a server that it looks for when a server fails, esp after 7 days.
Either way, a dns entry or a file on a physical server can be a trusted source as it takes elevated permission by someone in charge of a domain to usually do such a thing. #MastoDev#MastoAdmin
Small quality of life update in ActivityPub for WordPress 7.0.0: You can now auto-approve likes and boosts from the Fediverse! No more manual approval needed if you moderate new comments.
ALT text detailsWordPress ActivityPub plugin settings for post interactions, showing options to receive likes, receive reblogs (boosts), and auto approve reactions, with the first two options checked.
@nyquildotorg#Mastodon and #ActivityPub needs a mechanism where domain names can be recycled. The fact that WordPress alone has no mechanism to allow a domain to exit the fediverse is reason enough. Sometimes servers get bricked and there is no way to go back and self-destruct.
Domains could be validated with a text record in the DNS by the owner of the domain name. If text record ActivityPubKill is true, then it should be trusted as so and defederated.
I'm not sure how this could be done, I don't know the ins and out. Maybe software packages could poll the DNS of failing federated servers and look for a universal or software specific kill tag or a file could be placed somewhere on a server that it looks for when a server fails, esp after 7 days.
Either way, a dns entry or a file on a physical server can be a trusted source as it takes elevated permission by someone in charge of a domain to usually do such a thing. #MastoDev#MastoAdmin
I am looking for experts/#developers who are familiar with #ActivityPub and who might be willing to chat with me.
I have started talking with parts of my network (mainly in D and NL), about how we could make the #Fediverse more interesting for content providers and main stream media. This also means attracting ordinary users to join and to find fair and simple ways to support content providers (without #paywalls). I have some ideas, but now need more expertise and a deeper look under the hood.
This is the first checkin I've done with the #ActivityPub API using the new checkin tool I've been working on for the SocialCG geosocial task force (https://swicg.github.io/geosocial/).
It is pretty neat. I will share more info when the tool is working better, but it feels cool.
This is the first checkin I've done with the #ActivityPub API using the new checkin tool I've been working on for the SocialCG geosocial task force (https://swicg.github.io/geosocial/).
It is pretty neat. I will share more info when the tool is working better, but it feels cool.
This is the first checkin I've done with the #ActivityPub API using the new checkin tool I've been working on for the SocialCG geosocial task force (https://swicg.github.io/geosocial/).
It is pretty neat. I will share more info when the tool is working better, but it feels cool.
This is the first checkin I've done with the #ActivityPub API using the new checkin tool I've been working on for the SocialCG geosocial task force (https://swicg.github.io/geosocial/).
It is pretty neat. I will share more info when the tool is working better, but it feels cool.
This is the first checkin I've done with the #ActivityPub API using the new checkin tool I've been working on for the SocialCG geosocial task force (https://swicg.github.io/geosocial/).
It is pretty neat. I will share more info when the tool is working better, but it feels cool.
@nyquildotorg#Mastodon and #ActivityPub needs a mechanism where domain names can be recycled. The fact that WordPress alone has no mechanism to allow a domain to exit the fediverse is reason enough. Sometimes servers get bricked and there is no way to go back and self-destruct.
Domains could be validated with a text record in the DNS by the owner of the domain name. If text record ActivityPubKill is true, then it should be trusted as so and defederated.
I'm not sure how this could be done, I don't know the ins and out. Maybe software packages could poll the DNS of failing federated servers and look for a universal or software specific kill tag or a file could be placed somewhere on a server that it looks for when a server fails, esp after 7 days.
Either way, a dns entry or a file on a physical server can be a trusted source as it takes elevated permission by someone in charge of a domain to usually do such a thing. #MastoDev#MastoAdmin
ALT text detailsDas Bild zeigt ein Profil auf einer Mastodon-Instanz (fedi) mit dem Namen meinwegraus.de. Im oberen Bereich ist ein Headerbild zu sehen, das in dunklen Farben gehalten ist. Es zeigt eine stilisierte Zeichnung einer Person mit erhobener Faust, umgeben von Linien, die wie Blitze oder Risse wirken. Die Figur ist in Neonfarben (blau und pink) gezeichnet. Darunter steht in pink-blauer Verlaufsfarbe der Text: meinwegraus.de.
Links unten befindet sich das Profilbild, das dieselbe stilisierte Figur wie im Header zeigt.
Der Profilname lautet: meinwegraus.de
Der Benutzername ist: @fedi@meinwegraus.de
Der Beschreibungstext lautet:
„Dieser Account ist der Blog-Account von meinwegraus.de
Hier geht es um leben mit: #Depressionen #PTBS #Angststörung #Sozialphobie #Abnehmen #Diät #Gewichtsreduktion #OMAD #OMEOD #Intervallfasten #Fasten #IntermittierendesFasten #Zuckerfrei #Essstörung #Esssucht #BingeEating“
Rechts oben befindet sich ein lila Button mit der Aufschrift Entfolgen (der Account wird also bereits verfolgt).
Darunter sind Buttons für Benachrichtigungen, Kopieren der Profil-URL und ein Drei-Punkte-Menü zu sehen. Der Hintergrund ist insgesamt dunkel, die Schrift weiß oder lila.
Small quality of life update in ActivityPub for WordPress 7.0.0: You can now auto-approve likes and boosts from the Fediverse! No more manual approval needed if you moderate new comments.
ALT text detailsWordPress ActivityPub plugin settings for post interactions, showing options to receive likes, receive reblogs (boosts), and auto approve reactions, with the first two options checked.
Small quality of life update in ActivityPub for WordPress 7.0.0: You can now auto-approve likes and boosts from the Fediverse! No more manual approval needed if you moderate new comments.
ALT text detailsWordPress ActivityPub plugin settings for post interactions, showing options to receive likes, receive reblogs (boosts), and auto approve reactions, with the first two options checked.
Small quality of life update in ActivityPub for WordPress 7.0.0: You can now auto-approve likes and boosts from the Fediverse! No more manual approval needed if you moderate new comments.
ALT text detailsWordPress ActivityPub plugin settings for post interactions, showing options to receive likes, receive reblogs (boosts), and auto approve reactions, with the first two options checked.
Important work happening around HTTP Signatures in the Fediverse. Stronger key validation, better digest handling, clearer test vectors—all steps toward more secure and trustworthy ActivityPub communication. HTTP Signature Upgrades Coming Soon
The list was moved from delightful-activitypub-development, which will be overhauled (thanks to @nlnet) to fully focus on #development of new #fediverse applications and services and evolution of the open standards of the ActivityPub family of social web technologies.
Important work happening around HTTP Signatures in the Fediverse. Stronger key validation, better digest handling, clearer test vectors—all steps toward more secure and trustworthy ActivityPub communication. HTTP Signature Upgrades Coming Soon
PSA: the #activitypub plugin for #wordpress has improved noticeably and now seems to play well with caching. Or perhaps my caching plugin started working well with the activitypub one.
If you run a WordPress blog do link it up to the #fediverse now! Share it with me too!
You can even see replies and likes, plus reply back, from within the WP dashboard, which is cool.
I would still not suggest it as a replacement for a mastodon account, but it is pretty nice.
The list was moved from delightful-activitypub-development, which will be overhauled (thanks to @nlnet) to fully focus on #development of new #fediverse applications and services and evolution of the open standards of the ActivityPub family of social web technologies.
PSA: the #activitypub plugin for #wordpress has improved noticeably and now seems to play well with caching. Or perhaps my caching plugin started working well with the activitypub one.
If you run a WordPress blog do link it up to the #fediverse now! Share it with me too!
You can even see replies and likes, plus reply back, from within the WP dashboard, which is cool.
I would still not suggest it as a replacement for a mastodon account, but it is pretty nice.
If a Threads user with Fediverse sharing enabled mentions @mosseri in a post the link to his account fails, but will open in a browser / the Threads app.
Mentions from Mastodon successfully link to his account.
I am looking for experts/#developers who are familiar with #ActivityPub and who might be willing to chat with me.
I have started talking with parts of my network (mainly in D and NL), about how we could make the #Fediverse more interesting for content providers and main stream media. This also means attracting ordinary users to join and to find fair and simple ways to support content providers (without #paywalls). I have some ideas, but now need more expertise and a deeper look under the hood.
I am looking for experts/#developers who are familiar with #ActivityPub and who might be willing to chat with me.
I have started talking with parts of my network (mainly in D and NL), about how we could make the #Fediverse more interesting for content providers and main stream media. This also means attracting ordinary users to join and to find fair and simple ways to support content providers (without #paywalls). I have some ideas, but now need more expertise and a deeper look under the hood.
I am looking for experts/#developers who are familiar with #ActivityPub and who might be willing to chat with me.
I have started talking with parts of my network (mainly in D and NL), about how we could make the #Fediverse more interesting for content providers and main stream media. This also means attracting ordinary users to join and to find fair and simple ways to support content providers (without #paywalls). I have some ideas, but now need more expertise and a deeper look under the hood.
It's very annoying, but it's also good to customize your environment. At the moment I'm about to start #rdfpub with docker again and it's scary how many problems I have with the environment. Although I test a lot, there are still gaps in the integration. Or rather gaps again, I already had integration tests that used test containers. It's just so time-consuming that I deactivated it at some point.
It's very annoying, but it's also good to customize your environment. At the moment I'm about to start #rdfpub with docker again and it's scary how many problems I have with the environment. Although I test a lot, there are still gaps in the integration. Or rather gaps again, I already had integration tests that used test containers. It's just so time-consuming that I deactivated it at some point.
I am looking for experts/#developers who are familiar with #ActivityPub and who might be willing to chat with me.
I have started talking with parts of my network (mainly in D and NL), about how we could make the #Fediverse more interesting for content providers and main stream media. This also means attracting ordinary users to join and to find fair and simple ways to support content providers (without #paywalls). I have some ideas, but now need more expertise and a deeper look under the hood.
I am looking for experts/#developers who are familiar with #ActivityPub and who might be willing to chat with me.
I have started talking with parts of my network (mainly in D and NL), about how we could make the #Fediverse more interesting for content providers and main stream media. This also means attracting ordinary users to join and to find fair and simple ways to support content providers (without #paywalls). I have some ideas, but now need more expertise and a deeper look under the hood.
I am looking for experts/#developers who are familiar with #ActivityPub and who might be willing to chat with me.
I have started talking with parts of my network (mainly in D and NL), about how we could make the #Fediverse more interesting for content providers and main stream media. This also means attracting ordinary users to join and to find fair and simple ways to support content providers (without #paywalls). I have some ideas, but now need more expertise and a deeper look under the hood.
I am looking for experts/#developers who are familiar with #ActivityPub and who might be willing to chat with me.
I have started talking with parts of my network (mainly in D and NL), about how we could make the #Fediverse more interesting for content providers and main stream media. This also means attracting ordinary users to join and to find fair and simple ways to support content providers (without #paywalls). I have some ideas, but now need more expertise and a deeper look under the hood.
I am looking for experts/#developers who are familiar with #ActivityPub and who might be willing to chat with me.
I have started talking with parts of my network (mainly in D and NL), about how we could make the #Fediverse more interesting for content providers and main stream media. This also means attracting ordinary users to join and to find fair and simple ways to support content providers (without #paywalls). I have some ideas, but now need more expertise and a deeper look under the hood.
I am looking for experts/#developers who are familiar with #ActivityPub and who might be willing to chat with me.
I have started talking with parts of my network (mainly in D and NL), about how we could make the #Fediverse more interesting for content providers and main stream media. This also means attracting ordinary users to join and to find fair and simple ways to support content providers (without #paywalls). I have some ideas, but now need more expertise and a deeper look under the hood.
I am looking for experts/#developers who are familiar with #ActivityPub and who might be willing to chat with me.
I have started talking with parts of my network (mainly in D and NL), about how we could make the #Fediverse more interesting for content providers and main stream media. This also means attracting ordinary users to join and to find fair and simple ways to support content providers (without #paywalls). I have some ideas, but now need more expertise and a deeper look under the hood.
Today I coded something I've been dreaming about for many months - a solution to the #ActivityPub scaling problem.
The problem is that if 20 people cast 5 votes and those votes are federated to 500 servers, the instance hosting the community needs to do 20 * 5 * 500 = 50,000 network requests.
Today I coded something I've been dreaming about for many months - a solution to the #ActivityPub scaling problem.
The problem is that if 20 people cast 5 votes and those votes are federated to 500 servers, the instance hosting the community needs to do 20 * 5 * 500 = 50,000 network requests.
Today I coded something I've been dreaming about for many months - a solution to the #ActivityPub scaling problem.
The problem is that if 20 people cast 5 votes and those votes are federated to 500 servers, the instance hosting the community needs to do 20 * 5 * 500 = 50,000 network requests.
Today I coded something I've been dreaming about for many months - a solution to the #ActivityPub scaling problem.
The problem is that if 20 people cast 5 votes and those votes are federated to 500 servers, the instance hosting the community needs to do 20 * 5 * 500 = 50,000 network requests.
Today I coded something I've been dreaming about for many months - a solution to the #ActivityPub scaling problem.
The problem is that if 20 people cast 5 votes and those votes are federated to 500 servers, the instance hosting the community needs to do 20 * 5 * 500 = 50,000 network requests.
Updating #ActivityPub objects and interactions seem to be somewhat complicated.
Many implementations incompletely support JSON-LD so piece-meal updating is not great, and implementations seem to have no ability to signal to eachother whether they do have such support (providing a limited context-set for interoperability if lacking support for different contexts, etc).
This makes me wonder how issues with the ActivityPub protocol are supposed to get addressed.
Updating #ActivityPub objects and interactions seem to be somewhat complicated.
Many implementations incompletely support JSON-LD so piece-meal updating is not great, and implementations seem to have no ability to signal to eachother whether they do have such support (providing a limited context-set for interoperability if lacking support for different contexts, etc).
This makes me wonder how issues with the ActivityPub protocol are supposed to get addressed.
"But under the hood, the #ActivityPub protocol doesn’t use full mentions at all. Instead, it uses actor IDs."
The actor ID for my main account is https://mastodon.social/users/crepels. In my case, there is a direct translation between the full mention and the actor ID, but that doesn’t have to be the case."
Intriguing. So in theory, the Actor ID for a fediverse account could also be represented in an app as @username@email.service or @username@xmpp.service 🤔
"But under the hood, the #ActivityPub protocol doesn’t use full mentions at all. Instead, it uses actor IDs."
The actor ID for my main account is https://mastodon.social/users/crepels. In my case, there is a direct translation between the full mention and the actor ID, but that doesn’t have to be the case."
Intriguing. So in theory, the Actor ID for a fediverse account could also be represented in an app as @username@email.service or @username@xmpp.service 🤔
Haven't turned on Federation yet, but my Bonfire instance is looking good. My second install of Bonfire. I can tell you two things: Installation was much easier this time, and performance is much better.
One note, Bonfire recommends a hungry 8 GB of memory to run, but with that amount, it runs nicely so far. I'll keep you updated, hoping to turn federation on by next weekend. (This will be an invite only instance for brave individuals that want to assist with testing)
ALT text detailsA screenshot of a discussion interface, featuring a user profile on the left side. The main content displays an image of a scenic landscape with two figures sitting by a fire. Below the image, there is a section labeled "Code" with a SQL command and a quote about using fire for transformation. The interface includes navigation elements and a trending topics section.
They made it clear, though, that they're not going to do it themselves in any foreseeable future, their "current focus isn't in this area", so it's up to the community to implement it. As I mentioned in the issue, I won't be able to come back to it until I'm done bootstraping the business I'm working on, so anyone who wants to see it done faster should feel free to jump in.
They made it clear, though, that they're not going to do it themselves in any foreseeable future, their "current focus isn't in this area", so it's up to the community to implement it. As I mentioned in the issue, I won't be able to come back to it until I'm done bootstraping the business I'm working on, so anyone who wants to see it done faster should feel free to jump in.
Ghost’s @johnonolan and WordPress’s @pfefferle want to help blogs and long content thrive on the open social web. Meet “the longformers,” who chatted to @mike for the latest edition of Dot Social.
It covers everything from setting up the #fediverse accounts and development environment to finding good first issues. While it's primarily for the OSSCA participants, anyone interested in contributing to @fedify is welcome to use it as a reference.
Ready to onboard the next wave of #ActivityPub developers!
이 문서는 기본적으로 오픈 소스 컨트리뷰션 아카데미 참여형 프로그램을 진행하게 된 멘티들을 위한 것입니다만, Fedify 프로젝트에 기여하고 싶은 분들이라면 얼마든지 활용하셔도 좋습니다.
안녕하세요. 오픈 소스 컨트리뷰션 아카데미 참여형 프로그램에서 Fedify 프로젝트를 함께 할 멘토 홍민희입니다.
Fedify 프로젝트에 참여하시게 된 것을 진심으로 환영합니다. 본 문서에서는 여러분이 앞으로 Fedify 프로젝트에 기여하기 위해서 알고 준비해야 하는 것들을 정리했습니다. 조금 긴 내용이 될 수도 있지만, 차근차근 읽어보시고 따라해야 할 과제는 따라해 주시기 바랍니다. 본 문서에 나온 과제들은 본격적인 기여를 위해 반드시 선행되어야 합니다.
소통 채널
중요
OSSCA 자체 Discord 서버에도 초대되셨을 것입니다만, 그곳에서는 행사에 관한 이야기만 주로 하게 될 겁니다. 실제 기여와 개발에 관련된 이야기는 지금부터 설명할 Fedify 프로젝트의 Discord 서버에서 이뤄지게 됩니다.
가장 먼저 해야 할 것은 Fedify 프로젝트의 Discord 서버에 입장하는 것입니다. 만약 아직 Discord 계정이 없다면 하나 만드세요. 꽤 많은 오픈 소스 프로젝트들이 Discord에서 소통을 합니다. Discord 계정을 만들어 두면 앞으로 다양한 오픈 소스 프로젝트에 기여할 때 쓸모가 많을 것입니다.
그러면 한국어를 포함해 자신이 이해할 수 있는 언어들을 선택하시면 됩니다. 그러면 여러 채널들이 보이게 되는데, 그 중에서 여러분이 주로 이용하게 될 채널은 #fedify-dev-ko 채널입니다.
본 문서를 읽고 따라하면서 중간에 어려움이 있거나 막히는 부분이 있으면 해당 채널에서 편하게 질문하시면 됩니다.
프로젝트 관련해서 궁금한 점은 사소한 것이라도 Discord 서버에서 질문 주세요. “시간이 날 때 천천히 해결해야지”보다는 일단 물어보는게 낫습니다. 특히 초반의 많은 문제는, 보통 질문을 많이 하면 빨리 해결됩니다. 시간을 정해두세요. 이를테면 30분으로 정했으면 30분 내로 해결이 안되면 일단 질문을 합시다.
과제
Discord 서버에 입장하신 뒤, #fedify-dev-ko 채널에서 간단히 자기 소개를 해 주세요. 본인의 이름과 GitHub 아이디를 꼭 알려주시기 바랍니다.
권고
원활하고 즉시적인 소통을 위해서는 모바일 앱으로 알림을 받을 수 있어야 합니다. 본인의 스마트폰에 Discord 앱을 설치하고 로그인한 뒤, 알림을 허용해 주세요. 랩톱 및 데스크톱 환경에서도 Discord 앱을 설치하고 항상 실행해 두실 것을 권합니다.
권고
가능하다면 Discord 계정의 아바타를 GitHub 계정의 프로필 사진과 통일해 주세요. 멘티가 워낙 많기 때문에 누가 누군지 기억하기 어렵기 때문입니다. 특히, 아무런 이미지도 설정해 두지 않은 분들은 아무 그림이라도 좋으니 시인성을 위해 설정을 부탁드립니다.
연합우주(fediverse)란?
안내
이미 연합우주나 ActivityPub에 대해 익숙하신 분들은 설명은 건너 뛰시고 이 섹션 마지막의 과제만 하셔도 괜찮습니다.
Fedify 프로젝트가 어떤 프로젝트인지 이해하기 위해서는, 우선 페디버스(fediverse), 즉 한국어로 연합우주에 대해 기본적인 이해를 갖출 필요가 있습니다.
종래의 중앙집권적인 SNS들은 크게 두 가지 특징이 있습니다. 첫째로, SNS에 올리는 사용자들의 모든 데이터를 특정 기업이 사유한다는 것입니다. 둘째로, 서로 다른 SNS끼리는 소통할 수 없다는 것입니다. 특히, 두번째 특징은 이메일을 생각해 보면 아주 자연스러운 것은 아니라는 것을 알 수 있습니다. 네이버 메일을 쓰는 사람이 Gmail을 쓰는 사람과 소통할 수 없을까요? 그렇지 않지요. 하지만 Instagram 사용자는 X (舊 Twitter) 사용자와 소통할 수 없습니다.
이러한 문제를 해결하고자 나온 대안 SNS들이 있습니다. Mastodon이나 Pixelfed 같은 것들이 그렇습니다. 그리고 이러한 SNS들은 누구라도 자신의 서버에 설치가 가능합니다. 실제로 홈 서버에서 돌아가는 Mastodon 서버도 꽤 많습니다. 물론, 직접 서버를 운영하고 싶지 않은 대부분의 사람들에게는 대형 서버라는 선택지도 있습니다. 이를테면, Mastodon 서버 중에서 가장 사용자가 많은 서버인 mastodon.social은 Mastodon 개발 팀이 직접 운영하는 서버입니다.
하지만 이런 의문이 드실 수 있습니다. 자신의 홈 서버에 Mastodon을 설치해봤자 혼자 쓰는 일기장이 아닌가? 사실, Mastodon 서버들은 서로 소통이 가능합니다. 마치 이메일과도 같습니다. 자신의 홈 서버에 이메일 서버를 설치하여 자신만의 이메일 주소를 만들어도, 네이버 메일이나 Gmail과 서로 메일을 주고 받을 수 있는 것처럼요. 실제로, Mastodon의 계정 이름은 이메일 주소와 비슷하게 생겼습니다:
@username@server.com
이렇게 서로 다른 Mastodon 서버끼리 소통할 수 있도록 고안된 표준이 바로 ActivityPub 프로토콜입니다. 참고로, 이 ActivityPub 프로토콜은 Mastodon 프로젝트가 독자적으로 정한 게 아니라, W3C에서 웹 표준으로 정한 것입니다. 따라서 Mastodon 뿐만 아니라, Pixelfed 등 ActivityPub을 구현하는 다른 소프트웨어들도 서로 소통이 됩니다. Mastodon에서 Pixelfed로 댓글 다는 것도 되고, Pixelfed 사용자가 Mastodon 사용자를 팔로하는 것도 됩니다.
이렇게 서로 다른 SNS 소프트웨어, 사로 다른 서버끼리 자유롭게 소통이 가능한 구조를 연합(federation)이라고 부릅니다. 어떻게 보면, 이렇게 연합된 서로 다른 SNS들을 모두 합쳐서 하나의 SNS라고 볼 수도 있습니다. 이를 부르는 말이 바로 연합우주, 페디버스입니다.
연합우주는 현재도 꾸준히 커 가고 있습니다. 최근에는 Meta의 Threads도 ActivityPub을 구현하게 되었고, WordPress도 ActivityPub 플러그인을 공식적으로 개발했습니다. 특히, 기존의 연합우주 소프트웨어들은 각자의 서버에 직접 설치할 수 있는 오픈 소스 소프트웨어였던 것에 반해, Threads는 오픈 소스가 아님에도 ActivityPub을 구현했다는 점에서 상당히 이례적이라고 할 수 있습니다. 이런 방식의 연합도 가능하다는 것이죠.
아직 연합우주를 경험해 본 적 없다면, 계정을 하나 만들어 봅시다. 계정을 만들기 위해서는 어떤 소프트웨어를 쓸 지 먼저 정해야 합니다. Mastodon과 Misskey는 일종의 X처럼 단문을 중심으로 한 SNS입니다. Pixelfed는 Instagram처럼 사진을 중심으로 한 SNS입니다. Meta의 Threads도 있습니다. 현재 읽고 계시는 이 글이 올라온 Hackers' Pub도 사실은 연합우주의 일부로서, 소프트웨어 개발자들을 위한 SNS입니다. 이 중 어떤 것을 선택하시든 서로 소통하는 데에는 문제가 없습니다.
만약 Mastodon이나 Misskey, Pixelfed를 선택하셨다면, 서버를 고르셔야 합니다. (물론, 서버를 직접 구축하시는 것도 괜찮습니다. 아마 많은 걸 배우실 수 있을 겁니다.) 무슨 서버를 골라야 할 지 모르시겠다면, Mastodon의 경우 silicon.moe 서버를, Misskey의 경우 stella.place 서버를, Pixelfed의 경우 chueok.pics 서버를 권합니다.
만약 Threads를 고르셨다면, 서버를 고를 필요가 없습니다. Threads는 설치형 소프트웨어가 아니라 Meta에서 운영하는 상용 서비스이기 때문입니다. 다만, 설정에 가셔서 페디버스 공유 설정을 켜 주셔야 합니다.
만약 Hackers' Pub을 고르셨다면, 역시 서버를 고를 필요가 없습니다. 단 하나의 서버만 있기 때문입니다. 다만, 초대장이 필요하므로 멘토에게 초대장을 요청하시기 바랍니다.
과제
연합우주 계정이 생기셨다면, 이제 친구를 사귀어야 합니다. 다른 멘티들에게 계정 주소를 물어보고 서로 팔로를 해 보세요. 멘토도 팔로해 보세요. (멘토도 맞팔 하겠습니다.) 멘토의 연합우주 계정 주소는 @hongminhee@hackers.pub입니다.
계정 주소로 팔로하는 방법은 소프트웨어마다 조금씩 다르지만, 대부분의 경우 검색창에 주소를 입력하면 해당 계정이 보입니다. 계정이 보인다면 팔로 버튼을 누르면 됩니다.
과제
생성한 계정으로 멘토의 계정인 @hongminhee@hackers.pub을 멘션하여 글을 써 주세요. 글 내용은 뭐든 좋습니다.
JavaScript와 TypeScript
안내
이미 JavaScript와 TypeScript에 익숙하시다면 이 챕터는 넘기셔도 됩니다.
Fedify 프로젝트는 TypeScript로 작성되어 있습니다. TypeScript는 JavaScript에 정적 타입 검사를 추가한 언어로, 런타임에 버그를 발생시키는 잘못된 코드를 코드 작성 시에 미리 알 수 있도록 도와줍니다. TypeScript를 이해하려면 먼저 JavaScript를 이해해야 합니다.
아직 JavaScript에 익숙하지 않으신 분들은 《모던 JavaScript 튜토리얼》의 파트 1을 읽고 따라해 볼 것을 권합니다. 파트 2 이후의 내용은 Fedify 프로젝트에 기여하는 데에 크게 필요하지 않으므로 읽지 않으셔도 좋습니다.
JavaScript에는 어느 정도 익숙하지만 아직 TypeScript에 익숙하지 않으신 분들께는, 《The TypeScript Handbook》을 읽고 따라해 볼 것을 권합니다. 참고로 핸드북 페이지 우측 상단에 한국어 번역으로 가는 링크가 있습니다.
사실 오픈 소스 프로젝트에 기여하기 위해 반드시 그 프로젝트에서 쓰이는 언어를 속속들이 깊게 이해해야 하는 건 아닙니다. 기여할 때 필요한 만큼만 이해해도 좋으니, 어느 정도 언어 문법에 익숙해졌다 싶으면 실제 Fedify 코드를 읽는 것을 좀 더 추천합니다. 코드를 읽다가 이해가 안 되는 부분이 있으면 해당 언어 문법에 대해 따로 조사하는 식으로 익히시는 게 더 효율적입니다. 정 이해가 안 되는 경우에는 부담 없이 Fedify 프로젝트 Discord 서버의 #fedify-dev-ko 채널에서 질문해 주세요.
Fedify란?
여러분은 웹 서버 애플리케이션을 만들 때 HTTP를 직접 구현하시나요? 아마도 대부분은 그렇지 않을 겁니다. 그러기엔 할 게 너무 많기 때문이죠. 대신 우리는 대부분 Express나 Next.js, Django 같은 웹 프레임워크를 이용해서 개발하게 됩니다.
마찬가지로, 연합우주 SNS 소프트웨어를 구현하려고 할 경우, ActivityPub을 바닥부터 구현하기에는 너무 할 게 많습니다. 따라서 개발을 쉽게 해 줄 프레임워크가 필요한데, 그게 바로 Fedify입니다.
어떤 오픈 소스 프로젝트든 간에, 해당 프로젝트에 기여하기 위해서는 먼저 그 소프트웨어를 써보고 기본적인 기능들을 숙지해야 합니다. 써보지도 않은 소프트웨어에 기여를 하는 것은 무리입니다. 여러분도 Fedify에 기여하기에 앞서 Fedify를 써 볼 필요가 있습니다.
Fedify는 연합우주 소프트웨어를 만드는 도구이므로, Fedify를 사용한다고 하면 연합우주 소프트웨어를 만들어 본다는 뜻이 됩니다. Fedify를 사용하여 작은 ActivityPub 서버 소프트웨어를 만들어 보세요. Fedify를 써 보면서 이해가 안 가거나 중간에 막히는 게 있다면 Discord 서버의 #fedify-help-ko 채널에서 질문하세요.
과제
Fedify를 배우고 써보는 가장 쉬운 방법은 튜토리얼을 읽고 따라하는 것입니다. Fedify 공식 튜토리얼의 한국어판인 〈나만의 연합우주 마이크로블로그 만들기〉를 읽고 그대로 따라서 진행하세요. 빠르면 하루, 느긋하게 하면 사흘 정도 걸립니다. 중간에 막히는 부분이 있으면 멘토에게 부담 없이 질문하세요.
저장소 포크 및 클론
주의
Windows 환경에서 작업하실 때는 (WSL을 사용하지 않는다면) Git의 core.autocrlf 설정을 꺼 주시기 바랍니다:
git config --global core.autocrlf false
안내
Fedify 프로젝트를 Windows 환경에서 개발할 수는 있지만, Linux나 macOS에 비해 편의성이 떨어지는 것도 사실입니다. 가능하면 WSL을 세팅하시고 WSL 안에서 작업하시는 걸 추천드립니다.
Fedify의 GitHub에 저장소가 올라가 있습니다. 해당 저장소를 각자 포크(fork)하신 뒤, 포크한 저장소를 로컬에 클론하세요. 클론하신 뒤, 클론한 로컬 저장소 안에 들어가 업스트림 저장소를 리모트로 추가하시는 것을 권합니다:
Fedify의 개발 환경 설정은 일반적인 JavaScript 프로젝트들에 비해 조금 복잡한 편입니다. Node.js 이외에도 Deno와 Bun 등 여러 런타임을 지원해야 하기 때문인데요. Fedify의 개발을 위해서는 다음 소프트웨어가 시스템에 모두 설치되어 있어야 합니다:
대부분의 Linux의 경우 (또는 Windows의 WSL 안에서 작업하는 경우) 별 다른 설정을 하지 않았다면 bash를 쓰고 계실 것입니다. macOS를 쓰시고 별 다른 설정을 하지 않으셨다면 zsh을 쓰고 계실 것입니다. (WSL이 아닌) Windows의 경우에는 명령 프롬프트가 아닌 PowerShell 안에서 작업하셔야 합니다.
mise를 설치하셨다면, 로컬 저장소 안에 들어가 다음 명령어로 필요한 모든 소프트웨어를 한 번에 설치하실 수 있습니다:
mise install --yes
위 명령어를 실행하면 아래와 같이 Fedify 저장소 안에 들어있는 mise 설정 파일을 신뢰하겠냐는 프롬프트가 뜹니다. Yes를 선택해 주세요:
mise config files in ~/fedify are not trusted. Trust them? Yes No All ←/→ toggle • y/n/a/enter submit
개발 환경이 잘 설정되었는지 확인하기 위해 Fedify의 전체 테스트 스위트를 실행해 봅시다. 첫 실행 시 통상 5분 정도 소요됩니다:
deno task test-all
Git 훅도 설치합니다:
deno task hooks:install
마지막으로 실제 편집 환경을 구성해야 합니다. 본 문서에서는 Visual Studio Code를 사용하는 것을 가정하겠습니다만, 같은 Visual Studio Code 계열인 Cursor나 Windsurf에서도 과정은 대동소이합니다.
경고
Visual Studio와 Visual Studio Code는 서로 전혀 다른 별개의 제품이니 주의하세요.
안내
여러분이 Emacs나 Vim의 독실한 신자라면 Visual Studio Code를 사용하고 싶지 않을 수 있습니다. 그런 경우, Deno의 공식 환경 설정 문서를 참고하여 Deno 랭귀지 서버를 설정해 주시기 바랍니다.
우선 로컬 저장소 안에서 code 명령어를 통해 Visual Studio Code를 띄웁니다:
code . # Visual Studio Code를 사용하는 경우cursor . # Cursor를 사용하는 경우windsurf . # Windsurf를 사용하는 경우
Visual Studio Code 창이 뜨면, 화면 가운데에 다음과 같은 프롬프트 창이 뜹니다:
프롬프트에서 예, 작성자를 신뢰합니다 버튼을 선택합니다. 그러면 오른쪽 아래에 다음과 같은 작은 프롬프트 창이 뜹니다:
프롬프트에서 설치 버튼을 선택합니다. 그러면 화면 가운데에 다음과 같은 프롬프트 창이 뜹니다:
프롬프트에서 게시자 신뢰 및 설치를 선택합니다. 그러면 Visual Studio Code에 Fedify 개발에 필요한 확장들이 설치되게 됩니다.
이로써 Fedify 기여에 필요한 기본적인 개발 환경 설정이 끝났습니다.
JavaScript 런타임
Fedify는 Deno, Node.js, Bun 등 다양한 JavaScript 런타임을 지원해야 합니다. 과연 JavaScript 런타임이 뭘까요?
JavaScript는 비교적 작은 언어입니다. 여러분이 process.exit() 같은 메서드를 활용하신 적 있다면, 이는 JavaScript 자체의 기능이 아니라 Node.js라는 특정한 JavaScript 런타임이 제공하는 기능입니다. 마찬가지로, 웹 브라우저에서 제공하는 DOM API 역시 JavaScript 자체의 기능이 아니라 웹 브라우저라는 (일종의) JavaScript 런타임이 제공하는 기능이라고 볼 수 있습니다.
모듈 시스템을 제공합니다. 예를 들어, Node.js는 node_modules/ 디렉터리 기반의 모듈 시스템을 제공하는 반면, Deno에서는 임포트 맵(import map) 기반의 모듈 시스템을 제공합니다. Node.js에서는 npm이나 pnpm, Yarn 등의 패키지 관리자를 사용해야 하지만, Deno나 Bun은 자체적인 패키지 관리자를 제공합니다. 웹 브라우저나 Cloudflare Workers는 패키지 관리자를 제공하지 않기 때문에 번들링이라는 과정을 거쳐야 합니다.
앞서 설명한 모든 것을 속속들이 이해해야 할 필요는 없습니다. 중요한 것은, 같은 JavaScript라고 하더라도 어느 런타임에서 실행하냐에 따라 상당히 다른 방식으로 언어를 사용해야 한다는 점입니다.
그러면 Fedify 프로젝트는 다양한 JavaScript 런타임을 어떻게 동시에 다 지원할 수 있을까요? 크게 두 가지 방법이 있습니다:
지원해야 하는 JavaScript 런타임 모두에서 공통적으로 지원하는 API만을 사용합니다.
런타임에 따라 다른 코드를 실행하도록 코드를 여러 벌 작성합니다.
Fedify 프로젝트는 두 가지 방법 모두 사용하고 있으며, 지원하는 모든 JavaScript 런타임에서 테스트 스위트를 실행해서 Fedify의 모든 기능이 각 JavaScript 런타임에서 잘 동작하는지를 검사합니다.
Fedify 저장소의 구조
2025년 7월 현재, Fedify 프로젝트의 저장소는 다음과 같은 구조로 되어 있습니다:
fedify/ — Fedify의 핵심인 @fedify/fedify 패키지입니다. 이 패키지는 Deno, Node.js, Bun, Cloudflare Workers 환경에서 동작합니다.
cli/ — Fedify 사용자들을 위한 CLI 개발 도구인 @fedify/cli 패키지입니다. 이 패키지는 Deno로만 작성됩니다.
examples/ — 이름 그대로 Fedify를 사용하는 예제 프로젝트들이 들어 있습니다.
scripts/ — 프로젝트 관리를 위한 스크립트들이 들어 있습니다. 대부분의 경우 건드릴 일이 없을 겁니다.
여러분은 주로 fedify/ 디렉터리 및 cli/ 디렉터리에서 작업을 하게 될 것입니다.
린트와 테스트
여느 오픈 소스 프로젝트들이 그렇듯, Fedify 프로젝트도 나름의 코딩 컨벤션과 규칙들이 있습니다. 다행히 이들 대부분은 커밋하기 전에 기계적으로 검사가 가능합니다. 다음 명령어는 현재 프로젝트의 코드가 코딩 컨벤션을 잘 지키고 타입 오류가 없는지 검사합니다:
deno task check
다음 명령어는 코드를 코딩 컨벤션에 맞게 알아서 서식화합니다:
deno fmt
앞서 언급한 것처럼, 다음 명령어는 Fedify 프로젝트의 전체 테스트 스위트를 실행하고 필요한 검사를 수행합니다. 풀 리퀘스트를 올리기 전에 한 번 실행해 보십시오:
deno task test-all
@fedify/fedify 패키지를 수정했을 경우, 수정과 관련된 일부 테스트 코드만 빠르게 실행해 보고 싶을 수 있습니다. 그럴 때는 다음과 같이 -f @fedify/fedify 옵션과 --filter 옵션을 함께 활용해 보세요 (태스크 이름이 test-all이 아니라 test임에 주의하세요):
deno task -f @fedify/fedify test --filter verifyRequest
혹은 -f @fedify/fedify 옵션을 쓰는 대신 직접 fedify/ 디렉터리 안에서 deno task test 명령어를 사용하셔도 됩니다:
cd fedify/deno task test --filter verifyRequest
참고로 --filter 옵션은 테스트 케이스 이름을 부분 문자열로 검색합니다. 이를테면, 다음과 같은 테스트가 있을 경우:
test("anArbitraryTest", () => { // … 생략 …});
다음과 같은 방식으로 모두 실행이 가능합니다:
deno task -f @fedify/fedify test --filter anArbitraryTestdeno task -f @fedify/fedify test --filter Arbitrarydeno task -f @fedify/fedify test --filter Test
앞서 설명한 deno task test 명령어는 Deno 런타임에서 테스트 스위트를 실행합니다. Node.js에서도 잘 돌아가나 확인하기 위해서는 Node.js 런타임에서도 테스트 스위트를 실행해 봐야 합니다. fedify/ 디렉터리 안쪽에서pnpm test 명령어를 통해 Node.js에서 테스트 스위트를 돌려 볼 수 있습니다:
cd fedify/pnpm test
일부 테스트만 빠르게 실행해 보고 싶을 경우 --test-name-pattern 옵션을 활용하세요:
pnpm test --test-name-pattern verifyRequest
Bun에서도 잘 돌아가는지 확인하려면 fedify/ 디렉터리 안쪽에서pnpm test:bun 명령어를 사용하세요:
pnpm test:bun
일부 테스트만 빠르게 실행해 보고 싶을 경우 마찬가지로 --test-name-pattern 옵션을 활용하세요:
pnpm test:bun --test-name-pattern verifyRequest
마지막으로, Cloudflare Workers에서도 잘 돌아가는지 검사해야 합니다. 이 경우에는 pnpm test:cfworkers 명령어를 활용하세요:
pnpm test:cfworkers
일부 테스트만 빠르게 실행해 보고 싶을 경우 인자로 부분 문자열 키워드를 넘기면 됩니다:
pnpm test:cfworkers verifyRequest
사실, 앞서 설명했던 deno task test-all 명령어는 한 번에 Deno, Node.js, Bun, Cloudflare Workers 모두에서 테스트 스위트를 실행하는 명령어입니다.
안내
테스트 실행 시 실패하는 케이스가 있나요? 그것 자체가 기여할 좋은 기회입니다. 실패하는 테스트가 성공하도록 직접 코드를 고쳐서 풀 리퀘스트를 올리셔도 좋고, 이슈 트래커에 이슈를 만들기만 해도 좋은 기여가 됩니다.
@fedify/cli: Fedify CLI 도구
@fedify/cli 패키지는 Fedify를 이용하여 ActivityPub 서버를 구현하는 개발자들을 위한 CLI 편의 도구로서, 주로 ActivityPub 서버 개발을 할 때 디버그나 테스트를 위해 필요한 기능들을 제공합니다. 라이브러리 패키지인 @fedify/fedify와 다르게 @fedify/cli는 패키지는 애플리케이션이기 때문에 코드를 수정한 뒤 바로 사용해 볼 수가 있습니다. 또한, 굳이 여러 런타임을 지원할 필요가 없기 때문에 Deno 환경만 신경쓰면 됩니다.
그런 이유로, @fedify/cli 패키지는 처음 기여하기에 좋습니다. 참고로 @fedif/cli는 CLI 애플리케이션 프레임워크로 Cliffy를 사용하고 있으니, 관련해서 궁금한 게 있다면 Cliffy 문서를 참고해 주세요.
일감 찾기
중요
오픈 소스 프로젝트에서는 할 일을 자발적으로 찾아야 합니다. 직장이 아니므로, 다른 누군가가 할 일을 할당해 주지 않습니다. 사실, 오픈 소스에서 활발하게 활동하는 프로그래머들은 단순히 소프트웨어 개발 실력이 좋은 게 아니라, 적절한 할 일을 잘 찾아내는 능력이 있습니다. 이 때 “적절하다”는 것은 자신의 실력으로 해낼 수 있을 정도의 난이도면서도 프로젝트에 임팩트를 낼 수 있는 것을 뜻합니다.
대부분의 오픈 소스 프로젝트는 할 일을 이슈 트래커에서 관리합니다. Fedify 역시 GitHub에서 제공하는 이슈 트래커로 할 일들을 관리하고 있습니다. 특별한 이유가 없는 한, 이슈는 기본적으로 영어로 작성되거나, 적어도 영어가 병기되어야 합니다. 영어가 익숙치 않은 분들은 Kagi 번역 등을 활용하시면 될 것 같습니다. 언어 때문에 어려우신 분은 멘토에게 도움을 청하세요.
이슈는 크게 세 종류로 나뉩니다:
피처 (feature)
말 그대로 새로운 기능을 뜻합니다.
버그 (bug)
기존에 있던 기능의 오작동을 뜻합니다.
태스크 (task)
신기능이나 버그 이외의 작업들을 가리킵니다. 예를 들면, 문서 수정 등이 여기에 속합니다.
미분류 (no type)
아직 분류되지 않은 이슈들인데, 이슈는 어떻게든 분류되어야 하므로 보통은 없습니다.
위의 분류와는 별개로, Fedify 이슈 트래커에서는 레이블을 구조화하여 활용하고 있습니다. 대부분의 레이블은 범례/레이블 이름 형식을 따르며, 대표적으로는 다음과 같은 것들이 있습니다:
여기서 여러분이 가장 주목하셔야 할 레이블은 바로 good first issue입니다. 해당 레이블이 붙은 이슈는 처음 기여하는 사람에게 적합하기 때문에, 여러분의 첫 기여 때 할 일을 찾을 때 도움이 됩니다. 이슈들을 찬찬히 읽어보시고 해 볼 만한 일감을 고르세요. 이슈를 읽어도 이해가 안 될 경우에는 댓글로 질문을 남기거나 멘토에게 질문하세요.
기여해 볼 이슈를 찾으셨다면, 해당 이슈를 이미 다른 사람이 진행중인지 확인하세요. 아무도 진행하고 있지 않다면 진행하겠다는 댓글을 이슈에 달아주세요.
과제
처음 기여할 이슈를 찾아 이슈에 댓글을 달아주세요. 이슈를 못 찾겠다면 멘토에게 도움을 요청하세요. 멘토가 기여할 만한 일을 함께 찾아줄 수 있습니다.
안내
굳이 이슈 트래커에 이미 있는 이슈 중에서만 고를 필요는 없습니다. Fedify를 써 보면서 개선할 부분을 발견하셨다면, 그걸 이슈로 만들어서 직접 해결하셔도 좋습니다. 사실, 오픈 소스의 많은 이슈들이 이슈를 제기한 사람에 의해 해결됩니다.
추가 정보 및 질문
본 문서에서 다루지 못한 내용도 많이 있을 것입니다. 아래 문서들은 부족한 부분을 좀 더 보충해 줄 수 있습니다:
#Fedify has moved to a monorepo structure with unified versioning across all packages (@fedify/fedify, @fedify/cli, database adapters & framework integrations).
All packages now release together, making dependency management much simpler!
ALT text detailsFedify monorepo structure diagram showing all packages (@fedify/fedify, @fedify/cli, database adapters, framework integrations) unified with shared versioning
It covers everything from setting up the #fediverse accounts and development environment to finding good first issues. While it's primarily for the OSSCA participants, anyone interested in contributing to @fedify is welcome to use it as a reference.
Ready to onboard the next wave of #ActivityPub developers!
이 문서는 기본적으로 오픈 소스 컨트리뷰션 아카데미 참여형 프로그램을 진행하게 된 멘티들을 위한 것입니다만, Fedify 프로젝트에 기여하고 싶은 분들이라면 얼마든지 활용하셔도 좋습니다.
안녕하세요. 오픈 소스 컨트리뷰션 아카데미 참여형 프로그램에서 Fedify 프로젝트를 함께 할 멘토 홍민희입니다.
Fedify 프로젝트에 참여하시게 된 것을 진심으로 환영합니다. 본 문서에서는 여러분이 앞으로 Fedify 프로젝트에 기여하기 위해서 알고 준비해야 하는 것들을 정리했습니다. 조금 긴 내용이 될 수도 있지만, 차근차근 읽어보시고 따라해야 할 과제는 따라해 주시기 바랍니다. 본 문서에 나온 과제들은 본격적인 기여를 위해 반드시 선행되어야 합니다.
소통 채널
중요
OSSCA 자체 Discord 서버에도 초대되셨을 것입니다만, 그곳에서는 행사에 관한 이야기만 주로 하게 될 겁니다. 실제 기여와 개발에 관련된 이야기는 지금부터 설명할 Fedify 프로젝트의 Discord 서버에서 이뤄지게 됩니다.
가장 먼저 해야 할 것은 Fedify 프로젝트의 Discord 서버에 입장하는 것입니다. 만약 아직 Discord 계정이 없다면 하나 만드세요. 꽤 많은 오픈 소스 프로젝트들이 Discord에서 소통을 합니다. Discord 계정을 만들어 두면 앞으로 다양한 오픈 소스 프로젝트에 기여할 때 쓸모가 많을 것입니다.
그러면 한국어를 포함해 자신이 이해할 수 있는 언어들을 선택하시면 됩니다. 그러면 여러 채널들이 보이게 되는데, 그 중에서 여러분이 주로 이용하게 될 채널은 #fedify-dev-ko 채널입니다.
본 문서를 읽고 따라하면서 중간에 어려움이 있거나 막히는 부분이 있으면 해당 채널에서 편하게 질문하시면 됩니다.
프로젝트 관련해서 궁금한 점은 사소한 것이라도 Discord 서버에서 질문 주세요. “시간이 날 때 천천히 해결해야지”보다는 일단 물어보는게 낫습니다. 특히 초반의 많은 문제는, 보통 질문을 많이 하면 빨리 해결됩니다. 시간을 정해두세요. 이를테면 30분으로 정했으면 30분 내로 해결이 안되면 일단 질문을 합시다.
과제
Discord 서버에 입장하신 뒤, #fedify-dev-ko 채널에서 간단히 자기 소개를 해 주세요. 본인의 이름과 GitHub 아이디를 꼭 알려주시기 바랍니다.
권고
원활하고 즉시적인 소통을 위해서는 모바일 앱으로 알림을 받을 수 있어야 합니다. 본인의 스마트폰에 Discord 앱을 설치하고 로그인한 뒤, 알림을 허용해 주세요. 랩톱 및 데스크톱 환경에서도 Discord 앱을 설치하고 항상 실행해 두실 것을 권합니다.
권고
가능하다면 Discord 계정의 아바타를 GitHub 계정의 프로필 사진과 통일해 주세요. 멘티가 워낙 많기 때문에 누가 누군지 기억하기 어렵기 때문입니다. 특히, 아무런 이미지도 설정해 두지 않은 분들은 아무 그림이라도 좋으니 시인성을 위해 설정을 부탁드립니다.
연합우주(fediverse)란?
안내
이미 연합우주나 ActivityPub에 대해 익숙하신 분들은 설명은 건너 뛰시고 이 섹션 마지막의 과제만 하셔도 괜찮습니다.
Fedify 프로젝트가 어떤 프로젝트인지 이해하기 위해서는, 우선 페디버스(fediverse), 즉 한국어로 연합우주에 대해 기본적인 이해를 갖출 필요가 있습니다.
종래의 중앙집권적인 SNS들은 크게 두 가지 특징이 있습니다. 첫째로, SNS에 올리는 사용자들의 모든 데이터를 특정 기업이 사유한다는 것입니다. 둘째로, 서로 다른 SNS끼리는 소통할 수 없다는 것입니다. 특히, 두번째 특징은 이메일을 생각해 보면 아주 자연스러운 것은 아니라는 것을 알 수 있습니다. 네이버 메일을 쓰는 사람이 Gmail을 쓰는 사람과 소통할 수 없을까요? 그렇지 않지요. 하지만 Instagram 사용자는 X (舊 Twitter) 사용자와 소통할 수 없습니다.
이러한 문제를 해결하고자 나온 대안 SNS들이 있습니다. Mastodon이나 Pixelfed 같은 것들이 그렇습니다. 그리고 이러한 SNS들은 누구라도 자신의 서버에 설치가 가능합니다. 실제로 홈 서버에서 돌아가는 Mastodon 서버도 꽤 많습니다. 물론, 직접 서버를 운영하고 싶지 않은 대부분의 사람들에게는 대형 서버라는 선택지도 있습니다. 이를테면, Mastodon 서버 중에서 가장 사용자가 많은 서버인 mastodon.social은 Mastodon 개발 팀이 직접 운영하는 서버입니다.
하지만 이런 의문이 드실 수 있습니다. 자신의 홈 서버에 Mastodon을 설치해봤자 혼자 쓰는 일기장이 아닌가? 사실, Mastodon 서버들은 서로 소통이 가능합니다. 마치 이메일과도 같습니다. 자신의 홈 서버에 이메일 서버를 설치하여 자신만의 이메일 주소를 만들어도, 네이버 메일이나 Gmail과 서로 메일을 주고 받을 수 있는 것처럼요. 실제로, Mastodon의 계정 이름은 이메일 주소와 비슷하게 생겼습니다:
@username@server.com
이렇게 서로 다른 Mastodon 서버끼리 소통할 수 있도록 고안된 표준이 바로 ActivityPub 프로토콜입니다. 참고로, 이 ActivityPub 프로토콜은 Mastodon 프로젝트가 독자적으로 정한 게 아니라, W3C에서 웹 표준으로 정한 것입니다. 따라서 Mastodon 뿐만 아니라, Pixelfed 등 ActivityPub을 구현하는 다른 소프트웨어들도 서로 소통이 됩니다. Mastodon에서 Pixelfed로 댓글 다는 것도 되고, Pixelfed 사용자가 Mastodon 사용자를 팔로하는 것도 됩니다.
이렇게 서로 다른 SNS 소프트웨어, 사로 다른 서버끼리 자유롭게 소통이 가능한 구조를 연합(federation)이라고 부릅니다. 어떻게 보면, 이렇게 연합된 서로 다른 SNS들을 모두 합쳐서 하나의 SNS라고 볼 수도 있습니다. 이를 부르는 말이 바로 연합우주, 페디버스입니다.
연합우주는 현재도 꾸준히 커 가고 있습니다. 최근에는 Meta의 Threads도 ActivityPub을 구현하게 되었고, WordPress도 ActivityPub 플러그인을 공식적으로 개발했습니다. 특히, 기존의 연합우주 소프트웨어들은 각자의 서버에 직접 설치할 수 있는 오픈 소스 소프트웨어였던 것에 반해, Threads는 오픈 소스가 아님에도 ActivityPub을 구현했다는 점에서 상당히 이례적이라고 할 수 있습니다. 이런 방식의 연합도 가능하다는 것이죠.
아직 연합우주를 경험해 본 적 없다면, 계정을 하나 만들어 봅시다. 계정을 만들기 위해서는 어떤 소프트웨어를 쓸 지 먼저 정해야 합니다. Mastodon과 Misskey는 일종의 X처럼 단문을 중심으로 한 SNS입니다. Pixelfed는 Instagram처럼 사진을 중심으로 한 SNS입니다. Meta의 Threads도 있습니다. 현재 읽고 계시는 이 글이 올라온 Hackers' Pub도 사실은 연합우주의 일부로서, 소프트웨어 개발자들을 위한 SNS입니다. 이 중 어떤 것을 선택하시든 서로 소통하는 데에는 문제가 없습니다.
만약 Mastodon이나 Misskey, Pixelfed를 선택하셨다면, 서버를 고르셔야 합니다. (물론, 서버를 직접 구축하시는 것도 괜찮습니다. 아마 많은 걸 배우실 수 있을 겁니다.) 무슨 서버를 골라야 할 지 모르시겠다면, Mastodon의 경우 silicon.moe 서버를, Misskey의 경우 stella.place 서버를, Pixelfed의 경우 chueok.pics 서버를 권합니다.
만약 Threads를 고르셨다면, 서버를 고를 필요가 없습니다. Threads는 설치형 소프트웨어가 아니라 Meta에서 운영하는 상용 서비스이기 때문입니다. 다만, 설정에 가셔서 페디버스 공유 설정을 켜 주셔야 합니다.
만약 Hackers' Pub을 고르셨다면, 역시 서버를 고를 필요가 없습니다. 단 하나의 서버만 있기 때문입니다. 다만, 초대장이 필요하므로 멘토에게 초대장을 요청하시기 바랍니다.
과제
연합우주 계정이 생기셨다면, 이제 친구를 사귀어야 합니다. 다른 멘티들에게 계정 주소를 물어보고 서로 팔로를 해 보세요. 멘토도 팔로해 보세요. (멘토도 맞팔 하겠습니다.) 멘토의 연합우주 계정 주소는 @hongminhee@hackers.pub입니다.
계정 주소로 팔로하는 방법은 소프트웨어마다 조금씩 다르지만, 대부분의 경우 검색창에 주소를 입력하면 해당 계정이 보입니다. 계정이 보인다면 팔로 버튼을 누르면 됩니다.
과제
생성한 계정으로 멘토의 계정인 @hongminhee@hackers.pub을 멘션하여 글을 써 주세요. 글 내용은 뭐든 좋습니다.
JavaScript와 TypeScript
안내
이미 JavaScript와 TypeScript에 익숙하시다면 이 챕터는 넘기셔도 됩니다.
Fedify 프로젝트는 TypeScript로 작성되어 있습니다. TypeScript는 JavaScript에 정적 타입 검사를 추가한 언어로, 런타임에 버그를 발생시키는 잘못된 코드를 코드 작성 시에 미리 알 수 있도록 도와줍니다. TypeScript를 이해하려면 먼저 JavaScript를 이해해야 합니다.
아직 JavaScript에 익숙하지 않으신 분들은 《모던 JavaScript 튜토리얼》의 파트 1을 읽고 따라해 볼 것을 권합니다. 파트 2 이후의 내용은 Fedify 프로젝트에 기여하는 데에 크게 필요하지 않으므로 읽지 않으셔도 좋습니다.
JavaScript에는 어느 정도 익숙하지만 아직 TypeScript에 익숙하지 않으신 분들께는, 《The TypeScript Handbook》을 읽고 따라해 볼 것을 권합니다. 참고로 핸드북 페이지 우측 상단에 한국어 번역으로 가는 링크가 있습니다.
사실 오픈 소스 프로젝트에 기여하기 위해 반드시 그 프로젝트에서 쓰이는 언어를 속속들이 깊게 이해해야 하는 건 아닙니다. 기여할 때 필요한 만큼만 이해해도 좋으니, 어느 정도 언어 문법에 익숙해졌다 싶으면 실제 Fedify 코드를 읽는 것을 좀 더 추천합니다. 코드를 읽다가 이해가 안 되는 부분이 있으면 해당 언어 문법에 대해 따로 조사하는 식으로 익히시는 게 더 효율적입니다. 정 이해가 안 되는 경우에는 부담 없이 Fedify 프로젝트 Discord 서버의 #fedify-dev-ko 채널에서 질문해 주세요.
Fedify란?
여러분은 웹 서버 애플리케이션을 만들 때 HTTP를 직접 구현하시나요? 아마도 대부분은 그렇지 않을 겁니다. 그러기엔 할 게 너무 많기 때문이죠. 대신 우리는 대부분 Express나 Next.js, Django 같은 웹 프레임워크를 이용해서 개발하게 됩니다.
마찬가지로, 연합우주 SNS 소프트웨어를 구현하려고 할 경우, ActivityPub을 바닥부터 구현하기에는 너무 할 게 많습니다. 따라서 개발을 쉽게 해 줄 프레임워크가 필요한데, 그게 바로 Fedify입니다.
어떤 오픈 소스 프로젝트든 간에, 해당 프로젝트에 기여하기 위해서는 먼저 그 소프트웨어를 써보고 기본적인 기능들을 숙지해야 합니다. 써보지도 않은 소프트웨어에 기여를 하는 것은 무리입니다. 여러분도 Fedify에 기여하기에 앞서 Fedify를 써 볼 필요가 있습니다.
Fedify는 연합우주 소프트웨어를 만드는 도구이므로, Fedify를 사용한다고 하면 연합우주 소프트웨어를 만들어 본다는 뜻이 됩니다. Fedify를 사용하여 작은 ActivityPub 서버 소프트웨어를 만들어 보세요. Fedify를 써 보면서 이해가 안 가거나 중간에 막히는 게 있다면 Discord 서버의 #fedify-help-ko 채널에서 질문하세요.
과제
Fedify를 배우고 써보는 가장 쉬운 방법은 튜토리얼을 읽고 따라하는 것입니다. Fedify 공식 튜토리얼의 한국어판인 〈나만의 연합우주 마이크로블로그 만들기〉를 읽고 그대로 따라서 진행하세요. 빠르면 하루, 느긋하게 하면 사흘 정도 걸립니다. 중간에 막히는 부분이 있으면 멘토에게 부담 없이 질문하세요.
저장소 포크 및 클론
주의
Windows 환경에서 작업하실 때는 (WSL을 사용하지 않는다면) Git의 core.autocrlf 설정을 꺼 주시기 바랍니다:
git config --global core.autocrlf false
안내
Fedify 프로젝트를 Windows 환경에서 개발할 수는 있지만, Linux나 macOS에 비해 편의성이 떨어지는 것도 사실입니다. 가능하면 WSL을 세팅하시고 WSL 안에서 작업하시는 걸 추천드립니다.
Fedify의 GitHub에 저장소가 올라가 있습니다. 해당 저장소를 각자 포크(fork)하신 뒤, 포크한 저장소를 로컬에 클론하세요. 클론하신 뒤, 클론한 로컬 저장소 안에 들어가 업스트림 저장소를 리모트로 추가하시는 것을 권합니다:
Fedify의 개발 환경 설정은 일반적인 JavaScript 프로젝트들에 비해 조금 복잡한 편입니다. Node.js 이외에도 Deno와 Bun 등 여러 런타임을 지원해야 하기 때문인데요. Fedify의 개발을 위해서는 다음 소프트웨어가 시스템에 모두 설치되어 있어야 합니다:
대부분의 Linux의 경우 (또는 Windows의 WSL 안에서 작업하는 경우) 별 다른 설정을 하지 않았다면 bash를 쓰고 계실 것입니다. macOS를 쓰시고 별 다른 설정을 하지 않으셨다면 zsh을 쓰고 계실 것입니다. (WSL이 아닌) Windows의 경우에는 명령 프롬프트가 아닌 PowerShell 안에서 작업하셔야 합니다.
mise를 설치하셨다면, 로컬 저장소 안에 들어가 다음 명령어로 필요한 모든 소프트웨어를 한 번에 설치하실 수 있습니다:
mise install --yes
위 명령어를 실행하면 아래와 같이 Fedify 저장소 안에 들어있는 mise 설정 파일을 신뢰하겠냐는 프롬프트가 뜹니다. Yes를 선택해 주세요:
mise config files in ~/fedify are not trusted. Trust them? Yes No All ←/→ toggle • y/n/a/enter submit
개발 환경이 잘 설정되었는지 확인하기 위해 Fedify의 전체 테스트 스위트를 실행해 봅시다. 첫 실행 시 통상 5분 정도 소요됩니다:
deno task test-all
Git 훅도 설치합니다:
deno task hooks:install
마지막으로 실제 편집 환경을 구성해야 합니다. 본 문서에서는 Visual Studio Code를 사용하는 것을 가정하겠습니다만, 같은 Visual Studio Code 계열인 Cursor나 Windsurf에서도 과정은 대동소이합니다.
경고
Visual Studio와 Visual Studio Code는 서로 전혀 다른 별개의 제품이니 주의하세요.
안내
여러분이 Emacs나 Vim의 독실한 신자라면 Visual Studio Code를 사용하고 싶지 않을 수 있습니다. 그런 경우, Deno의 공식 환경 설정 문서를 참고하여 Deno 랭귀지 서버를 설정해 주시기 바랍니다.
우선 로컬 저장소 안에서 code 명령어를 통해 Visual Studio Code를 띄웁니다:
code . # Visual Studio Code를 사용하는 경우cursor . # Cursor를 사용하는 경우windsurf . # Windsurf를 사용하는 경우
Visual Studio Code 창이 뜨면, 화면 가운데에 다음과 같은 프롬프트 창이 뜹니다:
프롬프트에서 예, 작성자를 신뢰합니다 버튼을 선택합니다. 그러면 오른쪽 아래에 다음과 같은 작은 프롬프트 창이 뜹니다:
프롬프트에서 설치 버튼을 선택합니다. 그러면 화면 가운데에 다음과 같은 프롬프트 창이 뜹니다:
프롬프트에서 게시자 신뢰 및 설치를 선택합니다. 그러면 Visual Studio Code에 Fedify 개발에 필요한 확장들이 설치되게 됩니다.
이로써 Fedify 기여에 필요한 기본적인 개발 환경 설정이 끝났습니다.
JavaScript 런타임
Fedify는 Deno, Node.js, Bun 등 다양한 JavaScript 런타임을 지원해야 합니다. 과연 JavaScript 런타임이 뭘까요?
JavaScript는 비교적 작은 언어입니다. 여러분이 process.exit() 같은 메서드를 활용하신 적 있다면, 이는 JavaScript 자체의 기능이 아니라 Node.js라는 특정한 JavaScript 런타임이 제공하는 기능입니다. 마찬가지로, 웹 브라우저에서 제공하는 DOM API 역시 JavaScript 자체의 기능이 아니라 웹 브라우저라는 (일종의) JavaScript 런타임이 제공하는 기능이라고 볼 수 있습니다.
모듈 시스템을 제공합니다. 예를 들어, Node.js는 node_modules/ 디렉터리 기반의 모듈 시스템을 제공하는 반면, Deno에서는 임포트 맵(import map) 기반의 모듈 시스템을 제공합니다. Node.js에서는 npm이나 pnpm, Yarn 등의 패키지 관리자를 사용해야 하지만, Deno나 Bun은 자체적인 패키지 관리자를 제공합니다. 웹 브라우저나 Cloudflare Workers는 패키지 관리자를 제공하지 않기 때문에 번들링이라는 과정을 거쳐야 합니다.
앞서 설명한 모든 것을 속속들이 이해해야 할 필요는 없습니다. 중요한 것은, 같은 JavaScript라고 하더라도 어느 런타임에서 실행하냐에 따라 상당히 다른 방식으로 언어를 사용해야 한다는 점입니다.
그러면 Fedify 프로젝트는 다양한 JavaScript 런타임을 어떻게 동시에 다 지원할 수 있을까요? 크게 두 가지 방법이 있습니다:
지원해야 하는 JavaScript 런타임 모두에서 공통적으로 지원하는 API만을 사용합니다.
런타임에 따라 다른 코드를 실행하도록 코드를 여러 벌 작성합니다.
Fedify 프로젝트는 두 가지 방법 모두 사용하고 있으며, 지원하는 모든 JavaScript 런타임에서 테스트 스위트를 실행해서 Fedify의 모든 기능이 각 JavaScript 런타임에서 잘 동작하는지를 검사합니다.
Fedify 저장소의 구조
2025년 7월 현재, Fedify 프로젝트의 저장소는 다음과 같은 구조로 되어 있습니다:
fedify/ — Fedify의 핵심인 @fedify/fedify 패키지입니다. 이 패키지는 Deno, Node.js, Bun, Cloudflare Workers 환경에서 동작합니다.
cli/ — Fedify 사용자들을 위한 CLI 개발 도구인 @fedify/cli 패키지입니다. 이 패키지는 Deno로만 작성됩니다.
examples/ — 이름 그대로 Fedify를 사용하는 예제 프로젝트들이 들어 있습니다.
scripts/ — 프로젝트 관리를 위한 스크립트들이 들어 있습니다. 대부분의 경우 건드릴 일이 없을 겁니다.
여러분은 주로 fedify/ 디렉터리 및 cli/ 디렉터리에서 작업을 하게 될 것입니다.
린트와 테스트
여느 오픈 소스 프로젝트들이 그렇듯, Fedify 프로젝트도 나름의 코딩 컨벤션과 규칙들이 있습니다. 다행히 이들 대부분은 커밋하기 전에 기계적으로 검사가 가능합니다. 다음 명령어는 현재 프로젝트의 코드가 코딩 컨벤션을 잘 지키고 타입 오류가 없는지 검사합니다:
deno task check
다음 명령어는 코드를 코딩 컨벤션에 맞게 알아서 서식화합니다:
deno fmt
앞서 언급한 것처럼, 다음 명령어는 Fedify 프로젝트의 전체 테스트 스위트를 실행하고 필요한 검사를 수행합니다. 풀 리퀘스트를 올리기 전에 한 번 실행해 보십시오:
deno task test-all
@fedify/fedify 패키지를 수정했을 경우, 수정과 관련된 일부 테스트 코드만 빠르게 실행해 보고 싶을 수 있습니다. 그럴 때는 다음과 같이 -f @fedify/fedify 옵션과 --filter 옵션을 함께 활용해 보세요 (태스크 이름이 test-all이 아니라 test임에 주의하세요):
deno task -f @fedify/fedify test --filter verifyRequest
혹은 -f @fedify/fedify 옵션을 쓰는 대신 직접 fedify/ 디렉터리 안에서 deno task test 명령어를 사용하셔도 됩니다:
cd fedify/deno task test --filter verifyRequest
참고로 --filter 옵션은 테스트 케이스 이름을 부분 문자열로 검색합니다. 이를테면, 다음과 같은 테스트가 있을 경우:
test("anArbitraryTest", () => { // … 생략 …});
다음과 같은 방식으로 모두 실행이 가능합니다:
deno task -f @fedify/fedify test --filter anArbitraryTestdeno task -f @fedify/fedify test --filter Arbitrarydeno task -f @fedify/fedify test --filter Test
앞서 설명한 deno task test 명령어는 Deno 런타임에서 테스트 스위트를 실행합니다. Node.js에서도 잘 돌아가나 확인하기 위해서는 Node.js 런타임에서도 테스트 스위트를 실행해 봐야 합니다. fedify/ 디렉터리 안쪽에서pnpm test 명령어를 통해 Node.js에서 테스트 스위트를 돌려 볼 수 있습니다:
cd fedify/pnpm test
일부 테스트만 빠르게 실행해 보고 싶을 경우 --test-name-pattern 옵션을 활용하세요:
pnpm test --test-name-pattern verifyRequest
Bun에서도 잘 돌아가는지 확인하려면 fedify/ 디렉터리 안쪽에서pnpm test:bun 명령어를 사용하세요:
pnpm test:bun
일부 테스트만 빠르게 실행해 보고 싶을 경우 마찬가지로 --test-name-pattern 옵션을 활용하세요:
pnpm test:bun --test-name-pattern verifyRequest
마지막으로, Cloudflare Workers에서도 잘 돌아가는지 검사해야 합니다. 이 경우에는 pnpm test:cfworkers 명령어를 활용하세요:
pnpm test:cfworkers
일부 테스트만 빠르게 실행해 보고 싶을 경우 인자로 부분 문자열 키워드를 넘기면 됩니다:
pnpm test:cfworkers verifyRequest
사실, 앞서 설명했던 deno task test-all 명령어는 한 번에 Deno, Node.js, Bun, Cloudflare Workers 모두에서 테스트 스위트를 실행하는 명령어입니다.
안내
테스트 실행 시 실패하는 케이스가 있나요? 그것 자체가 기여할 좋은 기회입니다. 실패하는 테스트가 성공하도록 직접 코드를 고쳐서 풀 리퀘스트를 올리셔도 좋고, 이슈 트래커에 이슈를 만들기만 해도 좋은 기여가 됩니다.
@fedify/cli: Fedify CLI 도구
@fedify/cli 패키지는 Fedify를 이용하여 ActivityPub 서버를 구현하는 개발자들을 위한 CLI 편의 도구로서, 주로 ActivityPub 서버 개발을 할 때 디버그나 테스트를 위해 필요한 기능들을 제공합니다. 라이브러리 패키지인 @fedify/fedify와 다르게 @fedify/cli는 패키지는 애플리케이션이기 때문에 코드를 수정한 뒤 바로 사용해 볼 수가 있습니다. 또한, 굳이 여러 런타임을 지원할 필요가 없기 때문에 Deno 환경만 신경쓰면 됩니다.
그런 이유로, @fedify/cli 패키지는 처음 기여하기에 좋습니다. 참고로 @fedif/cli는 CLI 애플리케이션 프레임워크로 Cliffy를 사용하고 있으니, 관련해서 궁금한 게 있다면 Cliffy 문서를 참고해 주세요.
일감 찾기
중요
오픈 소스 프로젝트에서는 할 일을 자발적으로 찾아야 합니다. 직장이 아니므로, 다른 누군가가 할 일을 할당해 주지 않습니다. 사실, 오픈 소스에서 활발하게 활동하는 프로그래머들은 단순히 소프트웨어 개발 실력이 좋은 게 아니라, 적절한 할 일을 잘 찾아내는 능력이 있습니다. 이 때 “적절하다”는 것은 자신의 실력으로 해낼 수 있을 정도의 난이도면서도 프로젝트에 임팩트를 낼 수 있는 것을 뜻합니다.
대부분의 오픈 소스 프로젝트는 할 일을 이슈 트래커에서 관리합니다. Fedify 역시 GitHub에서 제공하는 이슈 트래커로 할 일들을 관리하고 있습니다. 특별한 이유가 없는 한, 이슈는 기본적으로 영어로 작성되거나, 적어도 영어가 병기되어야 합니다. 영어가 익숙치 않은 분들은 Kagi 번역 등을 활용하시면 될 것 같습니다. 언어 때문에 어려우신 분은 멘토에게 도움을 청하세요.
이슈는 크게 세 종류로 나뉩니다:
피처 (feature)
말 그대로 새로운 기능을 뜻합니다.
버그 (bug)
기존에 있던 기능의 오작동을 뜻합니다.
태스크 (task)
신기능이나 버그 이외의 작업들을 가리킵니다. 예를 들면, 문서 수정 등이 여기에 속합니다.
미분류 (no type)
아직 분류되지 않은 이슈들인데, 이슈는 어떻게든 분류되어야 하므로 보통은 없습니다.
위의 분류와는 별개로, Fedify 이슈 트래커에서는 레이블을 구조화하여 활용하고 있습니다. 대부분의 레이블은 범례/레이블 이름 형식을 따르며, 대표적으로는 다음과 같은 것들이 있습니다:
여기서 여러분이 가장 주목하셔야 할 레이블은 바로 good first issue입니다. 해당 레이블이 붙은 이슈는 처음 기여하는 사람에게 적합하기 때문에, 여러분의 첫 기여 때 할 일을 찾을 때 도움이 됩니다. 이슈들을 찬찬히 읽어보시고 해 볼 만한 일감을 고르세요. 이슈를 읽어도 이해가 안 될 경우에는 댓글로 질문을 남기거나 멘토에게 질문하세요.
기여해 볼 이슈를 찾으셨다면, 해당 이슈를 이미 다른 사람이 진행중인지 확인하세요. 아무도 진행하고 있지 않다면 진행하겠다는 댓글을 이슈에 달아주세요.
과제
처음 기여할 이슈를 찾아 이슈에 댓글을 달아주세요. 이슈를 못 찾겠다면 멘토에게 도움을 요청하세요. 멘토가 기여할 만한 일을 함께 찾아줄 수 있습니다.
안내
굳이 이슈 트래커에 이미 있는 이슈 중에서만 고를 필요는 없습니다. Fedify를 써 보면서 개선할 부분을 발견하셨다면, 그걸 이슈로 만들어서 직접 해결하셔도 좋습니다. 사실, 오픈 소스의 많은 이슈들이 이슈를 제기한 사람에 의해 해결됩니다.
추가 정보 및 질문
본 문서에서 다루지 못한 내용도 많이 있을 것입니다. 아래 문서들은 부족한 부분을 좀 더 보충해 줄 수 있습니다:
Ghost’s @johnonolan and WordPress’s @pfefferle want to help blogs and long content thrive on the open social web. Meet “the longformers,” who chatted to @mike for the latest edition of Dot Social.
#Fedify has moved to a monorepo structure with unified versioning across all packages (@fedify/fedify, @fedify/cli, database adapters & framework integrations).
All packages now release together, making dependency management much simpler!
ALT text detailsFedify monorepo structure diagram showing all packages (@fedify/fedify, @fedify/cli, database adapters, framework integrations) unified with shared versioning
#Fedify has moved to a monorepo structure with unified versioning across all packages (@fedify/fedify, @fedify/cli, database adapters & framework integrations).
All packages now release together, making dependency management much simpler!
ALT text detailsFedify monorepo structure diagram showing all packages (@fedify/fedify, @fedify/cli, database adapters, framework integrations) unified with shared versioning
I'd like to mark the start of 2025 with the first message from my self-hosted instance. You may already know me as @_elena@mastodon.social. Well, now I also run my own #ActivityPub microblogging server, thanks to the magic of #YunoHost and #GoToSocial (and #Phanpy, which I'm using to compose this).
I registered this domain – aseachange.com – a looooong time ago but never did anything with it. It was the very first domain name I ever bought, even before securing elenarossini.com (!!!). It was so long ago, but I remember I was inspired by Beck's album Sea Change. seachange[dot]com was taken, so I grabbed Aseachange.
I absolutely love its meaning of profound transformation and I think it's PERFECT for my self-hosted #Fediverse instance and what it represents: independence, empowerment and digital sovereignty.
Ever since setting it up, I've been feeling joyful and hopeful. Everytime I look at myself in the mirror, I think: I'm in control of my own social media platform. And it feels SOOO GOOD.
What do I have in store for 2025? I plan to use this account to post messages about #selfhosting, learning #Linux, privacy and digital sovereignty.
I will also keep posting from my Mastodon account because you don't give a Lamborghini to someone who just passed their driver's license. I barely know what I'm doing here, so I feel a lot safer (for now) keeping my mastodon.social account as well... In case anything goes wrong here. Better safe than sorry!
So, this is my #Introduction and if you've read as far as here I just want to thank the Fediverse for being so amazing and allowing me to connect with people on my own terms. And thank you Fedi people for being so generous and supportive with your superb advice and kind words.
Privacy Expectations in Federated Protocols by @fionafokus "Exemplified by the recent Pixelfed vulnerability (https://fokus.cool/2025/03/25/pixelfed-vulnerability.html) I'll summarize how incomplete or wrong #ActivityPub implementations can violate our expectations on how privacy is treated. Afterwards there is room for an open discussion on how to handle these problems on a protocol and community level."
#Fedify has moved to a monorepo structure with unified versioning across all packages (@fedify/fedify, @fedify/cli, database adapters & framework integrations).
All packages now release together, making dependency management much simpler!
ALT text detailsFedify monorepo structure diagram showing all packages (@fedify/fedify, @fedify/cli, database adapters, framework integrations) unified with shared versioning
#Fedify has moved to a monorepo structure with unified versioning across all packages (@fedify/fedify, @fedify/cli, database adapters & framework integrations).
All packages now release together, making dependency management much simpler!
ALT text detailsFedify monorepo structure diagram showing all packages (@fedify/fedify, @fedify/cli, database adapters, framework integrations) unified with shared versioning
#Fedify has moved to a monorepo structure with unified versioning across all packages (@fedify/fedify, @fedify/cli, database adapters & framework integrations).
All packages now release together, making dependency management much simpler!
ALT text detailsFedify monorepo structure diagram showing all packages (@fedify/fedify, @fedify/cli, database adapters, framework integrations) unified with shared versioning
#Fedify has moved to a monorepo structure with unified versioning across all packages (@fedify/fedify, @fedify/cli, database adapters & framework integrations).
All packages now release together, making dependency management much simpler!
ALT text detailsFedify monorepo structure diagram showing all packages (@fedify/fedify, @fedify/cli, database adapters, framework integrations) unified with shared versioning
#Fedify has moved to a monorepo structure with unified versioning across all packages (@fedify/fedify, @fedify/cli, database adapters & framework integrations).
All packages now release together, making dependency management much simpler!
ALT text detailsFedify monorepo structure diagram showing all packages (@fedify/fedify, @fedify/cli, database adapters, framework integrations) unified with shared versioning
Ω🪬Ω Latest version of #FediAlgo, the customizable timeline algorithm / filtering system for your Mastodon feed, allows for the use of multiple accounts on multiple Mastodon servers. Also fixes some #GoToSocial interoperability issues.
Privacy Expectations in Federated Protocols by @fionafokus "Exemplified by the recent Pixelfed vulnerability (https://fokus.cool/2025/03/25/pixelfed-vulnerability.html) I'll summarize how incomplete or wrong #ActivityPub implementations can violate our expectations on how privacy is treated. Afterwards there is room for an open discussion on how to handle these problems on a protocol and community level."
Ω🪬Ω Latest version of #FediAlgo, the customizable timeline algorithm / filtering system for your Mastodon feed, allows for the use of multiple accounts on multiple Mastodon servers. Also fixes some #GoToSocial interoperability issues.
Ω🪬Ω Latest version of #FediAlgo, the customizable timeline algorithm / filtering system for your Mastodon feed, allows for the use of multiple accounts on multiple Mastodon servers. Also fixes some #GoToSocial interoperability issues.
"The ActivityPub protocol is making its way into the social media sphere. In this talk, Andreas will discuss how the protocol could also be used by TYPO3 and what advantages it offers over other conventional tools. He will also provide a simple insight into how the protocol works." https://www.meetup.com/munich-typo3-user-group/events/308809916/
"The ActivityPub protocol is making its way into the social media sphere. In this talk, Andreas will discuss how the protocol could also be used by TYPO3 and what advantages it offers over other conventional tools. He will also provide a simple insight into how the protocol works." https://www.meetup.com/munich-typo3-user-group/events/308809916/
Meine Deutsch-palestinischen Freunde (ich wusste nicht dass ich so viele habe) wechseln gerade alle zu https://upscrolled.com/, mit dem Versprechen freisprechen zu können. Ich mache mir Sorgen, dass sie nur in die nächste Falle laufen. Vielleicht kann man sie überreden, dass sie wenigstens Activity Pub einbinden. ------------------------- My German-Palestinian friends (I didn't know I had so many) are all switching to https://upscrolled.com/, with the promise of being able to make free calls. I'm worried they're just walking into the next trap. Maybe we can persuade them to at least integrate Activity Pub. -------------------------- أصدقائي الألمان الفلسطينيون (لم أكن أعلم أن لدي الكثير منهم) ينتقلون جميعًا إلى https://upscrolled.com/، مع وعد بإمكانية التحدث مجانًا. أنا قلق من أنهم يقعون في الفخ التالي. ربما يمكن إقناعهم على الأقل بدمج Activity Pub #upscrolled#activitypub#freespeech#palestine#freenetwork#federation
I'm kind of ridiculously excited that @evan is going to be a keynote at WordCamp Canada in Ottawa this fall.
I'm not a developer of WordPress, but I do have a hand in managing a couple of sites. I'm sure I'll learn some useful things at WordCamp, and was planning to attend.
The chance to hear from the "Father of the Fediverse" directly seals my commitment to register!
Fediverse Report #123 - this week's #fediverse news:
- Tumblr will not migrate to WordPress, and resulting from that, will not be joining the fediverse after all - @Mastodon makes the release candidate for update 4.4 available, which among other features will display quote posts from other platforms - new funding round from @nlnet with grants for better event federation, #activitypub -based polls on WordPress, and for NodeBB and Funkwhale
Fediverse Report #123 - this week's #fediverse news:
- Tumblr will not migrate to WordPress, and resulting from that, will not be joining the fediverse after all - @Mastodon makes the release candidate for update 4.4 available, which among other features will display quote posts from other platforms - new funding round from @nlnet with grants for better event federation, #activitypub -based polls on WordPress, and for NodeBB and Funkwhale
Hi peertube team and #ActivityPub community! I’d love to suggest some features that would be super useful for content creators:
1️⃣ Dubbing/audio tracks: Currently, adding a new dub requires re-uploading the entire video. It’d be great to have a system for alternate audio tracks on the same video.
#Gitlab just closed the issue about supporting #ActivityPub. Kai Armstrong says "our current focus isn't in this area".
This is very sad, I really think this could have been a pretty good match *espacially* for Gitlab. It could have been a puzzle piece in how to do federated open source coordination. You know, the problem with "not wanting to be on github, but kinda finding it convenient everyone has an account already".
Fediverse Report #123 - this week's #fediverse news:
- Tumblr will not migrate to WordPress, and resulting from that, will not be joining the fediverse after all - @Mastodon makes the release candidate for update 4.4 available, which among other features will display quote posts from other platforms - new funding round from @nlnet with grants for better event federation, #activitypub -based polls on WordPress, and for NodeBB and Funkwhale
Q: "I was really high on interoperable social networking, and interoperable sites using #ActivityPub or #ATproto. It doesn’t matter to me, actually. At the end of the day, I just want to see more interoperability of these networks. Do you still think that’s going to happen?"
A: "Yeah, if I had a bet on one, actually, you know what I’d bet on is the #Matrix protocol, the dark horse in the corner." 👀
Automattic puts WordPress migration on hold to focus on user requests instead. CEO Mullenweg says they'd implement ActivityPub directly if there's enough demand though.
Hopefully with @forgefed adoption on the roadmap too, where this open standard supported by @NGIZero has been significantly progressed, but needs implementers in active feedback loops to refine and mature the specs.
#Gitlab just closed the issue about supporting #ActivityPub. Kai Armstrong says "our current focus isn't in this area".
This is very sad, I really think this could have been a pretty good match *espacially* for Gitlab. It could have been a puzzle piece in how to do federated open source coordination. You know, the problem with "not wanting to be on github, but kinda finding it convenient everyone has an account already".
#Gitlab just closed the issue about supporting #ActivityPub. Kai Armstrong says "our current focus isn't in this area".
This is very sad, I really think this could have been a pretty good match *espacially* for Gitlab. It could have been a puzzle piece in how to do federated open source coordination. You know, the problem with "not wanting to be on github, but kinda finding it convenient everyone has an account already".
Automattic puts WordPress migration on hold to focus on user requests instead. CEO Mullenweg says they'd implement ActivityPub directly if there's enough demand though.
Automattic's plan to move Tumblr's backend to WordPress is "on hold," which means Tumblr posts also won't be available in the fediverse in the near future, CEO Matt Mullenweg said in a Decoder episode. Here's more from @theverge.
#Gitlab just closed the issue about supporting #ActivityPub. Kai Armstrong says "our current focus isn't in this area".
This is very sad, I really think this could have been a pretty good match *espacially* for Gitlab. It could have been a puzzle piece in how to do federated open source coordination. You know, the problem with "not wanting to be on github, but kinda finding it convenient everyone has an account already".
Q: "I was really high on interoperable social networking, and interoperable sites using #ActivityPub or #ATproto. It doesn’t matter to me, actually. At the end of the day, I just want to see more interoperability of these networks. Do you still think that’s going to happen?"
A: "Yeah, if I had a bet on one, actually, you know what I’d bet on is the #Matrix protocol, the dark horse in the corner." 👀
Fediverse Report #123 - this week's #fediverse news:
- Tumblr will not migrate to WordPress, and resulting from that, will not be joining the fediverse after all - @Mastodon makes the release candidate for update 4.4 available, which among other features will display quote posts from other platforms - new funding round from @nlnet with grants for better event federation, #activitypub -based polls on WordPress, and for NodeBB and Funkwhale
Hi peertube team and #ActivityPub community! I’d love to suggest some features that would be super useful for content creators:
1️⃣ Dubbing/audio tracks: Currently, adding a new dub requires re-uploading the entire video. It’d be great to have a system for alternate audio tracks on the same video.
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
@lauren > There is a parallel here to what happened when Google disastrously tried to integrate YT comments with G+ threads
Difference here being that what's bridged is the fediverse (#ActivityPub) and the ATmosphere (#ATproto), which are protocol-defined networks, not monolithic platforms. There is already a need to address different kinds of UX within each network. So bridging them doesn't introduce new UX problems to either.
Automattic puts WordPress migration on hold to focus on user requests instead. CEO Mullenweg says they'd implement ActivityPub directly if there's enough demand though.
So uh, is anyone looking to hire a developer with an uncomfortable amount of knowledge about #atproto and #activitypub, experience building from scratch and running a social network (@ludumdare.com), hacking on GPU drivers/network protocols/the Linux kernel, plus a couple decades as a pro gamedev? 🤷
So uh, is anyone looking to hire a developer with an uncomfortable amount of knowledge about #atproto and #activitypub, experience building from scratch and running a social network (@ludumdare.com), hacking on GPU drivers/network protocols/the Linux kernel, plus a couple decades as a pro gamedev? 🤷
Here's an idea. What if we extend #ActivityPub C2S (C2S++?) with a minimal set of features (FEPs) to provide a reasonable (or even excellent) UX? Along with servers that already support C2S, we could write an external protocol adapter from C2S to the Mastodon client API to increase the number of users that could potential use a C2S client. The C2S API would be general, but the UIs could be domain-specific (microblogging, media sharing, long-form, etc.). Who's with me? https://www.youtube.com/watch?v=6eX3fiQLo84
So uh, is anyone looking to hire a developer with an uncomfortable amount of knowledge about #atproto and #activitypub, experience building from scratch and running a social network (@ludumdare.com), hacking on GPU drivers/network protocols/the Linux kernel, plus a couple decades as a pro gamedev? 🤷
Automattic's plan to move Tumblr's backend to WordPress is "on hold," which means Tumblr posts also won't be available in the fediverse in the near future, CEO Matt Mullenweg said in a Decoder episode. Here's more from @theverge.
Just finished listening to the newest episode of Decoder podcast (@2123) containing a pretty hard hitting 1 hour interview of Matt Mullenweg (@photomatt) by Nilay Patel (@reckless1280) where they talked about #Beeper, @tumblr, #ActivityPub vs #ATProto and or course the latest in WordPress (drama), regardless of what you think of Matt it was an interesting listen.
Here's an idea. What if we extend #ActivityPub C2S (C2S++?) with a minimal set of features (FEPs) to provide a reasonable (or even excellent) UX? Along with servers that already support C2S, we could write an external protocol adapter from C2S to the Mastodon client API to increase the number of users that could potential use a C2S client. The C2S API would be general, but the UIs could be domain-specific (microblogging, media sharing, long-form, etc.). Who's with me? https://www.youtube.com/watch?v=6eX3fiQLo84
@mamund thank you. I will also give the linked article on agentic systems a read.
Note that #ActivityPub here on the #fediverse has this need to discover and introspect the capabilities of actor endpoints on the network.
This entirely missing. With #ActivityStreams#LinkedData endlessly versatile, a player on the fediverse can freely invent their own flavours on-the-fly, introducing protocol decay and makes #interoperability harder.
Whack-a-mole driven development to moving targets ensues.
Here's an idea. What if we extend #ActivityPub C2S (C2S++?) with a minimal set of features (FEPs) to provide a reasonable (or even excellent) UX? Along with servers that already support C2S, we could write an external protocol adapter from C2S to the Mastodon client API to increase the number of users that could potential use a C2S client. The C2S API would be general, but the UIs could be domain-specific (microblogging, media sharing, long-form, etc.). Who's with me? https://www.youtube.com/watch?v=6eX3fiQLo84
ALT text detailsComic:
Panel 1: Mutter sitzt auf dem Sofa, Kind spielt mit Bauklötzen auf dem Boden.
Kind: Mami, wie föderieren Server im Fediverse?
Mutter: Hmm, also...
Panel 2:
Mutter hat in jeder Hand einen Bauklotz.
Mutter: Wenn ein Server und ein anderer Server sich ganz doll lieb haben, dann...
Kind: Dann benutzen sie ActivityPub?
Panel 3:
Mutter: Genau, dann benutzen sie ActivityPub.
> Post facto #interoperability [is] the absolute market dominance of a particular product in contravention of any applicable standards [..]. The vendor behind that product can then choose to ignore any forthcoming standards and not co-operate in any standardization process at all, using its near-monopoly to insist that its product sets the de facto standard by its very market dominance.
> Post facto #interoperability [is] the absolute market dominance of a particular product in contravention of any applicable standards [..]. The vendor behind that product can then choose to ignore any forthcoming standards and not co-operate in any standardization process at all, using its near-monopoly to insist that its product sets the de facto standard by its very market dominance.
I'm beginning to understand why there are so few blogging platforms that work with #activitypub. I thought I'd make my own as a weekend project and while it shows up fine in https://browser.pub/, getting #mastodon to correctly display posts and followers is driving me absolutely crazy.
Why does Mastodon need its own weird special stuff? Why can't it just load the followers and outbox collections like the standard expects? WHY?
Love the domains attribution feature of #wordpress#ActivityPub plugin- by associating cogdogblog.com domain in settings, if anyone includes a link to my blog in a post (the one here is a redirect to one, so that works too), it adds a “by” credit below the post preview, linking to the fediverse account for my blog.
ALT text detailsA mastodon post that includes a url that links to Cogdogblog.com with arrow to the credit at the bottom as By CogDogBlog an account link
ALT text detailsPlugin settings showing field for Attribution Domains and entered in field is Cogdogblog.com
Love the domains attribution feature of #wordpress#ActivityPub plugin- by associating cogdogblog.com domain in settings, if anyone includes a link to my blog in a post (the one here is a redirect to one, so that works too), it adds a “by” credit below the post preview, linking to the fediverse account for my blog.
ALT text detailsA mastodon post that includes a url that links to Cogdogblog.com with arrow to the credit at the bottom as By CogDogBlog an account link
ALT text detailsPlugin settings showing field for Attribution Domains and entered in field is Cogdogblog.com
I'm beginning to understand why there are so few blogging platforms that work with #activitypub. I thought I'd make my own as a weekend project and while it shows up fine in https://browser.pub/, getting #mastodon to correctly display posts and followers is driving me absolutely crazy.
Why does Mastodon need its own weird special stuff? Why can't it just load the followers and outbox collections like the standard expects? WHY?
I'm often grumpy about how "loose" the #ActivityPub protocol is. So it's important that I also point to positive examples of how to do it well.
https://w3id.org/fep/b2b8: "Long-form Text" is a great set of concrete terms and concepts that moves the #Fediverse forward in some really good ways. As we continue growing beyond "microblogging" we need this, and more stuff like it.
Thank you to @evanprodromou for putting your time into this document. It's a solid investment for everyone.
I'm often grumpy about how "loose" the #ActivityPub protocol is. So it's important that I also point to positive examples of how to do it well.
https://w3id.org/fep/b2b8: "Long-form Text" is a great set of concrete terms and concepts that moves the #Fediverse forward in some really good ways. As we continue growing beyond "microblogging" we need this, and more stuff like it.
Thank you to @evanprodromou for putting your time into this document. It's a solid investment for everyone.
I'm often grumpy about how "loose" the #ActivityPub protocol is. So it's important that I also point to positive examples of how to do it well.
https://w3id.org/fep/b2b8: "Long-form Text" is a great set of concrete terms and concepts that moves the #Fediverse forward in some really good ways. As we continue growing beyond "microblogging" we need this, and more stuff like it.
Thank you to @evanprodromou for putting your time into this document. It's a solid investment for everyone.
ALT text detailsComic:
Panel 1: Mutter sitzt auf dem Sofa, Kind spielt mit Bauklötzen auf dem Boden.
Kind: Mami, wie föderieren Server im Fediverse?
Mutter: Hmm, also...
Panel 2:
Mutter hat in jeder Hand einen Bauklotz.
Mutter: Wenn ein Server und ein anderer Server sich ganz doll lieb haben, dann...
Kind: Dann benutzen sie ActivityPub?
Panel 3:
Mutter: Genau, dann benutzen sie ActivityPub.
Noch eine Frage zum #Fediverse: Da die Gemeinsamkeit das #activitypub Protokoll ist, sollte eine beliebige App doch eigentlich mit allen Servern klar kommen. Ist das so, oder gibt es tatsächlich Unterschiede?
Haven't turned on Federation yet, but my Bonfire instance is looking good. My second install of Bonfire. I can tell you two things: Installation was much easier this time, and performance is much better.
One note, Bonfire recommends a hungry 8 GB of memory to run, but with that amount, it runs nicely so far. I'll keep you updated, hoping to turn federation on by next weekend. (This will be an invite only instance for brave individuals that want to assist with testing)
ALT text detailsA screenshot of a discussion interface, featuring a user profile on the left side. The main content displays an image of a scenic landscape with two figures sitting by a fire. Below the image, there is a section labeled "Code" with a SQL command and a quote about using fire for transformation. The interface includes navigation elements and a trending topics section.
New NLNet Projects were recently announced, with a solid collection of ActivityPub related ones:
* Mastodon adding new features for institutional instances * ActivityPub Polls for Wordpress * Funkwhale Federation Improvements * Making Events more interoperable between Fediverse Platforms * Context Discovery in NodeBB * Icosa 3-D Model Sharing with ActivityPub
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Haven't turned on Federation yet, but my Bonfire instance is looking good. My second install of Bonfire. I can tell you two things: Installation was much easier this time, and performance is much better.
One note, Bonfire recommends a hungry 8 GB of memory to run, but with that amount, it runs nicely so far. I'll keep you updated, hoping to turn federation on by next weekend. (This will be an invite only instance for brave individuals that want to assist with testing)
ALT text detailsA screenshot of a discussion interface, featuring a user profile on the left side. The main content displays an image of a scenic landscape with two figures sitting by a fire. Below the image, there is a section labeled "Code" with a SQL command and a quote about using fire for transformation. The interface includes navigation elements and a trending topics section.
Haven't turned on Federation yet, but my Bonfire instance is looking good. My second install of Bonfire. I can tell you two things: Installation was much easier this time, and performance is much better.
One note, Bonfire recommends a hungry 8 GB of memory to run, but with that amount, it runs nicely so far. I'll keep you updated, hoping to turn federation on by next weekend. (This will be an invite only instance for brave individuals that want to assist with testing)
ALT text detailsA screenshot of a discussion interface, featuring a user profile on the left side. The main content displays an image of a scenic landscape with two figures sitting by a fire. Below the image, there is a section labeled "Code" with a SQL command and a quote about using fire for transformation. The interface includes navigation elements and a trending topics section.
Haven't turned on Federation yet, but my Bonfire instance is looking good. My second install of Bonfire. I can tell you two things: Installation was much easier this time, and performance is much better.
One note, Bonfire recommends a hungry 8 GB of memory to run, but with that amount, it runs nicely so far. I'll keep you updated, hoping to turn federation on by next weekend. (This will be an invite only instance for brave individuals that want to assist with testing)
ALT text detailsA screenshot of a discussion interface, featuring a user profile on the left side. The main content displays an image of a scenic landscape with two figures sitting by a fire. Below the image, there is a section labeled "Code" with a SQL command and a quote about using fire for transformation. The interface includes navigation elements and a trending topics section.
Haven't turned on Federation yet, but my Bonfire instance is looking good. My second install of Bonfire. I can tell you two things: Installation was much easier this time, and performance is much better.
One note, Bonfire recommends a hungry 8 GB of memory to run, but with that amount, it runs nicely so far. I'll keep you updated, hoping to turn federation on by next weekend. (This will be an invite only instance for brave individuals that want to assist with testing)
ALT text detailsA screenshot of a discussion interface, featuring a user profile on the left side. The main content displays an image of a scenic landscape with two figures sitting by a fire. Below the image, there is a section labeled "Code" with a SQL command and a quote about using fire for transformation. The interface includes navigation elements and a trending topics section.
Haven't turned on Federation yet, but my Bonfire instance is looking good. My second install of Bonfire. I can tell you two things: Installation was much easier this time, and performance is much better.
One note, Bonfire recommends a hungry 8 GB of memory to run, but with that amount, it runs nicely so far. I'll keep you updated, hoping to turn federation on by next weekend. (This will be an invite only instance for brave individuals that want to assist with testing)
ALT text detailsA screenshot of a discussion interface, featuring a user profile on the left side. The main content displays an image of a scenic landscape with two figures sitting by a fire. Below the image, there is a section labeled "Code" with a SQL command and a quote about using fire for transformation. The interface includes navigation elements and a trending topics section.
Question for @eleventy users: is anyone syndicating their site to the fediverse using #ActivityPub, similar to what Ghost is doing (eg @index); and if so, how are you doing this? i.e. making your site a first-class citizen of the fediverse. I know there was this project a few years ago by @lewis, but not sure if it’s currently being used: https://github.com/LewisDaleUK/eleventy-plugin-activity-pub
Reason I ask is I’d like to have a posts feed for Cybercultural, that people can eg subscribe to in Mastodon.
Question for @eleventy users: is anyone syndicating their site to the fediverse using #ActivityPub, similar to what Ghost is doing (eg @index); and if so, how are you doing this? i.e. making your site a first-class citizen of the fediverse. I know there was this project a few years ago by @lewis, but not sure if it’s currently being used: https://github.com/LewisDaleUK/eleventy-plugin-activity-pub
Reason I ask is I’d like to have a posts feed for Cybercultural, that people can eg subscribe to in Mastodon.
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
Ghost’s @johnonolan and WordPress’s @pfefferle want to help blogs and long content thrive on the open social web. Meet “the longformers,” who chatted to @mike for the latest edition of Dot Social.
Ghost’s @johnonolan and WordPress’s @pfefferle want to help blogs and long content thrive on the open social web. Meet “the longformers,” who chatted to @mike for the latest edition of Dot Social.
Ghost’s @johnonolan and WordPress’s @pfefferle want to help blogs and long content thrive on the open social web. Meet “the longformers,” who chatted to @mike for the latest edition of Dot Social.
Ghost’s @johnonolan and WordPress’s @pfefferle want to help blogs and long content thrive on the open social web. Meet “the longformers,” who chatted to @mike for the latest edition of Dot Social.
Ghost’s @johnonolan and WordPress’s @pfefferle want to help blogs and long content thrive on the open social web. Meet “the longformers,” who chatted to @mike for the latest edition of Dot Social.
Ghost’s @johnonolan and WordPress’s @pfefferle want to help blogs and long content thrive on the open social web. Meet “the longformers,” who chatted to @mike for the latest edition of Dot Social.
Ghost’s @johnonolan and WordPress’s @pfefferle want to help blogs and long content thrive on the open social web. Meet “the longformers,” who chatted to @mike for the latest edition of Dot Social.
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue — utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue — leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue — can now be configured to use AMQP broker's native retry mechanisms
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Ω🪬Ω Latest release of #FediAlgo, the customizable timeline algorithm / filtering system for your Mastodon feed, lets you blur / hide images marked as sensitive / #NSFW, which solves the "unwanted dick pics in your feed" issue that can come up when users of one of the more "risque" fediverse servers manage to make one of their favourite hashtags trend.
"And of course we work with standards [for Libervia], with XMPP notably. It's a communications standard which is ... mainly know for instant messaging but it can actually do a lot more. So we use it also for blogging ... for these kinds of things.
And I've been working on a gateway [other protocols], notably ActivityPub, the protocol behind Mastodon, PeerTube, Mobilizon, etc."
Really enjoyed appearing on @firesidefedi with @ozoned yesterday! Always lovely to have a friendly, rambling, tangent-filled conversation about @manyfold, the Fediverse, and technology in general. Thanks for having me!
Disclaimer: ho utilizzato Mastodon fino a ieri quindi non intendo certo demonizzarlo (ci scherzo un po' sopra ), prendete questo post come una riflessione sulla sua mastodontica ingombranza nel mondo #ActivityPub
Really enjoyed appearing on @firesidefedi with @ozoned yesterday! Always lovely to have a friendly, rambling, tangent-filled conversation about @manyfold, the Fediverse, and technology in general. Thanks for having me!
New NLNet Projects were recently announced, with a solid collection of ActivityPub related ones:
* Mastodon adding new features for institutional instances * ActivityPub Polls for Wordpress * Funkwhale Federation Improvements * Making Events more interoperable between Fediverse Platforms * Context Discovery in NodeBB * Icosa 3-D Model Sharing with ActivityPub
"And of course we work with standards [for Libervia], with XMPP notably. It's a communications standard which is ... mainly know for instant messaging but it can actually do a lot more. So we use it also for blogging ... for these kinds of things.
And I've been working on a gateway [other protocols], notably ActivityPub, the protocol behind Mastodon, PeerTube, Mobilizon, etc."
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
Ω🪬Ω Latest release of #FediAlgo, the customizable timeline algorithm / filtering system for your Mastodon feed, lets you blur / hide images marked as sensitive / #NSFW, which solves the "unwanted dick pics in your feed" issue that can come up when users of one of the more "risque" fediverse servers manage to make one of their favourite hashtags trend.
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
New NLNet Projects were recently announced, with a solid collection of ActivityPub related ones:
* Mastodon adding new features for institutional instances * ActivityPub Polls for Wordpress * Funkwhale Federation Improvements * Making Events more interoperable between Fediverse Platforms * Context Discovery in NodeBB * Icosa 3-D Model Sharing with ActivityPub
Just for the record dropping the open issue on the Fediverse Experience curated list where I keep track of a list of #ActivityPub C2S supporting projects and attempts. Any updates most welcome if there's stuff missing.
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.
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.
Just for the record dropping the open issue on the Fediverse Experience curated list where I keep track of a list of #ActivityPub C2S supporting projects and attempts. Any updates most welcome if there's stuff missing.
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.
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
New NLNet Projects were recently announced, with a solid collection of ActivityPub related ones:
* Mastodon adding new features for institutional instances * ActivityPub Polls for Wordpress * Funkwhale Federation Improvements * Making Events more interoperable between Fediverse Platforms * Context Discovery in NodeBB * Icosa 3-D Model Sharing with ActivityPub
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Tonight, this repo was discussed in a thread and I am so glad I clicked on it. Among free fediverse sticker designs you can print yourself and other artwork, there are also fediverse mascot paper toys! Really cute. Now if I only had a color printer...
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue — utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue — leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue — can now be configured to use AMQP broker's native retry mechanisms
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
Tonight, this repo was discussed in a thread and I am so glad I clicked on it. Among free fediverse sticker designs you can print yourself and other artwork, there are also fediverse mascot paper toys! Really cute. Now if I only had a color printer...
Tonight, this repo was discussed in a thread and I am so glad I clicked on it. Among free fediverse sticker designs you can print yourself and other artwork, there are also fediverse mascot paper toys! Really cute. Now if I only had a color printer...
Tonight, this repo was discussed in a thread and I am so glad I clicked on it. Among free fediverse sticker designs you can print yourself and other artwork, there are also fediverse mascot paper toys! Really cute. Now if I only had a color printer...
Tonight, this repo was discussed in a thread and I am so glad I clicked on it. Among free fediverse sticker designs you can print yourself and other artwork, there are also fediverse mascot paper toys! Really cute. Now if I only had a color printer...
Tonight, this repo was discussed in a thread and I am so glad I clicked on it. Among free fediverse sticker designs you can print yourself and other artwork, there are also fediverse mascot paper toys! Really cute. Now if I only had a color printer...
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue — utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue — leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue — can now be configured to use AMQP broker's native retry mechanisms
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
New NLNet Projects were recently announced, with a solid collection of ActivityPub related ones:
* Mastodon adding new features for institutional instances * ActivityPub Polls for Wordpress * Funkwhale Federation Improvements * Making Events more interoperable between Fediverse Platforms * Context Discovery in NodeBB * Icosa 3-D Model Sharing with ActivityPub
🎉 Development for Mastodon compatible #ActivityPub polls in #WordPress is starting. This project is receiving funding from the latest round of the NGI Zero Commons Fund. #ngi0#NLnet
New NLNet Projects were recently announced, with a solid collection of ActivityPub related ones:
* Mastodon adding new features for institutional instances * ActivityPub Polls for Wordpress * Funkwhale Federation Improvements * Making Events more interoperable between Fediverse Platforms * Context Discovery in NodeBB * Icosa 3-D Model Sharing with ActivityPub
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
Just a thought, from a knuckle-dragging biology scientist. TL;DR: I believe there is scope to make the hosting of a peertube instance even more lightweight in the future.
Since then, I believe #WebGPU has done/is doing some clever things to improve the browser's access to the device's GPU.
I have not seen any #peertube capability that offloads video transcoding to the user in this way.
I imagine, though, that this would align well with peertube's agenda of lowering the bar to entry into web-video hosting, so I cannot help but think that this will come in time.
My own interest is seeing a #Piefed (activitypub) instance whose web-pages could #autotranslate posts into the user's own language using the user's own processing power... One day, maybe!
Thank you again for all your hard work; it is an inspiration.
Just a thought, from a knuckle-dragging biology scientist. TL;DR: I believe there is scope to make the hosting of a peertube instance even more lightweight in the future.
Since then, I believe #WebGPU has done/is doing some clever things to improve the browser's access to the device's GPU.
I have not seen any #peertube capability that offloads video transcoding to the user in this way.
I imagine, though, that this would align well with peertube's agenda of lowering the bar to entry into web-video hosting, so I cannot help but think that this will come in time.
My own interest is seeing a #Piefed (activitypub) instance whose web-pages could #autotranslate posts into the user's own language using the user's own processing power... One day, maybe!
Thank you again for all your hard work; it is an inspiration.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
New NLNet Projects were recently announced, with a solid collection of ActivityPub related ones:
* Mastodon adding new features for institutional instances * ActivityPub Polls for Wordpress * Funkwhale Federation Improvements * Making Events more interoperable between Fediverse Platforms * Context Discovery in NodeBB * Icosa 3-D Model Sharing with ActivityPub
New NLNet Projects were recently announced, with a solid collection of ActivityPub related ones:
* Mastodon adding new features for institutional instances * ActivityPub Polls for Wordpress * Funkwhale Federation Improvements * Making Events more interoperable between Fediverse Platforms * Context Discovery in NodeBB * Icosa 3-D Model Sharing with ActivityPub
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue — utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue — leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue — can now be configured to use AMQP broker's native retry mechanisms
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
🎉 Development for Mastodon compatible #ActivityPub polls in #WordPress is starting. This project is receiving funding from the latest round of the NGI Zero Commons Fund. #ngi0#NLnet
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue — utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue — leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue — can now be configured to use AMQP broker's native retry mechanisms
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue — utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue — leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue — can now be configured to use AMQP broker's native retry mechanisms
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
I decided since I don't understand how all of this works, I will just simply ask Jerry personally about all of this data and technical details, so that people will no longer be confused about all of this.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue — utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue — leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue — can now be configured to use AMQP broker's native retry mechanisms
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
🎉 Development for Mastodon compatible #ActivityPub polls in #WordPress is starting. This project is receiving funding from the latest round of the NGI Zero Commons Fund. #ngi0#NLnet
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue — utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue — leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue — can now be configured to use AMQP broker's native retry mechanisms
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue — utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue — leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue — can now be configured to use AMQP broker's native retry mechanisms
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue — utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue — leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue — can now be configured to use AMQP broker's native retry mechanisms
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue — utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue — leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue — can now be configured to use AMQP broker's native retry mechanisms
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue — utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue — leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue — can now be configured to use AMQP broker's native retry mechanisms
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
🎉 Development for Mastodon compatible #ActivityPub polls in #WordPress is starting. This project is receiving funding from the latest round of the NGI Zero Commons Fund. #ngi0#NLnet
🎉 Development for Mastodon compatible #ActivityPub polls in #WordPress is starting. This project is receiving funding from the latest round of the NGI Zero Commons Fund. #ngi0#NLnet
🎉 Development for Mastodon compatible #ActivityPub polls in #WordPress is starting. This project is receiving funding from the latest round of the NGI Zero Commons Fund. #ngi0#NLnet
🎉 Development for Mastodon compatible #ActivityPub polls in #WordPress is starting. This project is receiving funding from the latest round of the NGI Zero Commons Fund. #ngi0#NLnet
I decided since I don't understand how all of this works, I will just simply ask Jerry personally about all of this data and technical details, so that people will no longer be confused about all of this.
Anybody with an #activitypub or #atproto or related open social web project planning to go to Web Summit in Lisbon, Portugal, in November? Is that something this community does?
Just a thought, from a knuckle-dragging biology scientist. TL;DR: I believe there is scope to make the hosting of a peertube instance even more lightweight in the future.
Since then, I believe #WebGPU has done/is doing some clever things to improve the browser's access to the device's GPU.
I have not seen any #peertube capability that offloads video transcoding to the user in this way.
I imagine, though, that this would align well with peertube's agenda of lowering the bar to entry into web-video hosting, so I cannot help but think that this will come in time.
My own interest is seeing a #Piefed (activitypub) instance whose web-pages could #autotranslate posts into the user's own language using the user's own processing power... One day, maybe!
Thank you again for all your hard work; it is an inspiration.
💗 While it has a #passionate user base, it remains a #niche platform.
📲 At #FediForum, new apps like #Bounce, #Surf, and #Bandwagon were showcased, demonstrating progress in social graph migration, feed management, and monetisation for creators.
- @activitypub.blog talks about how they plan to make WordPress sites a full member of the fediverse, with replies, follows, and your own feed - @fediforum videos now available, with some thoughts on the ones that stood out to me - server admins can now opt-in to @fed.brid.gy on a per-server basis - @swf releases draft for E2EE messaging over #activitypub with MLS
💗 While it has a #passionate user base, it remains a #niche platform.
📲 At #FediForum, new apps like #Bounce, #Surf, and #Bandwagon were showcased, demonstrating progress in social graph migration, feed management, and monetisation for creators.
Just a thought, from a knuckle-dragging biology scientist. TL;DR: I believe there is scope to make the hosting of a peertube instance even more lightweight in the future.
Since then, I believe #WebGPU has done/is doing some clever things to improve the browser's access to the device's GPU.
I have not seen any #peertube capability that offloads video transcoding to the user in this way.
I imagine, though, that this would align well with peertube's agenda of lowering the bar to entry into web-video hosting, so I cannot help but think that this will come in time.
My own interest is seeing a #Piefed (activitypub) instance whose web-pages could #autotranslate posts into the user's own language using the user's own processing power... One day, maybe!
Thank you again for all your hard work; it is an inspiration.
Despite traveling, I've been working on some things for #GoActivityPub and one of them is the ability to generate web optimized images when uploading JPG/PNG files.
The end result is an Image object containing multiple URL entries to small/medium web-optimized copies, plus the original.
This still requires some work on the frontend web components to be able to select from multiple variants based on the reported width/height.
But it also allowed me to fix issues with the ability of the library to process activities that contain multiple Objects.
I just updated the #fediverse experience curated list with the latest #ActivityPub server platforms. Great to see new types of applications finding their way to the interoperable #SocialWeb!
Despite traveling, I've been working on some things for #GoActivityPub and one of them is the ability to generate web optimized images when uploading JPG/PNG files.
The end result is an Image object containing multiple URL entries to small/medium web-optimized copies, plus the original.
This still requires some work on the frontend web components to be able to select from multiple variants based on the reported width/height.
But it also allowed me to fix issues with the ability of the library to process activities that contain multiple Objects.
Stanco dei soliti social network e della costante ingerenza dei giganti della tecnologia? La regista @_elena ti apre le porte del Fediverso, un universo digitale dove la tua privacy è rispettata e il potere torna finalmente nelle mani degli utenti.
I still wonder why remote interaction is made so difficult when there will always be more remote users than local ones. After all, every like on PeerTube so far counts 10 times more. ;-)
Hint: If you have an account on GitHub you can vote for this issue.
I still wonder why remote interaction is made so difficult when there will always be more remote users than local ones. After all, every like on PeerTube so far counts 10 times more. ;-)
Hint: If you have an account on GitHub you can vote for this issue.
There is now a free open self-hostable Fediverse trail recorder called Wanderer. You can upload GPS data directly and it also lets you import your data from Strava and Komoot.
Wanderer is federated through ActivityPub so Wanderer servers can connect to other Wanderer servers and Mastodon etc servers too. More info at the official website:
There is now a free open self-hostable Fediverse trail recorder called Wanderer. You can upload GPS data directly and it also lets you import your data from Strava and Komoot.
Wanderer is federated through ActivityPub so Wanderer servers can connect to other Wanderer servers and Mastodon etc servers too. More info at the official website:
There is now a free open self-hostable Fediverse trail recorder called Wanderer. You can upload GPS data directly and it also lets you import your data from Strava and Komoot.
Wanderer is federated through ActivityPub so Wanderer servers can connect to other Wanderer servers and Mastodon etc servers too. More info at the official website:
Just rolled out some fediverse-related improvements:
- Now you can follow Write.as blogs from Ghost! There was a tiny bug with this that we just fixed. (WriteFreely PR: https://writefreely.org/pull/1373)
- We now support the `preview` property as a fallback for Articles. This will make your posts look much nicer as more platforms support it! (WriteFreely PR: https://writefreely.org/pull/1374)
Ω🪬Ω new release of #Fedialgo, the customizable timeline algorithm / filtering system for your Mastodon feed, counts the number of times each hashtag appears in your timeline even if people don't use a "#" character to give you a better sense of what people are talking about in the Fediverse.
there's a little bit of art vs. science here because some strings are disqualified from this kind of counting (e.g. a word like "the" should not be counted even if some maniac decided to make it a hashtag) so let me know if you see any weirdly high counts.
wanderer, a self hosted trail logging app, has added federation via ActivityPub. You can now follow, like and comment on trails shared from other instances.
wanderer, a self hosted trail logging app, has added federation via ActivityPub. You can now follow, like and comment on trails shared from other instances.
Ω🪬Ω new release of #Fedialgo, the customizable timeline algorithm / filtering system for your Mastodon feed, counts the number of times each hashtag appears in your timeline even if people don't use a "#" character to give you a better sense of what people are talking about in the Fediverse.
there's a little bit of art vs. science here because some strings are disqualified from this kind of counting (e.g. a word like "the" should not be counted even if some maniac decided to make it a hashtag) so let me know if you see any weirdly high counts.
Jeden Verein, jede Organisation, der oder die Wordpress einsetzt, muss man eigentlich nur umwerben, das #Wordpress-Plugin #ActivityPub einzusetzen. Schon allein dadurch wüchse das Fediverse binnen Wochen um (regional) relevanten Content und lokale Communities. Das könnte man als eine kettenbriefartige Kampagne anlegen bzw. als Mitmach-Challenge. Ein kleines Video-Tutorial, fertig. @_elena@kuketzblog Wie wär's? 1/x
For the past year I've been working on an activitypub federated instant messenger called Shoot. I haven't had time to work on it for a while because of my job, so I'm making it public to see if anyone would be interested in helping out.
Featureset currently includes: - Dm channels - Friends/relationships - Guilds - Guild channels - Guild invites - Voice calls (not yet federated) - Mostly working federation with itself - Iffy federation with other platforms
There's no official instance yet, but I could host one if there is interest.
What I need help with most is: - Frontend development. The client code is very hacky and gross, let alone the UI haha - Safety features - Probably general architecture stuff
wanderer, a self hosted trail logging app, has added federation via ActivityPub. You can now follow, like and comment on trails shared from other instances.
For the past year I've been working on an activitypub federated instant messenger called Shoot. I haven't had time to work on it for a while because of my job, so I'm making it public to see if anyone would be interested in helping out.
Featureset currently includes: - Dm channels - Friends/relationships - Guilds - Guild channels - Guild invites - Voice calls (not yet federated) - Mostly working federation with itself - Iffy federation with other platforms
There's no official instance yet, but I could host one if there is interest.
What I need help with most is: - Frontend development. The client code is very hacky and gross, let alone the UI haha - Safety features - Probably general architecture stuff
Ω🪬Ω new release of #Fedialgo, the customizable timeline algorithm / filtering system for your Mastodon feed, counts the number of times each hashtag appears in your timeline even if people don't use a "#" character to give you a better sense of what people are talking about in the Fediverse.
there's a little bit of art vs. science here because some strings are disqualified from this kind of counting (e.g. a word like "the" should not be counted even if some maniac decided to make it a hashtag) so let me know if you see any weirdly high counts.
For the past year I've been working on an activitypub federated instant messenger called Shoot. I haven't had time to work on it for a while because of my job, so I'm making it public to see if anyone would be interested in helping out.
Featureset currently includes: - Dm channels - Friends/relationships - Guilds - Guild channels - Guild invites - Voice calls (not yet federated) - Mostly working federation with itself - Iffy federation with other platforms
There's no official instance yet, but I could host one if there is interest.
What I need help with most is: - Frontend development. The client code is very hacky and gross, let alone the UI haha - Safety features - Probably general architecture stuff
ALT text detailsThe image shows a screenshot of a mastodon client. In it a post by @demo@demo.wanderer.to displaying a picture of a trail with the GPX file attached and a link to the post.
ALT text detailsThe image shows a screenshot of a mastodon client. In it a post by @demo@demo.wanderer.to displaying a picture of a trail with the GPX file attached and a link to the post.
For the past year I've been working on an activitypub federated instant messenger called Shoot. I haven't had time to work on it for a while because of my job, so I'm making it public to see if anyone would be interested in helping out.
Featureset currently includes: - Dm channels - Friends/relationships - Guilds - Guild channels - Guild invites - Voice calls (not yet federated) - Mostly working federation with itself - Iffy federation with other platforms
There's no official instance yet, but I could host one if there is interest.
What I need help with most is: - Frontend development. The client code is very hacky and gross, let alone the UI haha - Safety features - Probably general architecture stuff
wanderer, a self hosted trail logging app, has added federation via ActivityPub. You can now follow, like and comment on trails shared from other instances.
wanderer, a self hosted trail logging app, has added federation via ActivityPub. You can now follow, like and comment on trails shared from other instances.
wanderer, a self hosted trail logging app, has added federation via ActivityPub. You can now follow, like and comment on trails shared from other instances.
ALT text detailsThe image shows a screenshot of a mastodon client. In it a post by @demo@demo.wanderer.to displaying a picture of a trail with the GPX file attached and a link to the post.
wanderer, a self hosted trail logging app, has added federation via ActivityPub. You can now follow, like and comment on trails shared from other instances.
For the past year I've been working on an activitypub federated instant messenger called Shoot. I haven't had time to work on it for a while because of my job, so I'm making it public to see if anyone would be interested in helping out.
Featureset currently includes: - Dm channels - Friends/relationships - Guilds - Guild channels - Guild invites - Voice calls (not yet federated) - Mostly working federation with itself - Iffy federation with other platforms
There's no official instance yet, but I could host one if there is interest.
What I need help with most is: - Frontend development. The client code is very hacky and gross, let alone the UI haha - Safety features - Probably general architecture stuff
wanderer, a self hosted trail logging app, has added federation via ActivityPub. You can now follow, like and comment on trails shared from other instances.
wanderer, a self hosted trail logging app, has added federation via ActivityPub. You can now follow, like and comment on trails shared from other instances.
wanderer, a self hosted trail logging app, has added federation via ActivityPub. You can now follow, like and comment on trails shared from other instances.
wanderer, a self hosted trail logging app, has added federation via ActivityPub. You can now follow, like and comment on trails shared from other instances.
Eagle-eyed product developer @parkerortolani spotted something in Apple's WWDC 2025 presentation: Mastodon. During designer Billy Sorrentino's section on visual intelligence, there's a clear shot of @ivory. "It was clearly both a way to subtly show developers what they can do with their own apps, but also read as a sort of endorsement of Mastodon as a social platform," Ortolani writes on his blog. "Apple didn’t show Bluesky, Threads, or X. They chose to show a third-party Mastodon client."
Eagle-eyed product developer @parkerortolani spotted something in Apple's WWDC 2025 presentation: Mastodon. During designer Billy Sorrentino's section on visual intelligence, there's a clear shot of @ivory. "It was clearly both a way to subtly show developers what they can do with their own apps, but also read as a sort of endorsement of Mastodon as a social platform," Ortolani writes on his blog. "Apple didn’t show Bluesky, Threads, or X. They chose to show a third-party Mastodon client."
The final form of the #GoActivityPub library that deals with the processing of Activities will most likely be a state machine with pluggable states based on "activity type" x "object type" pairs.
This ensures calling code can inject its own processing if it has custom vocabulary, or fallback to the ActivtiyPub specification defaults.
How to combine the two without having conflicts might be more difficult though.
noob question. Does @pixelfed and Mastodon play nice when moving. ie: can I move an account from Mastodon to Pixelfed and bring our followers with us ?
However, #deltachat is vertically centralized in that all UIs use the same #rust core which implements all networking, encryption, chat/group/message logic in a single centralized place. The now 40+ #chatmail mail relay network is driven from centralized code.
At each level replication and federation is built in.
- @activitypub.blog talks about how they plan to make WordPress sites a full member of the fediverse, with replies, follows, and your own feed - @fediforum videos now available, with some thoughts on the ones that stood out to me - server admins can now opt-in to @fed.brid.gy on a per-server basis - @swf releases draft for E2EE messaging over #activitypub with MLS
For anyone that can't come to my talk at #ForwardJS in #Ottawa tonight, check out my slides and run the speaker notes through the shittiest text to speech you can find to get a similar experience.
For anyone that can't come to my talk at #ForwardJS in #Ottawa tonight, check out my slides and run the speaker notes through the shittiest text to speech you can find to get a similar experience.
However, #deltachat is vertically centralized in that all UIs use the same #rust core which implements all networking, encryption, chat/group/message logic in a single centralized place. The now 40+ #chatmail mail relay network is driven from centralized code.
At each level replication and federation is built in.
If Vance were to join mastodon by comparison, assuming a similar desire to block from so many users, how differently might this play out based on the way that federation works within an Activity Pub context.
Just trying to understand the practical nature of the two protocols as applied to this case.
From what I understand of ATProrocol all that folks blocking achieves is it filters that account off for that user but otherwise the account can roll along just fine to other users. Correct me if I’m wrong here also. Keen to know more.
I just spoke with a #US#Senator office about the #fediverse . They're asking for more information to help spread around #Capital#Hill in small bite sized easy to understand pieces. I'm obviously going to give them @elena beautiful #movie on the #fedi (with some light editing which she's agreed to).
I'd love to know from folks any EASY to understand projects that best encompass the Fediverse and explanations of it.
What are some projects you'd hand to your friends and family that would explain and display to them what we are?
I'll say this isn't going to happen over night. There's lot of questions around regulations, trust & safety, etc. But I feel it's pertinent to at least get the conversation going, especially considering the current state of disdain for big social media and the impending legislation around these things.
I'll finally state if there's anyone in this list that does NOT want to be involved with this, that's totally fine and I understand and I can exclude you from the materials I give to them.
This article is published on a website which is powered by BDServer. And I'm trying to make this website support ActivityPub, so you could for example, subscribe to me from your Mastodon account. Yet it is easier said than done.
If you have any experience with ActivityPub, web-development or Python, please consider helping me. We have BDServ...
I just spoke with a #US#Senator office about the #fediverse . They're asking for more information to help spread around #Capital#Hill in small bite sized easy to understand pieces. I'm obviously going to give them @elena beautiful #movie on the #fedi (with some light editing which she's agreed to).
I'd love to know from folks any EASY to understand projects that best encompass the Fediverse and explanations of it.
What are some projects you'd hand to your friends and family that would explain and display to them what we are?
I'll say this isn't going to happen over night. There's lot of questions around regulations, trust & safety, etc. But I feel it's pertinent to at least get the conversation going, especially considering the current state of disdain for big social media and the impending legislation around these things.
I'll finally state if there's anyone in this list that does NOT want to be involved with this, that's totally fine and I understand and I can exclude you from the materials I give to them.
This article is published on a website which is powered by BDServer. And I'm trying to make this website support ActivityPub, so you could for example, subscribe to me from your Mastodon account. Yet it is easier said than done.
If you have any experience with ActivityPub, web-development or Python, please consider helping me. We have BDServ...
Though it dates from a couple years back, on #SocialHub can be found the 3-part webinar #ActivityPub for Administrations organized specifically for a target audience in #government.
I just spoke with a #US#Senator office about the #fediverse . They're asking for more information to help spread around #Capital#Hill in small bite sized easy to understand pieces. I'm obviously going to give them @elena beautiful #movie on the #fedi (with some light editing which she's agreed to).
I'd love to know from folks any EASY to understand projects that best encompass the Fediverse and explanations of it.
What are some projects you'd hand to your friends and family that would explain and display to them what we are?
I'll say this isn't going to happen over night. There's lot of questions around regulations, trust & safety, etc. But I feel it's pertinent to at least get the conversation going, especially considering the current state of disdain for big social media and the impending legislation around these things.
I'll finally state if there's anyone in this list that does NOT want to be involved with this, that's totally fine and I understand and I can exclude you from the materials I give to them.
I just spoke with a #US#Senator office about the #fediverse . They're asking for more information to help spread around #Capital#Hill in small bite sized easy to understand pieces. I'm obviously going to give them @elena beautiful #movie on the #fedi (with some light editing which she's agreed to).
I'd love to know from folks any EASY to understand projects that best encompass the Fediverse and explanations of it.
What are some projects you'd hand to your friends and family that would explain and display to them what we are?
I'll say this isn't going to happen over night. There's lot of questions around regulations, trust & safety, etc. But I feel it's pertinent to at least get the conversation going, especially considering the current state of disdain for big social media and the impending legislation around these things.
I'll finally state if there's anyone in this list that does NOT want to be involved with this, that's totally fine and I understand and I can exclude you from the materials I give to them.
I just spoke with a #US#Senator office about the #fediverse . They're asking for more information to help spread around #Capital#Hill in small bite sized easy to understand pieces. I'm obviously going to give them @elena beautiful #movie on the #fedi (with some light editing which she's agreed to).
I'd love to know from folks any EASY to understand projects that best encompass the Fediverse and explanations of it.
What are some projects you'd hand to your friends and family that would explain and display to them what we are?
I'll say this isn't going to happen over night. There's lot of questions around regulations, trust & safety, etc. But I feel it's pertinent to at least get the conversation going, especially considering the current state of disdain for big social media and the impending legislation around these things.
I'll finally state if there's anyone in this list that does NOT want to be involved with this, that's totally fine and I understand and I can exclude you from the materials I give to them.
I just spoke with a #US#Senator office about the #fediverse . They're asking for more information to help spread around #Capital#Hill in small bite sized easy to understand pieces. I'm obviously going to give them @elena beautiful #movie on the #fedi (with some light editing which she's agreed to).
I'd love to know from folks any EASY to understand projects that best encompass the Fediverse and explanations of it.
What are some projects you'd hand to your friends and family that would explain and display to them what we are?
I'll say this isn't going to happen over night. There's lot of questions around regulations, trust & safety, etc. But I feel it's pertinent to at least get the conversation going, especially considering the current state of disdain for big social media and the impending legislation around these things.
I'll finally state if there's anyone in this list that does NOT want to be involved with this, that's totally fine and I understand and I can exclude you from the materials I give to them.
@jeff@TheAdmin can u please assist w my concern re #threads access to our postings & #fediverse per this update #Threads is largest app to adopt #ActivityPub, protocol powering the fediverse, worrying some that Meta will take over decentralized, open source social network made up of interconnected servers. Though Threads isn’t yet full integrated, already some #Mastodon server operators have preemptively #blocked Threads, so their users can’t interact w Meta-run social network and vice versa.
- @activitypub.blog talks about how they plan to make WordPress sites a full member of the fediverse, with replies, follows, and your own feed - @fediforum videos now available, with some thoughts on the ones that stood out to me - server admins can now opt-in to @fed.brid.gy on a per-server basis - @swf releases draft for E2EE messaging over #activitypub with MLS
This is great, really love it. I recently overhauled the #Fediverse Experience curated list, with a different taxonomy to highlight more innovative #ActivityPub areas other than those where adoption is already going strong.
The #OpenScience section still has disappointing few entries, so I am delighted to add @encyclia as newcomer.
Ω🪬Ω Just pushed a new release of #FediAlgo to production. Now sprinkles the latest posts from your homeserver into your feed, caches more stuff for performance reasons, fully supports blocked domains, and some other stuff.
Ω🪬Ω Just pushed a new release of #FediAlgo to production. Now sprinkles the latest posts from your homeserver into your feed, caches more stuff for performance reasons, fully supports blocked domains, and some other stuff.
Ω🪬Ω #FediAlgo, the customizable timeline algorithm / filtering system for your Mastodon feed, is now deployed on Github Pages and can be used from your web browser.
Ω🪬Ω Just pushed a new release of #FediAlgo to production. Now sprinkles the latest posts from your homeserver into your feed, caches more stuff for performance reasons, fully supports blocked domains, and some other stuff.
- @activitypub.blog talks about how they plan to make WordPress sites a full member of the fediverse, with replies, follows, and your own feed - @fediforum videos now available, with some thoughts on the ones that stood out to me - server admins can now opt-in to @fed.brid.gy on a per-server basis - @swf releases draft for E2EE messaging over #activitypub with MLS
Ω🪬Ω Just pushed a new release of #FediAlgo to production. Now sprinkles the latest posts from your homeserver into your feed, caches more stuff for performance reasons, fully supports blocked domains, and some other stuff.
- @activitypub.blog talks about how they plan to make WordPress sites a full member of the fediverse, with replies, follows, and your own feed - @fediforum videos now available, with some thoughts on the ones that stood out to me - server admins can now opt-in to @fed.brid.gy on a per-server basis - @swf releases draft for E2EE messaging over #activitypub with MLS
- @activitypub.blog talks about how they plan to make WordPress sites a full member of the fediverse, with replies, follows, and your own feed - @fediforum videos now available, with some thoughts on the ones that stood out to me - server admins can now opt-in to @fed.brid.gy on a per-server basis - @swf releases draft for E2EE messaging over #activitypub with MLS
🥳 Manyfold v0.114.0 is out, once again focused on public instances. Features include automatic setup of a creator profile for new users, required creator and license for published models, and the usual host of bugfixes.
And, get ready, because now that lot's done, we're launching our public instance *very* soon.
I saw #mastodonSocial just updated their terms of service to prohibit scraping data for training #LLMs which sucks. Maybe I'll move instances again.
But I wonder; how does this work across the #Fediverse? Like, surely an instance that federates with m.s doesn't have to abide by this rule, and could allow the same #ActivityPub content to be scrapped from their servers instead.
🥳 Manyfold v0.114.0 is out, once again focused on public instances. Features include automatic setup of a creator profile for new users, required creator and license for published models, and the usual host of bugfixes.
And, get ready, because now that lot's done, we're launching our public instance *very* soon.
Hey there. AFAIK there are no #Strava alternatives with #ActivityPub yet. However in my recent overhaul of the #Fediverse Experience curated list I found there's one platform planning it:
#Librecast LIVE will bring all the technology together, to demonstrate and be a reference implementation. With #ActivityPub support being planned. See:
Has anyone coined a colloquial term for #Bluesky's flavor of decentralization? #ActivityPub is often associated with the “federation" flavor, but that term doesn't feel applicable to Bsky/ #ATProtocol
#Librecast LIVE will bring all the technology together, to demonstrate and be a reference implementation. With #ActivityPub support being planned. See:
@simon_brooke@mastodon.scot · Reply to Aaron's post
@hosford42 I have copies of all my public repositories on GitHub still, because on GitHub they're discoverable. But GitHub is no longer a safe place for #OpenSource people; it's increasingly an engine of exploitation, and it's increasingly a place where malefactors are tolerated.
I am really looking forward to the point where #ActivityPub federation in @forgejo works well, so that we can have reasonable discoverability in #Forgejo.
What should happen if an #ActivityPub Like activity uses direct addressing (no as:Public)? It seems the intent is that you want to send a "private" Like notification to the activity recipients. Should the public like count be incremented or not as a side-effect? If not, Like counts would be dependent on the authorization of the actor fetching an AP object. I hope ActivityPub 2.0 has better authorization guidance.
#Better#MentalHealth 🧠 Research shows that algorithm-driven feeds fuel anxiety and addiction: #ActivityPub platforms, like #Mastodon, avoid manipulative engagement tactics. (1/2)
@simon_brooke@mastodon.scot · Reply to Aaron's post
@hosford42 I have copies of all my public repositories on GitHub still, because on GitHub they're discoverable. But GitHub is no longer a safe place for #OpenSource people; it's increasingly an engine of exploitation, and it's increasingly a place where malefactors are tolerated.
I am really looking forward to the point where #ActivityPub federation in @forgejo works well, so that we can have reasonable discoverability in #Forgejo.
What should happen if an #ActivityPub Like activity uses direct addressing (no as:Public)? It seems the intent is that you want to send a "private" Like notification to the activity recipients. Should the public like count be incremented or not as a side-effect? If not, Like counts would be dependent on the authorization of the actor fetching an AP object. I hope ActivityPub 2.0 has better authorization guidance.
React if you’d like a #ActivityPubSpecAlert when there are proposals to change the requirements of ActivityPub as we’ve begun to see the last couple weeks.
#PrivacyProtection 🔒 Unlike Facebook, Instagram, LinkedIn, Reddit, TikTok, YouTube, XTwitter, decentralised networks don’t harvest your data for profit: You are in #fullcontrol!
#PrivacyProtection 🔒 Unlike Facebook, Instagram, LinkedIn, Reddit, TikTok, YouTube, XTwitter, decentralised networks don’t harvest your data for profit: You are in #fullcontrol!
#Better#MentalHealth 🧠 Research shows that algorithm-driven feeds fuel anxiety and addiction: #ActivityPub platforms, like #Mastodon, avoid manipulative engagement tactics. (1/2)
React if you’d like a #ActivityPubSpecAlert when there are proposals to change the requirements of ActivityPub as we’ve begun to see the last couple weeks.
"At the heart of these alternative apps lies #theFediverse platform — a portmanteau of "federated" and "universe" that represents a radical reimagining of how social media can work. Unlike traditional platforms where users are locked into isolated ecosystems, the Fediverse operates as an interconnected network of independent servers that communicate with each other through a standard protocol called #ActivityPub."
With just 32 hours left to go...I can't believe it...they are less than $500 away from meeting the $55k goal, which will add in-app live streaming capabilities.
With just 32 hours left to go...I can't believe it...they are less than $500 away from meeting the $55k goal, which will add in-app live streaming capabilities.
With just 32 hours left to go...I can't believe it...they are less than $500 away from meeting the $55k goal, which will add in-app live streaming capabilities.
With just 32 hours left to go...I can't believe it...they are less than $500 away from meeting the $55k goal, which will add in-app live streaming capabilities.
The #ActivityPub spec says "sharedInbox endpoints SHOULD also be publicly readable OrderedCollection objects containing objects addressed to the Public special collection". Has anybody seen any implementations of this? The spec doesn't specify if the public objects are local to the instance being queried or should only include federated objects (or activities?). Given it's an "inbox" endpoint, I'd guess it's a collection of federated activities (since that's what's posted to the sharedInbox). 🤷
"At the heart of these alternative apps lies #theFediverse platform — a portmanteau of "federated" and "universe" that represents a radical reimagining of how social media can work. Unlike traditional platforms where users are locked into isolated ecosystems, the Fediverse operates as an interconnected network of independent servers that communicate with each other through a standard protocol called #ActivityPub."
The #ActivityPub spec says "sharedInbox endpoints SHOULD also be publicly readable OrderedCollection objects containing objects addressed to the Public special collection". Has anybody seen any implementations of this? The spec doesn't specify if the public objects are local to the instance being queried or should only include federated objects (or activities?). Given it's an "inbox" endpoint, I'd guess it's a collection of federated activities (since that's what's posted to the sharedInbox). 🤷
The #ActivityPub spec says "sharedInbox endpoints SHOULD also be publicly readable OrderedCollection objects containing objects addressed to the Public special collection". Has anybody seen any implementations of this? The spec doesn't specify if the public objects are local to the instance being queried or should only include federated objects (or activities?). Given it's an "inbox" endpoint, I'd guess it's a collection of federated activities (since that's what's posted to the sharedInbox). 🤷
"At the heart of these alternative apps lies #theFediverse platform — a portmanteau of "federated" and "universe" that represents a radical reimagining of how social media can work. Unlike traditional platforms where users are locked into isolated ecosystems, the Fediverse operates as an interconnected network of independent servers that communicate with each other through a standard protocol called #ActivityPub."
I decided since I don't understand how all of this works, I will just simply ask Jerry personally about all of this data and technical details, so that people will no longer be confused about all of this.
Hey @pfefferle, is there any recommended ways to scale up a WordPress installation that has a lot of #ActivityPub subscribers? It seems whenever I push out a podcast episode now, there’s a period of downtime while my server tries to push everything out. 😞
I decided since I don't understand how all of this works, I will just simply ask Jerry personally about all of this data and technical details, so that people will no longer be confused about all of this.
from #Forbes ByEsat Dedezade, Contributor. Esat Dedezade is U.K.-based journalist who covers Big Tech for Forbes Jan 25, 2025, 12:23pm EST
[a very well-written article with a favorable yet realistic angle on the #Fediverse]
"At the heart of these alternative apps lies the Fediverse platform — a portmanteau of "federated" and "universe" that represents a radical reimagining of how social media can work. Unlike traditional platforms where users are locked into isolated ecosystems, the Fediverse operates as an interconnected network of independent servers that communicate with each other through a standard protocol called #ActivityPub."
What is the state of key-based identities in ActivityPub? Or applications that utilize key-based identities on top of ActivityPub? #fediverse#activitypub#mastodon#nostr
For today at #DevConf_CZ I highly recommend @Tobias 's talk "about:#Fediverse - An introduction to the decentralised social network" at 11:00 in room A112! Learn more about #activitypub , get a good overview about the concept of the fediverse and how @Mastodon@pixelfed@friendica@wordpress and other services work in a decentralised way.
For today at #DevConf_CZ I highly recommend @Tobias 's talk "about:#Fediverse - An introduction to the decentralised social network" at 11:00 in room A112! Learn more about #activitypub , get a good overview about the concept of the fediverse and how @Mastodon@pixelfed@friendica@wordpress and other services work in a decentralised way.
from #Forbes ByEsat Dedezade, Contributor. Esat Dedezade is U.K.-based journalist who covers Big Tech for Forbes Jan 25, 2025, 12:23pm EST
[a very well-written article with a favorable yet realistic angle on the #Fediverse]
"At the heart of these alternative apps lies the Fediverse platform — a portmanteau of "federated" and "universe" that represents a radical reimagining of how social media can work. Unlike traditional platforms where users are locked into isolated ecosystems, the Fediverse operates as an interconnected network of independent servers that communicate with each other through a standard protocol called #ActivityPub."
Re: #AcademicMastodon + #OpenScience. I'm initiator of Delightful #commons for people to keep curated directories. Similar to Awesome on #github except only for open resources.
There's 2 lists I want to bring to attention. First one, the #ActivityPub#fediverse experience. It needs more open science entries 💪
from #Forbes ByEsat Dedezade, Contributor. Esat Dedezade is U.K.-based journalist who covers Big Tech for Forbes Jan 25, 2025, 12:23pm EST
[a very well-written article with a favorable yet realistic angle on the #Fediverse]
"At the heart of these alternative apps lies the Fediverse platform — a portmanteau of "federated" and "universe" that represents a radical reimagining of how social media can work. Unlike traditional platforms where users are locked into isolated ecosystems, the Fediverse operates as an interconnected network of independent servers that communicate with each other through a standard protocol called #ActivityPub."
#FediAlgo will now let you filter your feed by the server your timeline toots are originating from. You can also choose whether to color highlight hashtags you've participated in or favourited and some other fun stuff.
Good question. Fedi sheds delight, informs, connects people. Brings hope, inclusion, spreads awareness, protects, loves and supports. This is a fedi to care for, foster, nurture and grow. Towards a #peopleverse
Built on foundations of free software projects, now we must build cohesive ecosystems in order to take our next steps.
W3C #ActivityPub is getting a fresh portal. It awaits your input and ideas. I just gave my 2cts: a #FX list.
#FediAlgo will now let you filter your feed by the server your timeline toots are originating from. You can also choose whether to color highlight hashtags you've participated in or favourited and some other fun stuff.
Is this what my Wordpress blog should look like? Bringing my Domain name, my primary blog and my SocialWeb stuff together into one united page? (they would stack in mobile) 🤔 #SocialWeb#WordPress#Fediverse#ActivityPub
ALT text detailsOWGF wordpress page and mastodon pages combined.
Is this what my Wordpress blog should look like? Bringing my Domain name, my primary blog and my SocialWeb stuff together into one united page? (they would stack in mobile) 🤔 #SocialWeb#WordPress#Fediverse#ActivityPub
ALT text detailsOWGF wordpress page and mastodon pages combined.
Is this what my Wordpress blog should look like? Bringing my Domain name, my primary blog and my SocialWeb stuff together into one united page? (they would stack in mobile) 🤔 #SocialWeb#WordPress#Fediverse#ActivityPub
ALT text detailsOWGF wordpress page and mastodon pages combined.
"In addition to the way servers communicate with each other across the Fediverse, #ActivityPub also defines a “Client-to-Server” API. This #API is mainly designed to allow apps and clients (such as mobile apps) to publish content to a Fediverse server. In the future, this could open up interesting possibilities for #WordPress — for example, allowing WordPress to act as a bridge or proxy, making it easier to bring in and federate content from other tools or platforms."
"In addition to the way servers communicate with each other across the Fediverse, #ActivityPub also defines a “Client-to-Server” API. This #API is mainly designed to allow apps and clients (such as mobile apps) to publish content to a Fediverse server. In the future, this could open up interesting possibilities for #WordPress — for example, allowing WordPress to act as a bridge or proxy, making it easier to bring in and federate content from other tools or platforms."
📢 In it, I discuss how the Fediverse, through ActivityPub, is the antidote against walled gardens, oppressive advertising, data-stealing, surveillance, and enshittification by Big Tech™.
"In addition to the way servers communicate with each other across the Fediverse, #ActivityPub also defines a “Client-to-Server” API. This #API is mainly designed to allow apps and clients (such as mobile apps) to publish content to a Fediverse server. In the future, this could open up interesting possibilities for #WordPress — for example, allowing WordPress to act as a bridge or proxy, making it easier to bring in and federate content from other tools or platforms."
When I made my Fediverse list, I wasn't too focused on how things looked or read, so long as I got my list out as quickly as possible - Not knowing how fast things may happen in the world.
Things in the world are still getting, worse, that has, unfortunately, not changed, but I had time to finally get around improving the repo:
When I made my Fediverse list, I wasn't too focused on how things looked or read, so long as I got my list out as quickly as possible - Not knowing how fast things may happen in the world.
Things in the world are still getting, worse, that has, unfortunately, not changed, but I had time to finally get around improving the repo:
📢 In it, I discuss how the Fediverse, through ActivityPub, is the antidote against walled gardens, oppressive advertising, data-stealing, surveillance, and enshittification by Big Tech™.
📢 In it, I discuss how the Fediverse, through ActivityPub, is the antidote against walled gardens, oppressive advertising, data-stealing, surveillance, and enshittification by Big Tech™.
- @fediforum happened, with a ton of demos, sessions and keynotes - @bonfire gets close to a formal 1.0 release, and is already available for usage - @anewsocial announces Bounce, a tool to migrate your social graph from #atproto to #activitypub - shutdown of a lemmy server provides opportunity for @piefedadmin
The pro-government technology R&D NGO T3 Foundation in Turkey has launched its own social media platform by forking Mastodon without giving any credit. Although it claims to be a decentralized social network in its server description, posts from accounts registered on sosyal.teknofest.app cannot be viewed on other Mastodon servers.
I think the theoretical existence of "reply guys" on #Mastodon has very simple technical explanation.
The existing #activitypub implementation in #Mastodon has critical flaw in displaying only small subset of replies to any given toot (status). This is because only subset of replies is shown: only those existing in already cached federated timeline are shown. This is typical example of state-of-the art primitive algorithm (actually: there is currently no algorithm, where there should be one: not shady and manipulating algorithm, but rather deterministic and transparent one).
And if we don't see all replies (which is true especially on small, self-hosted instances, which cache very limited subset of federated content), than we tend to answer. And because we don't see other like us, we don't know there are many like us explaining the same thing. And poor author of original toot sees it all - and don't understand, why we all repeat more or less the same thing. Why we don't just fav the other replies, like we did on Xitter? Well... because we don't see them! We would need to "open original page" each time we want to reply.
To make #Mastodon really useful tool of public discourse, we would need a chance to see all replies. Of course, we would like to apply our own sort criteria, not be manipulated by algorithm choosing "personalized best replies for us" like on late Xitter - but really, we need chance to see them all. Well, limitations may apply, like "only replies from first hour, only replies with most favs and boosts". But we need a chance to seem them all . Reply spam would become an issue, of course.
I wonder, if upcoming new releases of Mastodon are going to fix this issue... and to be true, it is not an easy engineering problem, as distributed information systems are really a hard problem. We are now merely confederated, we are not really federated.
- @fediforum happened, with a ton of demos, sessions and keynotes - @bonfire gets close to a formal 1.0 release, and is already available for usage - @anewsocial announces Bounce, a tool to migrate your social graph from #atproto to #activitypub - shutdown of a lemmy server provides opportunity for @piefedadmin
Remember when the web was fun? @cwebber does, and she reminded users of that in her keynote speech at last week's FediForum, in which she talked about how the fediverse can't succeed without joy. Here's @ricmac's writeup of the event, which included presentations from @_elena, @quillmatiq, @mike, @michael, @benpate and more.
- @fediforum happened, with a ton of demos, sessions and keynotes - @bonfire gets close to a formal 1.0 release, and is already available for usage - @anewsocial announces Bounce, a tool to migrate your social graph from #atproto to #activitypub - shutdown of a lemmy server provides opportunity for @piefedadmin
- @fediforum happened, with a ton of demos, sessions and keynotes - @bonfire gets close to a formal 1.0 release, and is already available for usage - @anewsocial announces Bounce, a tool to migrate your social graph from #atproto to #activitypub - shutdown of a lemmy server provides opportunity for @piefedadmin
- @fediforum happened, with a ton of demos, sessions and keynotes - @bonfire gets close to a formal 1.0 release, and is already available for usage - @anewsocial announces Bounce, a tool to migrate your social graph from #atproto to #activitypub - shutdown of a lemmy server provides opportunity for @piefedadmin
I borrowed a lot of the concepts I used to implement #django#activitypub toolkit to implement the #typescript local-first client: usage of rdf libraries to process linked data regardless of implementation quirks, first-citizen classes for Actors/Objects/Activities, a handy "Reference" class to work as a container of data that has only URLs instead of documents, etc...
In the process of removing the "server stuff" (database, mostly) I ended up with a small "core" module for typescript.
- @fediforum happened, with a ton of demos, sessions and keynotes - @bonfire gets close to a formal 1.0 release, and is already available for usage - @anewsocial announces Bounce, a tool to migrate your social graph from #atproto to #activitypub - shutdown of a lemmy server provides opportunity for @piefedadmin
Remember when the web was fun? @cwebber does, and she reminded users of that in her keynote speech at last week's FediForum, in which she talked about how the fediverse can't succeed without joy. Here's @ricmac's writeup of the event, which included presentations from @_elena, @quillmatiq, @mike, @michael, @benpate and more.
- @fediforum happened, with a ton of demos, sessions and keynotes - @bonfire gets close to a formal 1.0 release, and is already available for usage - @anewsocial announces Bounce, a tool to migrate your social graph from #atproto to #activitypub - shutdown of a lemmy server provides opportunity for @piefedadmin
- @fediforum happened, with a ton of demos, sessions and keynotes - @bonfire gets close to a formal 1.0 release, and is already available for usage - @anewsocial announces Bounce, a tool to migrate your social graph from #atproto to #activitypub - shutdown of a lemmy server provides opportunity for @piefedadmin
Remember when the web was fun? @cwebber does, and she reminded users of that in her keynote speech at last week's FediForum, in which she talked about how the fediverse can't succeed without joy. Here's @ricmac's writeup of the event, which included presentations from @_elena, @quillmatiq, @mike, @michael, @benpate and more.
Remember when the web was fun? @cwebber does, and she reminded users of that in her keynote speech at last week's FediForum, in which she talked about how the fediverse can't succeed without joy. Here's @ricmac's writeup of the event, which included presentations from @_elena, @quillmatiq, @mike, @michael, @benpate and more.
Remember when the web was fun? @cwebber does, and she reminded users of that in her keynote speech at last week's FediForum, in which she talked about how the fediverse can't succeed without joy. Here's @ricmac's writeup of the event, which included presentations from @_elena, @quillmatiq, @mike, @michael, @benpate and more.
ALT text detailsThis launch, though, feels bigger than most, because ActivityPub is more than a protocol or a fancy feature; it’s a statement that the open web still matters.
Federating Ghost means publishers no longer have to choose between owning their work and reaching an audience. You post once, on your own domain, and it travels everywhere—the network effect without the lock-in.
That's the dream.
I think the theoretical existence of "reply guys" on #Mastodon has very simple technical explanation.
The existing #activitypub implementation in #Mastodon has critical flaw in displaying only small subset of replies to any given toot (status). This is because only subset of replies is shown: only those existing in already cached federated timeline are shown. This is typical example of state-of-the art primitive algorithm (actually: there is currently no algorithm, where there should be one: not shady and manipulating algorithm, but rather deterministic and transparent one).
And if we don't see all replies (which is true especially on small, self-hosted instances, which cache very limited subset of federated content), than we tend to answer. And because we don't see other like us, we don't know there are many like us explaining the same thing. And poor author of original toot sees it all - and don't understand, why we all repeat more or less the same thing. Why we don't just fav the other replies, like we did on Xitter? Well... because we don't see them! We would need to "open original page" each time we want to reply.
To make #Mastodon really useful tool of public discourse, we would need a chance to see all replies. Of course, we would like to apply our own sort criteria, not be manipulated by algorithm choosing "personalized best replies for us" like on late Xitter - but really, we need chance to see them all. Well, limitations may apply, like "only replies from first hour, only replies with most favs and boosts". But we need a chance to seem them all . Reply spam would become an issue, of course.
I wonder, if upcoming new releases of Mastodon are going to fix this issue... and to be true, it is not an easy engineering problem, as distributed information systems are really a hard problem. We are now merely confederated, we are not really federated.
ALT text detailsThis launch, though, feels bigger than most, because ActivityPub is more than a protocol or a fancy feature; it’s a statement that the open web still matters.
Federating Ghost means publishers no longer have to choose between owning their work and reaching an audience. You post once, on your own domain, and it travels everywhere—the network effect without the lock-in.
That's the dream.
💗 While it has a #passionate user base, it remains a #niche platform.
📲 At #FediForum, new apps like #Bounce, #Surf, and #Bandwagon were showcased, demonstrating progress in social graph migration, feed management, and monetisation for creators.
Open science forms the pillar for mankind to invent a better world, and a society worth living in. Or so it should be, if academia weren’t held captive or willing prisoner to commercial interests. Fediverse opens new grazing grounds for #scientists, #engineers, or anyone for that matter, to uncover new #wisdom and #insights collectively.
But we have @bonfire Open Science app, and @scifed as early adopters.
ALT text detailsSnapshot of draft text for delightful-fediverse-experience curated list. It displays the text in the toot as well as the 2 platforms I mentioned.
💗 While it has a #passionate user base, it remains a #niche platform.
📲 At #FediForum, new apps like #Bounce, #Surf, and #Bandwagon were showcased, demonstrating progress in social graph migration, feed management, and monetisation for creators.
Open science forms the pillar for mankind to invent a better world, and a society worth living in. Or so it should be, if academia weren’t held captive or willing prisoner to commercial interests. Fediverse opens new grazing grounds for #scientists, #engineers, or anyone for that matter, to uncover new #wisdom and #insights collectively.
But we have @bonfire Open Science app, and @scifed as early adopters.
ALT text detailsSnapshot of draft text for delightful-fediverse-experience curated list. It displays the text in the toot as well as the 2 platforms I mentioned.
Open science forms the pillar for mankind to invent a better world, and a society worth living in. Or so it should be, if academia weren’t held captive or willing prisoner to commercial interests. Fediverse opens new grazing grounds for #scientists, #engineers, or anyone for that matter, to uncover new #wisdom and #insights collectively.
But we have @bonfire Open Science app, and @scifed as early adopters.
ALT text detailsSnapshot of draft text for delightful-fediverse-experience curated list. It displays the text in the toot as well as the 2 platforms I mentioned.
Social experience is uniquely personal, social networking starts with us. A social web supportive of real people allows us to roam freely, to express ourselves, and be with whom we want to be. From global public square to intimite inter-personal relationships, our fediverse must support whom we actually want to be, in connection with those around us. 💞
Some more draft text of the - thanks to @nlnet support - soon revamped delightful-fediverse-experience curated list, demonstrating how I deliberately step away from strict #TechnicalLanguage.
Not sure if you like the language. Yet feel its good if fluffy and spiky are in balance.
ALT text detailsAn exerpt from the draft text that shows various section descriptions of the new taxonomy..
--
# Personal social networking
Social experience is uniquely personal, social networking starts with us. A social web supportive of real people allows us to roam freely, to express ourselves, and be with whom we want to be. From global public square to intimite inter-personal relationships, our fediverse must support whom we actually want to be, in connection with those around us.
Personal social networking is where 💪 people are in control and free to live their daily life.
## Social profiles
Be free. Be who you want to be. Proudly show your identities. Manage rich, fun, and self-sovereign profiles for every fediverse experience.
## Social verifiable credentials
We all deserve to be recognized for who we are and what we do. Get attribution for our work and acknowledgment for our skills and human traits. Social verifiable credentials as envisioned by Doug Belshaw makes strides towards open recognition of all the splendid individuals that make a fediverse thrive.
And I was immediately reminded of Fedijam, originally started by @houkime using #Itchio, after which I think a total 7 or 8 fun jams were organized on the #fediverse.
Inspired by @dajb I will use 'Social verifiable credentials' as the category for #BadgeFed in the new taxonomy I am creating for delightful-fediverse-apps curated list. Which I am in the process of giving a complete makeover and revitalization. Hope to have it live soon
Inspired by @dajb I will use 'Social verifiable credentials' as the category for #BadgeFed in the new taxonomy I am creating for delightful-fediverse-apps curated list. Which I am in the process of giving a complete makeover and revitalization. Hope to have it live soon
A list of Fedi sites that use NON - US Domain extensions, meaning their domain name extension is outside Us Jurisdiction. I have not verified where all these are hosting.
I shared the full current list as of June 9, 2025, here on the Fediverse, but you can also find the list at the URL, which is hosting on a GIT by Code Berg, located in Germany, Europe.
You can also download the current list (June 9, 2025), that I just shared, by downloading the ZIP file attached.
A list of Fedi sites that use NON - US Domain extensions, meaning their domain name extension is outside Us Jurisdiction. I have not verified where all these are hosting.
I shared the full current list as of June 9, 2025, here on the Fediverse, but you can also find the list at the URL, which is hosting on a GIT by Code Berg, located in Germany, Europe.
You can also download the current list (June 9, 2025), that I just shared, by downloading the ZIP file attached.
🥳 Manyfold v0.112.0 is out, with improvements to ActivityPub federation (remote previews, more notes), a brand new Japanese translation, and a bulk hide option for problems.
This article is published on a website which is powered by BDServer. And I'm trying to make this website support ActivityPub, so you could for example, subscribe to me from your Mastodon account. Yet it is easier said than done.
If you have any experience with ActivityPub, web-development or Python, please consider helping me. We have BDServ...
🥳 Manyfold v0.112.0 is out, with improvements to ActivityPub federation (remote previews, more notes), a brand new Japanese translation, and a bulk hide option for problems.
🥳 Manyfold v0.112.0 is out, with improvements to ActivityPub federation (remote previews, more notes), a brand new Japanese translation, and a bulk hide option for problems.
🥳 Manyfold v0.112.0 is out, with improvements to ActivityPub federation (remote previews, more notes), a brand new Japanese translation, and a bulk hide option for problems.
This article is published on a website which is powered by BDServer. And I'm trying to make this website support ActivityPub, so you could for example, subscribe to me from your Mastodon account. Yet it is easier said than done.
If you have any experience with ActivityPub, web-development or Python, please consider helping me. We have BDServ...
This is an ActivityPub library used internally in Mitra and in other my projects.
Unlike some other ActivityPub libraries, this library is low-level. It doesn't restrict what databases or frameworks could be used, and doesn't care about object types or properties. There are only URIs, keys, signatures, JSON documents and HTTP requests. It also contains primitives for building nomadic applications (FEP-ef61).
The license is AGPL-3, but I might consider changing it to a more permissive one.
Btw #BadgeFed, I bumped into https://activitybadges.org and even though it hasn't been updated in a while, it might be interesting if you hadn't seen it already.
This article is published on a website which is powered by BDServer. And I'm trying to make this website support ActivityPub, so you could for example, subscribe to me from your Mastodon account. Yet it is easier said than done.
If you have any experience with ActivityPub, web-development or Python, please consider helping me. We have BDServ...
This is an ActivityPub library used internally in Mitra and in other my projects.
Unlike some other ActivityPub libraries, this library is low-level. It doesn't restrict what databases or frameworks could be used, and doesn't care about object types or properties. There are only URIs, keys, signatures, JSON documents and HTTP requests. It also contains primitives for building nomadic applications (FEP-ef61).
The license is AGPL-3, but I might consider changing it to a more permissive one.
Hello waffle! Been escaping from the dumpster fire that is Big Social for a while now, but only to find that the two main alternatives are not on talking terms with each other, due to technical differences which sucks. I hope wafrn will deliver the ease of moving between ActivityPub and ATProto. Having accounts on both is not ideal.
I'm still wrapping my head around it, a bit woozy from the Millennial tumblr chaotic energy.
Here's some galettes.
This article is published on a website which is powered by BDServer. And I'm trying to make this website support ActivityPub, so you could for example, subscribe to me from your Mastodon account. Yet it is easier said than done.
If you have any experience with ActivityPub, web-development or Python, please consider helping me. We have BDServ...
This is an ActivityPub library used internally in Mitra and in other my projects.
Unlike some other ActivityPub libraries, this library is low-level. It doesn't restrict what databases or frameworks could be used, and doesn't care about object types or properties. There are only URIs, keys, signatures, JSON documents and HTTP requests. It also contains primitives for building nomadic applications (FEP-ef61).
The license is AGPL-3, but I might consider changing it to a more permissive one.
This is an ActivityPub library used internally in Mitra and in other my projects.
Unlike some other ActivityPub libraries, this library is low-level. It doesn't restrict what databases or frameworks could be used, and doesn't care about object types or properties. There are only URIs, keys, signatures, JSON documents and HTTP requests. It also contains primitives for building nomadic applications (FEP-ef61).
The license is AGPL-3, but I might consider changing it to a more permissive one.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
@WordPress have created the #Fediverse files, a serie of videos about the Fediverse and ActivityPub, hosted by @docpop. It's really refreshing and you'll probably learn a thing or two!
ALT text detailsScreenshot of the ActivityPub plugin onboarding screen in WordPress. The page welcomes users to the Fediverse and displays a progress circle showing step 2 of 6. Completed steps include 'Plugin installed' and 'Check your site’s health.' Remaining steps are: 'New to the Fediverse? Start Here' with a 'View intro' button, 'Select how you want to share' with a 'Choose mode' button, 'Set up your public profile' with an 'Edit profile' button, and 'Learn more about Fediverse features' with an 'Explore features' button.
@WordPress have created the #Fediverse files, a serie of videos about the Fediverse and ActivityPub, hosted by @docpop. It's really refreshing and you'll probably learn a thing or two!
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
In Episode 642 of Do the Woo, host Matthias Pfefferle brings us another Open Web Conversations and dives into the world of decentralized social networks and the open web, specifically focusing on the Fediverse, with guest André Menrath.
André shares his unconventional journey into software development, driven by his passion for events and democracy, and his vision for a federated future. They explore the challenges and opportunities in integrating WordPress with the Fediverse, discussing André's innovative plugins bridging WordPress events with ActivityPub.
The conversation sheds light on the potential for WordPress to become a dominant platform in the Fediverse, hosting diverse content types while maintaining an open and interconnected web. Join them as they navigate the technical and social landscape of creating a truly decentralized internet.
[…]
ALT text detailsBring Federated Events to Your WordPress Site with André Menrath
Is anyone running their blog on a static or semi-static stack like Hugo, VitePress, etc.?
If so, is there an easy way to add an ActivityPub-based comment system, maybe some share buttons, and also republish content to the Fediverse? I'm not looking for ActivityPub-native blogging platforms, more interested in adding ActivityPub support in a mostly client-side way.
Is anyone running their blog on a static or semi-static stack like Hugo, VitePress, etc.?
If so, is there an easy way to add an ActivityPub-based comment system, maybe some share buttons, and also republish content to the Fediverse? I'm not looking for ActivityPub-native blogging platforms, more interested in adding ActivityPub support in a mostly client-side way.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
We've turned on ActivityPub for Shellie's website :)
That means you can follow Shellie at @shellie and each time she updates the blog with a new recipe, you should see that pop into your feed.
I had hoped the plugin would make all her old recipes live, but that doesn't happen. Unless, you punch the URL into a search box for Mastodon. In which case it makes a new toot, but backdated, and I can retoot it :) #ShellieMakesItBetter#IronChefShellie#FoodBlogging#ActivityPub
ALT text detailsThis is the new home for Shellie on the Fediverse.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
I've been a #Flickr Pro user for a long-time, but decided not to renew my subscription as the platform seems to have stopped evolving and I no longer find value in paying for the service. The WebUI is outdated, the mobile Android app sucks.
I wonder if Flickr could become more attractive again if they would support #ActivityPub and became part of the #Fediverse. Maybe as an alternative to #Pixelfed? Or are there any clients that could use Flickr as a storage backend for pictures?
We've turned on ActivityPub for Shellie's website :)
That means you can follow Shellie at @shellie and each time she updates the blog with a new recipe, you should see that pop into your feed.
I had hoped the plugin would make all her old recipes live, but that doesn't happen. Unless, you punch the URL into a search box for Mastodon. In which case it makes a new toot, but backdated, and I can retoot it :) #ShellieMakesItBetter#IronChefShellie#FoodBlogging#ActivityPub
ALT text detailsThis is the new home for Shellie on the Fediverse.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
Ω🪬Ω #FediAlgo, the customizable timeline algorithm / filtering system for your Mastodon feed, now has a "TOTAL CHAOS" preset for when you're really feeling like mixing up your timeline in addition to a way to weight toots based on the author's follower count, highlighting of hashtags based on how much you use or interact with them, and a bunch of other fund stuff.
Ω🪬Ω #FediAlgo, the customizable timeline algorithm / filtering system for your Mastodon feed, now has a "TOTAL CHAOS" preset for when you're really feeling like mixing up your timeline in addition to a way to weight toots based on the author's follower count, highlighting of hashtags based on how much you use or interact with them, and a bunch of other fund stuff.
Ω🪬Ω #FediAlgo, the customizable timeline algorithm / filtering system for your Mastodon feed, now has a "TOTAL CHAOS" preset for when you're really feeling like mixing up your timeline in addition to a way to weight toots based on the author's follower count, highlighting of hashtags based on how much you use or interact with them, and a bunch of other fund stuff.
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
In Mastodon flavor ActivityPub, the webfinger's subject decides a user's displayed handle. The URLs used as IDs or the location of the "self" endpoint don't have to match the user at all.
So then, what if webfingers resolved to DID URLs instead?
❤️🔥 CHAOS! ❤️🔥 #atproto#atdev#activitypub
ALT text detailsIn my code I have my activitypub endpoints that take a user handle and resolve things. What if we used DID's instead?
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
🔥 Bonfire Social 1.0 release candidate has landed!
Curious about what the fediverse could look like with real community control?
Try out features like custom feeds, nested discussions, shared profiles, circles, and boundary-based permissions — then let us know what breaks or needs improvement.
We are in the middle of the #FediForum speed demo track.
A New Social just announced Bounce, the first-ever migration tool of accounts between #AtProto and #ActivityPub. You can keep your followers across networks!
We are in the middle of the #FediForum speed demo track.
A New Social just announced Bounce, the first-ever migration tool of accounts between #AtProto and #ActivityPub. You can keep your followers across networks!
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
This is a chance to poke at the process, challenge assumptions, and have an open conversation. Bring your curiosity, hard questions, and ideas about co-design, funding, burnout, moderation, and the messy realities of open-source work.
Let’s dig into how fediverse apps get built, maintained, and shaped by their communities.
This is a chance to poke at the process, challenge assumptions, and have an open conversation. Bring your curiosity, hard questions, and ideas about co-design, funding, burnout, moderation, and the messy realities of open-source work.
Let’s dig into how fediverse apps get built, maintained, and shaped by their communities.
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
Exciting news for the #Hollo project! We're thrilled to announce that Emelia Smith (@thisismissem) has joined as a co-maintainer alongside Hong Minhee (@hongminhee).
Emelia brings extensive experience in the #fediverse ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across #ActivityPub platforms.
Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.
This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀
So, if you wondered why that random friend or family member, tried Mastodon, but that week felts drawn to use Facebook more, that is why. They were targeted.
If at any time you shared a link back to any of your personal accounts, anywhere -- Meta knows you have an account.
That includes competing social media platforms, such as the Fediverse.
The value in this is both market resource and further marketing, for example, if you talked about watching Netflix, expect Meta to recommend, HBO Max. And if Meta notices you're using a known competing app or platform, Meta's app will increase the notification to draw you back to Meta.
If at any time you shared a link back to any of your personal accounts, anywhere -- Meta knows you have an account.
That includes competing social media platforms, such as the Fediverse.
The value in this is both market resource and further marketing, for example, if you talked about watching Netflix, expect Meta to recommend, HBO Max. And if Meta notices you're using a known competing app or platform, Meta's app will increase the notification to draw you back to Meta.
So, if you wondered why that random friend or family member, tried Mastodon, but that week felts drawn to use Facebook more, that is why. They were targeted.
If at any time you shared a link back to any of your personal accounts, anywhere -- Meta knows you have an account.
That includes competing social media platforms, such as the Fediverse.
The value in this is both market resource and further marketing, for example, if you talked about watching Netflix, expect Meta to recommend, HBO Max. And if Meta notices you're using a known competing app or platform, Meta's app will increase the notification to draw you back to Meta.
If at any time you shared a link back to any of your personal accounts, anywhere -- Meta knows you have an account.
That includes competing social media platforms, such as the Fediverse.
The value in this is both market resource and further marketing, for example, if you talked about watching Netflix, expect Meta to recommend, HBO Max. And if Meta notices you're using a known competing app or platform, Meta's app will increase the notification to draw you back to Meta.
The idea is: Use *any* resource described as RDF (e.g. from #Wikidata or an #ActivityPub action), link a #Jinja template to it or its rdf:type in your own set of statements, and there you got your visualisation!
Based on #TaganakNet, the #Rust#RDF development kit by @codecraft and me. We are collecting real-world examples at a good rate!
ALT text detailsScreenshot of a Turtle document; see linked code in post for text version.
ALT text detailsA quite basic web page with heading "Ninja Turtles", followed by four cards with names and depictions of the four Ninja Turtles Leonardo, Raphael, Donatello and Michelangelo.
The idea is: Use *any* resource described as RDF (e.g. from #Wikidata or an #ActivityPub action), link a #Jinja template to it or its rdf:type in your own set of statements, and there you got your visualisation!
Based on #TaganakNet, the #Rust#RDF development kit by @codecraft and me. We are collecting real-world examples at a good rate!
ALT text detailsScreenshot of a Turtle document; see linked code in post for text version.
ALT text detailsA quite basic web page with heading "Ninja Turtles", followed by four cards with names and depictions of the four Ninja Turtles Leonardo, Raphael, Donatello and Michelangelo.
Since it is more related to adoption and evolution of the commons-based social web in general, I brought the #ActivityPub#Fediverse ⚒️ Golden Hammer discussion to the Social coding commons forum.
This relates to the Fediverse Vision wiki and discussion started by @helge and the proposal to start a fellowship of people that focus on fedi evolution beyond the nitty-gritty implementation details that are commonly discussed (and that lead to protocol decay and tech debt).
A quiet week as the hype announcements are waiting for this week's @fediforum . You can catch me on Thursday on Fediforum with a session on whats new on the open social web!
In other news: - A @peertube AMA on Lemmy, and the first milestone of their fundraising for their app reached - The @swf publishes #activitypub Web Components
A quiet week as the hype announcements are waiting for this week's @fediforum . You can catch me on Thursday on Fediforum with a session on whats new on the open social web!
In other news: - A @peertube AMA on Lemmy, and the first milestone of their fundraising for their app reached - The @swf publishes #activitypub Web Components
#ActivityPub trick question. If a C2S client actor identified by “http://bar.example/actor” posts {“id”: “https://foo.example/something”} to its *outbox* server endpoint, is that valid? Why or why not? If the answer is “it depends”, it depends on what?
#ActivityPub trick question. If a C2S client actor identified by “http://bar.example/actor” posts {“id”: “https://foo.example/something”} to its *outbox* server endpoint, is that valid? Why or why not? If the answer is “it depends”, it depends on what?
#ActivityPub trick question. If a C2S client actor identified by “http://bar.example/actor” posts {“id”: “https://foo.example/something”} to its *outbox* server endpoint, is that valid? Why or why not? If the answer is “it depends”, it depends on what?
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare#Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare#Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare#Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare#Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare#Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare#Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
New problems emerge the more I try to use it. Direct AP<->AP works fine. Bridged stuff is inconsistent. Likes, boosts, etc don't go through. Follows don't show even if there's a bridged pair for the following account.
I don't fault the people working on Bridgy but I do know this would be easier to get right if follow relationships were simple data any authenticated app could read.
I haven't heard a positive account of developing anything moderately complex for AP. By comparison, all the AT dev accounts are positive, usually noting how easy it is to work with everything since everything is "on protocol" (the term of art for storing data in lexicons on your PDS) rather than dependent on negotiating implementation differences between the dominant platform and everything else.
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare#Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare#Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
New problems emerge the more I try to use it. Direct AP<->AP works fine. Bridged stuff is inconsistent. Likes, boosts, etc don't go through. Follows don't show even if there's a bridged pair for the following account.
I don't fault the people working on Bridgy but I do know this would be easier to get right if follow relationships were simple data any authenticated app could read.
I haven't heard a positive account of developing anything moderately complex for AP. By comparison, all the AT dev accounts are positive, usually noting how easy it is to work with everything since everything is "on protocol" (the term of art for storing data in lexicons on your PDS) rather than dependent on negotiating implementation differences between the dominant platform and everything else.
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare#Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare#Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare#Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare#Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare#Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare#Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
Ω🪬Ω The new version of #Fedialgo is much, much faster at loading and reordering the timeline. Also has fancy gradients to show you which hashtags in your feed are the ones trending the most and which ones you post about the most. Also a bunch of other tweaks and improvements.
Yet the curated list is only for open source resources and without license the script is technically not. Would you be open to add a FOSS license to it, perhaps?
Reminder: AS/AP-based suffers from #BallOfMud based ad-hoc expansion unless we find common practices and stick to them. Collaboration across a commons is essential here. Just coding your app with custom #ActivityPub protocol extension is contributing to #ProtocolDecay and increasing complexity to facilitate broad #interoperability.
The #FEP process and #SocialCG are where collective effort and proactive participation can improve #fedi for all. We need a bottom up standardization process.
ALT text detailsScene from Indiana Jones Raiders of the Lost Ark, where Indy is fleeing a tunnel vision with a huge boulder in pursuit. The boulder is named "Protocol Decay" and Indy is labeled "Fediverse".
In Mastodon flavor ActivityPub, the webfinger's subject decides a user's displayed handle. The URLs used as IDs or the location of the "self" endpoint don't have to match the user at all.
So then, what if webfingers resolved to DID URLs instead?
❤️🔥 CHAOS! ❤️🔥 #atproto#atdev#activitypub
ALT text detailsIn my code I have my activitypub endpoints that take a user handle and resolve things. What if we used DID's instead?
"Stonenet is a #p2p (social) publish-subscribe network, also known as a decentralized social media platform. It is designed to protect free speech, and resist censorship. Everyone moderates their own home feed, and content is only distributed by those peers that have consented to do so, by subscribing to someone and thereby explicitly supporting their content"
Ω🪬Ω The new version of #Fedialgo is much, much faster at loading and reordering the timeline. Also has fancy gradients to show you which hashtags in your feed are the ones trending the most and which ones you post about the most. Also a bunch of other tweaks and improvements.
Trying Ghost's AP implementation just emphasizes what I don't like about AP-in-practice. Between that and all the bridge profiles, there are 4 new profiles, each with their own copy of the data to maintain.
With AT, it's just the one account across all platforms with all the data stored on my PDS.
Worse, to get any notice to posts appearing on them, I have to boost from my existing accounts on each network. That's a lot of trouble! With AT, they would just pull it from the relay, which pulls from my PDS. Or go directly to the PDS in some circumstances.
AP could probably be better in practice, but everyone is required to make it work with Mastodon or essentially be incompatible since it has most of the network on a few servers with a standard ignoring implementation.
Ω🪬Ω The new version of #Fedialgo is much, much faster at loading and reordering the timeline. Also has fancy gradients to show you which hashtags in your feed are the ones trending the most and which ones you post about the most. Also a bunch of other tweaks and improvements.
🎉 #Cloudflare#Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
Ω🪬Ω The new version of #Fedialgo is much, much faster at loading and reordering the timeline. Also has fancy gradients to show you which hashtags in your feed are the ones trending the most and which ones you post about the most. Also a bunch of other tweaks and improvements.
Trying Ghost's AP implementation just emphasizes what I don't like about AP-in-practice. Between that and all the bridge profiles, there are 4 new profiles, each with their own copy of the data to maintain.
With AT, it's just the one account across all platforms with all the data stored on my PDS.
Worse, to get any notice to posts appearing on them, I have to boost from my existing accounts on each network. That's a lot of trouble! With AT, they would just pull it from the relay, which pulls from my PDS. Or go directly to the PDS in some circumstances.
AP could probably be better in practice, but everyone is required to make it work with Mastodon or essentially be incompatible since it has most of the network on a few servers with a standard ignoring implementation.
🎉 #Cloudflare#Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
🎉 #Cloudflare#Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
🎉 #Cloudflare#Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
🎉 #Cloudflare#Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
Salut le Fediverse, je cherche à autohéberger (sur #YunoHost) un serveur #ActivityPub pour microblogger. Pas trop envie d'installer #Mastodon pour 2,3 comptes qui ne feront que publier automatiquement les actus des projets. Il y a #GoToSocial mais il est en version nowasm (Et ça me semble risqué). Est-ce qu'il y a des utilisateur⋅ices de #Stream ou #Forte qui ont un retour d'expérience à exprimer ? Et dans l'idéal, moins il consomme de ressources, plus ça me convient =)
Il y a aussi #MissKey et #Pleroma (mais je n'ai pas besoin d'une interface graphique qui consomme de la ressource pour rien...)
🎉 #Cloudflare#Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
🎉 #Cloudflare#Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
🎉 #Cloudflare#Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
🎉 #Cloudflare#Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
🎉 #Cloudflare#Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
Had a huge backlog and I am making lotsa updates now to process it. Earlier did too to apps and clients fedi delightful lists, and the root list, now hosted at https://delightful.coding.social
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
Ha, you can run an ActivityPub server on your android phone through termux
ALT text detailsimage/jpeg
Screenshot of a mastodon user page from activitypub.academy
Page shows a user named Tom Casavant (Android)
@tomcasavant@rnyyg-86-48-9-153.a.free.pin...
1 post 22s ago:
Hello from my samsung s22
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
Hello waffle! Been escaping from the dumpster fire that is Big Social for a while now, but only to find that the two main alternatives are not on talking terms with each other, due to technical differences which sucks. I hope wafrn will deliver the ease of moving between ActivityPub and ATProto. Having accounts on both is not ideal.
I'm still wrapping my head around it, a bit woozy from the Millennial tumblr chaotic energy.
Here's some galettes.
Ha, you can run an ActivityPub server on your android phone through termux
ALT text detailsimage/jpeg
Screenshot of a mastodon user page from activitypub.academy
Page shows a user named Tom Casavant (Android)
@tomcasavant@rnyyg-86-48-9-153.a.free.pin...
1 post 22s ago:
Hello from my samsung s22
Ha, you can run an ActivityPub server on your android phone through termux
ALT text detailsimage/jpeg
Screenshot of a mastodon user page from activitypub.academy
Page shows a user named Tom Casavant (Android)
@tomcasavant@rnyyg-86-48-9-153.a.free.pin...
1 post 22s ago:
Hello from my samsung s22
Ha, you can run an ActivityPub server on your android phone through termux
ALT text detailsimage/jpeg
Screenshot of a mastodon user page from activitypub.academy
Page shows a user named Tom Casavant (Android)
@tomcasavant@rnyyg-86-48-9-153.a.free.pin...
1 post 22s ago:
Hello from my samsung s22
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
Ha, you can run an ActivityPub server on your android phone through termux
ALT text detailsimage/jpeg
Screenshot of a mastodon user page from activitypub.academy
Page shows a user named Tom Casavant (Android)
@tomcasavant@rnyyg-86-48-9-153.a.free.pin...
1 post 22s ago:
Hello from my samsung s22
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
Even though it hasn't been updated for a while I want to add idkfa to delightful-activitypub-development, given the interesting approach you experiment with. Yet there is no license AFAIK, and the curated list is FOSS-only. Would you consider adding one?
I gave some good updates to the curated fediverse clients list. So many new fresh and cool web, desktop and mobile #UI clients to choose from to access your favorite #ActivityPub web services.
I agree. Yet the fediverse-related delightful lists serve a different purpose: to inform developers of all the things that are out there, give overview of the open #ActivityPub ecosystem, so they can be inspired by prior art or choose where to contribute and help improve the fedi as a whole.
I gave some good updates to the curated fediverse clients list. So many new fresh and cool web, desktop and mobile #UI clients to choose from to access your favorite #ActivityPub web services.
I will be giving an attendee badge to everyone to stop and say hi, so, if you have not registered for this virtual conference on June 5-7 go to https://fediforum.org/ and do it if you can!
See you there!
ALT text detailsThe image showcases the BadgeFed website, a platform for creating, issuing, and verifying digital badges. It begins with a purple banner featuring the text "Empower Your Community with Digital Badges" and a call-to-action button labeled "Get Started." Below, three sections highlight the platform's features: "Secure & Verifiable," "Decentralized," and "Community Focused," each accompanied by relevant icons and descriptions.
I will be giving an attendee badge to everyone to stop and say hi, so, if you have not registered for this virtual conference on June 5-7 go to https://fediforum.org/ and do it if you can!
See you there!
ALT text detailsThe image showcases the BadgeFed website, a platform for creating, issuing, and verifying digital badges. It begins with a purple banner featuring the text "Empower Your Community with Digital Badges" and a call-to-action button labeled "Get Started." Below, three sections highlight the platform's features: "Secure & Verifiable," "Decentralized," and "Community Focused," each accompanied by relevant icons and descriptions.
ALT text detailsThe image features a purple background with a prominent orange and brown geometric logo in the center, resembling a stylized "W" or "V" shape. In the top left corner, there is a white speech bubble with the text "#UNCONFERENCED ... and unbothered" in purple. In the top right corner, another white speech bubble contains the text "FediForum 2025" in white. At the bottom of the image, in white text, it reads "I Showed Up • I Shared • I #BadgeFed - June 2025." The overall design is simple and modern, with a focus on the central logo and the text elements.
ALT text detailsThe image features a purple background with a prominent orange and brown geometric logo in the center, resembling a stylized "W" or "V" shape. In the top left corner, there is a white speech bubble with the text "#UNCONFERENCED ... and unbothered" in purple. In the top right corner, another white speech bubble contains the text "FediForum 2025" in white. At the bottom of the image, in white text, it reads "I Showed Up • I Shared • I #BadgeFed - June 2025." The overall design is simple and modern, with a focus on the central logo and the text elements.
Seit Anfang Mai bin ich Fellow bei einem wegweisenden Programm von Media Lab Bayern, SWR X Lab und Mastodon:
Reinvent Social Platforms!
Gemeinsam wollen wir dezentrale, nachhaltige #SocialMedia stärken. Mit #Fediverse und #ActivityPub experimentieren. Medienmenschen an Bord holen. Innovative, attraktive Lösungen für journalistische Herausforderungen finden.
Falls ihr auf diese Themen auch Bock habt: Meldet euch sehr gerne bei mir. Ich habe viele Fragen. Und Ideen.
Seit Anfang Mai bin ich Fellow bei einem wegweisenden Programm von Media Lab Bayern, SWR X Lab und Mastodon:
Reinvent Social Platforms!
Gemeinsam wollen wir dezentrale, nachhaltige #SocialMedia stärken. Mit #Fediverse und #ActivityPub experimentieren. Medienmenschen an Bord holen. Innovative, attraktive Lösungen für journalistische Herausforderungen finden.
Falls ihr auf diese Themen auch Bock habt: Meldet euch sehr gerne bei mir. Ich habe viele Fragen. Und Ideen.
We're planning to reorganize our #GitHub labels to better reflect #Fedify's project structure! 🏷️
Currently using GitHub's default labels, but we want something more tailored to our needs—like component-specific labels (vocab, federation, actor, etc.), runtime tags (Deno/Node/Bun), and #ActivityPub compatibility tracking.
The proposal includes hierarchical labeling with categories like:
type/ for bug, feature, documentation
component/ for different parts of Fedify
activitypub/ for interop issues with Mastodon, Misskey, etc.
We'd love your thoughts! What labels would be most helpful for contributors and maintainers?
We're planning to reorganize our #GitHub labels to better reflect #Fedify's project structure! 🏷️
Currently using GitHub's default labels, but we want something more tailored to our needs—like component-specific labels (vocab, federation, actor, etc.), runtime tags (Deno/Node/Bun), and #ActivityPub compatibility tracking.
The proposal includes hierarchical labeling with categories like:
type/ for bug, feature, documentation
component/ for different parts of Fedify
activitypub/ for interop issues with Mastodon, Misskey, etc.
We'd love your thoughts! What labels would be most helpful for contributors and maintainers?
We're planning to reorganize our #GitHub labels to better reflect #Fedify's project structure! 🏷️
Currently using GitHub's default labels, but we want something more tailored to our needs—like component-specific labels (vocab, federation, actor, etc.), runtime tags (Deno/Node/Bun), and #ActivityPub compatibility tracking.
The proposal includes hierarchical labeling with categories like:
type/ for bug, feature, documentation
component/ for different parts of Fedify
activitypub/ for interop issues with Mastodon, Misskey, etc.
We'd love your thoughts! What labels would be most helpful for contributors and maintainers?
We're planning to reorganize our #GitHub labels to better reflect #Fedify's project structure! 🏷️
Currently using GitHub's default labels, but we want something more tailored to our needs—like component-specific labels (vocab, federation, actor, etc.), runtime tags (Deno/Node/Bun), and #ActivityPub compatibility tracking.
The proposal includes hierarchical labeling with categories like:
type/ for bug, feature, documentation
component/ for different parts of Fedify
activitypub/ for interop issues with Mastodon, Misskey, etc.
We'd love your thoughts! What labels would be most helpful for contributors and maintainers?
I gave some good updates to the curated fediverse clients list. So many new fresh and cool web, desktop and mobile #UI clients to choose from to access your favorite #ActivityPub web services.
That's great. Intrinsic motivation is what works best in the commons. Nice project! I have it queued up for addition to the #ActivityPub delightful lists, in particular this one:
That's great. Intrinsic motivation is what works best in the commons. Nice project! I have it queued up for addition to the #ActivityPub delightful lists, in particular this one:
I gave some good updates to the curated fediverse clients list. So many new fresh and cool web, desktop and mobile #UI clients to choose from to access your favorite #ActivityPub web services.
I gave some good updates to the curated fediverse clients list. So many new fresh and cool web, desktop and mobile #UI clients to choose from to access your favorite #ActivityPub web services.
I gave some good updates to the curated fediverse clients list. So many new fresh and cool web, desktop and mobile #UI clients to choose from to access your favorite #ActivityPub web services.
I gave some good updates to the curated fediverse clients list. So many new fresh and cool web, desktop and mobile #UI clients to choose from to access your favorite #ActivityPub web services.
When installing the patched versions of Misskey (Pull Request available) and Sharkey (with changes already applied) on a Fedora 42 environment, you may encounter the following errors:
error: ‘uint8_t’ was not declared in this scopeerror: ‘state’ was not declared in this scope
These issues seem to stem from the version of GCC being used (Reference). Below, I will outline how to resolve these problems on Fedora 42.
Step 1: Install Dependencies
First, as indicated in the wiki, install the necessary dependencies:
Using the default GCC bundled with Fedora may lead to failed installations when running pnpm install (as of May 27, 2025). To avoid this issue, we need to compile and use a other version of GCC/G++.
Start by downloading the GCC source code using wget, then extract it and navigate to the source directory:
With these adjustments, you should be able to install Misskey and Sharkey without any issues. Enjoy Fediverse!
*I have used LLM to some extent to modify the text to make it more natural. I checked to some extent before post, but please let us know if there are any unnatural parts.
When installing the patched versions of Misskey (Pull Request available) and Sharkey (with changes already applied) on a Fedora 42 environment, you may encounter the following errors:
error: ‘uint8_t’ was not declared in this scopeerror: ‘state’ was not declared in this scope
These issues seem to stem from the version of GCC being used (Reference). Below, I will outline how to resolve these problems on Fedora 42.
Step 1: Install Dependencies
First, as indicated in the wiki, install the necessary dependencies:
Using the default GCC bundled with Fedora may lead to failed installations when running pnpm install (as of May 27, 2025). To avoid this issue, we need to compile and use a other version of GCC/G++.
Start by downloading the GCC source code using wget, then extract it and navigate to the source directory:
With these adjustments, you should be able to install Misskey and Sharkey without any issues. Enjoy Fediverse!
*I have used LLM to some extent to modify the text to make it more natural. I checked to some extent before post, but please let us know if there are any unnatural parts.
When installing the patched versions of Misskey (Pull Request available) and Sharkey (with changes already applied) on a Fedora 42 environment, you may encounter the following errors:
error: ‘uint8_t’ was not declared in this scopeerror: ‘state’ was not declared in this scope
These issues seem to stem from the version of GCC being used (Reference). Below, I will outline how to resolve these problems on Fedora 42.
Step 1: Install Dependencies
First, as indicated in the wiki, install the necessary dependencies:
Using the default GCC bundled with Fedora may lead to failed installations when running pnpm install (as of May 27, 2025). To avoid this issue, we need to compile and use a other version of GCC/G++.
Start by downloading the GCC source code using wget, then extract it and navigate to the source directory:
With these adjustments, you should be able to install Misskey and Sharkey without any issues. Enjoy Fediverse!
*I have used LLM to some extent to modify the text to make it more natural. I checked to some extent before post, but please let us know if there are any unnatural parts.
When installing the patched versions of Misskey (Pull Request available) and Sharkey (with changes already applied) on a Fedora 42 environment, you may encounter the following errors:
error: ‘uint8_t’ was not declared in this scopeerror: ‘state’ was not declared in this scope
These issues seem to stem from the version of GCC being used (Reference). Below, I will outline how to resolve these problems on Fedora 42.
Step 1: Install Dependencies
First, as indicated in the wiki, install the necessary dependencies:
Using the default GCC bundled with Fedora may lead to failed installations when running pnpm install (as of May 27, 2025). To avoid this issue, we need to compile and use a other version of GCC/G++.
Start by downloading the GCC source code using wget, then extract it and navigate to the source directory:
With these adjustments, you should be able to install Misskey and Sharkey without any issues. Enjoy Fediverse!
*I have used LLM to some extent to modify the text to make it more natural. I checked to some extent before post, but please let us know if there are any unnatural parts.
When installing the patched versions of Misskey (Pull Request available) and Sharkey (with changes already applied) on a Fedora 42 environment, you may encounter the following errors:
error: ‘uint8_t’ was not declared in this scopeerror: ‘state’ was not declared in this scope
These issues seem to stem from the version of GCC being used (Reference). Below, I will outline how to resolve these problems on Fedora 42.
Step 1: Install Dependencies
First, as indicated in the wiki, install the necessary dependencies:
Using the default GCC bundled with Fedora may lead to failed installations when running pnpm install (as of May 27, 2025). To avoid this issue, we need to compile and use a other version of GCC/G++.
Start by downloading the GCC source code using wget, then extract it and navigate to the source directory:
With these adjustments, you should be able to install Misskey and Sharkey without any issues. Enjoy Fediverse!
*I have used LLM to some extent to modify the text to make it more natural. I checked to some extent before post, but please let us know if there are any unnatural parts.
When installing the patched versions of Misskey (Pull Request available) and Sharkey (with changes already applied) on a Fedora 42 environment, you may encounter the following errors:
error: ‘uint8_t’ was not declared in this scopeerror: ‘state’ was not declared in this scope
These issues seem to stem from the version of GCC being used (Reference). Below, I will outline how to resolve these problems on Fedora 42.
Step 1: Install Dependencies
First, as indicated in the wiki, install the necessary dependencies:
Using the default GCC bundled with Fedora may lead to failed installations when running pnpm install (as of May 27, 2025). To avoid this issue, we need to compile and use a other version of GCC/G++.
Start by downloading the GCC source code using wget, then extract it and navigate to the source directory:
With these adjustments, you should be able to install Misskey and Sharkey without any issues. Enjoy Fediverse!
*I have used LLM to some extent to modify the text to make it more natural. I checked to some extent before post, but please let us know if there are any unnatural parts.
It's great when more platforms enter the #Fediverse, esp a project like OSSN.
Esp awesome since OSSN is installable in so many PHP hosting control panels, like CPANEL's Softaculous. It's like it is opening the Fediverse to a entirely new class of self-hosters.
It's great when more platforms enter the #Fediverse, esp a project like OSSN.
Esp awesome since OSSN is installable in so many PHP hosting control panels, like CPANEL's Softaculous. It's like it is opening the Fediverse to a entirely new class of self-hosters.
ALT text detailsThe image displays a list titled "TOP ACTIVE SERVERS" against a dark background. The list is organized in a vertical format with each server name followed by its corresponding number of active users. The servers are listed in descending order of user count. The first server, "mastodon.social," has 708,592 active users, followed by "newsmast.community" with 240,301 users, "troet.cafe" with 161,996 users, "mstdn.social" with 156,552 users, "flipboard.com" with 155,969 users, "chaos.social" with 124,363 users, "pubeurope.com" with 108,015 users, and "norden.social" with 91,883 users. Each server name is preceded by a dark blue dot, and the numbers are in a lighter blue color. The text is white, providing a clear contrast against the dark background.
ALT text detailsThe image displays a list titled "TOP ACTIVE SERVERS" against a dark background. The list is organized in a vertical format with each server name followed by its corresponding number of active users. The servers are listed in descending order of user count. The first server, "mastodon.social," has 708,592 active users, followed by "newsmast.community" with 240,301 users, "troet.cafe" with 161,996 users, "mstdn.social" with 156,552 users, "flipboard.com" with 155,969 users, "chaos.social" with 124,363 users, "pubeurope.com" with 108,015 users, and "norden.social" with 91,883 users. Each server name is preceded by a dark blue dot, and the numbers are in a lighter blue color. The text is white, providing a clear contrast against the dark background.
Ω🪬Ω You can now send replies to Toots as well as expand threads directly within the #FediAlgo demo app, no need to click through to the regular Mastodon web interface.
While #Fedify's #Vocabulary API provides comprehensive support for #ActivityPub and major vendor extensions, its code-generation approach makes runtime extensions challenging. However, the project welcomes contributions to expand the supported types and properties.
Fedify accepts vocabulary contributions when they meet any of these criteria:
Documented in FEP (Fediverse Enhancement Proposals) or equivalent specification
Already adopted by widely-used #fediverse implementations like Mastodon or Pleroma
Contributing new vocabulary is straightforward. The vocabulary definitions live in YAML files within the fedify/vocab/ directory. To add a new type, create a new .yaml file. To add properties to existing types, extend the properties section in the relevant .yaml file.
This approach ensures Fedify's vocabulary coverage grows with the fediverse ecosystem while maintaining type safety and comprehensive documentation. If you're working with custom ActivityPub extensions, consider contributing them upstream to benefit the entire community.
While #Fedify's #Vocabulary API provides comprehensive support for #ActivityPub and major vendor extensions, its code-generation approach makes runtime extensions challenging. However, the project welcomes contributions to expand the supported types and properties.
Fedify accepts vocabulary contributions when they meet any of these criteria:
Documented in FEP (Fediverse Enhancement Proposals) or equivalent specification
Already adopted by widely-used #fediverse implementations like Mastodon or Pleroma
Contributing new vocabulary is straightforward. The vocabulary definitions live in YAML files within the fedify/vocab/ directory. To add a new type, create a new .yaml file. To add properties to existing types, extend the properties section in the relevant .yaml file.
This approach ensures Fedify's vocabulary coverage grows with the fediverse ecosystem while maintaining type safety and comprehensive documentation. If you're working with custom ActivityPub extensions, consider contributing them upstream to benefit the entire community.
While #Fedify's #Vocabulary API provides comprehensive support for #ActivityPub and major vendor extensions, its code-generation approach makes runtime extensions challenging. However, the project welcomes contributions to expand the supported types and properties.
Fedify accepts vocabulary contributions when they meet any of these criteria:
Documented in FEP (Fediverse Enhancement Proposals) or equivalent specification
Already adopted by widely-used #fediverse implementations like Mastodon or Pleroma
Contributing new vocabulary is straightforward. The vocabulary definitions live in YAML files within the fedify/vocab/ directory. To add a new type, create a new .yaml file. To add properties to existing types, extend the properties section in the relevant .yaml file.
This approach ensures Fedify's vocabulary coverage grows with the fediverse ecosystem while maintaining type safety and comprehensive documentation. If you're working with custom ActivityPub extensions, consider contributing them upstream to benefit the entire community.
While #Fedify's #Vocabulary API provides comprehensive support for #ActivityPub and major vendor extensions, its code-generation approach makes runtime extensions challenging. However, the project welcomes contributions to expand the supported types and properties.
Fedify accepts vocabulary contributions when they meet any of these criteria:
Documented in FEP (Fediverse Enhancement Proposals) or equivalent specification
Already adopted by widely-used #fediverse implementations like Mastodon or Pleroma
Contributing new vocabulary is straightforward. The vocabulary definitions live in YAML files within the fedify/vocab/ directory. To add a new type, create a new .yaml file. To add properties to existing types, extend the properties section in the relevant .yaml file.
This approach ensures Fedify's vocabulary coverage grows with the fediverse ecosystem while maintaining type safety and comprehensive documentation. If you're working with custom ActivityPub extensions, consider contributing them upstream to benefit the entire community.
While #Fedify's #Vocabulary API provides comprehensive support for #ActivityPub and major vendor extensions, its code-generation approach makes runtime extensions challenging. However, the project welcomes contributions to expand the supported types and properties.
Fedify accepts vocabulary contributions when they meet any of these criteria:
Documented in FEP (Fediverse Enhancement Proposals) or equivalent specification
Already adopted by widely-used #fediverse implementations like Mastodon or Pleroma
Contributing new vocabulary is straightforward. The vocabulary definitions live in YAML files within the fedify/vocab/ directory. To add a new type, create a new .yaml file. To add properties to existing types, extend the properties section in the relevant .yaml file.
This approach ensures Fedify's vocabulary coverage grows with the fediverse ecosystem while maintaining type safety and comprehensive documentation. If you're working with custom ActivityPub extensions, consider contributing them upstream to benefit the entire community.
Ω🪬Ω You can now send replies to Toots as well as expand threads directly within the #FediAlgo demo app, no need to click through to the regular Mastodon web interface.
"#ActivityPub is a #protocol – like email, jpeg, MP3 and ‘http’ (behind every website) – that’s built for a world with millions of ‘pubs’ with 1000s or 100 or even just one or two people in them. But it’s not just a mini-social network builder – there’s the key extra ability to connect with anyone in any pub, and chat/subscribe/like/repost not-to-mention change venue, at any point. This is a completely new approach to the challenge of moderating social media: break it into smaller human-run ‘pubs’, and then let those pubs federate with those with similar values and #moderation skills. So the technology itself isn’t where #censorship happens – but between #communities". @nic
"#ActivityPub is a #protocol – like email, jpeg, MP3 and ‘http’ (behind every website) – that’s built for a world with millions of ‘pubs’ with 1000s or 100 or even just one or two people in them. But it’s not just a mini-social network builder – there’s the key extra ability to connect with anyone in any pub, and chat/subscribe/like/repost not-to-mention change venue, at any point. This is a completely new approach to the challenge of moderating social media: break it into smaller human-run ‘pubs’, and then let those pubs federate with those with similar values and #moderation skills. So the technology itself isn’t where #censorship happens – but between #communities". @nic
just a shower thought... while making a #ActivityPub compatible server, should i allow anyone for download access to attachment type of files? like images, vids, etc.
for context, my server is only gonna serve physical products (like tshirts, shoes, or whatever), for now.
just a shower thought... while making a #ActivityPub compatible server, should i allow anyone for download access to attachment type of files? like images, vids, etc.
for context, my server is only gonna serve physical products (like tshirts, shoes, or whatever), for now.
just a shower thought... while making a #ActivityPub compatible server, should i allow anyone for download access to attachment type of files? like images, vids, etc.
for context, my server is only gonna serve physical products (like tshirts, shoes, or whatever), for now.
I will be giving an attendee badge to everyone to stop and say hi, so, if you have not registered for this virtual conference on June 5-7 go to https://fediforum.org/ and do it if you can!
See you there!
ALT text detailsThe image showcases the BadgeFed website, a platform for creating, issuing, and verifying digital badges. It begins with a purple banner featuring the text "Empower Your Community with Digital Badges" and a call-to-action button labeled "Get Started." Below, three sections highlight the platform's features: "Secure & Verifiable," "Decentralized," and "Community Focused," each accompanied by relevant icons and descriptions.
I will be giving an attendee badge to everyone to stop and say hi, so, if you have not registered for this virtual conference on June 5-7 go to https://fediforum.org/ and do it if you can!
See you there!
ALT text detailsThe image showcases the BadgeFed website, a platform for creating, issuing, and verifying digital badges. It begins with a purple banner featuring the text "Empower Your Community with Digital Badges" and a call-to-action button labeled "Get Started." Below, three sections highlight the platform's features: "Secure & Verifiable," "Decentralized," and "Community Focused," each accompanied by relevant icons and descriptions.
If you’re looking for a Pocket replacement, the good news is that there are tons of open source options available - if you’re willing to self host. And if you’re going that route, why not try a federated bookmarking platform? I know of two.
Might be a little biased as I’ve contributed once or twice, but Postmarks works great. Yes, it was built with Glitch in mind but I run it as a Docker container myself.
There are probably some flaws in here, reading the specs for ActivityStreams and Mastodon reminds me of a number of quirks regarding how different platforms implement things.
This release adds instant notifications, online statuses, friend lists, email notifications, account migration, and more. It's also the first version of Smithereen that isn't frustrating to install.
I have posted about this before, but wanted to re-iterate how much in love I am with FediAlgo:
I’m currently on paternity leave so have around half an hour per day for social. That is of course far from enough to keep up with a chronological timeline like mine, and previously with Mastodon the FOMO was real.
Now I go to FediAlgo and I feel I got an overview over what’s interesting in that day. It’s also immensely customisable, but the defaults do a decent job for me.
If you’re looking for a Pocket replacement, the good news is that there are tons of open source options available - if you’re willing to self host. And if you’re going that route, why not try a federated bookmarking platform? I know of two.
Might be a little biased as I’ve contributed once or twice, but Postmarks works great. Yes, it was built with Glitch in mind but I run it as a Docker container myself.
This release adds instant notifications, online statuses, friend lists, email notifications, account migration, and more. It's also the first version of Smithereen that isn't frustrating to install.
This release adds instant notifications, online statuses, friend lists, email notifications, account migration, and more. It's also the first version of Smithereen that isn't frustrating to install.
This release adds instant notifications, online statuses, friend lists, email notifications, account migration, and more. It's also the first version of Smithereen that isn't frustrating to install.
This release adds instant notifications, online statuses, friend lists, email notifications, account migration, and more. It's also the first version of Smithereen that isn't frustrating to install.
I have posted about this before, but wanted to re-iterate how much in love I am with FediAlgo:
I’m currently on paternity leave so have around half an hour per day for social. That is of course far from enough to keep up with a chronological timeline like mine, and previously with Mastodon the FOMO was real.
Now I go to FediAlgo and I feel I got an overview over what’s interesting in that day. It’s also immensely customisable, but the defaults do a decent job for me.
There are probably some flaws in here, reading the specs for ActivityStreams and Mastodon reminds me of a number of quirks regarding how different platforms implement things.
There are probably some flaws in here, reading the specs for ActivityStreams and Mastodon reminds me of a number of quirks regarding how different platforms implement things.
Getting started with #ActivityPub on #WordPress just got a lot easier. A new guided onboarding experience is now part of the plugin, designed to help you configure key settings and understand how your site connects to the #Fediverse—from the moment you activate it.
Getting started with #ActivityPub on #WordPress just got a lot easier. A new guided onboarding experience is now part of the plugin, designed to help you configure key settings and understand how your site connects to the #Fediverse—from the moment you activate it.
Getting started with #ActivityPub on #WordPress just got a lot easier. A new guided onboarding experience is now part of the plugin, designed to help you configure key settings and understand how your site connects to the #Fediverse—from the moment you activate it.
Getting started with #ActivityPub on #WordPress just got a lot easier. A new guided onboarding experience is now part of the plugin, designed to help you configure key settings and understand how your site connects to the #Fediverse—from the moment you activate it.
Getting started with #ActivityPub on #WordPress just got a lot easier. A new guided onboarding experience is now part of the plugin, designed to help you configure key settings and understand how your site connects to the #Fediverse—from the moment you activate it.
Getting started with #ActivityPub on #WordPress just got a lot easier. A new guided onboarding experience is now part of the plugin, designed to help you configure key settings and understand how your site connects to the #Fediverse—from the moment you activate it.
Can't deny being made up that three months after 1st trying to build a #WordPress site using @pfefferle's #ActivityPub plugin - yesterday it finally clicked, with two posts getting lots of boosts, stars & comments:
Am still far from perfecting the integration, but this bar at the bottom is lovely… as is discovering a bunch of servers using different forks/UIs to regular Masto that I've not seen before. Curiously still only one subscriber tho.
ALT text detailsA screengrab from the bottom of a WordPress post with the fediverse reaction.
Can't deny being made up that three months after 1st trying to build a #WordPress site using @pfefferle's #ActivityPub plugin - yesterday it finally clicked, with two posts getting lots of boosts, stars & comments:
Am still far from perfecting the integration, but this bar at the bottom is lovely… as is discovering a bunch of servers using different forks/UIs to regular Masto that I've not seen before. Curiously still only one subscriber tho.
ALT text detailsA screengrab from the bottom of a WordPress post with the fediverse reaction.
It’s meant to be a more personal alt that focuses on projects and opinions, but there’s probably still going to be some overlap between this account and that one. But, if you like what I have to say, feel free to give it a follow!
Handle can be found here: (at)sean@deadsuperhero.com
It’s meant to be a more personal alt that focuses on projects and opinions, but there’s probably still going to be some overlap between this account and that one. But, if you like what I have to say, feel free to give it a follow!
Handle can be found here: (at)sean@deadsuperhero.com
Bluesky still leaves me unconvinced. An open protocol isn’t enough if it’s controlled by a single entity. The future of social media lies in true federation, like the ActivityPub model: interoperability, decentralization, autonomy. Otherwise, how is it any different from the usual proprietary systems? #Bluesky#ActivityPub https://about.flipboard.com/fediverse/blacksky-rudy-fraser/
Exciting news! #Fread is now live on F-Droid! 🚀🎉 A big thanks to the F-Droid community for making this happen. Download it today and join the movement!
Bluesky still leaves me unconvinced. An open protocol isn’t enough if it’s controlled by a single entity. The future of social media lies in true federation, like the ActivityPub model: interoperability, decentralization, autonomy. Otherwise, how is it any different from the usual proprietary systems? #Bluesky#ActivityPub https://about.flipboard.com/fediverse/blacksky-rudy-fraser/
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
We've just submitted an #application to the Sovereign Tech Fund for the #Fedify project! Hoping to further develop and enhance the framework for a more robust federated web.
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
Exciting news! #Fread is now live on F-Droid! 🚀🎉 A big thanks to the F-Droid community for making this happen. Download it today and join the movement!
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
Exciting news! #Fread is now live on F-Droid! 🚀🎉 A big thanks to the F-Droid community for making this happen. Download it today and join the movement!
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
We've just submitted an #application to the Sovereign Tech Fund for the #Fedify project! Hoping to further develop and enhance the framework for a more robust federated web.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
We've just submitted an #application to the Sovereign Tech Fund for the #Fedify project! Hoping to further develop and enhance the framework for a more robust federated web.
We've just submitted an #application to the Sovereign Tech Fund for the #Fedify project! Hoping to further develop and enhance the framework for a more robust federated web.
We've just submitted an #application to the Sovereign Tech Fund for the #Fedify project! Hoping to further develop and enhance the framework for a more robust federated web.
We've just submitted an #application to the Sovereign Tech Fund for the #Fedify project! Hoping to further develop and enhance the framework for a more robust federated web.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Even small contributions help sustain development and show there's interest in open source #ActivityPub tools. Thanks to our existing sponsors who've already been helping move the project forward!
The goal remains the same: make building federated applications more accessible to developers so the #fediverse can continue to grow and thrive.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
Even small contributions help sustain development and show there's interest in open source #ActivityPub tools. Thanks to our existing sponsors who've already been helping move the project forward!
The goal remains the same: make building federated applications more accessible to developers so the #fediverse can continue to grow and thrive.
Thank you to folks that answered my #GTS poll. Seems like a LOT of folks don't know what GTS is! GTS or #GoToSocial is a #GO written #activityPub#server for small groups of folks that's super lightweight, fast and easy to install. You can find them on #Fediverse at @gotosocial .
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify is looking for new partnership opportunities!
What is Fedify?
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
What is Fedify?
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
What is Fedify?
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
What is Fedify?
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
What is Fedify?
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
What is Fedify?
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify is looking for new partnership opportunities!
What is Fedify?
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify is looking for new partnership opportunities!
What is Fedify?
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify is looking for new partnership opportunities!
What is Fedify?
#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
So, just running on microcomputers, everyone can put on their own index whatever they want.
A person can _easily_ index 50,000 pages on a rapsberry pi.
A #FediSearch can broadcast any query to known peers. Each peer returns top-k results. The originating node can then aggregate and rank.
So @alice queries their FediSearch, it searches its own index and queries subscribed peers, those peers do the same thing. Nodes can choose who they trust, cache, etc.
The number of indexes pages will be something along the lines of `pages_per_nod * log(number_nodes)`. So a thousand nodes may only cover a million pages, but if the trust network is good, those are probably the most important million pages.
Also, I would venture that you'd have some nodes specializing in having a lot of pages: tens of millions, others just for stuff they like, others specifically for non-commercial interests. Selecting who you federate your search with really affects the ranking.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
Even small contributions help sustain development and show there's interest in open source #ActivityPub tools. Thanks to our existing sponsors who've already been helping move the project forward!
The goal remains the same: make building federated applications more accessible to developers so the #fediverse can continue to grow and thrive.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
Thank you to folks that answered my #GTS poll. Seems like a LOT of folks don't know what GTS is! GTS or #GoToSocial is a #GO written #activityPub#server for small groups of folks that's super lightweight, fast and easy to install. You can find them on #Fediverse at @gotosocial .
Thank you to folks that answered my #GTS poll. Seems like a LOT of folks don't know what GTS is! GTS or #GoToSocial is a #GO written #activityPub#server for small groups of folks that's super lightweight, fast and easy to install. You can find them on #Fediverse at @gotosocial .
Even small contributions help sustain development and show there's interest in open source #ActivityPub tools. Thanks to our existing sponsors who've already been helping move the project forward!
The goal remains the same: make building federated applications more accessible to developers so the #fediverse can continue to grow and thrive.
Even small contributions help sustain development and show there's interest in open source #ActivityPub tools. Thanks to our existing sponsors who've already been helping move the project forward!
The goal remains the same: make building federated applications more accessible to developers so the #fediverse can continue to grow and thrive.
Even small contributions help sustain development and show there's interest in open source #ActivityPub tools. Thanks to our existing sponsors who've already been helping move the project forward!
The goal remains the same: make building federated applications more accessible to developers so the #fediverse can continue to grow and thrive.
Even small contributions help sustain development and show there's interest in open source #ActivityPub tools. Thanks to our existing sponsors who've already been helping move the project forward!
The goal remains the same: make building federated applications more accessible to developers so the #fediverse can continue to grow and thrive.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
So, just running on microcomputers, everyone can put on their own index whatever they want.
A person can _easily_ index 50,000 pages on a rapsberry pi.
A #FediSearch can broadcast any query to known peers. Each peer returns top-k results. The originating node can then aggregate and rank.
So @alice queries their FediSearch, it searches its own index and queries subscribed peers, those peers do the same thing. Nodes can choose who they trust, cache, etc.
The number of indexes pages will be something along the lines of `pages_per_nod * log(number_nodes)`. So a thousand nodes may only cover a million pages, but if the trust network is good, those are probably the most important million pages.
Also, I would venture that you'd have some nodes specializing in having a lot of pages: tens of millions, others just for stuff they like, others specifically for non-commercial interests. Selecting who you federate your search with really affects the ranking.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
Even small contributions help sustain development and show there's interest in open source #ActivityPub tools. Thanks to our existing sponsors who've already been helping move the project forward!
The goal remains the same: make building federated applications more accessible to developers so the #fediverse can continue to grow and thrive.
Even small contributions help sustain development and show there's interest in open source #ActivityPub tools. Thanks to our existing sponsors who've already been helping move the project forward!
The goal remains the same: make building federated applications more accessible to developers so the #fediverse can continue to grow and thrive.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
So, just running on microcomputers, everyone can put on their own index whatever they want.
A person can _easily_ index 50,000 pages on a rapsberry pi.
A #FediSearch can broadcast any query to known peers. Each peer returns top-k results. The originating node can then aggregate and rank.
So @alice queries their FediSearch, it searches its own index and queries subscribed peers, those peers do the same thing. Nodes can choose who they trust, cache, etc.
The number of indexes pages will be something along the lines of `pages_per_nod * log(number_nodes)`. So a thousand nodes may only cover a million pages, but if the trust network is good, those are probably the most important million pages.
Also, I would venture that you'd have some nodes specializing in having a lot of pages: tens of millions, others just for stuff they like, others specifically for non-commercial interests. Selecting who you federate your search with really affects the ranking.
Ω🪬Ω #FediAlgo, the customizable timeline algorithm / filtering system for your Mastodon feed, is now deployed on Github Pages and can be used from your web browser.
And there are a few more of this spec-vs-reality problems …
It is absolutely not fine. I am currently writing my database implementation and will also show it to @hongminhee … ActivityPub Conformance is hard but hey, I will be conformant :) Thanks for this piece.
Ω🪬Ω #FediAlgo, the customizable timeline algorithm / filtering system for your Mastodon feed, is now deployed on Github Pages and can be used from your web browser.
Ω🪬Ω #FediAlgo, the customizable timeline algorithm / filtering system for your Mastodon feed, is now deployed on Github Pages and can be used from your web browser.
@liaizon The Fediverse is a range of different open source softwares, all based on the #activitypub and federated by this protocol which has been designed to allow a federation of independent and totally autonomous instances with full control by their administrators. That's called "decentralisation".
HEY! I just found the fix for the webfinger "403 forbidden” problem I have been having to get my wordpress blog working fully with ActivityPub @pfefferle!
Looks like for nginx based servers if you are rolling your own or you have a strict web host you need to create a location statement in your nginx config options
HEY! I just found the fix for the webfinger "403 forbidden” problem I have been having to get my wordpress blog working fully with ActivityPub @pfefferle!
Looks like for nginx based servers if you are rolling your own or you have a strict web host you need to create a location statement in your nginx config options
Comme ActivityPub est pas du tout intégré dans les navigateurs, lorsqu'un trouve un contenu intéressant sur une instance qui n'est pas la sienne il y a de la friction pour interagir: il faut copier l'url, revenir dans son instance, chercher, attendre.
Il y a bien des extensions, mais c'est beaucoup de code et ça ne marche que sur Mastodon. Mais moi je veux naviguer le fediverse, pas le Mastoverse.
Du coup j'ai fait un bookmarklet tout bête qui fait le travail à ma place: c'est un signet standard sauf qu'à la place d'une url on peut mettre du code javascript. Et ce code javascript va lancer une recherche dans mon instance avec le contenu en question.
Pouet, post ou commentaire lemmy, vidéo peertube, événement mobilizon, ça marche partout.
Pour installer, rien de plus simple: 1. créer un signet 2. mettre le code minifié dans l'adresse, et par exemple "ouvrir dans mastodon" comme nom 3. c'est tout !
Comme ActivityPub est pas du tout intégré dans les navigateurs, lorsqu'un trouve un contenu intéressant sur une instance qui n'est pas la sienne il y a de la friction pour interagir: il faut copier l'url, revenir dans son instance, chercher, attendre.
Il y a bien des extensions, mais c'est beaucoup de code et ça ne marche que sur Mastodon. Mais moi je veux naviguer le fediverse, pas le Mastoverse.
Du coup j'ai fait un bookmarklet tout bête qui fait le travail à ma place: c'est un signet standard sauf qu'à la place d'une url on peut mettre du code javascript. Et ce code javascript va lancer une recherche dans mon instance avec le contenu en question.
Pouet, post ou commentaire lemmy, vidéo peertube, événement mobilizon, ça marche partout.
Pour installer, rien de plus simple: 1. créer un signet 2. mettre le code minifié dans l'adresse, et par exemple "ouvrir dans mastodon" comme nom 3. c'est tout !
Social media is as social as Las Vegas where #SocialMedia#advertisement giants as telecom providers of society, take care of the lightshow to lure us in.
Have been playing recently with wordpress activitypub, friends, enable mastodon apps and event bridge for activitypub plugins ... getting very close now to use wordpress as my fediverse server !
Have been playing recently with wordpress activitypub, friends, enable mastodon apps and event bridge for activitypub plugins ... getting very close now to use wordpress as my fediverse server !
Comme ActivityPub est pas du tout intégré dans les navigateurs, lorsqu'un trouve un contenu intéressant sur une instance qui n'est pas la sienne il y a de la friction pour interagir: il faut copier l'url, revenir dans son instance, chercher, attendre.
Il y a bien des extensions, mais c'est beaucoup de code et ça ne marche que sur Mastodon. Mais moi je veux naviguer le fediverse, pas le Mastoverse.
Du coup j'ai fait un bookmarklet tout bête qui fait le travail à ma place: c'est un signet standard sauf qu'à la place d'une url on peut mettre du code javascript. Et ce code javascript va lancer une recherche dans mon instance avec le contenu en question.
Pouet, post ou commentaire lemmy, vidéo peertube, événement mobilizon, ça marche partout.
Pour installer, rien de plus simple: 1. créer un signet 2. mettre le code minifié dans l'adresse, et par exemple "ouvrir dans mastodon" comme nom 3. c'est tout !
I’m really happy to have been asked to join the new FediForum Advisory Board that is helping to guide and steer the future of the event.
We are proud to announce the first-ever FediForum advisory board. We are very glad to have such an incredible group of committed and experienced Open Social Web pioneers and advocates come together to advise FediForum and help move the Open Social Web forward.
FediForum has been an important part of the development of the Fediverse over the past couple of years. It has provided a space for projects to share their latest releases and features, and also enabled the serendipitous sharing of needs and ideas. The Projects page on the FediForum site documents a few of the collaborations that have come out of the event already.
I particularly remember how Ben Pate came to share what he was building (Emissary), how several creators in the music space came together during the same event to discuss their hopes for new social channels to connect with their audiences, and how that evolved into both Bandwagon, and The Indie Beat FM. I’ve loved being a part of these kinds of conversations!
An unconference can be difficult to navigate to some people, but it can also enable exactly these kinds of unexpected, delightful fusions of shared interest and technical know-how. At the same time, there’s also a lot of value in more organised, formal events with agendas known in advance. My own belief is that there’s space for both formats to support the Fediverse community, and I hope to see these happen in the coming years. In the meantime, you’ll see some adjustments to the format of FediForum itself, in response to feedback heard at recent town halls.
I’ve helped to run various unconference format events in person in the past; I’m also a public speaker; and, I have been a community organiser myself. I know how complicated it can be to make events like FediForum happen! I’m grateful to have the opportunity to help keep this important shared space open, available, and valuable for the future. I’m also delighted about the wonderful group of people that are on the advisory board – we have a shared passion for the Fediverse, and more importantly, we care about the humans that are part of it.
Have been playing recently with wordpress activitypub, friends, enable mastodon apps and event bridge for activitypub plugins ... getting very close now to use wordpress as my fediverse server !
Have been playing recently with wordpress activitypub, friends, enable mastodon apps and event bridge for activitypub plugins ... getting very close now to use wordpress as my fediverse server !
Have been playing recently with wordpress activitypub, friends, enable mastodon apps and event bridge for activitypub plugins ... getting very close now to use wordpress as my fediverse server !
ALT text detailsScreenshot of the ActivityPub plugin onboarding screen in WordPress. The page welcomes users to the Fediverse and displays a progress circle showing step 2 of 6. Completed steps include 'Plugin installed' and 'Check your site’s health.' Remaining steps are: 'New to the Fediverse? Start Here' with a 'View intro' button, 'Select how you want to share' with a 'Choose mode' button, 'Set up your public profile' with an 'Edit profile' button, and 'Learn more about Fediverse features' with an 'Explore features' button.
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
7s screencast of dokieli's browser extension showing user w/ personal identifier loading up their (& contacts') annotations/objects from outbox/storage (AS2 Collection) displayed in context of where they were originally expressed.
Show me a server that's actually ready for others' clients ;)
7s screencast of dokieli's browser extension showing user w/ personal identifier loading up their (& contacts') annotations/objects from outbox/storage (AS2 Collection) displayed in context of where they were originally expressed.
Show me a server that's actually ready for others' clients ;)
Thank you! I have updated the list in the issue. I am currently collecting this info along with intent to restructure the 4 #ActivityPub fedi related delightful lists so they highlight more the innovative side of things.
Maybe that the #SocialHub C2S category has some historic information on clients that were planned or in the works and tested for compliance. But I'm not aware of any now.
AFAICT, #dokieli - https://dokie.li/ - https://git.dokie.li/ - is the only one that's strictly implementing the Client-to-Server "client" part of the specification. IOW, the software is not tightly coupled / shipped with its own server.
AFAICT, #dokieli - https://dokie.li/ - https://git.dokie.li/ - is the only one that's strictly implementing the Client-to-Server "client" part of the specification. IOW, the software is not tightly coupled / shipped with its own server.
I personally find this a really cool software. For the #ActivityPub fediverse to become home to many interoperable hetegeneous services, then good tools to quickly design services are needed.
Extending AP is still a Hard Thing™ to do, and our current approach will see that only introduce protocol decay.
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
What may be interesting is #AsyncAPI which is like #OpenAPI but then oriented towards event-driven architectures. More appropriate for message passing protocols like #ActivityPub.
What may be interesting is #AsyncAPI which is like #OpenAPI but then oriented towards event-driven architectures. More appropriate for message passing protocols like #ActivityPub.
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
I don't remember. How long has the W3C SocialCG been trying to form a Working Group to at least correct the errors in #ActivityPub? Has been 6 months, a year, longer?
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
I've been thinking about client-server interactions in the #fediverse. #ActivityPub#C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
We are implementing the final version of RFC9421 (HTTP Signatures) in Mastodon, and would like to test this with other ActivityPub implementations.
Do you know of any AP implementations supporting both incoming (verification) and outgoing (signing) RFC9421 signatures, and if possible with support for the double-knocking mechanism as described in https://swicg.github.io/activitypub-http-signature/ (section 3.5)?
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
The fine @michael has deployed the #FediAlgo demo app to a place where you can test out the customizable algorithm + filtering system for your home timeline with nothing more than a web browser. You can find it here:
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
The fine @michael has deployed the #FediAlgo demo app to a place where you can test out the customizable algorithm + filtering system for your home timeline with nothing more than a web browser. You can find it here:
Okay, I've just deployed a bleeding edge #Fedify, which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)
You should follow them. One of the mainstream protocols that make the Fediverse even possible, commonly used on Mastodon, CherryPick, Misskey, and Sharkey, is called, ActivityPub. They help write that protocol.
You should follow them. One of the mainstream protocols that make the Fediverse even possible, commonly used on Mastodon, CherryPick, Misskey, and Sharkey, is called, ActivityPub. They help write that protocol.
By the way, if you’re looking into decentralized tech where people are actually in control of their own data (as in who can use it, when and how), checkout #Solidhttps://solidproject.org There are a lot of interesting insights, especially for storing sensitive data. #OpenSocialWeb#ActivityPub#Fediverse
I'm exploring a new idea called FediOTP (codename): an authentication system that uses #ActivityPub DMs to deliver one-time passwords, allowing any #fediverse account to authenticate with web services. Unlike current solutions that rely on specific APIs (#Mastodon, #Misskey), this would work with any ActivityPub-compatible server, increasing interoperability across the fediverse. Would love to hear your thoughts on potential challenges or use cases for this approach.
By the way, if you’re looking into decentralized tech where people are actually in control of their own data (as in who can use it, when and how), checkout #Solidhttps://solidproject.org There are a lot of interesting insights, especially for storing sensitive data. #OpenSocialWeb#ActivityPub#Fediverse
By the way, if you’re looking into decentralized tech where people are actually in control of their own data (as in who can use it, when and how), checkout #Solidhttps://solidproject.org There are a lot of interesting insights, especially for storing sensitive data. #OpenSocialWeb#ActivityPub#Fediverse
Okay, I've just deployed a bleeding edge #Fedify, which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)
Some #Smithereen updates: - Friend lists: you can now assign lists to your friends. These are useful not only for remembering where you know someone from, but also for privacy settings. - Email notifications: self-explanatory. You only start receiving them if you haven't visited for at least a day, as determined by the online status.
Some #Smithereen updates: - Friend lists: you can now assign lists to your friends. These are useful not only for remembering where you know someone from, but also for privacy settings. - Email notifications: self-explanatory. You only start receiving them if you haven't visited for at least a day, as determined by the online status.
The fine @michael has deployed the #FediAlgo demo app to a place where you can test out the customizable algorithm + filtering system for your home timeline with nothing more than a web browser. You can find it here:
The fine @michael has deployed the #FediAlgo demo app to a place where you can test out the customizable algorithm + filtering system for your home timeline with nothing more than a web browser. You can find it here:
Okay, I've just deployed a bleeding edge #Fedify, which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)
Okay, I've just deployed a bleeding edge #Fedify, which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)
Okay, I've just deployed a bleeding edge #Fedify, which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)
Okay, I've just deployed a bleeding edge #Fedify, which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)
Okay, I've just deployed a bleeding edge #Fedify, which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)
Okay, I've just deployed a bleeding edge #Fedify, which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)
I'm still working on my article about installing and using Honk. The name is silly, and the commands / names for actions are a bit confusing. But under that layer of "do not take any of this seriously" are some interesting features that aren't on Mastodon.
Imports of Instagram, Twitter, Mastodon and Honk archives. Add Geo-coordinates to a post. Add Events Add RSS Feeds Custom timelines (combos) - I think - still figuring this one out!
Federated flair for PieFed communities and users is here. Think of them similar to hashtags that follow these objects around. It gives you a sense of the user's specific interest in a topic, or a way to filter a community to posts about a specific flair. Your community flair can be associated to a specific color.
Federated flair for PieFed communities and users is here. Think of them similar to hashtags that follow these objects around. It gives you a sense of the user's specific interest in a topic, or a way to filter a community to posts about a specific flair. Your community flair can be associated to a specific color.
Federated flair for PieFed communities and users is here. Think of them similar to hashtags that follow these objects around. It gives you a sense of the user's specific interest in a topic, or a way to filter a community to posts about a specific flair. Your community flair can be associated to a specific color.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
Some #Smithereen updates: - Friend lists: you can now assign lists to your friends. These are useful not only for remembering where you know someone from, but also for privacy settings. - Email notifications: self-explanatory. You only start receiving them if you haven't visited for at least a day, as determined by the online status.
Some #Smithereen updates: - Friend lists: you can now assign lists to your friends. These are useful not only for remembering where you know someone from, but also for privacy settings. - Email notifications: self-explanatory. You only start receiving them if you haven't visited for at least a day, as determined by the online status.
@imdavidpierce Its dramatically under-reported that the newly federated forum software #nodebb went from zero to 2.7 million federated users, and jumped. tobe the 2nd biggest platform on #ActivityPub after Mastodon shortly after launch..
Thank you to the organisers at @attacnorge, specifically @audunmb for giving me the opportunity to come and spread the word about #ActivityPub and the #Fediverse. 🙇
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
At SXSW's Fediverse House, it didn't matter which platform or protocol you preferred — everyone was focused on the singular goal of building a better internet. We've uploaded videos and highlights of key conversations from the event and rounded them up in one post. Here you go:
Just rolled out some fediverse-related improvements:
- Now you can follow Write.as blogs from Ghost! There was a tiny bug with this that we just fixed. (WriteFreely PR: https://writefreely.org/pull/1373)
- We now support the `preview` property as a fallback for Articles. This will make your posts look much nicer as more platforms support it! (WriteFreely PR: https://writefreely.org/pull/1374)
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
@imdavidpierce Its dramatically under-reported that the newly federated forum software #nodebb went from zero to 2.7 million federated users, and jumped. tobe the 2nd biggest platform on #ActivityPub after Mastodon shortly after launch..
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
Just rolled out some fediverse-related improvements:
- Now you can follow Write.as blogs from Ghost! There was a tiny bug with this that we just fixed. (WriteFreely PR: https://writefreely.org/pull/1373)
- We now support the `preview` property as a fallback for Articles. This will make your posts look much nicer as more platforms support it! (WriteFreely PR: https://writefreely.org/pull/1374)
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
ALT text detailsHTTP Message Signatures
This API is available since Fedify 1.6.0.
RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.
Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.
NOTE
Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsDouble-knocking HTTP Signatures
This API is available since Fedify 1.6.0.
As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.
To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
At SXSW's Fediverse House, it didn't matter which platform or protocol you preferred — everyone was focused on the singular goal of building a better internet. We've uploaded videos and highlights of key conversations from the event and rounded them up in one post. Here you go:
At SXSW's Fediverse House, it didn't matter which platform or protocol you preferred — everyone was focused on the singular goal of building a better internet. We've uploaded videos and highlights of key conversations from the event and rounded them up in one post. Here you go:
Just rolled out some fediverse-related improvements:
- Now you can follow Write.as blogs from Ghost! There was a tiny bug with this that we just fixed. (WriteFreely PR: https://writefreely.org/pull/1373)
- We now support the `preview` property as a fallback for Articles. This will make your posts look much nicer as more platforms support it! (WriteFreely PR: https://writefreely.org/pull/1374)
That is excellent and exemplary to other fediverse app developers to help the #ActivityPub ecosystem improve and become increase overall #interoperability.
PS. I noticed that no discussion thread for the #FEP was created on #SocialHub, so I took that upon me:
Just rolled out some fediverse-related improvements:
- Now you can follow Write.as blogs from Ghost! There was a tiny bug with this that we just fixed. (WriteFreely PR: https://writefreely.org/pull/1373)
- We now support the `preview` property as a fallback for Articles. This will make your posts look much nicer as more platforms support it! (WriteFreely PR: https://writefreely.org/pull/1374)
If you're a writer/blogger/press, a friendly reminder that the 17th Year Anniversary of the #Fediverse [social] network (**not** Mastodon® social network) is fast approaching.
May 18, 2008
So, if you want to publish a new article, you can start today. There are a hundred possible angles and scopes for that article. 😉
Just rolled out some fediverse-related improvements:
- Now you can follow Write.as blogs from Ghost! There was a tiny bug with this that we just fixed. (WriteFreely PR: https://writefreely.org/pull/1373)
- We now support the `preview` property as a fallback for Articles. This will make your posts look much nicer as more platforms support it! (WriteFreely PR: https://writefreely.org/pull/1374)
Just rolled out some fediverse-related improvements:
- Now you can follow Write.as blogs from Ghost! There was a tiny bug with this that we just fixed. (WriteFreely PR: https://writefreely.org/pull/1373)
- We now support the `preview` property as a fallback for Articles. This will make your posts look much nicer as more platforms support it! (WriteFreely PR: https://writefreely.org/pull/1374)
Then I referred to FEPs which are "Fediverse Enhancement Proposals" as the community ad-hoc-way to spec.ing … They are listed in this repo https://codeberg.org/fediverse/fep
In the next days, I will sketch out some concrete Activities workflow Please tell me what is missing :)
in the past days I have read many threads about the importance of facts in social networks and federating them.
On the other hand, the co-founder of wikipedia, Dr. Larry Sanger wants to create a "censorship resistant federated wikipedia". He became an altright conspiracy theorist and is part of Trumps culture-revolution-thinktank.
My fear is that they will not only remove tax status but also target Jimmy Wales, contributors and in the end the org domains.
@imdavidpierce Its dramatically under-reported that the newly federated forum software #nodebb went from zero to 2.7 million federated users, and jumped. tobe the 2nd biggest platform on #ActivityPub after Mastodon shortly after launch..
@imdavidpierce Its dramatically under-reported that the newly federated forum software #nodebb went from zero to 2.7 million federated users, and jumped. tobe the 2nd biggest platform on #ActivityPub after Mastodon shortly after launch..
That means more attention freed for #ActivityPub. The future of #social networking is strengthening #human connection online.
Let's lead the way forward in how #technology can serve mankind, instead of mindless digital transformation that only serves #capitalism and the bottom line.
We can envision a #peopleverse together. A place where online and offline are seamlessly connected, not separate worlds.
so now that features are really starting to diverge between different #activitypub sites we really need a way to come together and decide how these little bits can fit together. for instance #misskey has a ton of features they have implemented recently like polls and reactions other then 'star',
Fediverse Report #115 - This week's #fediverse news:
- @peertube launches v1 of their mobile apps - @Mastodon shares more information on their team is growing - @swf launches places.pub, a way to put OpenStreetMap data directly on #activitypub
#Tor and #ActivityPub experts, I'm curious to know if anyone has attempted to create a Fediverse instance as an Onion Service.
I understand that server-to-server communications in ActivityPub use HTTPS POST. So I imagine the sticking point would be routing server-to-server communications over the Tor network from, say, mastodon.social to valencia.onion.
Is this a problem with a trivial solution? Or perhaps an intractable one?
Me: > Imagine when you add a new fediverse account to the profile of an existing one, it offers to synchronise your avatar, other social accounts, etc between the two
Maybe an ActivityPods approach could be used for this?
I’m really happy to have been asked to join the new FediForum Advisory Board that is helping to guide and steer the future of the event.
We are proud to announce the first-ever FediForum advisory board. We are very glad to have such an incredible group of committed and experienced Open Social Web pioneers and advocates come together to advise FediForum and help move the Open Social Web forward.
FediForum has been an important part of the development of the Fediverse over the past couple of years. It has provided a space for projects to share their latest releases and features, and also enabled the serendipitous sharing of needs and ideas. The Projects page on the FediForum site documents a few of the collaborations that have come out of the event already.
I particularly remember how Ben Pate came to share what he was building (Emissary), how several creators in the music space came together during the same event to discuss their hopes for new social channels to connect with their audiences, and how that evolved into both Bandwagon, and The Indie Beat FM. I’ve loved being a part of these kinds of conversations!
An unconference can be difficult to navigate to some people, but it can also enable exactly these kinds of unexpected, delightful fusions of shared interest and technical know-how. At the same time, there’s also a lot of value in more organised, formal events with agendas known in advance. My own belief is that there’s space for both formats to support the Fediverse community, and I hope to see these happen in the coming years. In the meantime, you’ll see some adjustments to the format of FediForum itself, in response to feedback heard at recent town halls.
I’ve helped to run various unconference format events in person in the past; I’m also a public speaker; and, I have been a community organiser myself. I know how complicated it can be to make events like FediForum happen! I’m grateful to have the opportunity to help keep this important shared space open, available, and valuable for the future. I’m also delighted about the wonderful group of people that are on the advisory board – we have a shared passion for the Fediverse, and more importantly, we care about the humans that are part of it.
Me: > Imagine when you add a new fediverse account to the profile of an existing one, it offers to synchronise your avatar, other social accounts, etc between the two
Maybe an ActivityPods approach could be used for this?
#Tor and #ActivityPub experts, I'm curious to know if anyone has attempted to create a Fediverse instance as an Onion Service.
I understand that server-to-server communications in ActivityPub use HTTPS POST. So I imagine the sticking point would be routing server-to-server communications over the Tor network from, say, mastodon.social to valencia.onion.
Is this a problem with a trivial solution? Or perhaps an intractable one?
I’m really happy to have been asked to join the new FediForum Advisory Board that is helping to guide and steer the future of the event.
We are proud to announce the first-ever FediForum advisory board. We are very glad to have such an incredible group of committed and experienced Open Social Web pioneers and advocates come together to advise FediForum and help move the Open Social Web forward.
FediForum has been an important part of the development of the Fediverse over the past couple of years. It has provided a space for projects to share their latest releases and features, and also enabled the serendipitous sharing of needs and ideas. The Projects page on the FediForum site documents a few of the collaborations that have come out of the event already.
I particularly remember how Ben Pate came to share what he was building (Emissary), how several creators in the music space came together during the same event to discuss their hopes for new social channels to connect with their audiences, and how that evolved into both Bandwagon, and The Indie Beat FM. I’ve loved being a part of these kinds of conversations!
An unconference can be difficult to navigate to some people, but it can also enable exactly these kinds of unexpected, delightful fusions of shared interest and technical know-how. At the same time, there’s also a lot of value in more organised, formal events with agendas known in advance. My own belief is that there’s space for both formats to support the Fediverse community, and I hope to see these happen in the coming years. In the meantime, you’ll see some adjustments to the format of FediForum itself, in response to feedback heard at recent town halls.
I’ve helped to run various unconference format events in person in the past; I’m also a public speaker; and, I have been a community organiser myself. I know how complicated it can be to make events like FediForum happen! I’m grateful to have the opportunity to help keep this important shared space open, available, and valuable for the future. I’m also delighted about the wonderful group of people that are on the advisory board – we have a shared passion for the Fediverse, and more importantly, we care about the humans that are part of it.
We are implementing the final version of RFC9421 (HTTP Signatures) in Mastodon, and would like to test this with other ActivityPub implementations.
Do you know of any AP implementations supporting both incoming (verification) and outgoing (signing) RFC9421 signatures, and if possible with support for the double-knocking mechanism as described in https://swicg.github.io/activitypub-http-signature/ (section 3.5)?
The question is probably _how_ to federate wiki and the JSON-LD API already exists. @maxlath did much tooling already, currently I am working on versioning as In AP anything
Fediverse Report #115 - This week's #fediverse news:
- @peertube launches v1 of their mobile apps - @Mastodon shares more information on their team is growing - @swf launches places.pub, a way to put OpenStreetMap data directly on #activitypub
Fediverse Report #115 - This week's #fediverse news:
- @peertube launches v1 of their mobile apps - @Mastodon shares more information on their team is growing - @swf launches places.pub, a way to put OpenStreetMap data directly on #activitypub
We are implementing the final version of RFC9421 (HTTP Signatures) in Mastodon, and would like to test this with other ActivityPub implementations.
Do you know of any AP implementations supporting both incoming (verification) and outgoing (signing) RFC9421 signatures, and if possible with support for the double-knocking mechanism as described in https://swicg.github.io/activitypub-http-signature/ (section 3.5)?
Congratulations to @johnonolan and the team at Ghost on their 12th birthday! Here's John's post reflecting on the idea behind the product, some of the incredible indie publishers who have adopted it (including @404mediaco, @caseynewton's Platformer, and @drownedinsound) and what's next.
Congratulations to @johnonolan and the team at Ghost on their 12th birthday! Here's John's post reflecting on the idea behind the product, some of the incredible indie publishers who have adopted it (including @404mediaco, @caseynewton's Platformer, and @drownedinsound) and what's next.
Fediverse Report #115 - This week's #fediverse news:
- @peertube launches v1 of their mobile apps - @Mastodon shares more information on their team is growing - @swf launches places.pub, a way to put OpenStreetMap data directly on #activitypub
Fediverse Report #115 - This week's #fediverse news:
- @peertube launches v1 of their mobile apps - @Mastodon shares more information on their team is growing - @swf launches places.pub, a way to put OpenStreetMap data directly on #activitypub
We are implementing the final version of RFC9421 (HTTP Signatures) in Mastodon, and would like to test this with other ActivityPub implementations.
Do you know of any AP implementations supporting both incoming (verification) and outgoing (signing) RFC9421 signatures, and if possible with support for the double-knocking mechanism as described in https://swicg.github.io/activitypub-http-signature/ (section 3.5)?
If you're a writer/blogger/press, a friendly reminder that the 17th Year Anniversary of the #Fediverse [social] network (**not** Mastodon® social network) is fast approaching.
May 18, 2008
So, if you want to publish a new article, you can start today. There are a hundred possible angles and scopes for that article. 😉
Thank you to the organisers at @attacnorge, specifically @audunmb for giving me the opportunity to come and spread the word about #ActivityPub and the #Fediverse. 🙇
Thank you to the organisers at @attacnorge, specifically @audunmb for giving me the opportunity to come and spread the word about #ActivityPub and the #Fediverse. 🙇
We are implementing the final version of RFC9421 (HTTP Signatures) in Mastodon, and would like to test this with other ActivityPub implementations.
Do you know of any AP implementations supporting both incoming (verification) and outgoing (signing) RFC9421 signatures, and if possible with support for the double-knocking mechanism as described in https://swicg.github.io/activitypub-http-signature/ (section 3.5)?
We are implementing the final version of RFC9421 (HTTP Signatures) in Mastodon, and would like to test this with other ActivityPub implementations.
Do you know of any AP implementations supporting both incoming (verification) and outgoing (signing) RFC9421 signatures, and if possible with support for the double-knocking mechanism as described in https://swicg.github.io/activitypub-http-signature/ (section 3.5)?
We are implementing the final version of RFC9421 (HTTP Signatures) in Mastodon, and would like to test this with other ActivityPub implementations.
Do you know of any AP implementations supporting both incoming (verification) and outgoing (signing) RFC9421 signatures, and if possible with support for the double-knocking mechanism as described in https://swicg.github.io/activitypub-http-signature/ (section 3.5)?
We are implementing the final version of RFC9421 (HTTP Signatures) in Mastodon, and would like to test this with other ActivityPub implementations.
Do you know of any AP implementations supporting both incoming (verification) and outgoing (signing) RFC9421 signatures, and if possible with support for the double-knocking mechanism as described in https://swicg.github.io/activitypub-http-signature/ (section 3.5)?
We are implementing the final version of RFC9421 (HTTP Signatures) in Mastodon, and would like to test this with other ActivityPub implementations.
Do you know of any AP implementations supporting both incoming (verification) and outgoing (signing) RFC9421 signatures, and if possible with support for the double-knocking mechanism as described in https://swicg.github.io/activitypub-http-signature/ (section 3.5)?
We are implementing the final version of RFC9421 (HTTP Signatures) in Mastodon, and would like to test this with other ActivityPub implementations.
Do you know of any AP implementations supporting both incoming (verification) and outgoing (signing) RFC9421 signatures, and if possible with support for the double-knocking mechanism as described in https://swicg.github.io/activitypub-http-signature/ (section 3.5)?
We are implementing the final version of RFC9421 (HTTP Signatures) in Mastodon, and would like to test this with other ActivityPub implementations.
Do you know of any AP implementations supporting both incoming (verification) and outgoing (signing) RFC9421 signatures, and if possible with support for the double-knocking mechanism as described in https://swicg.github.io/activitypub-http-signature/ (section 3.5)?
We are implementing the final version of RFC9421 (HTTP Signatures) in Mastodon, and would like to test this with other ActivityPub implementations.
Do you know of any AP implementations supporting both incoming (verification) and outgoing (signing) RFC9421 signatures, and if possible with support for the double-knocking mechanism as described in https://swicg.github.io/activitypub-http-signature/ (section 3.5)?
We are implementing the final version of RFC9421 (HTTP Signatures) in Mastodon, and would like to test this with other ActivityPub implementations.
Do you know of any AP implementations supporting both incoming (verification) and outgoing (signing) RFC9421 signatures, and if possible with support for the double-knocking mechanism as described in https://swicg.github.io/activitypub-http-signature/ (section 3.5)?
Coda: The growth of BlueSky, and the novel features it launches with, point to a need for a 2.0 version of ActivityPub. One that fleshes out and updates the protocol based on dev experiences in the first decade of active use, and intentions going forward.
Ideally an AP 2.0 would include a formal mechanism for protocol extensions. One that learns from the experiences of the FEP process.
Hi folks, is there a LinkedIn equivalent on the Fediverse? Or is anyone working on creating one? My professional posts don't quite fit the tone and microblogging style of Mastodon, and they’re not really suited to long-form blogging either. It would also be great to have an ActivityPub job board.
The FediAlgo hashtag filter section now highlights any hashtags you've posted about recently.
Interestingly the most I've used the app the more I've found feed filtering gets a ton of mileage for me. It's a huge change of pace to be able to instantly flip between whatever people are talking about on the Fediverse. Not really something you can do on any other social media platform I'm aware of.
Hi folks, is there a LinkedIn equivalent on the Fediverse? Or is anyone working on creating one? My professional posts don't quite fit the tone and microblogging style of Mastodon, and they’re not really suited to long-form blogging either. It would also be great to have an ActivityPub job board.
Hi folks, is there a LinkedIn equivalent on the Fediverse? Or is anyone working on creating one? My professional posts don't quite fit the tone and microblogging style of Mastodon, and they’re not really suited to long-form blogging either. It would also be great to have an ActivityPub job board.
The FediAlgo hashtag filter section now highlights any hashtags you've posted about recently.
Interestingly the most I've used the app the more I've found feed filtering gets a ton of mileage for me. It's a huge change of pace to be able to instantly flip between whatever people are talking about on the Fediverse. Not really something you can do on any other social media platform I'm aware of.
In the last weeks, I noticed more & more messages from different instances/admins about moderation, banning and de-federations. Initially, people told the Fediverse is more open, not blocking and deleting content compared to other social medias. However, I think it shifted to the opposite where a single instance admin decides for the whole user base (which might not even be aware of it).
In the last weeks, I noticed more & more messages from different instances/admins about moderation, banning and de-federations. Initially, people told the Fediverse is more open, not blocking and deleting content compared to other social medias. However, I think it shifted to the opposite where a single instance admin decides for the whole user base (which might not even be aware of it).
What should #FEP Process be about? #ActivityPub et al? Or everything that vaguely represents #SocialWeb?
I took FEP codeberg chat to a #SocialHub thread that discusses how we can ensure and foster an open and grassroots ecosystem.
Imho the FEP Process should define its particular scope of protocols and technologies that are relevant, and that involves AS/AP and closely affiliated technologies.
FEP Process should NOT define what #Fediverse is. Leave that to Fedizens.
On the #W3C#SocialCG a related issue. For a good bottom-up standardization process that guarantees an open and inclusive #ActivityPub related ecosystem, there should be good alignment with the #FEP Process.
What should #FEP Process be about? #ActivityPub et al? Or everything that vaguely represents #SocialWeb?
I took FEP codeberg chat to a #SocialHub thread that discusses how we can ensure and foster an open and grassroots ecosystem.
Imho the FEP Process should define its particular scope of protocols and technologies that are relevant, and that involves AS/AP and closely affiliated technologies.
FEP Process should NOT define what #Fediverse is. Leave that to Fedizens.
Early bits of #decentralization of #Badges look how, I created one in one instance (verifiedby.maho.dev) for @lqdev and it got decentralized/federated to other instance (badges.vocalcat.com)
In a technical note, I am using notes (so it gets published to mastodon), but adding the badge as "attachment" which is in the #activitypub spec. Tried document type before, but it does not render in Mastodon. I am going to work in supporting openbadges as activitypub attachments as well, so you can bring your existing openbadges to the fediverse.
Early bits of #decentralization of #Badges look how, I created one in one instance (verifiedby.maho.dev) for @lqdev and it got decentralized/federated to other instance (badges.vocalcat.com)
In a technical note, I am using notes (so it gets published to mastodon), but adding the badge as "attachment" which is in the #activitypub spec. Tried document type before, but it does not render in Mastodon. I am going to work in supporting openbadges as activitypub attachments as well, so you can bring your existing openbadges to the fediverse.
Early bits of #decentralization of #Badges look how, I created one in one instance (verifiedby.maho.dev) for @lqdev and it got decentralized/federated to other instance (badges.vocalcat.com)
In a technical note, I am using notes (so it gets published to mastodon), but adding the badge as "attachment" which is in the #activitypub spec. Tried document type before, but it does not render in Mastodon. I am going to work in supporting openbadges as activitypub attachments as well, so you can bring your existing openbadges to the fediverse.
I am trying to connect an application I am making with the Fediverse. When I search for an actor I am successfully able to get to the profile (yay) but when I search for a post I cannot find it.
I am receiving the GET request and am sending the response with the content type ("application/activity+json") (for example):
I am trying to connect an application I am making with the Fediverse. When I search for an actor I am successfully able to get to the profile (yay) but when I search for a post I cannot find it.
I am receiving the GET request and am sending the response with the content type ("application/activity+json") (for example):
I am trying to connect an application I am making with the Fediverse. When I search for an actor I am successfully able to get to the profile (yay) but when I search for a post I cannot find it.
I am receiving the GET request and am sending the response with the content type ("application/activity+json") (for example):
Today I learned that the fediverse platform Honk can import posts from a Mastodon, Twitter, or Instagram archive and backdate them appropriately. That's honkin' terrific!
Today I learned that the fediverse platform Honk can import posts from a Mastodon, Twitter, or Instagram archive and backdate them appropriately. That's honkin' terrific!
Today I learned that the fediverse platform Honk can import posts from a Mastodon, Twitter, or Instagram archive and backdate them appropriately. That's honkin' terrific!
Today I learned that the fediverse platform Honk can import posts from a Mastodon, Twitter, or Instagram archive and backdate them appropriately. That's honkin' terrific!
Question of the day, I have #mastodon hosted on my halis.io domain, same for my #synapse instance, and it works without issues because one uses #activitypub and the other #matrix
But, if I setup a #manyfold instance on the same domain, as in without subdomain, it shouldn’t work, right ?
Would there be a way to converge both manyfold and mastodon under the same base domain ? Or do I have to use a subdomain for one ?
My relay instance for the #Fediverse evolved in a great way - more than 120 instances are already connected to boost your posts across the Fediverse.
If you're running #snac / #snac2, #Mastodon, #Pleroma or any other software on the #ActivityPub protocol that supports relay instances - feel free to join the relay! Hopefully #GoToSocial also supports relay services soon! Of course #IPv6 is supported (for IPV6 only instances).
ALT text detailsScreenshot of the overview page of fedi-relay.gyptazy.com showing more than 120 connected instances for a federated network within the Fediverse.
My relay instance for the #Fediverse evolved in a great way - more than 120 instances are already connected to boost your posts across the Fediverse.
If you're running #snac / #snac2, #Mastodon, #Pleroma or any other software on the #ActivityPub protocol that supports relay instances - feel free to join the relay! Hopefully #GoToSocial also supports relay services soon! Of course #IPv6 is supported (for IPV6 only instances).
ALT text detailsScreenshot of the overview page of fedi-relay.gyptazy.com showing more than 120 connected instances for a federated network within the Fediverse.
My relay instance for the #Fediverse evolved in a great way - more than 120 instances are already connected to boost your posts across the Fediverse.
If you're running #snac / #snac2, #Mastodon, #Pleroma or any other software on the #ActivityPub protocol that supports relay instances - feel free to join the relay! Hopefully #GoToSocial also supports relay services soon! Of course #IPv6 is supported (for IPV6 only instances).
ALT text detailsScreenshot of the overview page of fedi-relay.gyptazy.com showing more than 120 connected instances for a federated network within the Fediverse.
We’ve just uploaded a bunch of clips from @davidimel's Fediverse Corner panel at the Fediverse House at SXSW 2025, featuring @evan, @mmasnick and @pcottle
We know the sound is super rough 😅 but many of these snippets deserve to be heard. Thanks for bearing with us. They talk about:
- Solving the cold start problem - Taking control back from billionaires - The deal with Threads’ federation - Keeping vibes sacred (and whole)
Threads updated their terms of service. Lots of CYA when interacting with “the Protocol” which at this point in time, is ActivityPub. But it’s never named, and it’s noted that the protocol could change at anytime.
Important terms to review: protocol and third party *. Also that little sneaky point about needing to adhere to both Threads and Instagram’s ToS.
Threads updated their terms of service. Lots of CYA when interacting with “the Protocol” which at this point in time, is ActivityPub. But it’s never named, and it’s noted that the protocol could change at anytime.
Important terms to review: protocol and third party *. Also that little sneaky point about needing to adhere to both Threads and Instagram’s ToS.
After almost 12 years I migrated my blog from #Github Pages to @Codeberg.
I also added an #ActivityPub-based comments system (which means you can now comment using your Mastodon account), and archived the legacy comments (which used Github issues).
This post gives some technical background info on how I did this, which might be useful for others who are thinking about moving their sites away from Github.
Threads updated their terms of service. Lots of CYA when interacting with “the Protocol” which at this point in time, is ActivityPub. But it’s never named, and it’s noted that the protocol could change at anytime.
Important terms to review: protocol and third party *. Also that little sneaky point about needing to adhere to both Threads and Instagram’s ToS.
laden euch ein zum ersten Teil aus der Workshopreihe "Sovereign. Sustainable. Digital. Digitale Souveränität nachhaltig stärken." der Community Nachhaltige Digitalisierung des @bmuv
ALT text detailsDas Sharepic enthält:
- Logos der Community Nachhaltige Digitalisierung und des Bundesministerium für Umwelt, Naturschutz, nukleare Sicherheit und Verbraucherschutz
- Icons von diversen Fediverse-Diensten
- Titel und Datum der Veranstaltung: Das Fediverse und soziale Medien, am 06. Mai 2025 | 14:30 bis 16:30 Uhr.
I'm looking to either self-host (ideally) or rent some #ActivityPub related services. Namely #GoToSocial, #PeerTube and possible #Owncast. As more or less of a noob on these things, where do I go to get started and to gather the basics of what I need?
I did not mention a #SocialHub thread. There are multiple discussions where various aspects were discussed, that might still be useful. The search facility is best way to find them.
As for AndStatus the github issue lists their step-by-step progress in investigating what was needed, and what the challenges were. One of them was unavailibility of appropriate server back-ends to test against, mentioned *at the time* as challenge.
I'm looking to either self-host (ideally) or rent some #ActivityPub related services. Namely #GoToSocial, #PeerTube and possible #Owncast. As more or less of a noob on these things, where do I go to get started and to gather the basics of what I need?
Ω🪬Ω New release of #FediAlgo (customizable #algorithm for your #Mastodon timeline) has a couple of cool features:
1. Configuration presets (so you can easily put discussions or trending toots at the top of your #timeline without fiddling with the individual settings)
2. A "What's Trending" section that will show you the top trending hashtags, links, and posts scraped from 30 or so of the most popular Mastodon servers
All the old features like filtering for particular languages / hashtags / users or a minimum number of replies / boosts / etc. are still there.
It would be cooler if it would just resolve both webfingers to https://www.404media.co/.ghost/activitypub/users/index cause then we can JUST use "404media.co" without any handle bullshit too. This is also how we'll do it in the Public Broadcasters Project, e.g. here also for the subdomains (special interest programmes like ZDF neo or arte)
So, following your encouragement, I will do weekly blog posts sharing a behind-the-scenes look at the making of my Fedi video(s).
My two amazing interns will be helping out for the next 8 weeks... and they know NOTHING about the Fediverse (we kept things this way so they'll look at the script with fresh eyes and provide feedback from the POV of our ideal audience).
Today I get to tell them about #ActivityPub - exciteeed 🥰
Does anyone know of a Common Lisp activitypub library that is complete enough to implement subscription to accounts, tracking subscribers and posting messages?
I want to build a small service which allows users to tag it in a message (or users can ask the serviceto subscribeto it, in which case it will absorb all mesaages), and conaume those messages, and then post updates to its main feed.
The other one is around Direct Messages which are a hack (a Note with special sauce). #LitePub specifies ChatMessage object type here, which is the intended way to extend the protocol. #FEP
The other one is around Direct Messages which are a hack (a Note with special sauce). #LitePub specifies ChatMessage object type here, which is the intended way to extend the protocol. #FEP
The other one is around Direct Messages which are a hack (a Note with special sauce). #LitePub specifies ChatMessage object type here, which is the intended way to extend the protocol. #FEP
A very detailed investigation on what is needed client-side can be found in the #AndStatus project. It was never completed AFAIK as there were among others no server implementations to test against.
We’ve just uploaded a bunch of clips from @davidimel's Fediverse Corner panel at the Fediverse House at SXSW 2025, featuring @evan, @mmasnick and @pcottle
We know the sound is super rough 😅 but many of these snippets deserve to be heard. Thanks for bearing with us. They talk about:
- Solving the cold start problem - Taking control back from billionaires - The deal with Threads’ federation - Keeping vibes sacred (and whole)
We’ve just uploaded a bunch of clips from @davidimel's Fediverse Corner panel at the Fediverse House at SXSW 2025, featuring @evan, @mmasnick and @pcottle
We know the sound is super rough 😅 but many of these snippets deserve to be heard. Thanks for bearing with us. They talk about:
- Solving the cold start problem - Taking control back from billionaires - The deal with Threads’ federation - Keeping vibes sacred (and whole)
It would be really nice to be able to import/export word filters on #Mastdon. Not sure why this functionality isn't there. Perhaps a feature request is in order.
It would be great if the #ActivityPub#Discourse plugin supported moving topics to remote forums it federates with.
I wanted to transfer some topics with a bunch of posts to another discourse installation, but the procedure is quite involved. Not a simple export/import via the UI, unless I overlooked something.
So, following your encouragement, I will do weekly blog posts sharing a behind-the-scenes look at the making of my Fedi video(s).
My two amazing interns will be helping out for the next 8 weeks... and they know NOTHING about the Fediverse (we kept things this way so they'll look at the script with fresh eyes and provide feedback from the POV of our ideal audience).
Today I get to tell them about #ActivityPub - exciteeed 🥰
It would be great if the #ActivityPub#Discourse plugin supported moving topics to remote forums it federates with.
I wanted to transfer some topics with a bunch of posts to another discourse installation, but the procedure is quite involved. Not a simple export/import via the UI, unless I overlooked something.
I'm exploring a new idea called FediOTP (codename): an authentication system that uses #ActivityPub DMs to deliver one-time passwords, allowing any #fediverse account to authenticate with web services. Unlike current solutions that rely on specific APIs (#Mastodon, #Misskey), this would work with any ActivityPub-compatible server, increasing interoperability across the fediverse. Would love to hear your thoughts on potential challenges or use cases for this approach.
I'm exploring a new idea called FediOTP (codename): an authentication system that uses #ActivityPub DMs to deliver one-time passwords, allowing any #fediverse account to authenticate with web services. Unlike current solutions that rely on specific APIs (#Mastodon, #Misskey), this would work with any ActivityPub-compatible server, increasing interoperability across the fediverse. Would love to hear your thoughts on potential challenges or use cases for this approach.
It would be really nice to be able to import/export word filters on #Mastdon. Not sure why this functionality isn't there. Perhaps a feature request is in order.
I know most people dislike AI on the Fediverse, but we really do need an AI on the Fediverse to deal with the spam problems.
I work for Meta, and do you think we spend all day, every day, removing spam?
NO. - We have an AI for that.
The only time I see spam is when someone appeals. You'd be surprised on how entitled people feel to post, junk. Beyond that, we mostly deal with normal junk, and spam is generally a low issue.
I'm exploring a new idea called FediOTP (codename): an authentication system that uses #ActivityPub DMs to deliver one-time passwords, allowing any #fediverse account to authenticate with web services. Unlike current solutions that rely on specific APIs (#Mastodon, #Misskey), this would work with any ActivityPub-compatible server, increasing interoperability across the fediverse. Would love to hear your thoughts on potential challenges or use cases for this approach.
Hello, I'm an open source software engineer in my late 30s living in #Seoul, #Korea, and an avid advocate of #FLOSS and the #fediverse.
I'm the creator of @fedify, an #ActivityPub server framework in #TypeScript, @hollo, an ActivityPub-enabled microblogging software for single users, and @botkit, a simple ActivityPub bot framework.
I'm exploring a new idea called FediOTP (codename): an authentication system that uses #ActivityPub DMs to deliver one-time passwords, allowing any #fediverse account to authenticate with web services. Unlike current solutions that rely on specific APIs (#Mastodon, #Misskey), this would work with any ActivityPub-compatible server, increasing interoperability across the fediverse. Would love to hear your thoughts on potential challenges or use cases for this approach.
I'm exploring a new idea called FediOTP (codename): an authentication system that uses #ActivityPub DMs to deliver one-time passwords, allowing any #fediverse account to authenticate with web services. Unlike current solutions that rely on specific APIs (#Mastodon, #Misskey), this would work with any ActivityPub-compatible server, increasing interoperability across the fediverse. Would love to hear your thoughts on potential challenges or use cases for this approach.
I'm exploring a new idea called FediOTP (codename): an authentication system that uses #ActivityPub DMs to deliver one-time passwords, allowing any #fediverse account to authenticate with web services. Unlike current solutions that rely on specific APIs (#Mastodon, #Misskey), this would work with any ActivityPub-compatible server, increasing interoperability across the fediverse. Would love to hear your thoughts on potential challenges or use cases for this approach.
I'm exploring a new idea called FediOTP (codename): an authentication system that uses #ActivityPub DMs to deliver one-time passwords, allowing any #fediverse account to authenticate with web services. Unlike current solutions that rely on specific APIs (#Mastodon, #Misskey), this would work with any ActivityPub-compatible server, increasing interoperability across the fediverse. Would love to hear your thoughts on potential challenges or use cases for this approach.
I'm exploring a new idea called FediOTP (codename): an authentication system that uses #ActivityPub DMs to deliver one-time passwords, allowing any #fediverse account to authenticate with web services. Unlike current solutions that rely on specific APIs (#Mastodon, #Misskey), this would work with any ActivityPub-compatible server, increasing interoperability across the fediverse. Would love to hear your thoughts on potential challenges or use cases for this approach.
I'm exploring a new idea called FediOTP (codename): an authentication system that uses #ActivityPub DMs to deliver one-time passwords, allowing any #fediverse account to authenticate with web services. Unlike current solutions that rely on specific APIs (#Mastodon, #Misskey), this would work with any ActivityPub-compatible server, increasing interoperability across the fediverse. Would love to hear your thoughts on potential challenges or use cases for this approach.
For those skeptical of DMs in #ActivityPub: I'm also considering an alternative verification approach using ActivityPub's Question feature. Instead of sending numeric codes, the system could send a poll with several emoji options, and the user would select the one that matches what's displayed on their login screen. This visual authentication method might offer better security against certain automated attacks while still leveraging federation rather than platform-specific APIs. Would this approach address some of the privacy concerns around DM-based verification?
I'm exploring a new idea called FediOTP (codename): an authentication system that uses #ActivityPub DMs to deliver one-time passwords, allowing any #fediverse account to authenticate with web services. Unlike current solutions that rely on specific APIs (#Mastodon, #Misskey), this would work with any ActivityPub-compatible server, increasing interoperability across the fediverse. Would love to hear your thoughts on potential challenges or use cases for this approach.
For those skeptical of DMs in #ActivityPub: I'm also considering an alternative verification approach using ActivityPub's Question feature. Instead of sending numeric codes, the system could send a poll with several emoji options, and the user would select the one that matches what's displayed on their login screen. This visual authentication method might offer better security against certain automated attacks while still leveraging federation rather than platform-specific APIs. Would this approach address some of the privacy concerns around DM-based verification?
I'm exploring a new idea called FediOTP (codename): an authentication system that uses #ActivityPub DMs to deliver one-time passwords, allowing any #fediverse account to authenticate with web services. Unlike current solutions that rely on specific APIs (#Mastodon, #Misskey), this would work with any ActivityPub-compatible server, increasing interoperability across the fediverse. Would love to hear your thoughts on potential challenges or use cases for this approach.
I'm exploring a new idea called FediOTP (codename): an authentication system that uses #ActivityPub DMs to deliver one-time passwords, allowing any #fediverse account to authenticate with web services. Unlike current solutions that rely on specific APIs (#Mastodon, #Misskey), this would work with any ActivityPub-compatible server, increasing interoperability across the fediverse. Would love to hear your thoughts on potential challenges or use cases for this approach.
I'm exploring a new idea called FediOTP (codename): an authentication system that uses #ActivityPub DMs to deliver one-time passwords, allowing any #fediverse account to authenticate with web services. Unlike current solutions that rely on specific APIs (#Mastodon, #Misskey), this would work with any ActivityPub-compatible server, increasing interoperability across the fediverse. Would love to hear your thoughts on potential challenges or use cases for this approach.
Ω🪬Ω New release of #FediAlgo (customizable #algorithm for your #Mastodon timeline) has a couple of cool features:
1. Configuration presets (so you can easily put discussions or trending toots at the top of your #timeline without fiddling with the individual settings)
2. A "What's Trending" section that will show you the top trending hashtags, links, and posts scraped from 30 or so of the most popular Mastodon servers
All the old features like filtering for particular languages / hashtags / users or a minimum number of replies / boosts / etc. are still there.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
Ω🪬Ω New release of #FediAlgo (customizable #algorithm for your #Mastodon timeline) has a couple of cool features:
1. Configuration presets (so you can easily put discussions or trending toots at the top of your #timeline without fiddling with the individual settings)
2. A "What's Trending" section that will show you the top trending hashtags, links, and posts scraped from 30 or so of the most popular Mastodon servers
All the old features like filtering for particular languages / hashtags / users or a minimum number of replies / boosts / etc. are still there.
Ω🪬Ω New release of #FediAlgo (customizable #algorithm for your #Mastodon timeline) has a couple of cool features:
1. Configuration presets (so you can easily put discussions or trending toots at the top of your #timeline without fiddling with the individual settings)
2. A "What's Trending" section that will show you the top trending hashtags, links, and posts scraped from 30 or so of the most popular Mastodon servers
All the old features like filtering for particular languages / hashtags / users or a minimum number of replies / boosts / etc. are still there.
Ω🪬Ω New release of #FediAlgo (customizable #algorithm for your #Mastodon timeline) has a couple of cool features:
1. Configuration presets (so you can easily put discussions or trending toots at the top of your #timeline without fiddling with the individual settings)
2. A "What's Trending" section that will show you the top trending hashtags, links, and posts scraped from 30 or so of the most popular Mastodon servers
All the old features like filtering for particular languages / hashtags / users or a minimum number of replies / boosts / etc. are still there.
Another highlight from 5.8.0: You can now embed any Fediverse post in the WordPress editor—even if it doesn’t support oEmbed! When no oEmbed handler is available, we automatically fall back to our custom embed view.
Basically: if it’s on the Fediverse, you can embed it. ✨
ALT text detailsScreenshot of a Mobilizon event embedded in the WordPress editor, showing the fallback ActivityPub preview with event title, description, and author info.
ALT text detailsScreenshot of a Pixelfed post embedded in the WordPress editor, showing the fallback ActivityPub preview with image, description, and author info
This update includes two things I’ve been especially excited about: new email templates and user-specific notification settings.
Emails now have way more information—mentions and direct messages embed the full post, and the refreshed design looks more modern and polished. New follower emails come with a profile card to help you get a sense of who’s engaging with your content.
Another highlight from 5.8.0: You can now embed any Fediverse post in the WordPress editor—even if it doesn’t support oEmbed! When no oEmbed handler is available, we automatically fall back to our custom embed view.
Basically: if it’s on the Fediverse, you can embed it. ✨
ALT text detailsScreenshot of a Mobilizon event embedded in the WordPress editor, showing the fallback ActivityPub preview with event title, description, and author info.
ALT text detailsScreenshot of a Pixelfed post embedded in the WordPress editor, showing the fallback ActivityPub preview with image, description, and author info
This update includes two things I’ve been especially excited about: new email templates and user-specific notification settings.
Emails now have way more information—mentions and direct messages embed the full post, and the refreshed design looks more modern and polished. New follower emails come with a profile card to help you get a sense of who’s engaging with your content.
This must be a part of the plan to turn Misskey into proprietary silo. ATProto and Nostr creators at least tried to solve a real problem, but arguments for creating this protocol are incredibly weak:
>Messages are in plain JSON format, which is wasteful
Another highlight from 5.8.0: You can now embed any Fediverse post in the WordPress editor—even if it doesn’t support oEmbed! When no oEmbed handler is available, we automatically fall back to our custom embed view.
Basically: if it’s on the Fediverse, you can embed it. ✨
ALT text detailsScreenshot of a Mobilizon event embedded in the WordPress editor, showing the fallback ActivityPub preview with event title, description, and author info.
ALT text detailsScreenshot of a Pixelfed post embedded in the WordPress editor, showing the fallback ActivityPub preview with image, description, and author info
This update includes two things I’ve been especially excited about: new email templates and user-specific notification settings.
Emails now have way more information—mentions and direct messages embed the full post, and the refreshed design looks more modern and polished. New follower emails come with a profile card to help you get a sense of who’s engaging with your content.
This must be a part of the plan to turn Misskey into proprietary silo. ATProto and Nostr creators at least tried to solve a real problem, but arguments for creating this protocol are incredibly weak:
>Messages are in plain JSON format, which is wasteful
🏕️ my adventures in #selfhosting - day 128 (a bit Clueless edition) 🎬
Bonjour Fedi friends!
I'm having a really interesting week: 4 adult caretakers in a house with 3 little children... as I admitted to someone on here, self-hosting is FAR easier than being a referee in fights about LEGOs 😅
Now, whenever the cousins are busy playing in the garden, I try to do a bit of work, namely: figuring out #PeerTube from the POV of a self-hoster.
Yesterday I finally understood how I could create a user account (other than "root" - the superuser created during the PeerTube installation).
Today I'm busy trying to solve another problem: how do you tell your followers you've moved to a new instance? Because yes, PeerTube is powered by #ActivityPub, but it doesn't support the MOVE function.
I rarely posted on my MakerTube account and only have 150 subscribers, who followed me when reading about it on my blog post about PeerTube.
But I have to admit, the whole "following" thing is really convoluted on PeerTube because you can follow an entire account or specific channels. And I'm a little lost regarding how I notify my followers about the change.
This must be a part of the plan to turn Misskey into proprietary silo. ATProto and Nostr creators at least tried to solve a real problem, but arguments for creating this protocol are incredibly weak:
>Messages are in plain JSON format, which is wasteful
This must be a part of the plan to turn Misskey into proprietary silo. ATProto and Nostr creators at least tried to solve a real problem, but arguments for creating this protocol are incredibly weak:
>Messages are in plain JSON format, which is wasteful
This must be a part of the plan to turn Misskey into proprietary silo. ATProto and Nostr creators at least tried to solve a real problem, but arguments for creating this protocol are incredibly weak:
>Messages are in plain JSON format, which is wasteful
This must be a part of the plan to turn Misskey into proprietary silo. ATProto and Nostr creators at least tried to solve a real problem, but arguments for creating this protocol are incredibly weak:
>Messages are in plain JSON format, which is wasteful
This must be a part of the plan to turn Misskey into proprietary silo. ATProto and Nostr creators at least tried to solve a real problem, but arguments for creating this protocol are incredibly weak:
>Messages are in plain JSON format, which is wasteful
BotKit 0.2.0 버전이 릴리스되었습니다! BotKit을 처음 접하시는 분들을 위해 간단히 소개하자면, BotKit은 TypeScript로 개발된 독립형 #ActivityPub 봇 프레임워크입니다. Mastodon, Misskey 등 다양한 #연합우주(#fediverse) 플랫폼과 상호작용할 수 있으며, 기존 플랫폼의 제약에서 벗어나 자유롭게 봇을 만들 수 있습니다.
이번 릴리스는 연합우주 봇 개발을 더 쉽고 강력하게 만들기 위한 여정에서 중요한 발걸음입니다. 커뮤니티에서 요청해 왔던 여러 기능들을 새롭게 선보입니다.
더 나은 봇 상호작용을 위한 여정
BotKit을 개발하면서 우리는 항상 봇이 더 표현력 있고 상호작용이 풍부하도록 만드는 데 집중해 왔습니다. 0.2.0 버전에서는 연합우주의 사회적 측면을 봇에 접목시켜 한 단계 더 발전시켰습니다.
커스텀 에모지로 봇의 개성 표현하기
가장 많이 요청받았던 기능 중 하나가 #커스텀_에모지 지원입니다. 이제 봇은 독특한 시각적 요소로 메시지를 돋보이게 하며 자신만의 개성을 표현할 수 있습니다.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
@snaggen My concern during the account migration is that the original server is being used for redirection. Even if the migration is successful, I’m worried that if the original server were to disappear, my account might also vanish from the new server. #activitypub
Fighting words from @molly0xfff's opening talk at the Fediverse House at SXSW 2025:
“We're facing an existential threat. We need a web that serves people not profit, a web built on protocols, not platforms…It's being built right now by people like you in communities like this one.”
Thank you, developers and denizens of the open social web.🙏🏼
Fighting words from @molly0xfff's opening talk at the Fediverse House at SXSW 2025:
“We're facing an existential threat. We need a web that serves people not profit, a web built on protocols, not platforms…It's being built right now by people like you in communities like this one.”
Thank you, developers and denizens of the open social web.🙏🏼
Fighting words from @molly0xfff's opening talk at the Fediverse House at SXSW 2025:
“We're facing an existential threat. We need a web that serves people not profit, a web built on protocols, not platforms…It's being built right now by people like you in communities like this one.”
Thank you, developers and denizens of the open social web.🙏🏼
Fighting words from @molly0xfff's opening talk at the Fediverse House at SXSW 2025:
“We're facing an existential threat. We need a web that serves people not profit, a web built on protocols, not platforms…It's being built right now by people like you in communities like this one.”
Thank you, developers and denizens of the open social web.🙏🏼
Fighting words from @molly0xfff's opening talk at the Fediverse House at SXSW 2025:
“We're facing an existential threat. We need a web that serves people not profit, a web built on protocols, not platforms…It's being built right now by people like you in communities like this one.”
Thank you, developers and denizens of the open social web.🙏🏼
My stance on #ActivityPub's adoption of JSON-LD: Since we've already decided to use JSON-LD, I hope we do it properly. However, if we hadn't used JSON-LD from the beginning, things would have been much less complicated.
My stance on #ActivityPub's adoption of JSON-LD: Since we've already decided to use JSON-LD, I hope we do it properly. However, if we hadn't used JSON-LD from the beginning, things would have been much less complicated.
My stance on #ActivityPub's adoption of JSON-LD: Since we've already decided to use JSON-LD, I hope we do it properly. However, if we hadn't used JSON-LD from the beginning, things would have been much less complicated.
My stance on #ActivityPub's adoption of JSON-LD: Since we've already decided to use JSON-LD, I hope we do it properly. However, if we hadn't used JSON-LD from the beginning, things would have been much less complicated.
My stance on #ActivityPub's adoption of JSON-LD: Since we've already decided to use JSON-LD, I hope we do it properly. However, if we hadn't used JSON-LD from the beginning, things would have been much less complicated.
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
Remember this has good and bad repercussions whether you use Flickr or not, it would be the first time an old giant joins us but also would bring many many new issues we would have to face together. Please boost for reach!
I've been reflecting lately on projects like @fedify, @hollo, and @botkit. Sometimes I wonder if I'm solving problems that very few people actually need solved. How many developers truly want to build their own #ActivityPub server from scratch?
It feels a bit like inventing shoes that let people walk on their hands all day. Would there be a viable market? How many would actually buy them?
That's the sense I get with these projects. They do have users who find them tremendously valuable, but the total user base is inherently limited. The tools serve an important function for a small audience of specialized developers.
There are moments when my motivation wavers. When the user community consists of just a handful of enthusiastic supporters, it's sometimes difficult to maintain momentum and justify the ongoing investment of time and energy.
And yet, there's something meaningful about creating specialized tools that solve complex problems well, even if they're only used by a few. Perhaps that's enough.
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
It was our honor to host the Fediverse House at SXSW 2025. It didn’t matter whether you were in the ActivityPub or AT Proto camp. We were all Team Fediverse, uniting to “move fast and break kings” in the name of building a better internet.
We’ll be sharing highlights all week on our social channels and at PeerTube, including fireside chats with @pluralistic and @pfrazee.com, clips from @davidimel's Fediverse Corner, and a panel about building communities on the social web featuring @andypiper. Thanks to all who joined us at #FediverseHouse!
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
@omi_geek But also, my livelihood / income does not depend on my social media exposure / social media graph. For other people it may be different, and current #activitypub may not be good enough. I can only comment for myself.
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.ts
import { createFederation } from "@fedify/fedify";
export const federation = createFederation<AppContext>({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
// Now we need to import this federation instance in other files
// to register dispatchers and listeners...
You can now do this:
// builder.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export const federation = await builder.build({
kv: new DbKvStore(),
queue: new RedisMessageQueue(),
// Other options...
});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
I’ve heard that #activitypub has shortcomings that prevent perfect account migration, but I don’t think moving accounts is that important. Whether you choose to stay grounded or live like a nomad is a personal choice. #fediverse#bluesky
As we consider ways to implement #ActivityPub into our FOSS Community Calendar Ecosystem platform Koalagator, I've been looking over the differing specs for how to specify the event object schema.
Have any other folk wrestled with this?Asking before I get arms deep in this stuff.
For those playing at home...
--- Schema.org - Event
Schema.org is a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet.
This specification describes the Activity vocabulary. It is intended to be used in the context of the ActivityStreams 2.0 format and provides a foundational vocabulary for activity structures, and specific activity types.
Fediverse Enhancement Proposal FEP-8a8e: A common approach to using the Event object type
ActivityStreams defines the Object Type Event. In real-world applications, the event object immediately showed the need for extension. Applications featuring Event objects have often chosen to add additional attributes and clarifications (i.e., interpretations) in order to implement their particular use case. This proposal clarifies and extends the ActivityPub standard to address the needs that have arisen in real-world implementations.
People are using microformats to mark up profiles, posts, events and other data on their personal sites, enabling developers to build applications which use this data in useful and interesting ways.
iCalendar was first defined as a standard as RFC 2445 in 1998 by the Internet Engineering Task Force (IETF). Today, iCalendar is used to import and synchronize events on various platforms, including smart phones, computer and web applications.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
I've been reflecting lately on projects like @fedify, @hollo, and @botkit. Sometimes I wonder if I'm solving problems that very few people actually need solved. How many developers truly want to build their own #ActivityPub server from scratch?
It feels a bit like inventing shoes that let people walk on their hands all day. Would there be a viable market? How many would actually buy them?
That's the sense I get with these projects. They do have users who find them tremendously valuable, but the total user base is inherently limited. The tools serve an important function for a small audience of specialized developers.
There are moments when my motivation wavers. When the user community consists of just a handful of enthusiastic supporters, it's sometimes difficult to maintain momentum and justify the ongoing investment of time and energy.
And yet, there's something meaningful about creating specialized tools that solve complex problems well, even if they're only used by a few. Perhaps that's enough.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
I've been reflecting lately on projects like @fedify, @hollo, and @botkit. Sometimes I wonder if I'm solving problems that very few people actually need solved. How many developers truly want to build their own #ActivityPub server from scratch?
It feels a bit like inventing shoes that let people walk on their hands all day. Would there be a viable market? How many would actually buy them?
That's the sense I get with these projects. They do have users who find them tremendously valuable, but the total user base is inherently limited. The tools serve an important function for a small audience of specialized developers.
There are moments when my motivation wavers. When the user community consists of just a handful of enthusiastic supporters, it's sometimes difficult to maintain momentum and justify the ongoing investment of time and energy.
And yet, there's something meaningful about creating specialized tools that solve complex problems well, even if they're only used by a few. Perhaps that's enough.
I've been reflecting lately on projects like @fedify, @hollo, and @botkit. Sometimes I wonder if I'm solving problems that very few people actually need solved. How many developers truly want to build their own #ActivityPub server from scratch?
It feels a bit like inventing shoes that let people walk on their hands all day. Would there be a viable market? How many would actually buy them?
That's the sense I get with these projects. They do have users who find them tremendously valuable, but the total user base is inherently limited. The tools serve an important function for a small audience of specialized developers.
There are moments when my motivation wavers. When the user community consists of just a handful of enthusiastic supporters, it's sometimes difficult to maintain momentum and justify the ongoing investment of time and energy.
And yet, there's something meaningful about creating specialized tools that solve complex problems well, even if they're only used by a few. Perhaps that's enough.
I've been reflecting lately on projects like @fedify, @hollo, and @botkit. Sometimes I wonder if I'm solving problems that very few people actually need solved. How many developers truly want to build their own #ActivityPub server from scratch?
It feels a bit like inventing shoes that let people walk on their hands all day. Would there be a viable market? How many would actually buy them?
That's the sense I get with these projects. They do have users who find them tremendously valuable, but the total user base is inherently limited. The tools serve an important function for a small audience of specialized developers.
There are moments when my motivation wavers. When the user community consists of just a handful of enthusiastic supporters, it's sometimes difficult to maintain momentum and justify the ongoing investment of time and energy.
And yet, there's something meaningful about creating specialized tools that solve complex problems well, even if they're only used by a few. Perhaps that's enough.
It was our honor to host the Fediverse House at SXSW 2025. It didn’t matter whether you were in the ActivityPub or AT Proto camp. We were all Team Fediverse, uniting to “move fast and break kings” in the name of building a better internet.
It was our honor to host the Fediverse House at SXSW 2025. It didn’t matter whether you were in the ActivityPub or AT Proto camp. We were all Team Fediverse, uniting to “move fast and break kings” in the name of building a better internet.
We’ll be sharing highlights all week on our social channels and at PeerTube, including fireside chats with @pluralistic and @pfrazee.com, clips from @davidimel's Fediverse Corner, and a panel about building communities on the social web featuring @andypiper. Thanks to all who joined us at #FediverseHouse!
We’ll be sharing highlights all week on our social channels and at PeerTube, including fireside chats with @pluralistic and @pfrazee.com, clips from @davidimel's Fediverse Corner, and a panel about building communities on the social web featuring @andypiper. Thanks to all who joined us at #FediverseHouse!
It was our honor to host the Fediverse House at SXSW 2025. It didn’t matter whether you were in the ActivityPub or AT Proto camp. We were all Team Fediverse, uniting to “move fast and break kings” in the name of building a better internet.
Does anyone know of a Common Lisp activitypub library that is complete enough to implement subscription to accounts, tracking subscribers and posting messages?
I want to build a small service which allows users to tag it in a message (or users can ask the serviceto subscribeto it, in which case it will absorb all mesaages), and conaume those messages, and then post updates to its main feed.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
#フェディバース(#fediverse)用のボットを作りたいですか?#BotKit by Fedifyを使えば、わずか数行のコードでスタンドアロンのActivityPubボットを構築できます!従来のMastodonやMisskeyボットとは異なり、BotKitはプラットフォームの制約なしに完全なActivityPubサーバーを作成できます。
We’ll be sharing highlights all week on our social channels and at PeerTube, including fireside chats with @pluralistic and @pfrazee.com, clips from @davidimel's Fediverse Corner, and a panel about building communities on the social web featuring @andypiper. Thanks to all who joined us at #FediverseHouse!
It was our honor to host the Fediverse House at SXSW 2025. It didn’t matter whether you were in the ActivityPub or AT Proto camp. We were all Team Fediverse, uniting to “move fast and break kings” in the name of building a better internet.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
BotKit 0.2.0 버전이 릴리스되었습니다! BotKit을 처음 접하시는 분들을 위해 간단히 소개하자면, BotKit은 TypeScript로 개발된 독립형 #ActivityPub 봇 프레임워크입니다. Mastodon, Misskey 등 다양한 #연합우주(#fediverse) 플랫폼과 상호작용할 수 있으며, 기존 플랫폼의 제약에서 벗어나 자유롭게 봇을 만들 수 있습니다.
이번 릴리스는 연합우주 봇 개발을 더 쉽고 강력하게 만들기 위한 여정에서 중요한 발걸음입니다. 커뮤니티에서 요청해 왔던 여러 기능들을 새롭게 선보입니다.
더 나은 봇 상호작용을 위한 여정
BotKit을 개발하면서 우리는 항상 봇이 더 표현력 있고 상호작용이 풍부하도록 만드는 데 집중해 왔습니다. 0.2.0 버전에서는 연합우주의 사회적 측면을 봇에 접목시켜 한 단계 더 발전시켰습니다.
커스텀 에모지로 봇의 개성 표현하기
가장 많이 요청받았던 기능 중 하나가 #커스텀_에모지 지원입니다. 이제 봇은 독특한 시각적 요소로 메시지를 돋보이게 하며 자신만의 개성을 표현할 수 있습니다.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
Coming soon in #BotKit 0.2.0: Native #quote post support!
We're excited to share a preview of the upcoming quoting features in BotKit 0.2.0. This update will make it easier for your bots to engage with quoted content across the fediverse.
The quoting feature set includes:
Detecting when someone quotes your bot's posts with the new Bot.onQuote event handler
Here's a quick example of how you can use the quote detection:
bot.onQuote = async (session, quote) => {
// The quote parameter is a Message object representing the post that quoted your bot
await quote.reply(text`Thanks for quoting my post, ${quote.actor}!`);
// You can access the original quoted message
const originalPost = quote.quoteTarget;
console.log(`Original message: ${originalPost?.text}`);
};
And creating quote posts is just as simple:
// Quote in a new post
await session.publish(
text`I'm quoting this interesting message!`,
{ quoteTarget: someMessage }
);
// Or quote in a reply
await message.reply(
text`Interesting point! I'm quoting another relevant post here.`,
{ quoteTarget: anotherMessage }
);
Remember that quoting behavior may vary across different #ActivityPub implementations—some platforms like Misskey display quotes prominently, while others like Mastodon might implement them differently.
Want to try these features right now? You can install the development version from JSR:
deno add jsr:@fedify/botkit@0.2.0-dev.90+d6ab4bdc
We're looking forward to seeing how you use these quoting capabilities in your bots!
In case you weren't aware, #Fedify has both #Discord and #Matrix communities where you can get help, discuss features, or just chat about #ActivityPub and federated social networks.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
BotKit 0.2.0 버전이 릴리스되었습니다! BotKit을 처음 접하시는 분들을 위해 간단히 소개하자면, BotKit은 TypeScript로 개발된 독립형 #ActivityPub 봇 프레임워크입니다. Mastodon, Misskey 등 다양한 #연합우주(#fediverse) 플랫폼과 상호작용할 수 있으며, 기존 플랫폼의 제약에서 벗어나 자유롭게 봇을 만들 수 있습니다.
이번 릴리스는 연합우주 봇 개발을 더 쉽고 강력하게 만들기 위한 여정에서 중요한 발걸음입니다. 커뮤니티에서 요청해 왔던 여러 기능들을 새롭게 선보입니다.
더 나은 봇 상호작용을 위한 여정
BotKit을 개발하면서 우리는 항상 봇이 더 표현력 있고 상호작용이 풍부하도록 만드는 데 집중해 왔습니다. 0.2.0 버전에서는 연합우주의 사회적 측면을 봇에 접목시켜 한 단계 더 발전시켰습니다.
커스텀 에모지로 봇의 개성 표현하기
가장 많이 요청받았던 기능 중 하나가 #커스텀_에모지 지원입니다. 이제 봇은 독특한 시각적 요소로 메시지를 돋보이게 하며 자신만의 개성을 표현할 수 있습니다.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
BotKit 0.2.0 버전이 릴리스되었습니다! BotKit을 처음 접하시는 분들을 위해 간단히 소개하자면, BotKit은 TypeScript로 개발된 독립형 #ActivityPub 봇 프레임워크입니다. Mastodon, Misskey 등 다양한 #연합우주(#fediverse) 플랫폼과 상호작용할 수 있으며, 기존 플랫폼의 제약에서 벗어나 자유롭게 봇을 만들 수 있습니다.
이번 릴리스는 연합우주 봇 개발을 더 쉽고 강력하게 만들기 위한 여정에서 중요한 발걸음입니다. 커뮤니티에서 요청해 왔던 여러 기능들을 새롭게 선보입니다.
더 나은 봇 상호작용을 위한 여정
BotKit을 개발하면서 우리는 항상 봇이 더 표현력 있고 상호작용이 풍부하도록 만드는 데 집중해 왔습니다. 0.2.0 버전에서는 연합우주의 사회적 측면을 봇에 접목시켜 한 단계 더 발전시켰습니다.
커스텀 에모지로 봇의 개성 표현하기
가장 많이 요청받았던 기능 중 하나가 #커스텀_에모지 지원입니다. 이제 봇은 독특한 시각적 요소로 메시지를 돋보이게 하며 자신만의 개성을 표현할 수 있습니다.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
BotKit 0.2.0 버전이 릴리스되었습니다! BotKit을 처음 접하시는 분들을 위해 간단히 소개하자면, BotKit은 TypeScript로 개발된 독립형 #ActivityPub 봇 프레임워크입니다. Mastodon, Misskey 등 다양한 #연합우주(#fediverse) 플랫폼과 상호작용할 수 있으며, 기존 플랫폼의 제약에서 벗어나 자유롭게 봇을 만들 수 있습니다.
이번 릴리스는 연합우주 봇 개발을 더 쉽고 강력하게 만들기 위한 여정에서 중요한 발걸음입니다. 커뮤니티에서 요청해 왔던 여러 기능들을 새롭게 선보입니다.
더 나은 봇 상호작용을 위한 여정
BotKit을 개발하면서 우리는 항상 봇이 더 표현력 있고 상호작용이 풍부하도록 만드는 데 집중해 왔습니다. 0.2.0 버전에서는 연합우주의 사회적 측면을 봇에 접목시켜 한 단계 더 발전시켰습니다.
커스텀 에모지로 봇의 개성 표현하기
가장 많이 요청받았던 기능 중 하나가 #커스텀_에모지 지원입니다. 이제 봇은 독특한 시각적 요소로 메시지를 돋보이게 하며 자신만의 개성을 표현할 수 있습니다.
We're pleased to announce the release of BotKit 0.2.0! For those new to our project, #BotKit is a #TypeScript framework for creating standalone #ActivityPub bots that can interact with Mastodon, Misskey, and other #fediverse platforms without the constraints of these existing platforms.
This release marks an important step in our journey to make fediverse bot development more accessible and powerful, introducing several features that our community has been requesting.
The Journey to Better Bot Interactions
In building BotKit, we've always focused on making bots more expressive and interactive. With version 0.2.0, we're taking this to the next level by bringing the social aspects of the fediverse to your bots.
Expressing Your Bot's Personality with Custom Emojis
One of the most requested features has been #custom_emoji support. Now your bots can truly express their personality with unique visuals that make their messages stand out.
// Define custom emojis for your bot
const emojis = bot.addCustomEmojis({
botkit: {
file: `${import.meta.dirname}/images/botkit.png`,
type: "image/png"
},
fedify: {
url: "https://fedify.dev/logo.png",
type: "image/png"
}
});
// Use these custom emojis in your messages
await session.publish(
text`BotKit ${customEmoji(emojis.botkit)} is powered by Fedify ${customEmoji(emojis.fedify)}`
);
With this new API, you can:
Add custom emojis to your bot with Bot.addCustomEmojis()
Include these emojis in messages with the customEmoji() function
Communication isn't just about posting messages—it's also about responding to others. The new reaction system creates natural interaction points between your bot and its followers:
// React to a message with a standard Unicode emoji
await message.react(emoji`👍`);
// Or use one of your custom emojis as a reaction
await message.react(emojis.botkit);
// Create a responsive bot that acknowledges reactions
bot.onReact = async (session, reaction) => {
await session.publish(
text`Thanks for reacting with ${reaction.emoji} to my message, ${reaction.actor}!`,
{ visibility: "direct" }
);
};
Discussions often involve referencing what others have said. Our new #quote support enables more cohesive conversation threads:
// Quote another message in your bot's post
await session.publish(
text`Responding to this interesting point...`,
{ quoteTarget: originalMessage }
);
// Handle when users quote your bot's messages
bot.onQuote = async (session, quoteMessage) => {
await session.publish(
text`Thanks for sharing my thoughts, ${quoteMessage.actor}!`,
{ visibility: "direct" }
);
};
With these simple steps, you're ready to create or upgrade your fediverse bot with our latest features.
Looking Forward
BotKit 0.2.0 represents our ongoing commitment to making fediverse bot development accessible, powerful, and enjoyable. We believe these new features will help your bots become more engaging and interactive members of the fediverse community.
For complete docs and more examples, visit our docs site.
Thank you to everyone who contributed to this release through feedback, feature requests, and code contributions. The BotKit community continues to grow, and we're excited to see what you'll create!
BotKit is powered by Fedify, a lower-level framework for creating ActivityPub server applications.
#Fread 1.3.1 has been released, the release note is as follows: 1. Now supports mirror URLs🎉🎉🎉. 2. Interaction experience has been optimized. 3. A few bugs have been fixed.
Coming soon in #BotKit 0.2.0: Native #quote post support!
We're excited to share a preview of the upcoming quoting features in BotKit 0.2.0. This update will make it easier for your bots to engage with quoted content across the fediverse.
The quoting feature set includes:
Detecting when someone quotes your bot's posts with the new Bot.onQuote event handler
Here's a quick example of how you can use the quote detection:
bot.onQuote = async (session, quote) => {
// The quote parameter is a Message object representing the post that quoted your bot
await quote.reply(text`Thanks for quoting my post, ${quote.actor}!`);
// You can access the original quoted message
const originalPost = quote.quoteTarget;
console.log(`Original message: ${originalPost?.text}`);
};
And creating quote posts is just as simple:
// Quote in a new post
await session.publish(
text`I'm quoting this interesting message!`,
{ quoteTarget: someMessage }
);
// Or quote in a reply
await message.reply(
text`Interesting point! I'm quoting another relevant post here.`,
{ quoteTarget: anotherMessage }
);
Remember that quoting behavior may vary across different #ActivityPub implementations—some platforms like Misskey display quotes prominently, while others like Mastodon might implement them differently.
Want to try these features right now? You can install the development version from JSR:
deno add jsr:@fedify/botkit@0.2.0-dev.90+d6ab4bdc
We're looking forward to seeing how you use these quoting capabilities in your bots!
Coming soon in #BotKit 0.2.0: Native #quote post support!
We're excited to share a preview of the upcoming quoting features in BotKit 0.2.0. This update will make it easier for your bots to engage with quoted content across the fediverse.
The quoting feature set includes:
Detecting when someone quotes your bot's posts with the new Bot.onQuote event handler
Here's a quick example of how you can use the quote detection:
bot.onQuote = async (session, quote) => {
// The quote parameter is a Message object representing the post that quoted your bot
await quote.reply(text`Thanks for quoting my post, ${quote.actor}!`);
// You can access the original quoted message
const originalPost = quote.quoteTarget;
console.log(`Original message: ${originalPost?.text}`);
};
And creating quote posts is just as simple:
// Quote in a new post
await session.publish(
text`I'm quoting this interesting message!`,
{ quoteTarget: someMessage }
);
// Or quote in a reply
await message.reply(
text`Interesting point! I'm quoting another relevant post here.`,
{ quoteTarget: anotherMessage }
);
Remember that quoting behavior may vary across different #ActivityPub implementations—some platforms like Misskey display quotes prominently, while others like Mastodon might implement them differently.
Want to try these features right now? You can install the development version from JSR:
deno add jsr:@fedify/botkit@0.2.0-dev.90+d6ab4bdc
We're looking forward to seeing how you use these quoting capabilities in your bots!
Coming soon in #BotKit 0.2.0: Native #quote post support!
We're excited to share a preview of the upcoming quoting features in BotKit 0.2.0. This update will make it easier for your bots to engage with quoted content across the fediverse.
The quoting feature set includes:
Detecting when someone quotes your bot's posts with the new Bot.onQuote event handler
Here's a quick example of how you can use the quote detection:
bot.onQuote = async (session, quote) => {
// The quote parameter is a Message object representing the post that quoted your bot
await quote.reply(text`Thanks for quoting my post, ${quote.actor}!`);
// You can access the original quoted message
const originalPost = quote.quoteTarget;
console.log(`Original message: ${originalPost?.text}`);
};
And creating quote posts is just as simple:
// Quote in a new post
await session.publish(
text`I'm quoting this interesting message!`,
{ quoteTarget: someMessage }
);
// Or quote in a reply
await message.reply(
text`Interesting point! I'm quoting another relevant post here.`,
{ quoteTarget: anotherMessage }
);
Remember that quoting behavior may vary across different #ActivityPub implementations—some platforms like Misskey display quotes prominently, while others like Mastodon might implement them differently.
Want to try these features right now? You can install the development version from JSR:
deno add jsr:@fedify/botkit@0.2.0-dev.90+d6ab4bdc
We're looking forward to seeing how you use these quoting capabilities in your bots!
Coming soon in #BotKit 0.2.0: Native #quote post support!
We're excited to share a preview of the upcoming quoting features in BotKit 0.2.0. This update will make it easier for your bots to engage with quoted content across the fediverse.
The quoting feature set includes:
Detecting when someone quotes your bot's posts with the new Bot.onQuote event handler
Here's a quick example of how you can use the quote detection:
bot.onQuote = async (session, quote) => {
// The quote parameter is a Message object representing the post that quoted your bot
await quote.reply(text`Thanks for quoting my post, ${quote.actor}!`);
// You can access the original quoted message
const originalPost = quote.quoteTarget;
console.log(`Original message: ${originalPost?.text}`);
};
And creating quote posts is just as simple:
// Quote in a new post
await session.publish(
text`I'm quoting this interesting message!`,
{ quoteTarget: someMessage }
);
// Or quote in a reply
await message.reply(
text`Interesting point! I'm quoting another relevant post here.`,
{ quoteTarget: anotherMessage }
);
Remember that quoting behavior may vary across different #ActivityPub implementations—some platforms like Misskey display quotes prominently, while others like Mastodon might implement them differently.
Want to try these features right now? You can install the development version from JSR:
deno add jsr:@fedify/botkit@0.2.0-dev.90+d6ab4bdc
We're looking forward to seeing how you use these quoting capabilities in your bots!
Coming soon in #BotKit 0.2.0: Native #quote post support!
We're excited to share a preview of the upcoming quoting features in BotKit 0.2.0. This update will make it easier for your bots to engage with quoted content across the fediverse.
The quoting feature set includes:
Detecting when someone quotes your bot's posts with the new Bot.onQuote event handler
Here's a quick example of how you can use the quote detection:
bot.onQuote = async (session, quote) => {
// The quote parameter is a Message object representing the post that quoted your bot
await quote.reply(text`Thanks for quoting my post, ${quote.actor}!`);
// You can access the original quoted message
const originalPost = quote.quoteTarget;
console.log(`Original message: ${originalPost?.text}`);
};
And creating quote posts is just as simple:
// Quote in a new post
await session.publish(
text`I'm quoting this interesting message!`,
{ quoteTarget: someMessage }
);
// Or quote in a reply
await message.reply(
text`Interesting point! I'm quoting another relevant post here.`,
{ quoteTarget: anotherMessage }
);
Remember that quoting behavior may vary across different #ActivityPub implementations—some platforms like Misskey display quotes prominently, while others like Mastodon might implement them differently.
Want to try these features right now? You can install the development version from JSR:
deno add jsr:@fedify/botkit@0.2.0-dev.90+d6ab4bdc
We're looking forward to seeing how you use these quoting capabilities in your bots!
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
In case you weren't aware, #Fedify has both #Discord and #Matrix communities where you can get help, discuss features, or just chat about #ActivityPub and federated social networks.
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
Eine Grundlage für algorithmische Timeline wäre eine standardisierte Vegleichbarkeit von Inhalten.
Das wichtigste hierbei sind für uns eindeutige Links basierend auf wikidata, OSM und dem Restwissen der Welt. Um z.B. meine Perle zu beschreiben, ist der primäre Link https://www.wikidata.org/wiki/Q1055 und ein eindeutiges as:Profile speichert die OSM Links und etliche andere. Dies bedeutet gleichzeitig, das wir maschinenlesbar das Wissen haben, über was geredet wird und in allen Sprachen die Beschreibungen, Texte, commons etc.
We're excited to announce that #BotKit 0.2.0 will introduce custom emoji support! This feature allows your bots to express themselves with more personality and engagement.
What's included:
Add custom emojis to your bot with Bot.addCustomEmojis()
Use emoji in messages with the customEmoji() function
Support for both local image files and remote URLs as emoji sources
We're excited to announce that #BotKit 0.2.0 will introduce custom emoji support! This feature allows your bots to express themselves with more personality and engagement.
What's included:
Add custom emojis to your bot with Bot.addCustomEmojis()
Use emoji in messages with the customEmoji() function
Support for both local image files and remote URLs as emoji sources
We're excited to announce that #BotKit 0.2.0 will introduce custom emoji support! This feature allows your bots to express themselves with more personality and engagement.
What's included:
Add custom emojis to your bot with Bot.addCustomEmojis()
Use emoji in messages with the customEmoji() function
Support for both local image files and remote URLs as emoji sources
We're excited to announce that #BotKit 0.2.0 will introduce custom emoji support! This feature allows your bots to express themselves with more personality and engagement.
What's included:
Add custom emojis to your bot with Bot.addCustomEmojis()
Use emoji in messages with the customEmoji() function
Support for both local image files and remote URLs as emoji sources
In case you weren't aware, #Fedify has both #Discord and #Matrix communities where you can get help, discuss features, or just chat about #ActivityPub and federated social networks.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
In case you weren't aware, #Fedify has both #Discord and #Matrix communities where you can get help, discuss features, or just chat about #ActivityPub and federated social networks.
In case you weren't aware, #Fedify has both #Discord and #Matrix communities where you can get help, discuss features, or just chat about #ActivityPub and federated social networks.
In case you weren't aware, #Fedify has both #Discord and #Matrix communities where you can get help, discuss features, or just chat about #ActivityPub and federated social networks.
In case you weren't aware, #Fedify has both #Discord and #Matrix communities where you can get help, discuss features, or just chat about #ActivityPub and federated social networks.
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
Upon reading more about the Puxelfed follower bug - and realising it’s a fundamental problem with the ActivityPub protocol - I can’t see much point in staying follower-only on Mastodon. I’ll go public and just keep my mouth shut about anything even vaguely related to work.
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
Both Mastodon and Bluesky offer decentralized alternatives, but only one puts users first. While Bluesky’s VC-backed model serves shareholder interests, Mastodon’s nonprofit structure safeguards a truly open internet. The future of social media shouldn’t be for sale.
Both Mastodon and Bluesky offer decentralized alternatives, but only one puts users first. While Bluesky’s VC-backed model serves shareholder interests, Mastodon’s nonprofit structure safeguards a truly open internet. The future of social media shouldn’t be for sale.
Both Mastodon and Bluesky offer decentralized alternatives, but only one puts users first. While Bluesky’s VC-backed model serves shareholder interests, Mastodon’s nonprofit structure safeguards a truly open internet. The future of social media shouldn’t be for sale.
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
Another cool ActivityPub project I came across today - BadgeFed.
From the point of view of your regular Fediverse instance - I could foresee this being used to recognise members for financial contributions, being moderators, Creating x number of Peertube videos, y posts on Mastodon, winning community contests, stuff like that. Really cool and I will definitely look into this further a bit further down the line.
@osma This just proves #ATProtocol isn't federated and it's all marketing scam. @bsky.app has been nothing but false promises, wasn't it suppose to federate to #ActivityPub natively? Welp, that never happened.
I'm disabling the #bridgy until there are other AT Protocol instances that aren't corporation involved.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
In Episode 642 of Do the Woo, host Matthias Pfefferle brings us another Open Web Conversations and dives into the world of decentralized social networks and the open web, specifically focusing on the Fediverse, with guest André Menrath.
André shares his unconventional journey into software development, driven by his passion for events and democracy, and his vision for a federated future. They explore the challenges and opportunities in integrating WordPress with the Fediverse, discussing André's innovative plugins bridging WordPress events with ActivityPub.
The conversation sheds light on the potential for WordPress to become a dominant platform in the Fediverse, hosting diverse content types while maintaining an open and interconnected web. Join them as they navigate the technical and social landscape of creating a truly decentralized internet.
[…]
ALT text detailsBring Federated Events to Your WordPress Site with André Menrath
Another cool ActivityPub project I came across today - BadgeFed.
From the point of view of your regular Fediverse instance - I could foresee this being used to recognise members for financial contributions, being moderators, Creating x number of Peertube videos, y posts on Mastodon, winning community contests, stuff like that. Really cool and I will definitely look into this further a bit further down the line.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Among other things, this release brings more helpful details to Site Health and upgrades the Reply block—it now embeds the referenced post, even if oEmbed isn’t supported!
ALT text detailsWordPress editor showing a Federated Reply block with an embedded post from PixelFed, featuring a photo of a bakery display full of pastries. The sidebar shows the ‘Embed Post’ setting toggled on.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation =