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.
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.
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.
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.
@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.
@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:
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.
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...
meta/threads invading #fediverse doesn’t feel like “growth”. it feels like a trojan horse.
this place was built on care, consent, moderation, open tech, and trust. meta doesn’t share those values, they’ve spent years doing the opposite.
they’re not “joining” fediverse. they’re trying to shape it in their image. if we don’t push back, we’ll end up with the same algorithmic garbage we came here to escape.
this isn’t gatekeeping. it’s protecting something rare.
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.
meta/threads invading #fediverse doesn’t feel like “growth”. it feels like a trojan horse.
this place was built on care, consent, moderation, open tech, and trust. meta doesn’t share those values, they’ve spent years doing the opposite.
they’re not “joining” fediverse. they’re trying to shape it in their image. if we don’t push back, we’ll end up with the same algorithmic garbage we came here to escape.
this isn’t gatekeeping. it’s protecting something rare.
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
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.
🔥 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!
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 = 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.
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.
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
Starting to feel, more and more, like I need to build my own #ActivityPub thing. This book sounds like a good foundation to build off of. Authored by @evan@cosocial.ca.
Starting to feel, more and more, like I need to build my own #ActivityPub thing. This book sounds like a good foundation to build off of. Authored by @evan@cosocial.ca.
UPDATE: A blog (that is federated) was created for communicate the progress, follow @badgefed
--
I am creating a #ActivityPub minimalistic implementation of a badge system similar to Credly, built using #dotnet and leveraging the #Fediverse
I have issued a first badge, the idea is to decentralize the verification systems, and allow organizations to self-certify. It is incredible that organizations like Microsoft or Non-Profits pay thousands of dollars to companies like Pearson to just provide "verified" badges. Similar to mastodons installed in social-dot-something, thinkg of badges<dot> mozilla<dot>com , certifications<dot>myschooldistrict<dot>com. Or even a podcast emitting a badge for its guests, with the verification in the domain.
ActivityPub already offers a secure way to sign artifacts and interact between actors. The fediverse already have people with profiles, a social graph as @mike says, ready to use. Think of how LetsEncrypt disrupted that market of few actors selling certificates for websites.
I have a functional poc, @fediverse is not a mastodon, pledora or blog, it is an actor in a badge system, but you can follow it in Mastodon. Its badges will show in #mastodon but they are not notes or articles. If you want to learn more, follow me, I will be sharing the progress here. Or follow the github project here: https://github.com/tryvocalcat/activitypub-badges
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.
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.
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.
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.
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.
By quickly glancing through the ATP docs, it seems like a much more pleasant experience to work with over AP but there's probably more to it than just the technical part.
Can anyone #help me understand any atproto downsides?
#연합우주(#fediverse)를 위한 봇을 만들고 싶으신가요? #BotKit by Fedify를 사용하면 몇 줄의 코드만으로 독립형 #ActivityPub 봇을 구축할 수 있습니다! 일반적인 Mastodon 또는 Misskey 봇과 달리, BotKit은 플랫폼 제약 없이 완전한 ActivityPub 서버를 만들 수 있게 도와줍니다.
#フェディバース（#fediverse）用のボットを作りたいですか？#BotKit by Fedifyを使えば、わずか数行のコードでスタンドアロンのActivityPubボットを構築できます！従来のMastodonやMisskeyボットとは異なり、BotKitはプラットフォームの制約なしに完全なActivityPubサーバーを作成できます。
#フェディバース（#fediverse）用のボットを作りたいですか？#BotKit by Fedifyを使えば、わずか数行のコードでスタンドアロンのActivityPubボットを構築できます！従来のMastodonやMisskeyボットとは異なり、BotKitはプラットフォームの制約なしに完全なActivityPubサーバーを作成できます。
#연합우주(#fediverse)를 위한 봇을 만들고 싶으신가요? #BotKit by Fedify를 사용하면 몇 줄의 코드만으로 독립형 #ActivityPub 봇을 구축할 수 있습니다! 일반적인 Mastodon 또는 Misskey 봇과 달리, BotKit은 플랫폼 제약 없이 완전한 ActivityPub 서버를 만들 수 있게 도와줍니다.
#연합우주(#fediverse)를 위한 봇을 만들고 싶으신가요? #BotKit by Fedify를 사용하면 몇 줄의 코드만으로 독립형 #ActivityPub 봇을 구축할 수 있습니다! 일반적인 Mastodon 또는 Misskey 봇과 달리, BotKit은 플랫폼 제약 없이 완전한 ActivityPub 서버를 만들 수 있게 도와줍니다.
#フェディバース（#fediverse）用のボットを作りたいですか？#BotKit by Fedifyを使えば、わずか数行のコードでスタンドアロンのActivityPubボットを構築できます！従来のMastodonやMisskeyボットとは異なり、BotKitはプラットフォームの制約なしに完全なActivityPubサーバーを作成できます。
I believe this is possible and can be built over the ActivityPub protocol, based on what we've learned from the library of things, makerspaces, commons, permaculture, alternative currencies, and so many other amazing concepts and their incredible success stories...
I am currently drafting this project. Let me know if it makes any sense to you...
I believe this is possible and can be built over the ActivityPub protocol, based on what we've learned from the library of things, makerspaces, commons, permaculture, alternative currencies, and so many other amazing concepts and their incredible success stories...
I am currently drafting this project. Let me know if it makes any sense to you...
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
It's nice when you finish a bit of work that goes well and requires no yak shaving in order to get done.
For the past week I've been struggling again with the #frontend bits of #ONI, the single user #ActivityPub server, when I decided to take a little break and work on something else.
So today I've add support for the traversal resistant file API for the FS storage part of #GoActivityPub. I'm still waiting for the symlink support to be added in the next major #Go version, but other than that we've increased robustness a little bit despite it being designed mainly for full transparency development work and not being run in production environments.
@KazukyAkayashi@feudjais j'ai souvent entendu du bien de Movim côté UI/UX, peux-tu décrire ce que tu n'aimes pas ?
Sinon j'ai développé avec Libervia une passerelle ActivityPub <=> XMPP grâce à une subvention NLnet/NGi0 qui devrait fonctionner avec Movim. Je suis très pris et je n'ai pas encore pu faire une release officielle, mais des gens utilisent déjà. https://libervia.org/__b/doc/backend/components.html#activitypub-gateway
Looks like @pixelfed and/or @Tusky might have fixed some issue with notifications? I'm getting quite a few notifications for faves ⭐ from 2 months ago.
Don't forget to support your Fedi admins in any way you can.
Fediverse isn't run by multi-billion dollar companies, and in a lot of cases, is simply run by kind folks who just want to have a nice social media platform.
Therefore, there's a high chance that the server costs come out of their pockets.
Storing #RDF or #LinkedData is the easy part (I am working on #activitypub client, so everything is JSON-LD anyway), but as soon as I need to formulate queries like "Give me list of the activities from all the actors who are on the following collection of my user, sorted by published/updated date", the amount of data mangling that I need to do is already making me think "ok, why don't I just push all of this to sqlite?"
I did some changes to my almost static #activitypub enabled blog, which enables @blog and @badgefed so now it can show the real number of followers.
I have only updated the #badgefed one. I am planning to migrate @vocalcat to such format because having a bot account does not make sense for the #fediverse. I rather post real uodates.
I did some changes to my almost static #activitypub enabled blog, which enables @blog and @badgefed so now it can show the real number of followers.
I have only updated the #badgefed one. I am planning to migrate @vocalcat to such format because having a bot account does not make sense for the #fediverse. I rather post real uodates.
I did some changes to my almost static #activitypub enabled blog, which enables @blog and @badgefed so now it can show the real number of followers.
I have only updated the #badgefed one. I am planning to migrate @vocalcat to such format because having a bot account does not make sense for the #fediverse. I rather post real uodates.
why /me so silent, you ask … databases are boring but the #deno#denokv#activitypub#normalization#i18n including proper indexing with ulid, geohash, types-hash (when,where,what) and text-similarity sorting and cid stuff MUST be done properly for all the activities side effects. ¯\_(ツ)_/¯
Unfortunately I need to cancel the #SocialCG#ActivityPub issue triage today. I had a travel mixup and won't have a quiet, private place to hold the meeting. Sorry for the late notice, and please plan on attending next week.
I don't have any demo to show you yet but i needed a way to announce and ask for things - so if you care, please follow! Here is how admin panel looks so far.
Spreading the info and participating in discussion highly appreciated! ❤️
I don't have any demo to show you yet but i needed a way to announce and ask for things - so if you care, please follow! Here is how admin panel looks so far.
Spreading the info and participating in discussion highly appreciated! ❤️
FYI: Abelio will provide couple of ways of publishing visual contents. One of them is part of the article editor and it let's you organise multiple images in a form of a flexible grid you can arrange as needed.
I don't have any demo to show you yet but i needed a way to announce and ask for things - so if you care, please follow! Here is how admin panel looks so far.
Spreading the info and participating in discussion highly appreciated! ❤️
You can put web+ap URIs into a message (or room description) and ideally a click on those will open your Mastodon client. However if no installed app supports those (the only app that I’m aware of is Fedilab) Conversations will open a browser instead.
Currently no app will create web+ap links but it is fairly easy to handcraft them.
* A Mastodon import (beta) * Improvements to the Welcome-Page * Basic Move functionality * A bunch of Outbox improvements * A ton of smaller changes and fixes
You can put web+ap URIs into a message (or room description) and ideally a click on those will open your Mastodon client. However if no installed app supports those (the only app that I’m aware of is Fedilab) Conversations will open a browser instead.
Currently no app will create web+ap links but it is fairly easy to handcraft them.
It’s a jam-packed release, led by a beta importer to bring your Mastodon posts into WordPress—plus improvements to make setup smoother when activating the plugin.
Congrats to @johnonolan and the team at Ghost, which today announced a public beta for users to connect their publications to the fediverse. If you're in their beta, you'll be able to find, follow and interact with people and publications on platforms including Ghost, WordPress, Threads, Mastodon, BlueSky, Flipboard and more. Get details in the blogpost here. If you want to know more about Ghost's approach to decentralization and the open social web, check out John's DotSocial conversation with @mike at the second link.
Congrats to @johnonolan and the team at Ghost, which today announced a public beta for users to connect their publications to the fediverse. If you're in their beta, you'll be able to find, follow and interact with people and publications on platforms including Ghost, WordPress, Threads, Mastodon, BlueSky, Flipboard and more. Get details in the blogpost here. If you want to know more about Ghost's approach to decentralization and the open social web, check out John's DotSocial conversation with @mike at the second link.
Congrats to @johnonolan and the team at Ghost, which today announced a public beta for users to connect their publications to the fediverse. If you're in their beta, you'll be able to find, follow and interact with people and publications on platforms including Ghost, WordPress, Threads, Mastodon, BlueSky, Flipboard and more. Get details in the blogpost here. If you want to know more about Ghost's approach to decentralization and the open social web, check out John's DotSocial conversation with @mike at the second link.
Listen, as someone that follows many fediverse platforms, @thisismissem is one of the most active in the community. She has jumped in and assisted with security and ActivityPub issues across them all.
Please consider contributing to her tip jar if you can, especially for this last bit of advocacy work. Find her contribution options on her profile.
Listen, as someone that follows many fediverse platforms, @thisismissem is one of the most active in the community. She has jumped in and assisted with security and ActivityPub issues across them all.
Please consider contributing to her tip jar if you can, especially for this last bit of advocacy work. Find her contribution options on her profile.
Listen, as someone that follows many fediverse platforms, @thisismissem is one of the most active in the community. She has jumped in and assisted with security and ActivityPub issues across them all.
Please consider contributing to her tip jar if you can, especially for this last bit of advocacy work. Find her contribution options on her profile.
Listen, as someone that follows many fediverse platforms, @thisismissem is one of the most active in the community. She has jumped in and assisted with security and ActivityPub issues across them all.
Please consider contributing to her tip jar if you can, especially for this last bit of advocacy work. Find her contribution options on her profile.
Listen, as someone that follows many fediverse platforms, @thisismissem is one of the most active in the community. She has jumped in and assisted with security and ActivityPub issues across them all.
Please consider contributing to her tip jar if you can, especially for this last bit of advocacy work. Find her contribution options on her profile.
* A Mastodon import (beta) * Improvements to the Welcome-Page * Basic Move functionality * A bunch of Outbox improvements * A ton of smaller changes and fixes
Congrats to @johnonolan and the team at Ghost, which today announced a public beta for users to connect their publications to the fediverse. If you're in their beta, you'll be able to find, follow and interact with people and publications on platforms including Ghost, WordPress, Threads, Mastodon, BlueSky, Flipboard and more. Get details in the blogpost here. If you want to know more about Ghost's approach to decentralization and the open social web, check out John's DotSocial conversation with @mike at the second link.
Congrats to @johnonolan and the team at Ghost, which today announced a public beta for users to connect their publications to the fediverse. If you're in their beta, you'll be able to find, follow and interact with people and publications on platforms including Ghost, WordPress, Threads, Mastodon, BlueSky, Flipboard and more. Get details in the blogpost here. If you want to know more about Ghost's approach to decentralization and the open social web, check out John's DotSocial conversation with @mike at the second link.
Congrats to @johnonolan and the team at Ghost, which today announced a public beta for users to connect their publications to the fediverse. If you're in their beta, you'll be able to find, follow and interact with people and publications on platforms including Ghost, WordPress, Threads, Mastodon, BlueSky, Flipboard and more. Get details in the blogpost here. If you want to know more about Ghost's approach to decentralization and the open social web, check out John's DotSocial conversation with @mike at the second link.
* A Mastodon import (beta) * Improvements to the Welcome-Page * Basic Move functionality * A bunch of Outbox improvements * A ton of smaller changes and fixes
* A Mastodon import (beta) * Improvements to the Welcome-Page * Basic Move functionality * A bunch of Outbox improvements * A ton of smaller changes and fixes
* A Mastodon import (beta) * Improvements to the Welcome-Page * Basic Move functionality * A bunch of Outbox improvements * A ton of smaller changes and fixes
Kudos to @dankeck for the first non-me contribution to @badgefed ! That deserves a badge, as soon as I deploy the #alttext#accessibility changes that Dan contributed I will issue a new one.
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
* A Mastodon import (beta) * Improvements to the Welcome-Page * Basic Move functionality * A bunch of Outbox improvements * A ton of smaller changes and fixes
* A Mastodon import (beta) * Improvements to the Welcome-Page * Basic Move functionality * A bunch of Outbox improvements * A ton of smaller changes and fixes
* A Mastodon import (beta) * Improvements to the Welcome-Page * Basic Move functionality * A bunch of Outbox improvements * A ton of smaller changes and fixes
* A Mastodon import (beta) * Improvements to the Welcome-Page * Basic Move functionality * A bunch of Outbox improvements * A ton of smaller changes and fixes
* A Mastodon import (beta) * Improvements to the Welcome-Page * Basic Move functionality * A bunch of Outbox improvements * A ton of smaller changes and fixes
It’s a jam-packed release, led by a beta importer to bring your Mastodon posts into WordPress—plus improvements to make setup smoother when activating the plugin.
It’s a jam-packed release, led by a beta importer to bring your Mastodon posts into WordPress—plus improvements to make setup smoother when activating the plugin.
Pixelfed before v0.12.5 has a vulnerability where it could leak your private posts, regardless of whether you are a Pixelfed user or not. Admins should update ASAP.
When following someone from a different server on the Fediverse, the remote server decides whether you are allowed to do that. This enables features like locked accounts. Due to an implementation mistake, Pixelfed ignores this and allows anyone to follow even private accounts on other servers. If a legitimate user from a Pixelfed instance follows you on your locked account, anyone on that Pixelfed instance can read your private posts.
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
Migrated to my own Mastodon. Looks like 27 followers haven't made it here yet, let's see if they arrive later.
I was planning to write my own ActivityPub server, and I even made some progress, but I didn't want to have a non-functional profile in the meantime, so Mastodon it is.
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
The ActivityPub specification does not have an example of the "sharedInbox" field in use.
Although it does say "An optional endpoint..." — I suspect a lot of people won't know (with confidence) that it can go under the "endpoints" field. For example:
ALT text detailssharedInbox
An optional endpoint used for wide delivery of publicly addressed activities and activities sent to followers. sharedInbox endpoints SHOULD also be publicly readable OrderedCollection objects containing objects addressed to the Public special collection. Reading from the sharedInbox endpoint MUST NOT present objects which are not addressed to the Public endpoint.
A reasonable ActivityPub / ActivityStreams API to schedule something to be posted in the future might be — to HTTP POST something to an account's outbox with the `published` field set to a date-time in the future.
A reasonable ActivityPub / ActivityStreams API to schedule something to be posted in the future might be — to HTTP POST something to an account's outbox with the `published` field set to a date-time in the future.
A reasonable ActivityPub / ActivityStreams API to schedule something to be posted in the future might be — to HTTP POST something to an account's outbox with the `published` field set to a date-time in the future.
The ActivityPub specification does not have an example of the "sharedInbox" field in use.
Although it does say "An optional endpoint..." — I suspect a lot of people won't know (with confidence) that it can go under the "endpoints" field. For example:
ALT text detailssharedInbox
An optional endpoint used for wide delivery of publicly addressed activities and activities sent to followers. sharedInbox endpoints SHOULD also be publicly readable OrderedCollection objects containing objects addressed to the Public special collection. Reading from the sharedInbox endpoint MUST NOT present objects which are not addressed to the Public endpoint.
A reasonable ActivityPub / ActivityStreams API to schedule something to be posted in the future might be — to HTTP POST something to an account's outbox with the `published` field set to a date-time in the future.
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
Thinking about internet protocols like #activitypub or #atproto as just "social media", namely platforms for sharing cat images, influencers and followers, shitposting and memes, trolls and flamewars etc. is missing the point entirely.
These are merely emergent behaviors when people interact with primitive forms of "digital society".
In truth these are "societal media", they increasingly capture a good fraction of human reality. The masters of #surveillancecapitalism know this all too well.
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
Thinking about internet protocols like #activitypub or #atproto as just "social media", namely platforms for sharing cat images, influencers and followers, shitposting and memes, trolls and flamewars etc. is missing the point entirely.
These are merely emergent behaviors when people interact with primitive forms of "digital society".
In truth these are "societal media", they increasingly capture a good fraction of human reality. The masters of #surveillancecapitalism know this all too well.
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
Ich habe mich mal testweise an Ghost herangetraut und wollte die ActivityPub-Funktion testen. Wer mag, kann meinen Erfahrungsbericht dazu auf meinem Blog lesen.
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
Tumblr continues to take baby steps into the fediverse. 👶
Buried in the latest Changes blog post, it was mentioned that specific blog has been running on WordPress for the past week! Doesn’t look like fediverse posting has been enabled…yet!
Tumblr continues to take baby steps into the fediverse. 👶
Buried in the latest Changes blog post, it was mentioned that specific blog has been running on WordPress for the past week! Doesn’t look like fediverse posting has been enabled…yet!
For the question whether Encyclia's ORCID bridge should be opt-in or opt-out (that is, whether we should bridge ORCID records without their owners' knowledge), I – @julian – will speak personally for a moment.
It is the central design question of Encyclia and one that has been on my mind since I started prototyping the platform. I have put as much thought into it as I am capable of, and I have sought feedback from multiple privacy and safety experts.
I'm looking for a new comment system for my #Hugo blog, and I'm not seeing any clearly great options.
I've been using #Commento for #comments on my blog for a few years now, and it's about time to switch comment systems.
Commento has been effectively unmaintained for 4 years (see https://gitlab.com/commento/commento). Their (paid) hosted version has been continuing to work, but I've seen increasing numbers of errors lately, so it's time to move.
I'd really *love* something that could integrate semi-natively with #activitypub so new blog posts could show up in Mastodon and Mastodon replies would show up as comments, *but* I don't want to require a fediverse account for commenters; that rules out most (all?) of the embedded-Mastodon comment options.. After looking through Hugo's somewhat-outdated list of commenting options (https://gohugo.io/content-management/comments/), it looks like #Discourse is the only option that even *slightly* fits that, and it's a lot heavier-weight than I really want to run today. Hours-of-maintenance-per-comment should be less than 1, thanks.
Basic requirements:
- Either easy to self-host or has a cheap hosted option. - Allows anonymous comments plus common external auth options. - Possible to import comments from Commento, possibly requiring code on my part, but it needs to allow arbitrary names, etc. - Works with static sites. - Not a privacy disaster - If self-hosted, ideally written in something sane -- Go, Rust, etc. *Ideally* it's a single binary that listens to HTTP and stores comments in Postgres. - Supports Markdown.
Does anyone have anything that they're really happy with?
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
This is the kind of innovation that #ActivityPub and the #Fediverse allows. I just learnt about #Bandwagon (through a post by @atomicpoet) which is a #music artist site (not unlike #Bandcamp). Artists and their posts can be followed just like anyone on the Fediverse.
It's a little rudimentary at the moment (both in style and functionality), and I don't think there is a way to purchase albums for download, but it is a nice example of what is possible.
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
The ActivityPub specification does not have an example of the "sharedInbox" field in use.
Although it does say "An optional endpoint..." — I suspect a lot of people won't know (with confidence) that it can go under the "endpoints" field. For example:
ALT text detailssharedInbox
An optional endpoint used for wide delivery of publicly addressed activities and activities sent to followers. sharedInbox endpoints SHOULD also be publicly readable OrderedCollection objects containing objects addressed to the Public special collection. Reading from the sharedInbox endpoint MUST NOT present objects which are not addressed to the Public endpoint.
This is the kind of innovation that #ActivityPub and the #Fediverse allows. I just learnt about #Bandwagon (through a post by @atomicpoet) which is a #music artist site (not unlike #Bandcamp). Artists and their posts can be followed just like anyone on the Fediverse.
It's a little rudimentary at the moment (both in style and functionality), and I don't think there is a way to purchase albums for download, but it is a nice example of what is possible.
One month has passed since I am using #selfhosted#activitypub instance 🎉. I have linux #docker compose stack with @mitra backend (#rust/#postgresql) written by @silverpill and @phanpy as my daily UI for desktop and mobile. Everything works fluent, backend memory print is really low and disk usage is about 2.3 GB as I have set data retention limit to one week and it is totally enough. I am following directly around 150 users + following 7 hashtags via https://relay.fedi.buzz/ which brings also optimal amount of federated posts into my server. Highly recommended!
One month has passed since I am using #selfhosted#activitypub instance 🎉. I have linux #docker compose stack with @mitra backend (#rust/#postgresql) written by @silverpill and @phanpy as my daily UI for desktop and mobile. Everything works fluent, backend memory print is really low and disk usage is about 2.3 GB as I have set data retention limit to one week and it is totally enough. I am following directly around 150 users + following 7 hashtags via https://relay.fedi.buzz/ which brings also optimal amount of federated posts into my server. Highly recommended!
Is there any #ActivityPub / #Mastodon URI scheme used in the wild that would allow me to open an ActivityPub account directly in my Android app?
I've seen 'acct' and 'web+ap' mentioned but none seem to be implemented.
The goal is that given a text of "Here is my Mastodon profile acct:daniel@gultsch.social" #Conversations_im can link that directly into #Tusky. (Just like mailto and xmpp URIs open my E-Mail or IM app respectively)
Have @apps or @Tusky considered that? If not way not?
I just added a new link to my Mastodon profile: @elena 🤗
How many #ActivityPub profiles do I have now? I don't want to know 😆
Off I go continue writing about #PeerTube for #TheFutureIsFederated (part 2, showing what it's like to use the software from the POV of a creator). I look forward to doing some tests and seeing what it's like to embed PeerTube videos on my website. Article coming tomorrow.
Wishing you all a lovely day!
ALT text detailsa screenshot showing my Mastodon profile description:
Italian filmmaker, photographer and writer based in Paris, France who hearts #FOSS. Director of: The Illusionists documentary. Soon: a Fediverse video series. self-hosting newbie (with a link to my GoToSocial account). Photos - followed by a link to my self-hosted Pixelfed. And a PeerTube link that is circled in red
I just added a new link to my Mastodon profile: @elena 🤗
How many #ActivityPub profiles do I have now? I don't want to know 😆
Off I go continue writing about #PeerTube for #TheFutureIsFederated (part 2, showing what it's like to use the software from the POV of a creator). I look forward to doing some tests and seeing what it's like to embed PeerTube videos on my website. Article coming tomorrow.
Wishing you all a lovely day!
ALT text detailsa screenshot showing my Mastodon profile description:
Italian filmmaker, photographer and writer based in Paris, France who hearts #FOSS. Director of: The Illusionists documentary. Soon: a Fediverse video series. self-hosting newbie (with a link to my GoToSocial account). Photos - followed by a link to my self-hosted Pixelfed. And a PeerTube link that is circled in red
I'm being driven up a wall by a Heisenbug I have with the #GoActivityPub HTTP-Signature plumbing.
On a multi tenant #ActivityPub service where I have two Actors, one of them can interact with the Fediverse at large without any issue, while the other gets HTTP Signature validation errors for every request.
There's no suspicious difference between the two private/public key pairs of the two actors. (I've even tried using the same key pair)
Pixelfed before v0.12.5 has a vulnerability where it could leak your private posts, regardless of whether you are a Pixelfed user or not. Admins should update ASAP.
When following someone from a different server on the Fediverse, the remote server decides whether you are allowed to do that. This enables features like locked accounts. Due to an implementation mistake, Pixelfed ignores this and allows anyone to follow even private accounts on other servers. If a legitimate user from a Pixelfed instance follows you on your locked account, anyone on that Pixelfed instance can read your private posts.
@fathermcgruder@jorts.horse · Reply to dansup's post
@dansup The follower approval feature itself in #activitypub is the vulnerability. It is wrong to give users the expectation that their social media posts are private. Also, approving followers reminds me of DRM on mp3 files. What are we doing?
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Pixelfed before v0.12.5 has a vulnerability where it could leak your private posts, regardless of whether you are a Pixelfed user or not. Admins should update ASAP.
When following someone from a different server on the Fediverse, the remote server decides whether you are allowed to do that. This enables features like locked accounts. Due to an implementation mistake, Pixelfed ignores this and allows anyone to follow even private accounts on other servers. If a legitimate user from a Pixelfed instance follows you on your locked account, anyone on that Pixelfed instance can read your private posts.
Pixelfed before v0.12.5 has a vulnerability where it could leak your private posts, regardless of whether you are a Pixelfed user or not. Admins should update ASAP.
When following someone from a different server on the Fediverse, the remote server decides whether you are allowed to do that. This enables features like locked accounts. Due to an implementation mistake, Pixelfed ignores this and allows anyone to follow even private accounts on other servers. If a legitimate user from a Pixelfed instance follows you on your locked account, anyone on that Pixelfed instance can read your private posts.
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Pixelfed before v0.12.5 has a vulnerability where it could leak your private posts, regardless of whether you are a Pixelfed user or not. Admins should update ASAP.
When following someone from a different server on the Fediverse, the remote server decides whether you are allowed to do that. This enables features like locked accounts. Due to an implementation mistake, Pixelfed ignores this and allows anyone to follow even private accounts on other servers. If a legitimate user from a Pixelfed instance follows you on your locked account, anyone on that Pixelfed instance can read your private posts.
Summary of the bug: If you have a protected account (on Pixelfed, Mastodon, GTS, whatever) and a Pixelfed user followed you and got approved by you, _all_ users on that instance were now able to see your followers-only posts, not just the one you approved.
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Pixelfed before v0.12.5 has a vulnerability where it could leak your private posts, regardless of whether you are a Pixelfed user or not. Admins should update ASAP.
When following someone from a different server on the Fediverse, the remote server decides whether you are allowed to do that. This enables features like locked accounts. Due to an implementation mistake, Pixelfed ignores this and allows anyone to follow even private accounts on other servers. If a legitimate user from a Pixelfed instance follows you on your locked account, anyone on that Pixelfed instance can read your private posts.
Pixelfed before v0.12.5 has a vulnerability where it could leak your private posts, regardless of whether you are a Pixelfed user or not. Admins should update ASAP.
When following someone from a different server on the Fediverse, the remote server decides whether you are allowed to do that. This enables features like locked accounts. Due to an implementation mistake, Pixelfed ignores this and allows anyone to follow even private accounts on other servers. If a legitimate user from a Pixelfed instance follows you on your locked account, anyone on that Pixelfed instance can read your private posts.
Pixelfed before v0.12.5 has a vulnerability where it could leak your private posts, regardless of whether you are a Pixelfed user or not. Admins should update ASAP.
When following someone from a different server on the Fediverse, the remote server decides whether you are allowed to do that. This enables features like locked accounts. Due to an implementation mistake, Pixelfed ignores this and allows anyone to follow even private accounts on other servers. If a legitimate user from a Pixelfed instance follows you on your locked account, anyone on that Pixelfed instance can read your private posts.
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Pixelfed before v0.12.5 has a vulnerability where it could leak your private posts, regardless of whether you are a Pixelfed user or not. Admins should update ASAP.
When following someone from a different server on the Fediverse, the remote server decides whether you are allowed to do that. This enables features like locked accounts. Due to an implementation mistake, Pixelfed ignores this and allows anyone to follow even private accounts on other servers. If a legitimate user from a Pixelfed instance follows you on your locked account, anyone on that Pixelfed instance can read your private posts.
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Had a great conversation with @mike on the history of the hashtag, why Elon is wrong about it, the future of social networks (vis a vis #ActivityPub, #ATProto, etc), and how LLMs may intersect with social media moderation.
Had a great conversation with @mike on the history of the hashtag, why Elon is wrong about it, the future of social networks (vis a vis #ActivityPub, #ATProto, etc), and how LLMs may intersect with social media moderation.
Had a great conversation with @mike on the history of the hashtag, why Elon is wrong about it, the future of social networks (vis a vis #ActivityPub, #ATProto, etc), and how LLMs may intersect with social media moderation.
Badges on the Fediverse?! Yep, it’s happening! 🎉 I’ve got a working prototype for issuing badges with ActivityPub! It's a bit rough around the edges, but I need some help to make it awesome!
💜 Check it out the teaser video and let me know what you think! 🦝✨
Badges on the Fediverse?! Yep, it’s happening! 🎉 I’ve got a working prototype for issuing badges with ActivityPub! It's a bit rough around the edges, but I need some help to make it awesome!
💜 Check it out the teaser video and let me know what you think! 🦝✨
Had a great conversation with @mike on the history of the hashtag, why Elon is wrong about it, the future of social networks (vis a vis #ActivityPub, #ATProto, etc), and how LLMs may intersect with social media moderation.
What I'd really like to see is BlueSky modifying their AT protocol to allow AT relays to treat ActivityPub servers as Personal Data Servers. Maybe by using aspects of the Solid protocol, as demonstrated by @activitypods?
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.
Getting back to #Fedify development today! Working on optimizing the outgoing activity queue to improve response times. Currently focusing on reducing latency when sending posts to large follower counts—should make the whole publishing experience feel much snappier.
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.
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.
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.
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.
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.
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.
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 always gush about @ZLabe and his account, because for one thing it makes the data he works with more accessible (via #ActivityPub), but secondly because the #infographics he stares are very informative - and consistent.
Are there any other #science, #edutainment and #infographic accounts on the #fediverse that has similar consistent and qualify of posts? Think content that is fairly easily digestible during a scroll.
I always gush about @ZLabe and his account, because for one thing it makes the data he works with more accessible (via #ActivityPub), but secondly because the #infographics he stares are very informative - and consistent.
Are there any other #science, #edutainment and #infographic accounts on the #fediverse that has similar consistent and qualify of posts? Think content that is fairly easily digestible during a scroll.
Llevaba tiempo preguntándome si sería posible integrar el protocolo #ActivityPub (el fedi) en los #PDS (Personal Data Server) de #ATProto (el protocolo que usa #BlueSky y potencialmente otras redes futuras) y he dado con este artículo.
En resumen: aún no, pero sí podría ser posible en un futuro. Honestamente, si existe una posibilidad de que ambos protocolos lleguen a converger, se debería apostar por ello. Internet ya está demasiado fragmentada.
Llevaba tiempo preguntándome si sería posible integrar el protocolo #ActivityPub (el fedi) en los #PDS (Personal Data Server) de #ATProto (el protocolo que usa #BlueSky y potencialmente otras redes futuras) y he dado con este artículo.
En resumen: aún no, pero sí podría ser posible en un futuro. Honestamente, si existe una posibilidad de que ambos protocolos lleguen a converger, se debería apostar por ello. Internet ya está demasiado fragmentada.
Getting back to #Fedify development today! Working on optimizing the outgoing activity queue to improve response times. Currently focusing on reducing latency when sending posts to large follower counts—should make the whole publishing experience feel much snappier.
Check out all episodes of DotSocial here, which include conversations with open social web leaders like @johnonolan, @jay.bsky.team, @kissane and more.
Newsletter platform #Ghost, an open source competitor to #Substack, is now connected to the fediverse, also known as the open social web.
Federated apps run on the protocol #ActivityPub, which powers apps like Mastodon, Pixelfed, Threads, Flipboard, and others, allowing posts published on one app to be seen and engaged with by those on other federated platforms.
Ghost said last year that it was working on an integration with ActivityPub, which would allow its publishers to share their blog posts with the broader open social web.
The company expected the integrations to go live last year. However, Ghost this week announced the launch of its social web beta, which now allows any site running on its Ghost Pro subscription to try out the new ActivityPub integration.
The beta feature is still in active development, the company notes in its help documentation, but is expected to ship in a more finalized state in the Ghost 6.0 release.
When Ghost Pro users connect their blog or newsletter to the fediverse, others across the open social web will be able to follow their account’s handle.
This handle is a combination of “@index,” representing the home page of the publication, followed by the domain name (@yoursite.com).
Ghost says users will soon be able to customize the @index part of their @index@yoursite.com handle.
Users on federated apps will then be able to follow the Ghost publisher’s posts, as well as interact with them by liking, replying, or reposting.
To help Ghost publishers also participate in the fediverse and build their readership, Ghost also launched a social web reader.
Here, users can browse a “feed” of the short-form content shared across the fediverse, including posts from services like Mastodon and Threads.
In a separate area called the “Inbox,” Ghost users can keep up with long-form content, like articles published on Ghost or WordPress, the popular publishing platform that integrated with the fediverse in 2023.
“Think of the Inbox screen like your email inbox. When you follow other publications on the social web, new articles they publish will show up here,” Ghost’s help page explains.
“Clicking on a post will open an inline reader view, right inside Ghost, and when you get to the end you’ll be able to like, repost or reply.”
With the integration of these two feeds into Ghost’s admin, Ghost will also now allow its publishers to directly post short-form content to the fediverse, helping them to build their reputation and following on the open social web.
Ghost’s Reader also alerts users of interactions like follows, replies, likes, and reposts in its “Notifications” section.
Plus, users can customize their Profile page to offer a preview of their social web account, following/followers, and their content, both short and long-form.
Later, the company hopes to more deeply integrate users’ social web profiles with Ghost memberships, but for now, they operate independently from one another.
Hey all, the easiest way I can find #Ghost blogs using #ActivityPub is to search for @index and you will get some Friendica results, etc, but for now, that should be a sure way to find almost all the blogs that have enabled this feature so far. I couldn't tell if replies appear as comments, so if you don't want your comments on their blog, don't reply to their fediverse posts. A few told me they can see my comments on their dashboard but I don't know what that means. #FediTips#Fediverse
Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!
After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.
As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.
Our solution? A new two-stage “fan-out” approach:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For developers with specific needs, we're adding a fanout option with three settings:
"auto" (default): Uses fanout for large recipient lists, direct delivery for small ones
"skip": Bypasses fanout when you need different payload per recipient
"force": Always uses fanout even with few recipients
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!
After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.
As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.
Our solution? A new two-stage “fan-out” approach:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For developers with specific needs, we're adding a fanout option with three settings:
"auto" (default): Uses fanout for large recipient lists, direct delivery for small ones
"skip": Bypasses fanout when you need different payload per recipient
"force": Always uses fanout even with few recipients
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Announcing Jaseur, an #ActivityPub server in C++, written by AI agents. Still in the early stages, but it already has several interesting features. See the git repo for more details.
Announcing Jaseur, an #ActivityPub server in C++, written by AI agents. Still in the early stages, but it already has several interesting features. See the git repo for more details.
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!
After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.
As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.
Our solution? A new two-stage “fan-out” approach:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For developers with specific needs, we're adding a fanout option with three settings:
"auto" (default): Uses fanout for large recipient lists, direct delivery for small ones
"skip": Bypasses fanout when you need different payload per recipient
"force": Always uses fanout even with few recipients
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!
After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.
As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.
Our solution? A new two-stage “fan-out” approach:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For developers with specific needs, we're adding a fanout option with three settings:
"auto" (default): Uses fanout for large recipient lists, direct delivery for small ones
"skip": Bypasses fanout when you need different payload per recipient
"force": Always uses fanout even with few recipients
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Thanks to the brilliant advice of @CyberSaloperie I have found an easy-to-implement, no sweat solution for my redirect issue. I am about to create a test subdomain with #YunoHost to try it out before I make the real switch (from my current Ghost blog to the new, self-hosted one).
Maybe tomorrow I'll share with you the URL of my self-hosted Ghost blog if you want to try things out? 🙈 I have already imported my existing members, I'm ready to go 🚀
And yes, I'm fully aware the timing of my switch (from a Ghost Pro plan to self-hosted) is odd, considering Ghost Pro accounts are now part of the Fediverse. It's just that I couldn't justify spending so much ($31/month) on a free, non-monetized blog that I am capable of self-hosting. It's 6x the cost of my Debian or Ubuntu VPS.
And I kept getting close to the edge of 1000 members, which would have increased my monthly payments. Now I don't have to stress out about getting new readers. From what I understand #ActivityPub followers count as members for Ghost, so someone who gets a sizable following on their federated Ghost site would have to pay more.
I'm sure many people will love this feature (it's fantastic!) but it's not for me. I already have 3 federated Wordpress blogs and too many ActivityPub profiles as it is 🙃
Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!
After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.
As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.
Our solution? A new two-stage “fan-out” approach:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For developers with specific needs, we're adding a fanout option with three settings:
"auto" (default): Uses fanout for large recipient lists, direct delivery for small ones
"skip": Bypasses fanout when you need different payload per recipient
"force": Always uses fanout even with few recipients
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!
After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.
As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.
Our solution? A new two-stage “fan-out” approach:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For developers with specific needs, we're adding a fanout option with three settings:
"auto" (default): Uses fanout for large recipient lists, direct delivery for small ones
"skip": Bypasses fanout when you need different payload per recipient
"force": Always uses fanout even with few recipients
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!
After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.
As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.
Our solution? A new two-stage “fan-out” approach:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For developers with specific needs, we're adding a fanout option with three settings:
"auto" (default): Uses fanout for large recipient lists, direct delivery for small ones
"skip": Bypasses fanout when you need different payload per recipient
"force": Always uses fanout even with few recipients
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!
After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.
As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.
Our solution? A new two-stage “fan-out” approach:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For developers with specific needs, we're adding a fanout option with three settings:
"auto" (default): Uses fanout for large recipient lists, direct delivery for small ones
"skip": Bypasses fanout when you need different payload per recipient
"force": Always uses fanout even with few recipients
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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 (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Newsletter platform #Ghost, an open source competitor to #Substack, is now connected to the fediverse, also known as the open social web.
Federated apps run on the protocol #ActivityPub, which powers apps like Mastodon, Pixelfed, Threads, Flipboard, and others, allowing posts published on one app to be seen and engaged with by those on other federated platforms.
Ghost said last year that it was working on an integration with ActivityPub, which would allow its publishers to share their blog posts with the broader open social web.
The company expected the integrations to go live last year. However, Ghost this week announced the launch of its social web beta, which now allows any site running on its Ghost Pro subscription to try out the new ActivityPub integration.
The beta feature is still in active development, the company notes in its help documentation, but is expected to ship in a more finalized state in the Ghost 6.0 release.
When Ghost Pro users connect their blog or newsletter to the fediverse, others across the open social web will be able to follow their account’s handle.
This handle is a combination of “@index,” representing the home page of the publication, followed by the domain name (@yoursite.com).
Ghost says users will soon be able to customize the @index part of their @index@yoursite.com handle.
Users on federated apps will then be able to follow the Ghost publisher’s posts, as well as interact with them by liking, replying, or reposting.
To help Ghost publishers also participate in the fediverse and build their readership, Ghost also launched a social web reader.
Here, users can browse a “feed” of the short-form content shared across the fediverse, including posts from services like Mastodon and Threads.
In a separate area called the “Inbox,” Ghost users can keep up with long-form content, like articles published on Ghost or WordPress, the popular publishing platform that integrated with the fediverse in 2023.
“Think of the Inbox screen like your email inbox. When you follow other publications on the social web, new articles they publish will show up here,” Ghost’s help page explains.
“Clicking on a post will open an inline reader view, right inside Ghost, and when you get to the end you’ll be able to like, repost or reply.”
With the integration of these two feeds into Ghost’s admin, Ghost will also now allow its publishers to directly post short-form content to the fediverse, helping them to build their reputation and following on the open social web.
Ghost’s Reader also alerts users of interactions like follows, replies, likes, and reposts in its “Notifications” section.
Plus, users can customize their Profile page to offer a preview of their social web account, following/followers, and their content, both short and long-form.
Later, the company hopes to more deeply integrate users’ social web profiles with Ghost memberships, but for now, they operate independently from one another.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
I gave a little bit of thinking on the changes I want to do to #badgefed before making my server public.
The one who emits the badges, is a #fediverse actor, this should be no controversial, after all, I use the public/private keys to sign the badges itself.
But in the first prototype the recipient of the grant, was a record in the system itself. The idea was to allow recipients outside the fediverse to receive badges as well. I did not wanted to store the email, so I required a profile url, think of your fediverse url, or for those outside #linkedin, #blog, even #facebook if they want. However, it gets things a little bit more complex and less clean than what I want.
Today, I decided that the recipient MUST be an actor of the #Fediverse. That is, it, that will be embedded as a mention, and should be clean and neat. For those who are not in the fediverse, #badgefed will provide an actor (and profile url) where they can add basic information such name, and bio links. Or they can create an account in any of the fediverse platforms at the moment of receiving the badge.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Hollo(@hollo)는 Fedify로 구동되는 1인 사용자용 마이크로블로깅 서버입니다. 1인 사용자를 위해 설계되었지만, ActivityPub를 통해 완전히 연합되어 연합우주 전체의 사용자들과 상호작용할 수 있습니다. Hollo는 Mastodon 호환 API를 구현하여 자체 웹 인터페이스 없이도 대부분의 Mastodon 클라이언트와 호환됩니다.
Hollo는 또한 정식 출시 전에 최신 Fedify 기능을 테스트하는 실험장으로도 활용되고 있습니다.
BotKit(@botkit)은 저희의 가장 새로운 구성원으로, ActivityPub 봇을 만들기 위해 특별히 설계된 프레임워크입니다. 전통적인 Mastodon 봇과 달리, BotKit은 플랫폼별 제한(글자 수 제한 등)에 구애받지 않는 독립적인 ActivityPub 서버를 만듭니다.
BotKit의 API는 의도적으로 단순하게 설계되어 단일 TypeScript 파일로 완전한 봇을 만들 수 있습니다!
세 프로젝트 모두 @fedify-dev GitHub 조직에서 오픈 소스로 공개되어 있습니다. 각기 다른 목적을 가지고 있지만, ActivityPub 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Hollo(@hollo)는 Fedify로 구동되는 1인 사용자용 마이크로블로깅 서버입니다. 1인 사용자를 위해 설계되었지만, ActivityPub를 통해 완전히 연합되어 연합우주 전체의 사용자들과 상호작용할 수 있습니다. Hollo는 Mastodon 호환 API를 구현하여 자체 웹 인터페이스 없이도 대부분의 Mastodon 클라이언트와 호환됩니다.
Hollo는 또한 정식 출시 전에 최신 Fedify 기능을 테스트하는 실험장으로도 활용되고 있습니다.
BotKit(@botkit)은 저희의 가장 새로운 구성원으로, ActivityPub 봇을 만들기 위해 특별히 설계된 프레임워크입니다. 전통적인 Mastodon 봇과 달리, BotKit은 플랫폼별 제한(글자 수 제한 등)에 구애받지 않는 독립적인 ActivityPub 서버를 만듭니다.
BotKit의 API는 의도적으로 단순하게 설계되어 단일 TypeScript 파일로 완전한 봇을 만들 수 있습니다!
세 프로젝트 모두 @fedify-dev GitHub 조직에서 오픈 소스로 공개되어 있습니다. 각기 다른 목적을 가지고 있지만, ActivityPub 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
Hollo(@hollo)는 Fedify로 구동되는 1인 사용자용 마이크로블로깅 서버입니다. 1인 사용자를 위해 설계되었지만, ActivityPub를 통해 완전히 연합되어 연합우주 전체의 사용자들과 상호작용할 수 있습니다. Hollo는 Mastodon 호환 API를 구현하여 자체 웹 인터페이스 없이도 대부분의 Mastodon 클라이언트와 호환됩니다.
Hollo는 또한 정식 출시 전에 최신 Fedify 기능을 테스트하는 실험장으로도 활용되고 있습니다.
BotKit(@botkit)은 저희의 가장 새로운 구성원으로, ActivityPub 봇을 만들기 위해 특별히 설계된 프레임워크입니다. 전통적인 Mastodon 봇과 달리, BotKit은 플랫폼별 제한(글자 수 제한 등)에 구애받지 않는 독립적인 ActivityPub 서버를 만듭니다.
BotKit의 API는 의도적으로 단순하게 설계되어 단일 TypeScript 파일로 완전한 봇을 만들 수 있습니다!
세 프로젝트 모두 @fedify-dev GitHub 조직에서 오픈 소스로 공개되어 있습니다. 각기 다른 목적을 가지고 있지만, ActivityPub 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
UPDATE: A blog (that is federated) was created for communicate the progress, follow @badgefed
--
I am creating a #ActivityPub minimalistic implementation of a badge system similar to Credly, built using #dotnet and leveraging the #Fediverse
I have issued a first badge, the idea is to decentralize the verification systems, and allow organizations to self-certify. It is incredible that organizations like Microsoft or Non-Profits pay thousands of dollars to companies like Pearson to just provide "verified" badges. Similar to mastodons installed in social-dot-something, thinkg of badges<dot> mozilla<dot>com , certifications<dot>myschooldistrict<dot>com. Or even a podcast emitting a badge for its guests, with the verification in the domain.
ActivityPub already offers a secure way to sign artifacts and interact between actors. The fediverse already have people with profiles, a social graph as @mike says, ready to use. Think of how LetsEncrypt disrupted that market of few actors selling certificates for websites.
I have a functional poc, @fediverse is not a mastodon, pledora or blog, it is an actor in a badge system, but you can follow it in Mastodon. Its badges will show in #mastodon but they are not notes or articles. If you want to learn more, follow me, I will be sharing the progress here. Or follow the github project here: https://github.com/tryvocalcat/activitypub-badges
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
We've been working on adding custom background task support to #Fedify as planned for version 1.5.0. After diving deeper into implementation, we've realized this is a more substantial undertaking than initially anticipated.
The feature would require significant API changes that would be too disruptive for a minor version update. Therefore, we've decided to postpone this feature to Fedify 2.0.0.
This allows us to:
Design a more robust and flexible worker architecture
Ensure better integration with existing task queue systems
Properly document the new APIs without rushing
We believe this decision will result in a more stable and well-designed feature that better serves your needs. However, some smaller improvements from our work that don't require API changes will still be included in Fedify 1.5.0 or subsequent minor updates.
We appreciate your understanding and continued support.
If you have specific use cases or requirements for background task support, please share them in our GitHub issue. Your input will help shape this feature for 2.0.0.
We've been working on adding custom background task support to #Fedify as planned for version 1.5.0. After diving deeper into implementation, we've realized this is a more substantial undertaking than initially anticipated.
The feature would require significant API changes that would be too disruptive for a minor version update. Therefore, we've decided to postpone this feature to Fedify 2.0.0.
This allows us to:
Design a more robust and flexible worker architecture
Ensure better integration with existing task queue systems
Properly document the new APIs without rushing
We believe this decision will result in a more stable and well-designed feature that better serves your needs. However, some smaller improvements from our work that don't require API changes will still be included in Fedify 1.5.0 or subsequent minor updates.
We appreciate your understanding and continued support.
If you have specific use cases or requirements for background task support, please share them in our GitHub issue. Your input will help shape this feature for 2.0.0.
Getting back to #Fedify development today! Working on optimizing the outgoing activity queue to improve response times. Currently focusing on reducing latency when sending posts to large follower counts—should make the whole publishing experience feel much snappier.
Getting back to #Fedify development today! Working on optimizing the outgoing activity queue to improve response times. Currently focusing on reducing latency when sending posts to large follower counts—should make the whole publishing experience feel much snappier.
We've been working on adding custom background task support to #Fedify as planned for version 1.5.0. After diving deeper into implementation, we've realized this is a more substantial undertaking than initially anticipated.
The feature would require significant API changes that would be too disruptive for a minor version update. Therefore, we've decided to postpone this feature to Fedify 2.0.0.
This allows us to:
Design a more robust and flexible worker architecture
Ensure better integration with existing task queue systems
Properly document the new APIs without rushing
We believe this decision will result in a more stable and well-designed feature that better serves your needs. However, some smaller improvements from our work that don't require API changes will still be included in Fedify 1.5.0 or subsequent minor updates.
We appreciate your understanding and continued support.
If you have specific use cases or requirements for background task support, please share them in our GitHub issue. Your input will help shape this feature for 2.0.0.
We've been working on adding custom background task support to #Fedify as planned for version 1.5.0. After diving deeper into implementation, we've realized this is a more substantial undertaking than initially anticipated.
The feature would require significant API changes that would be too disruptive for a minor version update. Therefore, we've decided to postpone this feature to Fedify 2.0.0.
This allows us to:
Design a more robust and flexible worker architecture
Ensure better integration with existing task queue systems
Properly document the new APIs without rushing
We believe this decision will result in a more stable and well-designed feature that better serves your needs. However, some smaller improvements from our work that don't require API changes will still be included in Fedify 1.5.0 or subsequent minor updates.
We appreciate your understanding and continued support.
If you have specific use cases or requirements for background task support, please share them in our GitHub issue. Your input will help shape this feature for 2.0.0.
We've been working on adding custom background task support to #Fedify as planned for version 1.5.0. After diving deeper into implementation, we've realized this is a more substantial undertaking than initially anticipated.
The feature would require significant API changes that would be too disruptive for a minor version update. Therefore, we've decided to postpone this feature to Fedify 2.0.0.
This allows us to:
Design a more robust and flexible worker architecture
Ensure better integration with existing task queue systems
Properly document the new APIs without rushing
We believe this decision will result in a more stable and well-designed feature that better serves your needs. However, some smaller improvements from our work that don't require API changes will still be included in Fedify 1.5.0 or subsequent minor updates.
We appreciate your understanding and continued support.
If you have specific use cases or requirements for background task support, please share them in our GitHub issue. Your input will help shape this feature for 2.0.0.
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:
Patch releases for #Fedify versions 1.0.21, 1.1.18, 1.2.18, 1.3.14, and 1.4.7 are now available. These updates address two important bugs across all supported release lines:
Fixed a WebFinger handler bug that prevented matching acct: URIs with port numbers in the host. Thanks to @revathskumar for reporting and debugging the bug!
Resolved server errors that occurred when invalid URLs were passed to the base-url parameter of followers collections.
We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.
Patch releases for #Fedify versions 1.0.21, 1.1.18, 1.2.18, 1.3.14, and 1.4.7 are now available. These updates address two important bugs across all supported release lines:
Fixed a WebFinger handler bug that prevented matching acct: URIs with port numbers in the host. Thanks to @revathskumar for reporting and debugging the bug!
Resolved server errors that occurred when invalid URLs were passed to the base-url parameter of followers collections.
We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.
Patch releases for #Fedify versions 1.0.21, 1.1.18, 1.2.18, 1.3.14, and 1.4.7 are now available. These updates address two important bugs across all supported release lines:
Fixed a WebFinger handler bug that prevented matching acct: URIs with port numbers in the host. Thanks to @revathskumar for reporting and debugging the bug!
Resolved server errors that occurred when invalid URLs were passed to the base-url parameter of followers collections.
We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.
Patch releases for #Fedify versions 1.0.21, 1.1.18, 1.2.18, 1.3.14, and 1.4.7 are now available. These updates address two important bugs across all supported release lines:
Fixed a WebFinger handler bug that prevented matching acct: URIs with port numbers in the host. Thanks to @revathskumar for reporting and debugging the bug!
Resolved server errors that occurred when invalid URLs were passed to the base-url parameter of followers collections.
We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.
Patch releases for #Fedify versions 1.0.21, 1.1.18, 1.2.18, 1.3.14, and 1.4.7 are now available. These updates address two important bugs across all supported release lines:
Fixed a WebFinger handler bug that prevented matching acct: URIs with port numbers in the host. Thanks to @revathskumar for reporting and debugging the bug!
Resolved server errors that occurred when invalid URLs were passed to the base-url parameter of followers collections.
We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.
This week's news: - Ghost's (@index) connection to the #fediverse is now availabe in public beta for Ghost Pro users, with both an #ActivityPub connection to send long-form posts into the fediverse, and a reader app to read/comment/interact with the fediverse - @anewsocial , the organisation that manages the bridge between the fediverse and #bluesky shared their upcoming plans
This week's news: - Ghost's (@index) connection to the #fediverse is now availabe in public beta for Ghost Pro users, with both an #ActivityPub connection to send long-form posts into the fediverse, and a reader app to read/comment/interact with the fediverse - @anewsocial , the organisation that manages the bridge between the fediverse and #bluesky shared their upcoming plans
The latest update on the AI-generated #ActivityPub server in C++... it now supports publishing signed messages and actors can be configured to autorespond. One autoresponder will use a local LLM (ollama) to generate responses to direct messages. Overall, the experiment has been useful. The code is not the greatest, but it works, which really surprises me. However, I'm seeing the agent having more issues as the complexity of the code increases. I may need to step in and write some code myself. 😮
UPDATE: A blog (that is federated) was created for communicate the progress, follow @badgefed
--
I am creating a #ActivityPub minimalistic implementation of a badge system similar to Credly, built using #dotnet and leveraging the #Fediverse
I have issued a first badge, the idea is to decentralize the verification systems, and allow organizations to self-certify. It is incredible that organizations like Microsoft or Non-Profits pay thousands of dollars to companies like Pearson to just provide "verified" badges. Similar to mastodons installed in social-dot-something, thinkg of badges<dot> mozilla<dot>com , certifications<dot>myschooldistrict<dot>com. Or even a podcast emitting a badge for its guests, with the verification in the domain.
ActivityPub already offers a secure way to sign artifacts and interact between actors. The fediverse already have people with profiles, a social graph as @mike says, ready to use. Think of how LetsEncrypt disrupted that market of few actors selling certificates for websites.
I have a functional poc, @fediverse is not a mastodon, pledora or blog, it is an actor in a badge system, but you can follow it in Mastodon. Its badges will show in #mastodon but they are not notes or articles. If you want to learn more, follow me, I will be sharing the progress here. Or follow the github project here: https://github.com/tryvocalcat/activitypub-badges
This week's news: - Ghost's (@index) connection to the #fediverse is now availabe in public beta for Ghost Pro users, with both an #ActivityPub connection to send long-form posts into the fediverse, and a reader app to read/comment/interact with the fediverse - @anewsocial , the organisation that manages the bridge between the fediverse and #bluesky shared their upcoming plans
This week's news: - Ghost's (@index) connection to the #fediverse is now availabe in public beta for Ghost Pro users, with both an #ActivityPub connection to send long-form posts into the fediverse, and a reader app to read/comment/interact with the fediverse - @anewsocial , the organisation that manages the bridge between the fediverse and #bluesky shared their upcoming plans
Link at end but I love this article for it's shocked tone. I love how the more tech of the Fediverse can't possibly comprehend that there are people that honestly just want to be left the fuck alone. This whole article was written like the writer was astonished such a thing could exist and my sides are splitting from them realizing not everybody wants to talk to you. https://wedistribute.org/2025/03/website-league-island-networks/#Fediverse#ActivityPub#privacy
This week's news: - Ghost's (@index) connection to the #fediverse is now availabe in public beta for Ghost Pro users, with both an #ActivityPub connection to send long-form posts into the fediverse, and a reader app to read/comment/interact with the fediverse - @anewsocial , the organisation that manages the bridge between the fediverse and #bluesky shared their upcoming plans
This week's news: - Ghost's (@index) connection to the #fediverse is now availabe in public beta for Ghost Pro users, with both an #ActivityPub connection to send long-form posts into the fediverse, and a reader app to read/comment/interact with the fediverse - @anewsocial , the organisation that manages the bridge between the fediverse and #bluesky shared their upcoming plans
This week's news: - Ghost's (@index) connection to the #fediverse is now availabe in public beta for Ghost Pro users, with both an #ActivityPub connection to send long-form posts into the fediverse, and a reader app to read/comment/interact with the fediverse - @anewsocial , the organisation that manages the bridge between the fediverse and #bluesky shared their upcoming plans
Can't find any reference about what I have to return on a Create Note (comment) activity. - Is status code 200 enough? - should I return an Accept Activity with the Request in it?
Well, it’s a lucky day 🍀. Our latest update contains a pot o’ gold for the Bluesky community especially. Take a look at what’s in this release, including linking your Bluesky account to Surf, a new Home Timeline that unifies your Bluesky and Mastodon, and Bluesky notifications in our app. 🦋
ALT text detailsApp release notes for Surf update week of March 17, 2025. This is post 1 of 2, and it says:
Link your Bluesky account in Surf settings!
New Home Timeline unifies your Bluesky & Mastodon
Post & engage with your Bluesky community
See your Bluesky notifications in Activity
Access your Bluesky lists, starter packs & custom feeds from your profile
ALT text detailsApp release notes for Surf app week of March 17, 2025. This is post 2 of 2 and it says:
Bluesky Digest is renamed Bluesky Following
Check out feeds from the community in the new Surf Shop destination
Tired of the Elon news? Tame your timeline by excluding hashtags, topics & people in your custom feeds (See Filter & Sort tab in Feed Settings)
Well, it’s a lucky day 🍀. Our latest update contains a pot o’ gold for the Bluesky community especially. Take a look at what’s in this release, including linking your Bluesky account to Surf, a new Home Timeline that unifies your Bluesky and Mastodon, and Bluesky notifications in our app. 🦋
ALT text detailsApp release notes for Surf update week of March 17, 2025. This is post 1 of 2, and it says:
Link your Bluesky account in Surf settings!
New Home Timeline unifies your Bluesky & Mastodon
Post & engage with your Bluesky community
See your Bluesky notifications in Activity
Access your Bluesky lists, starter packs & custom feeds from your profile
ALT text detailsApp release notes for Surf app week of March 17, 2025. This is post 2 of 2 and it says:
Bluesky Digest is renamed Bluesky Following
Check out feeds from the community in the new Surf Shop destination
Tired of the Elon news? Tame your timeline by excluding hashtags, topics & people in your custom feeds (See Filter & Sort tab in Feed Settings)
UPDATE: A blog (that is federated) was created for communicate the progress, follow @badgefed
--
I am creating a #ActivityPub minimalistic implementation of a badge system similar to Credly, built using #dotnet and leveraging the #Fediverse
I have issued a first badge, the idea is to decentralize the verification systems, and allow organizations to self-certify. It is incredible that organizations like Microsoft or Non-Profits pay thousands of dollars to companies like Pearson to just provide "verified" badges. Similar to mastodons installed in social-dot-something, thinkg of badges<dot> mozilla<dot>com , certifications<dot>myschooldistrict<dot>com. Or even a podcast emitting a badge for its guests, with the verification in the domain.
ActivityPub already offers a secure way to sign artifacts and interact between actors. The fediverse already have people with profiles, a social graph as @mike says, ready to use. Think of how LetsEncrypt disrupted that market of few actors selling certificates for websites.
I have a functional poc, @fediverse is not a mastodon, pledora or blog, it is an actor in a badge system, but you can follow it in Mastodon. Its badges will show in #mastodon but they are not notes or articles. If you want to learn more, follow me, I will be sharing the progress here. Or follow the github project here: https://github.com/tryvocalcat/activitypub-badges
Well, it’s a lucky day 🍀. Our latest update contains a pot o’ gold for the Bluesky community especially. Take a look at what’s in this release, including linking your Bluesky account to Surf, a new Home Timeline that unifies your Bluesky and Mastodon, and Bluesky notifications in our app. 🦋
ALT text detailsApp release notes for Surf update week of March 17, 2025. This is post 1 of 2, and it says:
Link your Bluesky account in Surf settings!
New Home Timeline unifies your Bluesky & Mastodon
Post & engage with your Bluesky community
See your Bluesky notifications in Activity
Access your Bluesky lists, starter packs & custom feeds from your profile
ALT text detailsApp release notes for Surf app week of March 17, 2025. This is post 2 of 2 and it says:
Bluesky Digest is renamed Bluesky Following
Check out feeds from the community in the new Surf Shop destination
Tired of the Elon news? Tame your timeline by excluding hashtags, topics & people in your custom feeds (See Filter & Sort tab in Feed Settings)
Well, it’s a lucky day 🍀. Our latest update contains a pot o’ gold for the Bluesky community especially. Take a look at what’s in this release, including linking your Bluesky account to Surf, a new Home Timeline that unifies your Bluesky and Mastodon, and Bluesky notifications in our app. 🦋
ALT text detailsApp release notes for Surf update week of March 17, 2025. This is post 1 of 2, and it says:
Link your Bluesky account in Surf settings!
New Home Timeline unifies your Bluesky & Mastodon
Post & engage with your Bluesky community
See your Bluesky notifications in Activity
Access your Bluesky lists, starter packs & custom feeds from your profile
ALT text detailsApp release notes for Surf app week of March 17, 2025. This is post 2 of 2 and it says:
Bluesky Digest is renamed Bluesky Following
Check out feeds from the community in the new Surf Shop destination
Tired of the Elon news? Tame your timeline by excluding hashtags, topics & people in your custom feeds (See Filter & Sort tab in Feed Settings)
The AI agent-developed C++ #ActivityPub server now has about 2000 SLOC (all written by AI) and can process Follow/Accept and Create/Note (inbox/federated) and Create/Note delivery (outbox/C2S) with HTTP signatures and a good set of unit tests. Having the AI write unit tests has been key because it often creates regressions when adding features. The agents do a surprisingly good job of diagnosing compiler and unit test failures and fixing the problem automatically.
The Venn diagram of the protocol wars between #activitypub and #atproto and thinking of a day that #Twitter will stop being the benchmark of success for decentralized social media platforms.
ALT text detailsPictorial representation of the "space" of decentralized web protocols. A large ellipse represents the vast range of possibilities or organizing online interactions, most of them yet to be conceived of (hence labelled as Terra Incognita). Two smaller ellipses represent currently specified and actively developed ideas, the atproto and activitypub protocol. The space of possibilities these offer is narrower, yet still largely unexplored. An arrow points to the small overlap area between the two protocols and helpfully declares that the currently best known applications respectively (bluesky and mastodon) "compete" for imitating an obsolete application formerly known as Twitter.
The Venn diagram of the protocol wars between #activitypub and #atproto and thinking of a day that #Twitter will stop being the benchmark of success for decentralized social media platforms.
ALT text detailsPictorial representation of the "space" of decentralized web protocols. A large ellipse represents the vast range of possibilities or organizing online interactions, most of them yet to be conceived of (hence labelled as Terra Incognita). Two smaller ellipses represent currently specified and actively developed ideas, the atproto and activitypub protocol. The space of possibilities these offer is narrower, yet still largely unexplored. An arrow points to the small overlap area between the two protocols and helpfully declares that the currently best known applications respectively (bluesky and mastodon) "compete" for imitating an obsolete application formerly known as Twitter.
I'm trying to #build a blogging, question-answering, and news site for software engineers, which is #ActivityPub enabled. What should I name it? (The options below are just the ones available to buy a domain.)
“The Fediverse Isn’t the Future. It’s the Present We’ve Been Denied.” Here’s yet another brilliant feature by @Daojoan. “The fediverse won’t succeed just because it’s better. It will succeed if and only if people choose it. If they reject the idea that being trapped in someone else’s ecosystem is just the cost of existing online. If they stop believing that “free” means surrendering ownership of your own connections, your own history, your own data. If they see that the internet wasn’t built to be a factory for engagement metrics and AI-generated content farms. It was built to connect us, not silo us to pad a wealth-extremist’s bank account,” she writes.
UPDATE: A blog (that is federated) was created for communicate the progress, follow @badgefed
--
I am creating a #ActivityPub minimalistic implementation of a badge system similar to Credly, built using #dotnet and leveraging the #Fediverse
I have issued a first badge, the idea is to decentralize the verification systems, and allow organizations to self-certify. It is incredible that organizations like Microsoft or Non-Profits pay thousands of dollars to companies like Pearson to just provide "verified" badges. Similar to mastodons installed in social-dot-something, thinkg of badges<dot> mozilla<dot>com , certifications<dot>myschooldistrict<dot>com. Or even a podcast emitting a badge for its guests, with the verification in the domain.
ActivityPub already offers a secure way to sign artifacts and interact between actors. The fediverse already have people with profiles, a social graph as @mike says, ready to use. Think of how LetsEncrypt disrupted that market of few actors selling certificates for websites.
I have a functional poc, @fediverse is not a mastodon, pledora or blog, it is an actor in a badge system, but you can follow it in Mastodon. Its badges will show in #mastodon but they are not notes or articles. If you want to learn more, follow me, I will be sharing the progress here. Or follow the github project here: https://github.com/tryvocalcat/activitypub-badges
UPDATE: A blog (that is federated) was created for communicate the progress, follow @badgefed
--
I am creating a #ActivityPub minimalistic implementation of a badge system similar to Credly, built using #dotnet and leveraging the #Fediverse
I have issued a first badge, the idea is to decentralize the verification systems, and allow organizations to self-certify. It is incredible that organizations like Microsoft or Non-Profits pay thousands of dollars to companies like Pearson to just provide "verified" badges. Similar to mastodons installed in social-dot-something, thinkg of badges<dot> mozilla<dot>com , certifications<dot>myschooldistrict<dot>com. Or even a podcast emitting a badge for its guests, with the verification in the domain.
ActivityPub already offers a secure way to sign artifacts and interact between actors. The fediverse already have people with profiles, a social graph as @mike says, ready to use. Think of how LetsEncrypt disrupted that market of few actors selling certificates for websites.
I have a functional poc, @fediverse is not a mastodon, pledora or blog, it is an actor in a badge system, but you can follow it in Mastodon. Its badges will show in #mastodon but they are not notes or articles. If you want to learn more, follow me, I will be sharing the progress here. Or follow the github project here: https://github.com/tryvocalcat/activitypub-badges
UPDATE: A blog (that is federated) was created for communicate the progress, follow @badgefed
--
I am creating a #ActivityPub minimalistic implementation of a badge system similar to Credly, built using #dotnet and leveraging the #Fediverse
I have issued a first badge, the idea is to decentralize the verification systems, and allow organizations to self-certify. It is incredible that organizations like Microsoft or Non-Profits pay thousands of dollars to companies like Pearson to just provide "verified" badges. Similar to mastodons installed in social-dot-something, thinkg of badges<dot> mozilla<dot>com , certifications<dot>myschooldistrict<dot>com. Or even a podcast emitting a badge for its guests, with the verification in the domain.
ActivityPub already offers a secure way to sign artifacts and interact between actors. The fediverse already have people with profiles, a social graph as @mike says, ready to use. Think of how LetsEncrypt disrupted that market of few actors selling certificates for websites.
I have a functional poc, @fediverse is not a mastodon, pledora or blog, it is an actor in a badge system, but you can follow it in Mastodon. Its badges will show in #mastodon but they are not notes or articles. If you want to learn more, follow me, I will be sharing the progress here. Or follow the github project here: https://github.com/tryvocalcat/activitypub-badges
UPDATE: A blog (that is federated) was created for communicate the progress, follow @badgefed
--
I am creating a #ActivityPub minimalistic implementation of a badge system similar to Credly, built using #dotnet and leveraging the #Fediverse
I have issued a first badge, the idea is to decentralize the verification systems, and allow organizations to self-certify. It is incredible that organizations like Microsoft or Non-Profits pay thousands of dollars to companies like Pearson to just provide "verified" badges. Similar to mastodons installed in social-dot-something, thinkg of badges<dot> mozilla<dot>com , certifications<dot>myschooldistrict<dot>com. Or even a podcast emitting a badge for its guests, with the verification in the domain.
ActivityPub already offers a secure way to sign artifacts and interact between actors. The fediverse already have people with profiles, a social graph as @mike says, ready to use. Think of how LetsEncrypt disrupted that market of few actors selling certificates for websites.
I have a functional poc, @fediverse is not a mastodon, pledora or blog, it is an actor in a badge system, but you can follow it in Mastodon. Its badges will show in #mastodon but they are not notes or articles. If you want to learn more, follow me, I will be sharing the progress here. Or follow the github project here: https://github.com/tryvocalcat/activitypub-badges
UPDATE: A blog (that is federated) was created for communicate the progress, follow @badgefed
--
I am creating a #ActivityPub minimalistic implementation of a badge system similar to Credly, built using #dotnet and leveraging the #Fediverse
I have issued a first badge, the idea is to decentralize the verification systems, and allow organizations to self-certify. It is incredible that organizations like Microsoft or Non-Profits pay thousands of dollars to companies like Pearson to just provide "verified" badges. Similar to mastodons installed in social-dot-something, thinkg of badges<dot> mozilla<dot>com , certifications<dot>myschooldistrict<dot>com. Or even a podcast emitting a badge for its guests, with the verification in the domain.
ActivityPub already offers a secure way to sign artifacts and interact between actors. The fediverse already have people with profiles, a social graph as @mike says, ready to use. Think of how LetsEncrypt disrupted that market of few actors selling certificates for websites.
I have a functional poc, @fediverse is not a mastodon, pledora or blog, it is an actor in a badge system, but you can follow it in Mastodon. Its badges will show in #mastodon but they are not notes or articles. If you want to learn more, follow me, I will be sharing the progress here. Or follow the github project here: https://github.com/tryvocalcat/activitypub-badges
UPDATE: A blog (that is federated) was created for communicate the progress, follow @badgefed
--
I am creating a #ActivityPub minimalistic implementation of a badge system similar to Credly, built using #dotnet and leveraging the #Fediverse
I have issued a first badge, the idea is to decentralize the verification systems, and allow organizations to self-certify. It is incredible that organizations like Microsoft or Non-Profits pay thousands of dollars to companies like Pearson to just provide "verified" badges. Similar to mastodons installed in social-dot-something, thinkg of badges<dot> mozilla<dot>com , certifications<dot>myschooldistrict<dot>com. Or even a podcast emitting a badge for its guests, with the verification in the domain.
ActivityPub already offers a secure way to sign artifacts and interact between actors. The fediverse already have people with profiles, a social graph as @mike says, ready to use. Think of how LetsEncrypt disrupted that market of few actors selling certificates for websites.
I have a functional poc, @fediverse is not a mastodon, pledora or blog, it is an actor in a badge system, but you can follow it in Mastodon. Its badges will show in #mastodon but they are not notes or articles. If you want to learn more, follow me, I will be sharing the progress here. Or follow the github project here: https://github.com/tryvocalcat/activitypub-badges
I've been playing with the experimental GitHub Copilot agent mode in vscode. I've asked it to start from an empty directory and create an #ActivityPub server in C++, directed only by prompts (no human coding). So far, it has created a C++ project and implemented WebFinger, resource persistence, resource retrieval and a decent set of unit tests. At this point, Mastodon is able to discover our actors. The AI is currently implementing Follow processing. I'm curious to learn how far I can push this.
"#ActivityPub has also led to a wave of start-up efforts such as #Mastodon, a microblogging service that now has more than 14 million accounts connected by a network of over 14,000 host computers, as well as start-ups like #Pixelfed and #PeerTube, distributed services that offer features similar to #Instagram and #YouTube."
A Long-Shot Bet to Bypass the Middlemen of #SocialMedia
What are you doing? Testing a Badge System built on #activitypub and the #fediverse empowering communities to issue and verify badges in a federated, open way, or what are you doing?
"#ActivityPub has also led to a wave of start-up efforts such as #Mastodon, a microblogging service that now has more than 14 million accounts connected by a network of over 14,000 host computers, as well as start-ups like #Pixelfed and #PeerTube, distributed services that offer features similar to #Instagram and #YouTube."
A Long-Shot Bet to Bypass the Middlemen of #SocialMedia
Finally, our team had a wonderful time at #SXSW on Sunday and Monday, where Flipboard and @surf hosted the first #FediverseHouse. Our CEO @mike and the whole team are 100% #TeamFediverse, and were thrilled to meet and talk to so many other open social web advocates. Here’s a feature by @Markoff for @newyorktimes, where Mike, @Gargron and @reckless1280 discuss the rise of decentralized social media, and how it can help publishers and media companies survive and thrive.
Finally, our team had a wonderful time at #SXSW on Sunday and Monday, where Flipboard and @surf hosted the first #FediverseHouse. Our CEO @mike and the whole team are 100% #TeamFediverse, and were thrilled to meet and talk to so many other open social web advocates. Here’s a feature by @Markoff for @newyorktimes, where Mike, @Gargron and @reckless1280 discuss the rise of decentralized social media, and how it can help publishers and media companies survive and thrive.
Finally, our team had a wonderful time at #SXSW on Sunday and Monday, where Flipboard and @surf hosted the first #FediverseHouse. Our CEO @mike and the whole team are 100% #TeamFediverse, and were thrilled to meet and talk to so many other open social web advocates. Here’s a feature by @Markoff for @newyorktimes, where Mike, @Gargron and @reckless1280 discuss the rise of decentralized social media, and how it can help publishers and media companies survive and thrive.
Finally, our team had a wonderful time at #SXSW on Sunday and Monday, where Flipboard and @surf hosted the first #FediverseHouse. Our CEO @mike and the whole team are 100% #TeamFediverse, and were thrilled to meet and talk to so many other open social web advocates. Here’s a feature by @Markoff for @newyorktimes, where Mike, @Gargron and @reckless1280 discuss the rise of decentralized social media, and how it can help publishers and media companies survive and thrive.
ALT text detailsA screen recording showing a Mastodon timeline view. The user clicks a "play" icon in a status, which then loads and displays an interactive 3D view of a dodecaheral chain from the 3MF sample files collection.
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
Finally, our team had a wonderful time at #SXSW on Sunday and Monday, where Flipboard and @surf hosted the first #FediverseHouse. Our CEO @mike and the whole team are 100% #TeamFediverse, and were thrilled to meet and talk to so many other open social web advocates. Here’s a feature by @Markoff for @newyorktimes, where Mike, @Gargron and @reckless1280 discuss the rise of decentralized social media, and how it can help publishers and media companies survive and thrive.
Finally, our team had a wonderful time at #SXSW on Sunday and Monday, where Flipboard and @surf hosted the first #FediverseHouse. Our CEO @mike and the whole team are 100% #TeamFediverse, and were thrilled to meet and talk to so many other open social web advocates. Here’s a feature by @Markoff for @newyorktimes, where Mike, @Gargron and @reckless1280 discuss the rise of decentralized social media, and how it can help publishers and media companies survive and thrive.
“The Fediverse Isn’t the Future. It’s the Present We’ve Been Denied.” Here’s yet another brilliant feature by @Daojoan. “The fediverse won’t succeed just because it’s better. It will succeed if and only if people choose it. If they reject the idea that being trapped in someone else’s ecosystem is just the cost of existing online. If they stop believing that “free” means surrendering ownership of your own connections, your own history, your own data. If they see that the internet wasn’t built to be a factory for engagement metrics and AI-generated content farms. It was built to connect us, not silo us to pad a wealth-extremist’s bank account,” she writes.
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
ALT text detailsA screen recording showing a Mastodon timeline view. The user clicks a "play" icon in a status, which then loads and displays an interactive 3D view of a dodecaheral chain from the 3MF sample files collection.
ALT text detailsA screen recording showing a Mastodon timeline view. The user clicks a "play" icon in a status, which then loads and displays an interactive 3D view of a dodecaheral chain from the 3MF sample files collection.
Little known fact: @evan and I worked at a startup in 2020 that never launched. It wasn't a great experience for me, but I loved the team we had hired, including Evan. I didn't know much then about #activitypub or the social web.
I went back to @Flipboard in 2021 and in 2023 I started to learn about #federation because of @mike's vision. Fast forward to 2025, Flipboard + @surf are organizing #SXSW's first #FediverseHouse. Evan was one of the first people to sign on, which created a snowball from there, which helped the event be a success.
This week, we got to meet IRL for the first time! So when I think about "the purpose" of that hard 10 months at that startup, I now know what it was.
ALT text detailsPicture of Mia Quagliarello and Evan Propromou smiling at SXSW
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
Most #ActivityPub implementations include Mention objects in the tag attribute when someone mentions another actor within the content of a Note or Article. Should actor objects like Person or Group also include Mention objects in their tag attribute when mentioning other actors within their bio (summary)? Are there any implementations that already work this way? (I've checked Mastodon and it seems they don't include these mentions.) What are your thoughts on this?
Most #ActivityPub implementations include Mention objects in the tag attribute when someone mentions another actor within the content of a Note or Article. Should actor objects like Person or Group also include Mention objects in their tag attribute when mentioning other actors within their bio (summary)? Are there any implementations that already work this way? (I've checked Mastodon and it seems they don't include these mentions.) What are your thoughts on this?
Most #ActivityPub implementations include Mention objects in the tag attribute when someone mentions another actor within the content of a Note or Article. Should actor objects like Person or Group also include Mention objects in their tag attribute when mentioning other actors within their bio (summary)? Are there any implementations that already work this way? (I've checked Mastodon and it seems they don't include these mentions.) What are your thoughts on this?
Most #ActivityPub implementations include Mention objects in the tag attribute when someone mentions another actor within the content of a Note or Article. Should actor objects like Person or Group also include Mention objects in their tag attribute when mentioning other actors within their bio (summary)? Are there any implementations that already work this way? (I've checked Mastodon and it seems they don't include these mentions.) What are your thoughts on this?
Most #ActivityPub implementations include Mention objects in the tag attribute when someone mentions another actor within the content of a Note or Article. Should actor objects like Person or Group also include Mention objects in their tag attribute when mentioning other actors within their bio (summary)? Are there any implementations that already work this way? (I've checked Mastodon and it seems they don't include these mentions.) What are your thoughts on this?
Most #ActivityPub implementations include Mention objects in the tag attribute when someone mentions another actor within the content of a Note or Article. Should actor objects like Person or Group also include Mention objects in their tag attribute when mentioning other actors within their bio (summary)? Are there any implementations that already work this way? (I've checked Mastodon and it seems they don't include these mentions.) What are your thoughts on this?
Most #ActivityPub implementations include Mention objects in the tag attribute when someone mentions another actor within the content of a Note or Article. Should actor objects like Person or Group also include Mention objects in their tag attribute when mentioning other actors within their bio (summary)? Are there any implementations that already work this way? (I've checked Mastodon and it seems they don't include these mentions.) What are your thoughts on this?
Most #ActivityPub implementations include Mention objects in the tag attribute when someone mentions another actor within the content of a Note or Article. Should actor objects like Person or Group also include Mention objects in their tag attribute when mentioning other actors within their bio (summary)? Are there any implementations that already work this way? (I've checked Mastodon and it seems they don't include these mentions.) What are your thoughts on this?
大部分의 #ActivityPub 具顯들이 Note나 Article의 內容 (content) 안에서 누군가 다른 액터를 멘션할 境遇 tag 屬性으로 該當하는 Mention 客體들을 包含시킵니다. 그러면 Person, Group 等 액터 客體들도 略歷 (summary) 안에서 누군가 다른 액터를 멘션할 境遇 tag 屬性으로 該當하는 Mention 客體들을 包含해야 할까요? 或是 이미 그렇게 動作하는 具顯이 있을까요? (Mastodon은 確認해 본 結果 包含시키지 않는 것 같습니다만.) 어떻게 보시나요?
大部分의 #ActivityPub 具顯들이 Note나 Article의 內容 (content) 안에서 누군가 다른 액터를 멘션할 境遇 tag 屬性으로 該當하는 Mention 客體들을 包含시킵니다. 그러면 Person, Group 等 액터 客體들도 略歷 (summary) 안에서 누군가 다른 액터를 멘션할 境遇 tag 屬性으로 該當하는 Mention 客體들을 包含해야 할까요? 或是 이미 그렇게 動作하는 具顯이 있을까요? (Mastodon은 確認해 본 結果 包含시키지 않는 것 같습니다만.) 어떻게 보시나요?
Most #ActivityPub implementations include Mention objects in the tag attribute when someone mentions another actor within the content of a Note or Article. Should actor objects like Person or Group also include Mention objects in their tag attribute when mentioning other actors within their bio (summary)? Are there any implementations that already work this way? (I've checked Mastodon and it seems they don't include these mentions.) What are your thoughts on this?
大部分의 #ActivityPub 具顯들이 Note나 Article의 內容 (content) 안에서 누군가 다른 액터를 멘션할 境遇 tag 屬性으로 該當하는 Mention 客體들을 包含시킵니다. 그러면 Person, Group 等 액터 客體들도 略歷 (summary) 안에서 누군가 다른 액터를 멘션할 境遇 tag 屬性으로 該當하는 Mention 客體들을 包含해야 할까요? 或是 이미 그렇게 動作하는 具顯이 있을까요? (Mastodon은 確認해 본 結果 包含시키지 않는 것 같습니다만.) 어떻게 보시나요?
Most #ActivityPub implementations include Mention objects in the tag attribute when someone mentions another actor within the content of a Note or Article. Should actor objects like Person or Group also include Mention objects in their tag attribute when mentioning other actors within their bio (summary)? Are there any implementations that already work this way? (I've checked Mastodon and it seems they don't include these mentions.) What are your thoughts on this?
Little known fact: @evan and I worked at a startup in 2020 that never launched. It wasn't a great experience for me, but I loved the team we had hired, including Evan. I didn't know much then about #activitypub or the social web.
I went back to @Flipboard in 2021 and in 2023 I started to learn about #federation because of @mike's vision. Fast forward to 2025, Flipboard + @surf are organizing #SXSW's first #FediverseHouse. Evan was one of the first people to sign on, which created a snowball from there, which helped the event be a success.
This week, we got to meet IRL for the first time! So when I think about "the purpose" of that hard 10 months at that startup, I now know what it was.
ALT text detailsPicture of Mia Quagliarello and Evan Propromou smiling at SXSW
Little known fact: @evan and I worked at a startup in 2020 that never launched. It wasn't a great experience for me, but I loved the team we had hired, including Evan. I didn't know much then about #activitypub or the social web.
I went back to @Flipboard in 2021 and in 2023 I started to learn about #federation because of @mike's vision. Fast forward to 2025, Flipboard + @surf are organizing #SXSW's first #FediverseHouse. Evan was one of the first people to sign on, which created a snowball from there, which helped the event be a success.
This week, we got to meet IRL for the first time! So when I think about "the purpose" of that hard 10 months at that startup, I now know what it was.
ALT text detailsPicture of Mia Quagliarello and Evan Propromou smiling at SXSW
I just created yet another minimal #activitypub service in #dotnet. Super excited about this one, but I may have time to put the actual cool features until the weekend.
Working on the Hybridized-concepts.com website again. Still trying to get the ActivityPub module to work.
Still unable to find @cwsmith@hybridized-concepts.com when I search it. Modified the NGINX config for error reporting. Maybe that will help me figure this out.
Will also be working on the Dirt Simple guide to hosting your own community as I go.
Working on the Hybridized-concepts.com website again. Still trying to get the ActivityPub module to work.
Still unable to find @cwsmith@hybridized-concepts.com when I search it. Modified the NGINX config for error reporting. Maybe that will help me figure this out.
Will also be working on the Dirt Simple guide to hosting your own community as I go.
Any deno kv experts out here? For FLOSS ActivityPub Clients: I am looking for best practices for a key which has a geohash as secondary index and might be searchable by Date as well, like an as `Event` with a `location` :)
What I'd really like to see is BlueSky modifying their AT protocol to allow AT relays to treat ActivityPub servers as Personal Data Servers. Maybe by using aspects of the Solid protocol, as demonstrated by @activitypods?
Kinda weird hearing about Threads devs talking at Fediverse House considering that they promised full federation by the end of 2024 and we're almost through the first quarter of 2025 and we don't seem any closer to that promise.
Those who were there, did they give an update on when they plan on allowing replies and such?
A lot of #openweb work, including the #ActivityPub standard, which was developed in such spaces, without the need for a paywall or corporate sponsorship. This ethos is central to the commons-building process, where trust, collaboration, and openness are valued more than monetization or statues in formal hard structures. Fediverse, grassroots, native, trust, openness, and collaboration https://hamishcampbell.com/fediverse-grassroots-native-trust-openness-and-collaboration-thrive/
A lot of #openweb work, including the #ActivityPub standard, which was developed in such spaces, without the need for a paywall or corporate sponsorship. This ethos is central to the commons-building process, where trust, collaboration, and openness are valued more than monetization or statues in formal hard structures. Fediverse, grassroots, native, trust, openness, and collaboration https://hamishcampbell.com/fediverse-grassroots-native-trust-openness-and-collaboration-thrive/
There's no perfect way to do "Comment with Mastodon" for external websites, because #Mastodon is not meant for this.
Mastodon is designed to be a social media, not a universal login. The servers are meant to save posts, not comments.
#ActivityPub is not designed to have one universal ID for the whole #fediverse, but more like an ID for each app you use (Mastodon, Pixelfeld, Lemmy, etc.). The ID and the application layers are not separated.
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
I am writing another #activitypub service in dotnet, I tried to use GitHub copilot, and it generated MY classes. I mean, it generated classes that clearly are 90% based in MY code that I wrote and is in github. The namespace, the methods names, the models, ... WOW
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
New York Times article about the Activity Pub protocol via @petersuber
"The energy around ActivityPub reminds me of the early days of the Web,” Mr. Nelson said in a recent interview, “where anything seemed possible, and innovation was around every corner.” #ActivityPub
Was most excellent getting to meet and hear Evan Prodromou, the main brain & big kahuna behind the team that brought us the Activity Pub protocol, at the Fediverse House talks yesterday at the Speakeasy for SXSW. Always great to see that a dev doing excellent work is also a truly cool person too. @evan#sxsw#austin#activitypub#fediverse#foss#tech#irl#meetups#atx#socialmedia
ALT text detailsSelfie photo of Steven Berson on left and Evan Prodromou on right, two smiling middle aged men with black framed glasses and gray moustaches.
ALT text detailsPhoto of Evan Prodromou standing and holding a microphone in front of a blueish lit stage, giving a talk at the Speakeasy in Austin Texas for SXSW "Fediverse House" meetup
ALT text detailsPhoto of Evan Prodromou standing in front of a blueish lit stage, giving a talk at the Speakeasy in Austin Texas for SXSW "Fediverse House" meetup
Was most excellent getting to meet and hear Evan Prodromou, the main brain & big kahuna behind the team that brought us the Activity Pub protocol, at the Fediverse House talks yesterday at the Speakeasy for SXSW. Always great to see that a dev doing excellent work is also a truly cool person too. @evan#sxsw#austin#activitypub#fediverse#foss#tech#irl#meetups#atx#socialmedia
ALT text detailsSelfie photo of Steven Berson on left and Evan Prodromou on right, two smiling middle aged men with black framed glasses and gray moustaches.
ALT text detailsPhoto of Evan Prodromou standing and holding a microphone in front of a blueish lit stage, giving a talk at the Speakeasy in Austin Texas for SXSW "Fediverse House" meetup
ALT text detailsPhoto of Evan Prodromou standing in front of a blueish lit stage, giving a talk at the Speakeasy in Austin Texas for SXSW "Fediverse House" meetup
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Content from static site generators like #faircamp and #hyper8 by @freebliss is easy to host, long term, but while one would be inclined to host more dynamic services, it would be great to have a kind of (general purpose) layer that could pick up newly published, static content and notify the #fediverse
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
been a while since i've given a proper #introduction of myself, and there have been a lot to join the #ActivityPub -based social media since that time.
i'm religious in the Methodist #Christian philosophy sense, which means i can be tolerant and accept science. i'm a #TTRPG fanatic. and a software engineer by trade in the midwest.
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
Added a footer, a language switcher and a privacy policy (adapted from Mastodon's). Was going to do this in 0.10 anyway but Threads blocked me for not having a privacy policy so I jumped ahead on my todo list.
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
@BeAware@thomasjwebb It's like saying someone can control the Internet. Fun fact: ActivityPub (the protocol that drives Mastodon and other Fediverse apps) is an official W3C recommended standard and W3C is lead by (drumroll) who other than the creator of the World Wide Web itself, sir Tim Berners-Lee. This is why I trust more to truly user driven social web Fediverse rather than corporate driven Bluesky.
@BeAware@thomasjwebb It's like saying someone can control the Internet. Fun fact: ActivityPub (the protocol that drives Mastodon and other Fediverse apps) is an official W3C recommended standard and W3C is lead by (drumroll) who other than the creator of the World Wide Web itself, sir Tim Berners-Lee. This is why I trust more to truly user driven social web Fediverse rather than corporate driven Bluesky.
Seeing Threads developers discuss "shipping slop or missing the hype train" is the epitome of irony today given how they've completely flopped the Fediverse Sharing "feature" that's still barely functional after a year and a half.
(Nevermind the fact that they promised full federation by the end of 2024, what year is it again?)🙄🤦♂️
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
Content from static site generators like #faircamp and #hyper8 by @freebliss is easy to host, long term, but while one would be inclined to host more dynamic services, it would be great to have a kind of (general purpose) layer that could pick up newly published, static content and notify the #fediverse
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
이 프로젝트는 #聯合宇宙(fediverse)板 velog 같은 것으로, 소프트웨어 開發者를 爲한 #ActivityPub 基盤의 SNS 兼 블로그 플랫폼입니다. AGPL-3.0 라이선스로 소스 코드가 公開되어 있을 뿐 아니라, GitHub에서 프로젝트를 公開的으로 進行하고 있습니다.
職業으로든 趣味로든 소프트웨어를 開發하시는 분들, 聯合宇宙를 좋아하시는 분들, 새로운 플랫폼을 써 보고 싶으신 분들은 부디 參與해 주시기 바랍니다! 關心 있으신 분들은 答글이나 DM으로 이메일 住所를 보내주시면 됩니다.
Content from static site generators like #faircamp and #hyper8 by @freebliss is easy to host, long term, but while one would be inclined to host more dynamic services, it would be great to have a kind of (general purpose) layer that could pick up newly published, static content and notify the #fediverse
Content from static site generators like #faircamp and #hyper8 by @freebliss is easy to host, long term, but while one would be inclined to host more dynamic services, it would be great to have a kind of (general purpose) layer that could pick up newly published, static content and notify the #fediverse
Content from static site generators like #faircamp and #hyper8 by @freebliss is easy to host, long term, but while one would be inclined to host more dynamic services, it would be great to have a kind of (general purpose) layer that could pick up newly published, static content and notify the #fediverse
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:
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
#JeRecrute, indépendants ou agence, de préférence sur #Toulouse, pour réaliser un projet de site internet (pour un petit groupe indépendant de super salles de cinéma…), qui soit notamment compatible avec #activitypub pour promouvoir les alternatives aux réseaux sociaux dominants.
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
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:
@newyorktimes's veteran tech reporter @Markoff interviewed some of #TeamFediverse including @Gargron, @reckless1280 and our CEO @mike for a feature on the rise of decentralized social media. “It goes back to the original principles where the internet started out as decentralized,” Eugen Rochko told Markoff. Here's the full story [may be paywalled].
We're so excited to develop these conversations further at SXSW this weekend — check out the itinerary and sign up to join us at #FediverseHouse at the second link.
New York Times article about the Activity Pub protocol via @petersuber
"The energy around ActivityPub reminds me of the early days of the Web,” Mr. Nelson said in a recent interview, “where anything seemed possible, and innovation was around every corner.” #ActivityPub
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
#Smithereen updates: - New notifications UI with grouping, your comment replies, and the ability to reply from there - A setting for whether to count likes and reposts towards unread notifications (off by default) - User presence statuses (without federation, for now — no idea how to federate that) and a new "online friends" block in profiles
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
Hi, I'm BeAware, sometimes I abbreviate it, BA. I just migrated here from my own instance because Mastodon updates have surpassed my Linux knowledge. Therefore, to save some headache, I decided the best option would be to move to an instance owned by someone I trust. So this is my new home
I am VERY passionate about decentralized systems like #ActivityPub and #Nostr and tend to discuss these topics at length. Especially the nuances of each and try to keep up with all the things regarding them.
I have #ADHD and #Hydrocephalus, which effects various aspects of my day to day life and how I think. I am also on disability because of it.
I am also very #AI-positive because it helps me with every day life. With my brain disorders, I don't think the same way others do, so AI helps me with describing things accurately and to make sure I get my point across in the way I mean to. I also tend to post #AIart from time to time to realize my creativity.
I'm a #Gamer that primarily plays PC games or games that are Cross Platform. Generally I enjoy #MMORPG, #SurvivalGames and such where I can just "zone out" and vibe without much stress.
Sometimes you'll see me discuss #Technology news as well.
If these seem to be within your interests, feel free to follow and if you have similar interests laid out in your bio, chances are good that ill follow back.
I've been here for a year and this is, by far, my favorite social media platform I've ever been on.
Thank for reading and may you be as federated as you wish!
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
Just published a post about Hackers' Pub's unique username change policy! Unlike most #fediverse platforms, they allow a one-time username change while preserving your connections and content history. It's all possible thanks to some clever #ActivityPub implementation using UUID-based actor URIs instead of username-based ones. If you're interested in trying it out, the platform is currently in invitation-only beta—check the post for details on how to request access!
Hackers' Pub is a community-focused platform where programmers and technology enthusiasts share knowledge and experiences. As an ActivityPub-enabled social network, it allows users to connect with others across the broader fediverse ecosystem, bringing technical discussions and insights directly to followers' feeds.
In the fediverse landscape, your username is typically set in stone once chosen. Most ActivityPub-powered platforms like Mastodon, Pleroma, and others enforce this permanence as a fundamental design principle. However, Hackers' Pub is charting a different course with a more flexible approach to digital identity.
One-Time Username Change: Freedom with Responsibility
Unlike most fediverse platforms, Hackers' Pub now allows users to change their username (the part before the @ in your Fediverse handle) exactly once during the lifetime of their account. This policy acknowledges that people grow, interests evolve, and the username that seemed perfect when you joined might not represent who you are today.
This one-time change limit strikes a careful balance—offering flexibility while maintaining the stability and reliability that's essential for a federated network.
Username Recycling: New Opportunities
When you change your username on Hackers' Pub, your previous username becomes available for other users to claim. This recycling mechanism creates new opportunities for meaningful usernames to find their most fitting owners, rather than remaining permanently locked to accounts that no longer use them.
For newcomers to the platform, this means a wider selection of desirable usernames might become available over time—something virtually unheard of in the traditional fediverse ecosystem.
Link Preservation: Maintaining Digital History
Worried about broken links after changing your username? Hackers' Pub has implemented a thoughtful solution. All permalinks containing your original username will continue to function until someone else claims that username. This approach helps preserve the web of connections and conversations that make the fediverse valuable.
This temporary preservation period gives your connections time to adjust to your new identity while preventing immediate link rot across the federation.
The Technical Foundation: ActivityPub Actor URIs
What enables Hackers' Pub to offer username changes while other fediverse platforms can't? The answer lies in how actor identities are implemented at the protocol level.
Hackers' Pub uses UUID-based actor URIs that don't contain the username. For example, a user with handle @hongminhee has an underlying ActivityPub actor URI that looks like https://hackers.pub/ap/actors/019382d3-63d7-7cf7-86e8-91e2551c306c. Since the username isn't part of this permanent identifier, it can be changed without breaking federation connections.
This contrasts sharply with platforms like Mastodon, where a user @hongminhee has an actor URI of https://mastodon.social/users/hongminhee. With the username embedded directly in the URI, changing it would break all federation connections, which is why these platforms don't allow username changes.
This architectural choice gives Hackers' Pub the technical flexibility to implement username changes while maintaining account continuity across the fediverse.
GitHub-Inspired Approach
Those familiar with GitHub might recognize this model—Hackers' Pub has adapted GitHub's username change policy for the fediverse context. This approach brings the best of both worlds: the option for identity evolution from centralized platforms and the federation benefits of the fediverse.
What This Means for Users
For Hackers' Pub users, this policy offers a significant advantage over other fediverse instances:
You can correct an unfortunate username choice
Your online identity can evolve as you do
Your content history remains intact during the transition
You maintain your social connections despite the change
The Future of Fediverse Identity
Hackers' Pub's username policy represents an interesting experiment in the fediverse—testing whether more flexible identity management can coexist with the stability needed for federation. If successful, we might see other platforms adopt similar approaches, creating a more adaptable yet still interconnected social web.
For now, users should consider this policy a compelling reason to choose Hackers' Pub as their fediverse home, especially if username flexibility matters to their online experience.
Hackers' Pub is currently in invitation-only beta. If you're interested in trying out the platform and its unique username policy, please leave your email address in the comments below. We'll add you to the allowlist, enabling you to sign up directly on the website. Note that this doesn't involve sending invitation emails—your address will simply be approved for registration when you visit the signup page.
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:
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
@newyorktimes's veteran tech reporter @Markoff interviewed some of #TeamFediverse including @Gargron, @reckless1280 and our CEO @mike for a feature on the rise of decentralized social media. “It goes back to the original principles where the internet started out as decentralized,” Eugen Rochko told Markoff. Here's the full story [may be paywalled].
We're so excited to develop these conversations further at SXSW this weekend — check out the itinerary and sign up to join us at #FediverseHouse at the second link.
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
In which I contrast the fact that @iftas is shutting down some of its services against the advent of "Free Our Feeds," and I speculate that maybe we're seeing an ATProto/ActivityPub standards war.
#フェディバース（#fediverse）用のボットを作りたいですか？#BotKit by Fedifyを使えば、わずか数行のコードでスタンドアロンのActivityPubボットを構築できます！従来のMastodonやMisskeyボットとは異なり、BotKitはプラットフォームの制約なしに完全なActivityPubサーバーを作成できます。
#연합우주(#fediverse)를 위한 봇을 만들고 싶으신가요? #BotKit by Fedify를 사용하면 몇 줄의 코드만으로 독립형 #ActivityPub 봇을 구축할 수 있습니다! 일반적인 Mastodon 또는 Misskey 봇과 달리, BotKit은 플랫폼 제약 없이 완전한 ActivityPub 서버를 만들 수 있게 도와줍니다.
Want to create a #bot for the #fediverse? #BotKit by @fedify lets you build standalone #ActivityPub bots with just a few lines of code! Unlike traditional Mastodon bots, BotKit helps you create complete ActivityPub servers without platform constraints.
With BotKit, you can:
Build bots that respond to mentions, follows, and messages
Create rich content with formatted text, mentions, and media
Publish scheduled posts and automatically manage conversations
Deploy easily on Deno Deploy, Docker, or self-hosted servers
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
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:
In which I contrast the fact that @iftas is shutting down some of its services against the advent of "Free Our Feeds," and I speculate that maybe we're seeing an ATProto/ActivityPub standards war.
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
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 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:
Want to create a #bot for the #fediverse? #BotKit by @fedify lets you build standalone #ActivityPub bots with just a few lines of code! Unlike traditional Mastodon bots, BotKit helps you create complete ActivityPub servers without platform constraints.
With BotKit, you can:
Build bots that respond to mentions, follows, and messages
Create rich content with formatted text, mentions, and media
Publish scheduled posts and automatically manage conversations
Deploy easily on Deno Deploy, Docker, or self-hosted servers
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:
Want to create a #bot for the #fediverse? #BotKit by @fedify lets you build standalone #ActivityPub bots with just a few lines of code! Unlike traditional Mastodon bots, BotKit helps you create complete ActivityPub servers without platform constraints.
With BotKit, you can:
Build bots that respond to mentions, follows, and messages
Create rich content with formatted text, mentions, and media
Publish scheduled posts and automatically manage conversations
Deploy easily on Deno Deploy, Docker, or self-hosted servers
#フェディバース（#fediverse）用のボットを作りたいですか？#BotKit by Fedifyを使えば、わずか数行のコードでスタンドアロンのActivityPubボットを構築できます！従来のMastodonやMisskeyボットとは異なり、BotKitはプラットフォームの制約なしに完全なActivityPubサーバーを作成できます。
#フェディバース（#fediverse）用のボットを作りたいですか？#BotKit by Fedifyを使えば、わずか数行のコードでスタンドアロンのActivityPubボットを構築できます！従来のMastodonやMisskeyボットとは異なり、BotKitはプラットフォームの制約なしに完全なActivityPubサーバーを作成できます。
#연합우주(#fediverse)를 위한 봇을 만들고 싶으신가요? #BotKit by Fedify를 사용하면 몇 줄의 코드만으로 독립형 #ActivityPub 봇을 구축할 수 있습니다! 일반적인 Mastodon 또는 Misskey 봇과 달리, BotKit은 플랫폼 제약 없이 완전한 ActivityPub 서버를 만들 수 있게 도와줍니다.
#フェディバース（#fediverse）用のボットを作りたいですか？#BotKit by Fedifyを使えば、わずか数行のコードでスタンドアロンのActivityPubボットを構築できます！従来のMastodonやMisskeyボットとは異なり、BotKitはプラットフォームの制約なしに完全なActivityPubサーバーを作成できます。
#연합우주(#fediverse)를 위한 봇을 만들고 싶으신가요? #BotKit by Fedify를 사용하면 몇 줄의 코드만으로 독립형 #ActivityPub 봇을 구축할 수 있습니다! 일반적인 Mastodon 또는 Misskey 봇과 달리, BotKit은 플랫폼 제약 없이 완전한 ActivityPub 서버를 만들 수 있게 도와줍니다.
Want to create a #bot for the #fediverse? #BotKit by @fedify lets you build standalone #ActivityPub bots with just a few lines of code! Unlike traditional Mastodon bots, BotKit helps you create complete ActivityPub servers without platform constraints.
With BotKit, you can:
Build bots that respond to mentions, follows, and messages
Create rich content with formatted text, mentions, and media
Publish scheduled posts and automatically manage conversations
Deploy easily on Deno Deploy, Docker, or self-hosted servers
Want to create a #bot for the #fediverse? #BotKit by @fedify lets you build standalone #ActivityPub bots with just a few lines of code! Unlike traditional Mastodon bots, BotKit helps you create complete ActivityPub servers without platform constraints.
With BotKit, you can:
Build bots that respond to mentions, follows, and messages
Create rich content with formatted text, mentions, and media
Publish scheduled posts and automatically manage conversations
Deploy easily on Deno Deploy, Docker, or self-hosted servers
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
Is there a good reference of #activitypub scaling with more users/clients, servers, content exchange, network topology etc. What happens when everything and everywhere is connected?
Looking for a more or less rigorous *model* to compare and contrast with e.g., how #atproto and #p2p protocols scale (at least in theory) and put some mathematical meat behind the recent "message passing" vs "shared heap" discussions.
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
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 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 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:
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
Quick note for anyone using the #WordPress#ActivityPub integration: we’ve been doing odd experiments with doing microblogging using Mastodon apps all from within our own site.
I think we’re really close to being able to make the switch over. We want @hello to eventually migrate completely over to @news, but there’s a few tiny headaches we’re trying to solve first.
If anyone is using the Enable Mastodon Apps plugin with Friends and ActivityPub, can you do me a favor and look at this outstanding issue? Seems like using the WordPress Status post format is causing server errors, and I suspect WordPress interprets most microblogging statuses as this type.
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂
It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!
In the last few months, many people have called on the EU to start supporting open alternatives to US-owned social media sites. The thing is: The EU has been doing that for some time already. It has financed, among others, ActivityPub, Mastodon and PeerTube. For @netzpolitik_feed, we spoke to Michiel Leenaars, who professionally gives out buckets of EU cash to open source projects.
An intriguing new project by @raphael provides a pluggable #django app with the models, views and background tasks to let any django application integrate with any other service that uses #ActivityPub
Enabling popular "generic" web platforms like django, laravel etc. to integrate with the #fediverse complements the development of plugins for more specific apps like #wordpress, #discourse etc. and the dedicated "social media" type servers like #mastodon and #pixelfed
An intriguing new project by @raphael provides a pluggable #django app with the models, views and background tasks to let any django application integrate with any other service that uses #ActivityPub
Enabling popular "generic" web platforms like django, laravel etc. to integrate with the #fediverse complements the development of plugins for more specific apps like #wordpress, #discourse etc. and the dedicated "social media" type servers like #mastodon and #pixelfed
In the last few months, many people have called on the EU to start supporting open alternatives to US-owned social media sites. The thing is: The EU has been doing that for some time already. It has financed, among others, ActivityPub, Mastodon and PeerTube. For @netzpolitik_feed, we spoke to Michiel Leenaars, who professionally gives out buckets of EU cash to open source projects.
In the last few months, many people have called on the EU to start supporting open alternatives to US-owned social media sites. The thing is: The EU has been doing that for some time already. It has financed, among others, ActivityPub, Mastodon and PeerTube. For @netzpolitik_feed, we spoke to Michiel Leenaars, who professionally gives out buckets of EU cash to open source projects.
The Internet and the web were born open, then closed walls were built in the name of profit and user convenience. It's time we leave the closed walls behind and go back to how the Internet was supposed to be: a collection of independent applications using common protocols.
The Internet and the web were born open, then closed walls were built in the name of profit and user convenience. It's time we leave the closed walls behind and go back to how the Internet was supposed to be: a collection of independent applications using common protocols.
In den letzten Monaten haben viele Menschen gefordert, die EU sollte doch mal bitte offene Alternativen zu amerikanischen Social-Media-Diensten fördern. Die Sache ist nur: Das tut sie schon lange. ActivityPub, Mastodon und PeerTube haben alle von einem EU-Förderprogramm profitiert. Für @netzpolitik_feed haben wir Michiel Leenaars interviewt, der das EU-Geld aus diesem Programm verteilt.
Are you an Austin-based developer working on the open social web? If so, you’re invited to our Developer Meetup, hosted by ActivityPub co-author @evan. You don’t need a badge to attend but we do ask that you RSVP. 🙏 Let’s see what you’re building! https://lu.ma/bvump3m6
Are you an Austin-based developer working on the open social web? If so, you’re invited to our Developer Meetup, hosted by ActivityPub co-author @evan. You don’t need a badge to attend but we do ask that you RSVP. 🙏 Let’s see what you’re building! https://lu.ma/bvump3m6
Are you an Austin-based developer working on the open social web? If so, you’re invited to our Developer Meetup, hosted by ActivityPub co-author @evan. You don’t need a badge to attend but we do ask that you RSVP. 🙏 Let’s see what you’re building! https://lu.ma/bvump3m6
Are you an Austin-based developer working on the open social web? If so, you’re invited to our Developer Meetup, hosted by ActivityPub co-author @evan. You don’t need a badge to attend but we do ask that you RSVP. 🙏 Let’s see what you’re building! https://lu.ma/bvump3m6
So #fediverse / #mastodon / #activitypub people, what do we have by now that is a usable alternative to facebooks group- & event feature?
I have a number of friends who work in event-related contexts, play in bands, do art exhibitions etc. most of them are still at metas platforms for basically 1-2 reasons. Twatter doesn't really matter at all to them because no feature keeps them there.
The Main reason for most of them to stay with meta is to promote their events & the easiness to invite people to an event or self-subscribe.
The other reasons are groups/channels where people have sub-discussion threads, that "feel a little bit isolated from the rest of the platform". I'm not 100% convinced, that this can/can't be substituted by something like "only display this toot to people following the #hashtag" or something similar.
Reason number three is network effect at the end of the day, which is not really technically addressable from "our side" imho. Being able to show easy to use alternatives should be doable tho.
In the last few months, many people have called on the EU to start supporting open alternatives to US-owned social media sites. The thing is: The EU has been doing that for some time already. It has financed, among others, ActivityPub, Mastodon and PeerTube. For @netzpolitik_feed, we spoke to Michiel Leenaars, who professionally gives out buckets of EU cash to open source projects.
In den letzten Monaten haben viele Menschen gefordert, die EU sollte doch mal bitte offene Alternativen zu amerikanischen Social-Media-Diensten fördern. Die Sache ist nur: Das tut sie schon lange. ActivityPub, Mastodon und PeerTube haben alle von einem EU-Förderprogramm profitiert. Für @netzpolitik_feed haben wir Michiel Leenaars interviewt, der das EU-Geld aus diesem Programm verteilt.
Proton is leaving because Proton cannot control the flow of information here on the Fediverse.
Most corporations mimic social algorithms to their advantage, particularly, to suppress news and information that may not paint them in a good light. Proton cannot do that on the Fediverse.
When Proton rebranded a few years ago, which caused some people to lose their accounts with no refund, they silenced any complaints on both Facebook and Reddit. I know, because I was one of those people. Most of you were happy to have the new upgraded accounts, but if you had the original family plan, which they discontinued (only to start selling a new family plan months later), you were not a happy person to find out you lost your service.
Additionally, it has been brought to people's attention that Proton now falls under Us-jurisdiction. Proton would like to argue that is only for Proton Wallet, but our legal system does not allow a company to pick and choose. Plus, even if they could (you cannot), it means they could still be pressured and influence by US Politics and US Laws now. This was another little fact, Proton wanted to suppress, but cannot because the Fediverse is organic, and not centralized.
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
Big question, Why ATProtocol from #BlueSkySocial#PBC’s mouth instead of Mastodon and ActivityPub?:
“Why not use ActivityPub? #ActivityPub is a federated social networking technology popularized by #Mastodon.
Account #portability is a major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects #users from sudden bans, server shutdowns, and policy disagreements. Our #solution for portability requires both signed data repositories and #DIDs, neither of which are easy to retrofit into ActivityPub. The migration #tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user's previous data.
Another major reason is #scalability. #ActivityPub depends heavily on delivering messages between a wide network of small-to-medium sized nodes, which can cause individual #nodes to be flooded with traffic and generally struggles to provide global views of #activity.”
Big question, Why ATProtocol from #BlueSkySocial#PBC’s mouth instead of Mastodon and ActivityPub?:
“Why not use ActivityPub? #ActivityPub is a federated social networking technology popularized by #Mastodon.
Account #portability is a major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects #users from sudden bans, server shutdowns, and policy disagreements. Our #solution for portability requires both signed data repositories and #DIDs, neither of which are easy to retrofit into ActivityPub. The migration #tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user's previous data.
Another major reason is #scalability. #ActivityPub depends heavily on delivering messages between a wide network of small-to-medium sized nodes, which can cause individual #nodes to be flooded with traffic and generally struggles to provide global views of #activity.”
ALT text detailsA rather fluffy technical diagram of the AT Protocol.
source https://www.theregister.com/2025/01/14/free_our_feeds_decentralized_social_media/
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
The hardest platform to interoperate with when implementing an #ActivityPub server is #Threads. They often spit out a 500 Internal Server Error with no message, and they don't even provide source code, which makes it impossible for me to reproduce the error.
@BeAware because #ActivityPub is worthless except in the context of a complete system, and it doesn't even specify that complete system, the way that HTTP+HTML=the web.
BTW I'm on Pleroma. It's another implementation of the Mastodon protocol.
I'll have to write a down-to-earth explanation of Mastodon Protocol (which != #ActivityPub) just so I can understand it myself, then use it to implement #Fediverse Login!
ActivityPub was clearly designed by Architecture Astronauts (a googleable term coined by Joel Spolsky).
The hardest platform to interoperate with when implementing an #ActivityPub server is #Threads. They often spit out a 500 Internal Server Error with no message, and they don't even provide source code, which makes it impossible for me to reproduce the error.
The hardest platform to interoperate with when implementing an #ActivityPub server is #Threads. They often spit out a 500 Internal Server Error with no message, and they don't even provide source code, which makes it impossible for me to reproduce the error.
The hardest platform to interoperate with when implementing an #ActivityPub server is #Threads. They often spit out a 500 Internal Server Error with no message, and they don't even provide source code, which makes it impossible for me to reproduce the error.
The hardest platform to interoperate with when implementing an #ActivityPub server is #Threads. They often spit out a 500 Internal Server Error with no message, and they don't even provide source code, which makes it impossible for me to reproduce the error.
I.e., a Note or Article or whatever is saying that the author is NOT an actor on the same server host (example·com), but an actor over on the server host mastodon·social.
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
ActivityPub outboxes are the new RSS / Atom / WebFeed.
You can just read from them to get a JSON feed of someone's posts.
I.e., you do NOT have to implement the full suite of Fediverse protocols, or Follow, or run your own server, or anything else to get someone's posts on the Fediverse — just read from their outbox.
ActivityPub outboxes are the new RSS / Atom / WebFeed.
You can just read from them to get a JSON feed of someone's posts.
I.e., you do NOT have to implement the full suite of Fediverse protocols, or Follow, or run your own server, or anything else to get someone's posts on the Fediverse — just read from their outbox.
I'm in the process of setting up my account on my personal instance and I'm noticing that my profile picture isn't being displayed when you view the account from Mastodon (official client or other external clients) or Pixelfed.
I know it works because I've seen several GtS accounts here with PPs that display fine. Any ideas on how to get it to display?
ActivityPub outboxes are the new RSS / Atom / WebFeed.
You can just read from them to get a JSON feed of someone's posts.
I.e., you do NOT have to implement the full suite of Fediverse protocols, or Follow, or run your own server, or anything else to get someone's posts on the Fediverse — just read from their outbox.
ActivityPub outboxes are the new RSS / Atom / WebFeed.
You can just read from them to get a JSON feed of someone's posts.
I.e., you do NOT have to implement the full suite of Fediverse protocols, or Follow, or run your own server, or anything else to get someone's posts on the Fediverse — just read from their outbox.
ActivityPub outboxes are the new RSS / Atom / WebFeed.
You can just read from them to get a JSON feed of someone's posts.
I.e., you do NOT have to implement the full suite of Fediverse protocols, or Follow, or run your own server, or anything else to get someone's posts on the Fediverse — just read from their outbox.
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Hollo(@hollo)는 Fedify로 구동되는 1인 사용자용 마이크로블로깅 서버입니다. 1인 사용자를 위해 설계되었지만, ActivityPub를 통해 완전히 연합되어 연합우주 전체의 사용자들과 상호작용할 수 있습니다. Hollo는 Mastodon 호환 API를 구현하여 자체 웹 인터페이스 없이도 대부분의 Mastodon 클라이언트와 호환됩니다.
Hollo는 또한 정식 출시 전에 최신 Fedify 기능을 테스트하는 실험장으로도 활용되고 있습니다.
BotKit(@botkit)은 저희의 가장 새로운 구성원으로, ActivityPub 봇을 만들기 위해 특별히 설계된 프레임워크입니다. 전통적인 Mastodon 봇과 달리, BotKit은 플랫폼별 제한(글자 수 제한 등)에 구애받지 않는 독립적인 ActivityPub 서버를 만듭니다.
BotKit의 API는 의도적으로 단순하게 설계되어 단일 TypeScript 파일로 완전한 봇을 만들 수 있습니다!
세 프로젝트 모두 @fedify-dev GitHub 조직에서 오픈 소스로 공개되어 있습니다. 각기 다른 목적을 가지고 있지만, ActivityPub 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Hollo(@hollo)는 Fedify로 구동되는 1인 사용자용 마이크로블로깅 서버입니다. 1인 사용자를 위해 설계되었지만, ActivityPub를 통해 완전히 연합되어 연합우주 전체의 사용자들과 상호작용할 수 있습니다. Hollo는 Mastodon 호환 API를 구현하여 자체 웹 인터페이스 없이도 대부분의 Mastodon 클라이언트와 호환됩니다.
Hollo는 또한 정식 출시 전에 최신 Fedify 기능을 테스트하는 실험장으로도 활용되고 있습니다.
BotKit(@botkit)은 저희의 가장 새로운 구성원으로, ActivityPub 봇을 만들기 위해 특별히 설계된 프레임워크입니다. 전통적인 Mastodon 봇과 달리, BotKit은 플랫폼별 제한(글자 수 제한 등)에 구애받지 않는 독립적인 ActivityPub 서버를 만듭니다.
BotKit의 API는 의도적으로 단순하게 설계되어 단일 TypeScript 파일로 완전한 봇을 만들 수 있습니다!
세 프로젝트 모두 @fedify-dev GitHub 조직에서 오픈 소스로 공개되어 있습니다. 각기 다른 목적을 가지고 있지만, ActivityPub 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
I'm kind of curious: how many of you on #ActivityPub based platforms also have an account on #Bluesky? most people I've seen using both usually opt in for something like Bridgy Fed, instead of maintaining separate accounts.
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Hollo(@hollo)는 Fedify로 구동되는 1인 사용자용 마이크로블로깅 서버입니다. 1인 사용자를 위해 설계되었지만, ActivityPub를 통해 완전히 연합되어 연합우주 전체의 사용자들과 상호작용할 수 있습니다. Hollo는 Mastodon 호환 API를 구현하여 자체 웹 인터페이스 없이도 대부분의 Mastodon 클라이언트와 호환됩니다.
Hollo는 또한 정식 출시 전에 최신 Fedify 기능을 테스트하는 실험장으로도 활용되고 있습니다.
BotKit(@botkit)은 저희의 가장 새로운 구성원으로, ActivityPub 봇을 만들기 위해 특별히 설계된 프레임워크입니다. 전통적인 Mastodon 봇과 달리, BotKit은 플랫폼별 제한(글자 수 제한 등)에 구애받지 않는 독립적인 ActivityPub 서버를 만듭니다.
BotKit의 API는 의도적으로 단순하게 설계되어 단일 TypeScript 파일로 완전한 봇을 만들 수 있습니다!
세 프로젝트 모두 @fedify-dev GitHub 조직에서 오픈 소스로 공개되어 있습니다. 각기 다른 목적을 가지고 있지만, ActivityPub 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Hollo(@hollo)는 Fedify로 구동되는 1인 사용자용 마이크로블로깅 서버입니다. 1인 사용자를 위해 설계되었지만, ActivityPub를 통해 완전히 연합되어 연합우주 전체의 사용자들과 상호작용할 수 있습니다. Hollo는 Mastodon 호환 API를 구현하여 자체 웹 인터페이스 없이도 대부분의 Mastodon 클라이언트와 호환됩니다.
Hollo는 또한 정식 출시 전에 최신 Fedify 기능을 테스트하는 실험장으로도 활용되고 있습니다.
BotKit(@botkit)은 저희의 가장 새로운 구성원으로, ActivityPub 봇을 만들기 위해 특별히 설계된 프레임워크입니다. 전통적인 Mastodon 봇과 달리, BotKit은 플랫폼별 제한(글자 수 제한 등)에 구애받지 않는 독립적인 ActivityPub 서버를 만듭니다.
BotKit의 API는 의도적으로 단순하게 설계되어 단일 TypeScript 파일로 완전한 봇을 만들 수 있습니다!
세 프로젝트 모두 @fedify-dev GitHub 조직에서 오픈 소스로 공개되어 있습니다. 각기 다른 목적을 가지고 있지만, ActivityPub 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
Hollo(@hollo)는 Fedify로 구동되는 1인 사용자용 마이크로블로깅 서버입니다. 1인 사용자를 위해 설계되었지만, ActivityPub를 통해 완전히 연합되어 연합우주 전체의 사용자들과 상호작용할 수 있습니다. Hollo는 Mastodon 호환 API를 구현하여 자체 웹 인터페이스 없이도 대부분의 Mastodon 클라이언트와 호환됩니다.
Hollo는 또한 정식 출시 전에 최신 Fedify 기능을 테스트하는 실험장으로도 활용되고 있습니다.
BotKit(@botkit)은 저희의 가장 새로운 구성원으로, ActivityPub 봇을 만들기 위해 특별히 설계된 프레임워크입니다. 전통적인 Mastodon 봇과 달리, BotKit은 플랫폼별 제한(글자 수 제한 등)에 구애받지 않는 독립적인 ActivityPub 서버를 만듭니다.
BotKit의 API는 의도적으로 단순하게 설계되어 단일 TypeScript 파일로 완전한 봇을 만들 수 있습니다!
세 프로젝트 모두 @fedify-dev GitHub 조직에서 오픈 소스로 공개되어 있습니다. 각기 다른 목적을 가지고 있지만, ActivityPub 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
I was thinking about managing a thread with #ActivityPub client and realized that observer actors would need to be created with Create(Application) activity where actor is user's primary actor (the one created during the registration).
This is unusual, but should work. Primary actors can't be created this way because the actor property of Create activity can't refer to a not yet created actor.
I was thinking about managing a thread with #ActivityPub client and realized that observer actors would need to be created with Create(Application) activity where actor is user's primary actor (the one created during the registration).
This is unusual, but should work. Primary actors can't be created this way because the actor property of Create activity can't refer to a not yet created actor.
Want different domains for your WebFinger handles and server URIs? Fedify 1.5.0 will let you use domains like @alice@example.com as fediverse handles while serving content from https://ap.example.com. This gives you more flexibility in how you structure your federated services.
Need to ensure consistent URLs across your infrastructure? The new canonical origin support lets you explicitly set your server's authoritative domain. This is particularly useful when running behind reverse proxies or load balancers—no more unexpected URLs generated from internal hostnames.
These features represent our ongoing commitment to making Fedify more flexible and production-ready.
Can't wait to try these features? You can experiment with them today using our unstable release v1.5.0-dev.680+562e3dc0 (JSR & npm). Keep in mind that this is an unstable release intended for testing—use it in production at your own risk.
Otherwise, stay tuned for the stable Fedify 1.5.0 release!
ALT text detailsSeparating WebFinger host from the server origin
This API is available since Fedify 1.5.0.
Sometimes you may want to use different domain names for WebFinger handles (i.e., fediverse handles) and the server origin. For example, you may want to use https://ap.example.com/actors/alice as an actor URI but want to use @alice@example.com as its fediverse handle.
In such cases, you can set the handleHost different from the webOrigin in the origin option. The handleHost is used to construct the WebFinger handles, and the webOrigin is used to construct the URLs in the Context object:
const federation = createFederation({
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
});
NOTE
Even if you set the handleHost different from the webOrigin, the other fediverse handle with the same domain name as the webOrigin will still be recognized.
In the above example, two fediverse handles are recognized as the same:
• @alice@example.com
• @alice@ap.example.com
ALT text detailsExplicitly setting the canonical origin
This API is available since Fedify 1.5.0.
Or you can explicitly set the canonical origin of the server by passing the origin option to the createFederation() function. The origin option is either a string or a FederationOrigin object, which consists of two fields: handleHost and webOrigin.
For example, if you want to set the canonical origin to https://example.com, you can pass the string:
const federation = createFederation({
origin: "https://example.com",
});
NOTE
The origin option has to include the leading https:// or http:// scheme.
Such a configuration leads the constructed URLs using Context to use the canonical origin instead of the origin from the incoming HTTP requests, which avoids constructing unexpected URLs when a request bypasses a reverse proxy or a load balancer.
CAUTION
For example, suppose that your federated server (upstream) is accessible at the http://1.2.3.4:8000 and your load balancer (downstream) is accessible at the https://example.com and forwards the requests to the upstream server. In this case, you should set the canonical origin to https://example.com to construct the correct URLs. Otherwise, when some malicious actor directly sends a request to the upstream server, the constructed URLs will start with http://1.2.3.4:8000 instead of https://example.com, which can lead to security issues.
Want different domains for your WebFinger handles and server URIs? Fedify 1.5.0 will let you use domains like @alice@example.com as fediverse handles while serving content from https://ap.example.com. This gives you more flexibility in how you structure your federated services.
Need to ensure consistent URLs across your infrastructure? The new canonical origin support lets you explicitly set your server's authoritative domain. This is particularly useful when running behind reverse proxies or load balancers—no more unexpected URLs generated from internal hostnames.
These features represent our ongoing commitment to making Fedify more flexible and production-ready.
Can't wait to try these features? You can experiment with them today using our unstable release v1.5.0-dev.680+562e3dc0 (JSR & npm). Keep in mind that this is an unstable release intended for testing—use it in production at your own risk.
Otherwise, stay tuned for the stable Fedify 1.5.0 release!
ALT text detailsSeparating WebFinger host from the server origin
This API is available since Fedify 1.5.0.
Sometimes you may want to use different domain names for WebFinger handles (i.e., fediverse handles) and the server origin. For example, you may want to use https://ap.example.com/actors/alice as an actor URI but want to use @alice@example.com as its fediverse handle.
In such cases, you can set the handleHost different from the webOrigin in the origin option. The handleHost is used to construct the WebFinger handles, and the webOrigin is used to construct the URLs in the Context object:
const federation = createFederation({
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
});
NOTE
Even if you set the handleHost different from the webOrigin, the other fediverse handle with the same domain name as the webOrigin will still be recognized.
In the above example, two fediverse handles are recognized as the same:
• @alice@example.com
• @alice@ap.example.com
ALT text detailsExplicitly setting the canonical origin
This API is available since Fedify 1.5.0.
Or you can explicitly set the canonical origin of the server by passing the origin option to the createFederation() function. The origin option is either a string or a FederationOrigin object, which consists of two fields: handleHost and webOrigin.
For example, if you want to set the canonical origin to https://example.com, you can pass the string:
const federation = createFederation({
origin: "https://example.com",
});
NOTE
The origin option has to include the leading https:// or http:// scheme.
Such a configuration leads the constructed URLs using Context to use the canonical origin instead of the origin from the incoming HTTP requests, which avoids constructing unexpected URLs when a request bypasses a reverse proxy or a load balancer.
CAUTION
For example, suppose that your federated server (upstream) is accessible at the http://1.2.3.4:8000 and your load balancer (downstream) is accessible at the https://example.com and forwards the requests to the upstream server. In this case, you should set the canonical origin to https://example.com to construct the correct URLs. Otherwise, when some malicious actor directly sends a request to the upstream server, the constructed URLs will start with http://1.2.3.4:8000 instead of https://example.com, which can lead to security issues.
Want different domains for your WebFinger handles and server URIs? Fedify 1.5.0 will let you use domains like @alice@example.com as fediverse handles while serving content from https://ap.example.com. This gives you more flexibility in how you structure your federated services.
Need to ensure consistent URLs across your infrastructure? The new canonical origin support lets you explicitly set your server's authoritative domain. This is particularly useful when running behind reverse proxies or load balancers—no more unexpected URLs generated from internal hostnames.
These features represent our ongoing commitment to making Fedify more flexible and production-ready.
Can't wait to try these features? You can experiment with them today using our unstable release v1.5.0-dev.680+562e3dc0 (JSR & npm). Keep in mind that this is an unstable release intended for testing—use it in production at your own risk.
Otherwise, stay tuned for the stable Fedify 1.5.0 release!
ALT text detailsSeparating WebFinger host from the server origin
This API is available since Fedify 1.5.0.
Sometimes you may want to use different domain names for WebFinger handles (i.e., fediverse handles) and the server origin. For example, you may want to use https://ap.example.com/actors/alice as an actor URI but want to use @alice@example.com as its fediverse handle.
In such cases, you can set the handleHost different from the webOrigin in the origin option. The handleHost is used to construct the WebFinger handles, and the webOrigin is used to construct the URLs in the Context object:
const federation = createFederation({
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
});
NOTE
Even if you set the handleHost different from the webOrigin, the other fediverse handle with the same domain name as the webOrigin will still be recognized.
In the above example, two fediverse handles are recognized as the same:
• @alice@example.com
• @alice@ap.example.com
ALT text detailsExplicitly setting the canonical origin
This API is available since Fedify 1.5.0.
Or you can explicitly set the canonical origin of the server by passing the origin option to the createFederation() function. The origin option is either a string or a FederationOrigin object, which consists of two fields: handleHost and webOrigin.
For example, if you want to set the canonical origin to https://example.com, you can pass the string:
const federation = createFederation({
origin: "https://example.com",
});
NOTE
The origin option has to include the leading https:// or http:// scheme.
Such a configuration leads the constructed URLs using Context to use the canonical origin instead of the origin from the incoming HTTP requests, which avoids constructing unexpected URLs when a request bypasses a reverse proxy or a load balancer.
CAUTION
For example, suppose that your federated server (upstream) is accessible at the http://1.2.3.4:8000 and your load balancer (downstream) is accessible at the https://example.com and forwards the requests to the upstream server. In this case, you should set the canonical origin to https://example.com to construct the correct URLs. Otherwise, when some malicious actor directly sends a request to the upstream server, the constructed URLs will start with http://1.2.3.4:8000 instead of https://example.com, which can lead to security issues.
Want different domains for your WebFinger handles and server URIs? Fedify 1.5.0 will let you use domains like @alice@example.com as fediverse handles while serving content from https://ap.example.com. This gives you more flexibility in how you structure your federated services.
Need to ensure consistent URLs across your infrastructure? The new canonical origin support lets you explicitly set your server's authoritative domain. This is particularly useful when running behind reverse proxies or load balancers—no more unexpected URLs generated from internal hostnames.
These features represent our ongoing commitment to making Fedify more flexible and production-ready.
Can't wait to try these features? You can experiment with them today using our unstable release v1.5.0-dev.680+562e3dc0 (JSR & npm). Keep in mind that this is an unstable release intended for testing—use it in production at your own risk.
Otherwise, stay tuned for the stable Fedify 1.5.0 release!
ALT text detailsSeparating WebFinger host from the server origin
This API is available since Fedify 1.5.0.
Sometimes you may want to use different domain names for WebFinger handles (i.e., fediverse handles) and the server origin. For example, you may want to use https://ap.example.com/actors/alice as an actor URI but want to use @alice@example.com as its fediverse handle.
In such cases, you can set the handleHost different from the webOrigin in the origin option. The handleHost is used to construct the WebFinger handles, and the webOrigin is used to construct the URLs in the Context object:
const federation = createFederation({
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
});
NOTE
Even if you set the handleHost different from the webOrigin, the other fediverse handle with the same domain name as the webOrigin will still be recognized.
In the above example, two fediverse handles are recognized as the same:
• @alice@example.com
• @alice@ap.example.com
ALT text detailsExplicitly setting the canonical origin
This API is available since Fedify 1.5.0.
Or you can explicitly set the canonical origin of the server by passing the origin option to the createFederation() function. The origin option is either a string or a FederationOrigin object, which consists of two fields: handleHost and webOrigin.
For example, if you want to set the canonical origin to https://example.com, you can pass the string:
const federation = createFederation({
origin: "https://example.com",
});
NOTE
The origin option has to include the leading https:// or http:// scheme.
Such a configuration leads the constructed URLs using Context to use the canonical origin instead of the origin from the incoming HTTP requests, which avoids constructing unexpected URLs when a request bypasses a reverse proxy or a load balancer.
CAUTION
For example, suppose that your federated server (upstream) is accessible at the http://1.2.3.4:8000 and your load balancer (downstream) is accessible at the https://example.com and forwards the requests to the upstream server. In this case, you should set the canonical origin to https://example.com to construct the correct URLs. Otherwise, when some malicious actor directly sends a request to the upstream server, the constructed URLs will start with http://1.2.3.4:8000 instead of https://example.com, which can lead to security issues.
Want different domains for your WebFinger handles and server URIs? Fedify 1.5.0 will let you use domains like @alice@example.com as fediverse handles while serving content from https://ap.example.com. This gives you more flexibility in how you structure your federated services.
Need to ensure consistent URLs across your infrastructure? The new canonical origin support lets you explicitly set your server's authoritative domain. This is particularly useful when running behind reverse proxies or load balancers—no more unexpected URLs generated from internal hostnames.
These features represent our ongoing commitment to making Fedify more flexible and production-ready.
Can't wait to try these features? You can experiment with them today using our unstable release v1.5.0-dev.680+562e3dc0 (JSR & npm). Keep in mind that this is an unstable release intended for testing—use it in production at your own risk.
Otherwise, stay tuned for the stable Fedify 1.5.0 release!
ALT text detailsSeparating WebFinger host from the server origin
This API is available since Fedify 1.5.0.
Sometimes you may want to use different domain names for WebFinger handles (i.e., fediverse handles) and the server origin. For example, you may want to use https://ap.example.com/actors/alice as an actor URI but want to use @alice@example.com as its fediverse handle.
In such cases, you can set the handleHost different from the webOrigin in the origin option. The handleHost is used to construct the WebFinger handles, and the webOrigin is used to construct the URLs in the Context object:
const federation = createFederation({
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
});
NOTE
Even if you set the handleHost different from the webOrigin, the other fediverse handle with the same domain name as the webOrigin will still be recognized.
In the above example, two fediverse handles are recognized as the same:
• @alice@example.com
• @alice@ap.example.com
ALT text detailsExplicitly setting the canonical origin
This API is available since Fedify 1.5.0.
Or you can explicitly set the canonical origin of the server by passing the origin option to the createFederation() function. The origin option is either a string or a FederationOrigin object, which consists of two fields: handleHost and webOrigin.
For example, if you want to set the canonical origin to https://example.com, you can pass the string:
const federation = createFederation({
origin: "https://example.com",
});
NOTE
The origin option has to include the leading https:// or http:// scheme.
Such a configuration leads the constructed URLs using Context to use the canonical origin instead of the origin from the incoming HTTP requests, which avoids constructing unexpected URLs when a request bypasses a reverse proxy or a load balancer.
CAUTION
For example, suppose that your federated server (upstream) is accessible at the http://1.2.3.4:8000 and your load balancer (downstream) is accessible at the https://example.com and forwards the requests to the upstream server. In this case, you should set the canonical origin to https://example.com to construct the correct URLs. Otherwise, when some malicious actor directly sends a request to the upstream server, the constructed URLs will start with http://1.2.3.4:8000 instead of https://example.com, which can lead to security issues.
Want different domains for your WebFinger handles and server URIs? Fedify 1.5.0 will let you use domains like @alice@example.com as fediverse handles while serving content from https://ap.example.com. This gives you more flexibility in how you structure your federated services.
Need to ensure consistent URLs across your infrastructure? The new canonical origin support lets you explicitly set your server's authoritative domain. This is particularly useful when running behind reverse proxies or load balancers—no more unexpected URLs generated from internal hostnames.
These features represent our ongoing commitment to making Fedify more flexible and production-ready.
Can't wait to try these features? You can experiment with them today using our unstable release v1.5.0-dev.680+562e3dc0 (JSR & npm). Keep in mind that this is an unstable release intended for testing—use it in production at your own risk.
Otherwise, stay tuned for the stable Fedify 1.5.0 release!
ALT text detailsSeparating WebFinger host from the server origin
This API is available since Fedify 1.5.0.
Sometimes you may want to use different domain names for WebFinger handles (i.e., fediverse handles) and the server origin. For example, you may want to use https://ap.example.com/actors/alice as an actor URI but want to use @alice@example.com as its fediverse handle.
In such cases, you can set the handleHost different from the webOrigin in the origin option. The handleHost is used to construct the WebFinger handles, and the webOrigin is used to construct the URLs in the Context object:
const federation = createFederation({
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
});
NOTE
Even if you set the handleHost different from the webOrigin, the other fediverse handle with the same domain name as the webOrigin will still be recognized.
In the above example, two fediverse handles are recognized as the same:
• @alice@example.com
• @alice@ap.example.com
ALT text detailsExplicitly setting the canonical origin
This API is available since Fedify 1.5.0.
Or you can explicitly set the canonical origin of the server by passing the origin option to the createFederation() function. The origin option is either a string or a FederationOrigin object, which consists of two fields: handleHost and webOrigin.
For example, if you want to set the canonical origin to https://example.com, you can pass the string:
const federation = createFederation({
origin: "https://example.com",
});
NOTE
The origin option has to include the leading https:// or http:// scheme.
Such a configuration leads the constructed URLs using Context to use the canonical origin instead of the origin from the incoming HTTP requests, which avoids constructing unexpected URLs when a request bypasses a reverse proxy or a load balancer.
CAUTION
For example, suppose that your federated server (upstream) is accessible at the http://1.2.3.4:8000 and your load balancer (downstream) is accessible at the https://example.com and forwards the requests to the upstream server. In this case, you should set the canonical origin to https://example.com to construct the correct URLs. Otherwise, when some malicious actor directly sends a request to the upstream server, the constructed URLs will start with http://1.2.3.4:8000 instead of https://example.com, which can lead to security issues.
Share this news with your favorite app developers!
GoToSocial has documented their new global and post level interaction policies. I know @Fedicat has already added these - would love to see them in other apps too.
Share this news with your favorite app developers!
GoToSocial has documented their new global and post level interaction policies. I know @Fedicat has already added these - would love to see them in other apps too.
Does anyone #onHere roll their own fediverse software? I'm starting to add #activitypub features to my blog and I think it would be nice to see what fucked up activities other hobbyists are sending
Really loving #NodeBB so far. We’re currently using it at forum.wedistribute.org, and filing issues as quirks come up. But it’s really a polished experience, and #ActivityPub federation feels really good so far.
Forums could potentially be a really good fit for the Threadiverse, I’m excited to keep exploring this.
Really loving #NodeBB so far. We’re currently using it at forum.wedistribute.org, and filing issues as quirks come up. But it’s really a polished experience, and #ActivityPub federation feels really good so far.
Forums could potentially be a really good fit for the Threadiverse, I’m excited to keep exploring this.
I've been meaning to check out @botkit for awhile now. Just built a quick bot in like 15 minutes and most of that time was spent trying to figure out how deno deploy works. Anyways, check out @gulfof, if you tag it in a message it will generate a 'Gulf of' map for you using https://gulfof.mapquest.com/
ALT text detailsImage showing the Gulf of Mexico except the text is replaced with 'Gulf of gulf of'
I've been meaning to check out @botkit for awhile now. Just built a quick bot in like 15 minutes and most of that time was spent trying to figure out how deno deploy works. Anyways, check out @gulfof, if you tag it in a message it will generate a 'Gulf of' map for you using https://gulfof.mapquest.com/
ALT text detailsImage showing the Gulf of Mexico except the text is replaced with 'Gulf of gulf of'
I am sure there is a reason why those who preach hate speech seem to prefer the software platform, Pleroma, as opposed to Mastodon or Misskey, or the many forks of either. 🤔
IceShrimp.NET has a new beta release, and the front end UI is starting to catch up to the back end. Including everyone's favorite, MFM! (Well, maybe not everybody, but between instances with support, it sure is fun in moderation)
ALT text detailsA screenshot of the IceShrimp.NET interface featuring two posts from the user "admin464." The first post expresses excitement about the new beta of IceShrimp.NET, highlighting improvements in the UI and backend. The second post features a comment on IceShrimp.NET, emphasizing its quality with the word "niiiiceee." Both use the Misskey Markdown, adding color and animation to the text.
IceShrimp.NET has a new beta release, and the front end UI is starting to catch up to the back end. Including everyone's favorite, MFM! (Well, maybe not everybody, but between instances with support, it sure is fun in moderation)
ALT text detailsA screenshot of the IceShrimp.NET interface featuring two posts from the user "admin464." The first post expresses excitement about the new beta of IceShrimp.NET, highlighting improvements in the UI and backend. The second post features a comment on IceShrimp.NET, emphasizing its quality with the word "niiiiceee." Both use the Misskey Markdown, adding color and animation to the text.
IceShrimp.NET has a new beta release, and the front end UI is starting to catch up to the back end. Including everyone's favorite, MFM! (Well, maybe not everybody, but between instances with support, it sure is fun in moderation)
ALT text detailsA screenshot of the IceShrimp.NET interface featuring two posts from the user "admin464." The first post expresses excitement about the new beta of IceShrimp.NET, highlighting improvements in the UI and backend. The second post features a comment on IceShrimp.NET, emphasizing its quality with the word "niiiiceee." Both use the Misskey Markdown, adding color and animation to the text.
The #EventBridge For #ActivityPub: an add-on for the WordPress #ActivityPubPlugin "The project goal is to depict typical use cases of event organizers and emphasize their continuity in workflows on WordPress websites. Through pre-study interviews with event organizers, the #plugin is developed closely to their interests and usability and thus, allows this rather non-technical group of users to actively shape the development along their needs and interests." https://event-federation.eu/wordpress-activitypub-event-extensions/
I've been meaning to check out @botkit for awhile now. Just built a quick bot in like 15 minutes and most of that time was spent trying to figure out how deno deploy works. Anyways, check out @gulfof, if you tag it in a message it will generate a 'Gulf of' map for you using https://gulfof.mapquest.com/
ALT text detailsImage showing the Gulf of Mexico except the text is replaced with 'Gulf of gulf of'
The #EventBridge For #ActivityPub: an add-on for the WordPress #ActivityPubPlugin "The project goal is to depict typical use cases of event organizers and emphasize their continuity in workflows on WordPress websites. Through pre-study interviews with event organizers, the #plugin is developed closely to their interests and usability and thus, allows this rather non-technical group of users to actively shape the development along their needs and interests." https://event-federation.eu/wordpress-activitypub-event-extensions/
A relay may complicate the above picture slightly. But if server Y in the above example is an isolated #GlobalSouth instance, or if it is running software (such as Hubzilla) not based on #ActivityPub, then the relay will most likely not be pulling posts from there, so the example will still hold.
In this context, remember many instances do not add relays because the additional posts pulled in through the relay increase the storage and processing costs.
Just published a guide on setting up Snac on an Ubuntu VM using NGINX Proxy Manager. Snac is an incredibly lightweight #ActivityPub server. A true nom nom among fediverse platforms.
If you're curious about minimal fediverse instances, check it out:
#FediDB respecting robots.txt has really changed how stats are tabulated.
Prior to this change, there were 997 #Pleroma servers that were counted. Now the count has been reduced to 582.
With #WordPress, the difference is more stark. Prior to the change, there was over 9,000 WordPress servers counted. Now the count is at 3,578 servers.
To be sure, I’m not complaining – privacy is important. But it is to say that #ActivityPub user counts should have a big asterisk: many servers have opted out of being crawled. This means they are not being counted.
FediDB says there are 12,923,059 accounts across the #Fediverse. But this is actually drastically higher.
#FediDB respecting robots.txt has really changed how stats are tabulated.
Prior to this change, there were 997 #Pleroma servers that were counted. Now the count has been reduced to 582.
With #WordPress, the difference is more stark. Prior to the change, there was over 9,000 WordPress servers counted. Now the count is at 3,578 servers.
To be sure, I’m not complaining – privacy is important. But it is to say that #ActivityPub user counts should have a big asterisk: many servers have opted out of being crawled. This means they are not being counted.
FediDB says there are 12,923,059 accounts across the #Fediverse. But this is actually drastically higher.
ALT text detailsA threads post by BeAware.social about joining the Fediverse featuring an image that shows the comparison of corporate social media and their Fediverse counterparts. The post has 9.1k views.
Just published a guide on setting up Snac on an Ubuntu VM using NGINX Proxy Manager. Snac is an incredibly lightweight #ActivityPub server. A true nom nom among fediverse platforms.
If you're curious about minimal fediverse instances, check it out:
Just published a guide on setting up Snac on an Ubuntu VM using NGINX Proxy Manager. Snac is an incredibly lightweight #ActivityPub server. A true nom nom among fediverse platforms.
If you're curious about minimal fediverse instances, check it out:
Just published a guide on setting up Snac on an Ubuntu VM using NGINX Proxy Manager. Snac is an incredibly lightweight #ActivityPub server. A true nom nom among fediverse platforms.
If you're curious about minimal fediverse instances, check it out:
Now if you’re not familiar with Elgg, it’s one of the first ever open source social media platforms. It launched all the way back in 2004 and was founded by @ben and Dave Tosh.
I remember installing Elgg 15 years ago, playing around with it for a bit, and not doing much with it because there wasn’t anyone I knew who used it. So ActivityPub will definitely extend its network effect.
You are going to see more post that argue this is the world we live in and that this is the way things are. There is going to be a strong, but steady push against people thinking we can change things and that this is the new normal, and that you should just come to accept it.
The idea is the belittle and dismiss people who stand against Trump and his worldview.
You are going to see this on every social media platform.
You are going to see more post that argue this is the world we live in and that this is the way things are. There is going to be a strong, but steady push against people thinking we can change things and that this is the new normal, and that you should just come to accept it.
The idea is the belittle and dismiss people who stand against Trump and his worldview.
You are going to see this on every social media platform.
As it is now, I think the 'discoverable' flag is broken.
And, I think the whole user-experience (UX) around the 'discoverable' flag is poor.
And, I think Fediverse software treating a 'false' value for 'discoverable' as "not discoverable" (rather than "not discoverable" or "no choice made") has hugely negative consequences for the user-experience (UX) of the Fediverse
With other conceptions, this lack of choice — this lack of setting a value — isn't as muddled.
With optional-types (which are also called "option-types" and "maybe-types") when something isn't assigned a value it is represented as 'nothing' / 'none'.
In relation-databases, this is represented as 'null'.
Now if you’re not familiar with Elgg, it’s one of the first ever open source social media platforms. It launched all the way back in 2004 and was founded by @ben and Dave Tosh.
I remember installing Elgg 15 years ago, playing around with it for a bit, and not doing much with it because there wasn’t anyone I knew who used it. So ActivityPub will definitely extend its network effect.
Now if you’re not familiar with Elgg, it’s one of the first ever open source social media platforms. It launched all the way back in 2004 and was founded by @ben and Dave Tosh.
I remember installing Elgg 15 years ago, playing around with it for a bit, and not doing much with it because there wasn’t anyone I knew who used it. So ActivityPub will definitely extend its network effect.
As it is now, I think the 'discoverable' flag is broken.
And, I think the whole user-experience (UX) around the 'discoverable' flag is poor.
And, I think Fediverse software treating a 'false' value for 'discoverable' as "not discoverable" (rather than "not discoverable" or "no choice made") has hugely negative consequences for the user-experience (UX) of the Fediverse
With other conceptions, this lack of choice — this lack of setting a value — isn't as muddled.
With optional-types (which are also called "option-types" and "maybe-types") when something isn't assigned a value it is represented as 'nothing' / 'none'.
In relation-databases, this is represented as 'null'.
Bluesky has tried to set up the corporate structure to be sellout resistant. But these measures have yet to be tested. Backed by venture capital, it will still be pressured to make a profit quickly - and discontinuing #ATProtocol would be a quick way to make a buck.
Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.
Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.
Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.
Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.
Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.
Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.
Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.
Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.
Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.
Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.
Bluesky has tried to set up the corporate structure to be sellout resistant. But these measures have yet to be tested. Backed by venture capital, it will still be pressured to make a profit quickly - and discontinuing #ATProtocol would be a quick way to make a buck.
There we go. #Snac2 up and running with the preferred installation process. Added custom styling to boot. One confusion point with styling is that it does NOT affect the root page (greeting.html) only the profile pages. So I thought I had done something wrong, but finally figured it out.
There we go. #Snac2 up and running with the preferred installation process. Added custom styling to boot. One confusion point with styling is that it does NOT affect the root page (greeting.html) only the profile pages. So I thought I had done something wrong, but finally figured it out.
There we go. #Snac2 up and running with the preferred installation process. Added custom styling to boot. One confusion point with styling is that it does NOT affect the root page (greeting.html) only the profile pages. So I thought I had done something wrong, but finally figured it out.
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
And it's another of those issues where I optimized too early in the life of the #GoActivityPub project and it now bit me in the behind. I split the library into too many modules, which granted are pretty independent functionally, but they create a web of dependencies that is hard to navigate sometimes.
The problem was that one of the modules that I forgot I modified in order make tests pass was not pushed upstream, and all the storage backends depended on it to be fixed.
ALT text detailsScreenshot of SourceHut CI pipeline where the integration tests are passing, except for the badger one (which is too old to be used at the moment).
The title of the commit that fixed the problem is: "Updated to filters module that doesn't override the totalItems" (sic)
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
You could create view-counts on posts, profiles, etc, using this.
Of course, there are privacy concerns with this.
And, also, what counts as a "view".
Although, I sometimes use a "Like" to indicate I viewed something. If a 'View' was something manual (such a pressing a button) that could be more semantically clean.
To me, it feels like the Activity Types should have been past-tense verbs, rather than present-tense verbs.
I.e.:
• "Accepted" rather than "Accept" • "Added" rather than "Add" • "Announced" rather than "Announce" • "Arrived" rather than "Arrive" • "Blocked" rather than "Block" • "Created" rather than "Create" • etc
To me, it feels like the Activity Types should have been past-tense verbs, rather than present-tense verbs.
I.e.:
• "Accepted" rather than "Accept" • "Added" rather than "Add" • "Announced" rather than "Announce" • "Arrived" rather than "Arrive" • "Blocked" rather than "Block" • "Created" rather than "Create" • etc
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
To me, it feels like the Activity Types should have been past-tense verbs, rather than present-tense verbs.
I.e.:
• "Accepted" rather than "Accept" • "Added" rather than "Add" • "Announced" rather than "Announce" • "Arrived" rather than "Arrive" • "Blocked" rather than "Block" • "Created" rather than "Create" • etc
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
🥳 Manyfold v0.101.0 is out, with a really fun new feature: Themes! There are 26 UI colour schemes to choose from, thanks to Bootswatch, so now you can make your instance a bit more your own.
We've also got a big bugfix for 3MF file display, particularly for files that use the production extension (e.g. slicer project files).
🥳 Manyfold v0.101.0 is out, with a really fun new feature: Themes! There are 26 UI colour schemes to choose from, thanks to Bootswatch, so now you can make your instance a bit more your own.
We've also got a big bugfix for 3MF file display, particularly for files that use the production extension (e.g. slicer project files).
🥳 Manyfold v0.101.0 is out, with a really fun new feature: Themes! There are 26 UI colour schemes to choose from, thanks to Bootswatch, so now you can make your instance a bit more your own.
We've also got a big bugfix for 3MF file display, particularly for files that use the production extension (e.g. slicer project files).
I need a Fediverse explanation that’s so simple anyone can relate to what I’m talking about. Can someone give me an analogy that’s relatable? I’ve tried everything #Fediverse#activitypub#discussion
I need a Fediverse explanation that’s so simple anyone can relate to what I’m talking about. Can someone give me an analogy that’s relatable? I’ve tried everything #Fediverse#activitypub#discussion
Context; I am writing a post about Mastodon and Bluesky and wouldn’t like to be imprecise.
I read in a blog that ActivityPub actually allows moving data of users and content from one server to another and that it is the Mastodon development of ActivityPub which puts the problem of portability.
ALT text detailsScreenshot of sourcehut build pipeline for FedBOX with multiple integration tests suites, one for each storage backend.
Their status is: storage-fs: passed, storage-boltdb: failed, storage-sqlite: failed, storage-badger: failed
Context; I am writing a post about Mastodon and Bluesky and wouldn’t like to be imprecise.
I read in a blog that ActivityPub actually allows moving data of users and content from one server to another and that it is the Mastodon development of ActivityPub which puts the problem of portability.
Context; I am writing a post about Mastodon and Bluesky and wouldn’t like to be imprecise.
I read in a blog that ActivityPub actually allows moving data of users and content from one server to another and that it is the Mastodon development of ActivityPub which puts the problem of portability.
The real magic of the #fediverse is collaboration.
Many of the largest projects have worked together behind the scenes on compatibility.
It's not that common now that ActivityPub has matured, but you better believe the early days of 2018 had big players like Mastodon and Pleroma working closely on compat.
#ActivityPub = Community + Collaboration The magic formula that sets us apart!
@BeAware Perhaps discoverability. Since #ActivityPub is not a single image of all posts, we need a better way to find posts we're interested in. Also, there should be less friction in engaging with another server; currently, you need to switch to that instance before you can interact with a post.
@BeAware Perhaps discoverability. Since #ActivityPub is not a single image of all posts, we need a better way to find posts we're interested in. Also, there should be less friction in engaging with another server; currently, you need to switch to that instance before you can interact with a post.
Discovering the #fediverse gives me the same feelings #linux did years ago. The endless choice, excitement of discovery, clash of philosophies and a community.
I spent years #distrohopping from #ubuntu , #arch , #voidlinux , #nixos etc and then back to arch. Also spent a long time switching desktop environments and window managers like i3.
🥳 🎂 Manyfold v0.100.0 is out, and enables federation of public creators, objects, and collections between instances! Now you can follow any public item from a different Manyfold instance, then search, tag, organise, and get all the updates straight into your activity feed! It's a huge step towards building a decentralised Thingiverse! 😁
🥳 🎂 Manyfold v0.100.0 is out, and enables federation of public creators, objects, and collections between instances! Now you can follow any public item from a different Manyfold instance, then search, tag, organise, and get all the updates straight into your activity feed! It's a huge step towards building a decentralised Thingiverse! 😁
No. Fuck this. I literally left #Tumblr a few month ago because they have a serious infestation of #CP and child #SA. If you’re an admin, I’d suggest blocking Tumblr. The #Fediverse will have to deal with more and more of this as it becomes increasingly popular. #ActivityPub support or not, we do NOT want an invasion of #CorporateCorruption.
🥳 🎂 Manyfold v0.100.0 is out, and enables federation of public creators, objects, and collections between instances! Now you can follow any public item from a different Manyfold instance, then search, tag, organise, and get all the updates straight into your activity feed! It's a huge step towards building a decentralised Thingiverse! 😁
🥳 🎂 Manyfold v0.100.0 is out, and enables federation of public creators, objects, and collections between instances! Now you can follow any public item from a different Manyfold instance, then search, tag, organise, and get all the updates straight into your activity feed! It's a huge step towards building a decentralised Thingiverse! 😁
🥳 🎂 Manyfold v0.100.0 is out, and enables federation of public creators, objects, and collections between instances! Now you can follow any public item from a different Manyfold instance, then search, tag, organise, and get all the updates straight into your activity feed! It's a huge step towards building a decentralised Thingiverse! 😁
Not only would this serve to pass institutional knowledge to devs who are new to #ActivityPub, but it would also serve as a means to protect them from harassment—especially since it’s so easy to break the “unwritten rules”.
And while this might be something outside the mandate of the Social Web Foundation, maybe it’s something @evan may want to consider.
Because something I see over and over again is:
New devs gets excited about ActivityPub
They build a new project
They get harassed and bullied for daring to build something
Hell, this isn’t even a problem for new devs. Old devs get caught in the crosshairs if their project reaches a certain level of popularity. And I’m not saying devs are always angels, but there should at least be some kind of organizational structure that assumes good will.
Not only would this serve to pass institutional knowledge to devs who are new to #ActivityPub, but it would also serve as a means to protect them from harassment—especially since it’s so easy to break the “unwritten rules”.
And while this might be something outside the mandate of the Social Web Foundation, maybe it’s something @evan may want to consider.
Because something I see over and over again is:
New devs gets excited about ActivityPub
They build a new project
They get harassed and bullied for daring to build something
Hell, this isn’t even a problem for new devs. Old devs get caught in the crosshairs if their project reaches a certain level of popularity. And I’m not saying devs are always angels, but there should at least be some kind of organizational structure that assumes good will.
Tumblr is going to join the fediverse! (Aka mastodon, Pixlr, PeerTube Etc.)
Automattic confirmed to TechCrunch that when the migration is complete, every Tumblr user will be able to federate their blog via ActivityPub, just as every WordPress.com user can today.
Tumblr is going to join the fediverse! (Aka mastodon, Pixlr, PeerTube Etc.)
Automattic confirmed to TechCrunch that when the migration is complete, every Tumblr user will be able to federate their blog via ActivityPub, just as every WordPress.com user can today.
And because it’s migrating to WordPress, it will be using #ActivityPub for WordPress to do this.
What’s interesting is that people are already demanding #ATProto so Tumblr will connect to #Bluesky. But from a business perspective, that’s a bad idea unless Automattic plans to run its on firehose—which can be quite expensive.
"While none of the newcomers is anywhere near ready to rival Meta’s size and scope, their ability to even carve out a small niche within Meta’s shadow is compelling." #fediverse#activitypub#pixelfed
"While none of the newcomers is anywhere near ready to rival Meta’s size and scope, their ability to even carve out a small niche within Meta’s shadow is compelling." #fediverse#activitypub#pixelfed
A milestone worth celebrating—#Fedify just hit 100+ releases! From day one, we've been committed to building a robust #ActivityPub framework, and each release has brought us closer to that goal. Here's to many more releases as we continue growing the #fediverse together! #fedidev
ALT text detailsScreenshot shows release stats for Fedify: latest version 1.4.1 was released 6 minutes ago, with a green tag showing “Latest.” Total release count shows “+ 100 releases.” A green icon resembling a tag appears next to the Fedify name.
A milestone worth celebrating—#Fedify just hit 100+ releases! From day one, we've been committed to building a robust #ActivityPub framework, and each release has brought us closer to that goal. Here's to many more releases as we continue growing the #fediverse together! #fedidev
ALT text detailsScreenshot shows release stats for Fedify: latest version 1.4.1 was released 6 minutes ago, with a green tag showing “Latest.” Total release count shows “+ 100 releases.” A green icon resembling a tag appears next to the Fedify name.
This security update fixes a message visibility bug where direct/followers-only replies to bots were unintentionally forwarded to bot followers. Upgrade recommended. Download at JSR:
A milestone worth celebrating—#Fedify just hit 100+ releases! From day one, we've been committed to building a robust #ActivityPub framework, and each release has brought us closer to that goal. Here's to many more releases as we continue growing the #fediverse together! #fedidev
ALT text detailsScreenshot shows release stats for Fedify: latest version 1.4.1 was released 6 minutes ago, with a green tag showing “Latest.” Total release count shows “+ 100 releases.” A green icon resembling a tag appears next to the Fedify name.
Just had a live pair-debugging session with @naturzukunft, where we sent #ActivityPub messages to each others dev servers and live debugged them. Highly recommended when working with this stuff, and if anyone else wants to do the same, hit me up!
Just had a live pair-debugging session with @naturzukunft, where we sent #ActivityPub messages to each others dev servers and live debugged them. Highly recommended when working with this stuff, and if anyone else wants to do the same, hit me up!
This security update fixes a message visibility bug where direct/followers-only replies to bots were unintentionally forwarded to bot followers. Upgrade recommended. Download at JSR:
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
A milestone worth celebrating—#Fedify just hit 100+ releases! From day one, we've been committed to building a robust #ActivityPub framework, and each release has brought us closer to that goal. Here's to many more releases as we continue growing the #fediverse together! #fedidev
ALT text detailsScreenshot shows release stats for Fedify: latest version 1.4.1 was released 6 minutes ago, with a green tag showing “Latest.” Total release count shows “+ 100 releases.” A green icon resembling a tag appears next to the Fedify name.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
A milestone worth celebrating—#Fedify just hit 100+ releases! From day one, we've been committed to building a robust #ActivityPub framework, and each release has brought us closer to that goal. Here's to many more releases as we continue growing the #fediverse together! #fedidev
ALT text detailsScreenshot shows release stats for Fedify: latest version 1.4.1 was released 6 minutes ago, with a green tag showing “Latest.” Total release count shows “+ 100 releases.” A green icon resembling a tag appears next to the Fedify name.
A milestone worth celebrating—#Fedify just hit 100+ releases! From day one, we've been committed to building a robust #ActivityPub framework, and each release has brought us closer to that goal. Here's to many more releases as we continue growing the #fediverse together! #fedidev
ALT text detailsScreenshot shows release stats for Fedify: latest version 1.4.1 was released 6 minutes ago, with a green tag showing “Latest.” Total release count shows “+ 100 releases.” A green icon resembling a tag appears next to the Fedify name.
This security update fixes a message visibility bug where direct/followers-only replies to bots were unintentionally forwarded to bot followers. Upgrade recommended. Download at JSR:
We're considering adding custom background task support to #Fedify 1.5.0.
Want to use Fedify's worker system for your own background tasks? We're exploring ways to let you register and process custom tasks alongside #ActivityPub jobs.
This security update fixes a message visibility bug where direct/followers-only replies to bots were unintentionally forwarded to bot followers. Upgrade recommended. Download at JSR:
This security update fixes a message visibility bug where direct/followers-only replies to bots were unintentionally forwarded to bot followers. Upgrade recommended. Download at JSR:
I'm starting to get the feeling that the Fedi Mafia doesn't REALLY care about anything on Fedi, they're just bored as hell all the time and want to stir up some drama to giggle at.
I don't see harassing developers as something to giggle at, but with their consistent absolute ignorance of the platform and unwillingness to see how harassment is hurting the platform, I can't help but think they're just really bored assholes.
If it's useful to Fedi, they harass and threaten the developer so that others will talk about them. Because any attention is good attention to these assholes.
If it's not useful, they just ignore it and the project doesn't go anywhere cause it's not useful.🤦♂️
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.
We're considering adding custom background task support to #Fedify 1.5.0.
Want to use Fedify's worker system for your own background tasks? We're exploring ways to let you register and process custom tasks alongside #ActivityPub jobs.
We're considering adding custom background task support to #Fedify 1.5.0.
Want to use Fedify's worker system for your own background tasks? We're exploring ways to let you register and process custom tasks alongside #ActivityPub jobs.
Because I'm an optimist, I submitted a few talks to FOSDEM in the hope one might be accepted. Because I'm lucky, I got two speaking slots. Because I'm an idiot, I decided to do both talks. On the same day. An hour apart. On opposite ends of the venue.
Fool!
My first talk was at the Social Web Birds-of-a-Feather session.…
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.
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.
Because I'm an optimist, I submitted a few talks to FOSDEM in the hope one might be accepted. Because I'm lucky, I got two speaking slots. Because I'm an idiot, I decided to do both talks. On the same day. An hour apart. On opposite ends of the venue.
Fool!
My first talk was at the Social Web Birds-of-a-Feather session.…
We're considering adding custom background task support to #Fedify 1.5.0.
Want to use Fedify's worker system for your own background tasks? We're exploring ways to let you register and process custom tasks alongside #ActivityPub jobs.
We're considering adding custom background task support to #Fedify 1.5.0.
Want to use Fedify's worker system for your own background tasks? We're exploring ways to let you register and process custom tasks alongside #ActivityPub jobs.
We're considering adding custom background task support to #Fedify 1.5.0.
Want to use Fedify's worker system for your own background tasks? We're exploring ways to let you register and process custom tasks alongside #ActivityPub jobs.
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.
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.
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.
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.
Problem: Remote profiles sometimes look empty on Mastodon because only the stickied posts are synchronized on profile update.
Observation: Neither the ActivityPub nor Mastodon specs limit the number of sticky posts on a profile. Nothing says you can't have 100 000 sticky posts.
Solution: an ActivityPub server implementation that auto-stickies every single post you write.
The things I come up with thinking about @fedify while in the shower.
Problem: Remote profiles sometimes look empty on Mastodon because only the stickied posts are synchronized on profile update.
Observation: Neither the ActivityPub nor Mastodon specs limit the number of sticky posts on a profile. Nothing says you can't have 100 000 sticky posts.
Solution: an ActivityPub server implementation that auto-stickies every single post you write.
The things I come up with thinking about @fedify while in the shower.
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.
Problem: Remote profiles sometimes look empty on Mastodon because only the stickied posts are synchronized on profile update.
Observation: Neither the ActivityPub nor Mastodon specs limit the number of sticky posts on a profile. Nothing says you can't have 100 000 sticky posts.
Solution: an ActivityPub server implementation that auto-stickies every single post you write.
The things I come up with thinking about @fedify while in the shower.
Problem: Remote profiles sometimes look empty on Mastodon because only the stickied posts are synchronized on profile update.
Observation: Neither the ActivityPub nor Mastodon specs limit the number of sticky posts on a profile. Nothing says you can't have 100 000 sticky posts.
Solution: an ActivityPub server implementation that auto-stickies every single post you write.
The things I come up with thinking about @fedify while in the shower.
The Verifiable Credentials Working Group invites implementations of the following Candidate Recommendation Snapshot: Controlled Identifiers (CIDs) v1.0.
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.
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.
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.
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.
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.
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.
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.
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.
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
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.
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.
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.
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.
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
Here goes useful info for those interested in following, or applying for this initiative. The public call involves hiring two professionals, for web communication and web technology. Candidates have until Feb 10 to apply. Our goal is to provide #museums and other #memoryinstitutions with an open tool that facilitates the exploration of decentralized social networks — #TheFediverse.
Here goes useful info for those interested in following, or applying for this initiative. The public call involves hiring two professionals, for web communication and web technology. Candidates have until Feb 10 to apply. Our goal is to provide #museums and other #memoryinstitutions with an open tool that facilitates the exploration of decentralized social networks — #TheFediverse.
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
🎉 Announcing BotKit 0.1.0: A new framework for creating ActivityPub bots!
We're thrilled to announce the initial release of #BotKit, a #TypeScript framework that makes creating standalone #ActivityPub bots simpler than ever before. With BotKit, you can create a complete fediverse bot in just a single TypeScript file!
Key features:
🔋 Standalone bot creation—no need for a Mastodon/Misskey account
If you plan on building discovery features for Fedi, BeAware of the "Fedi Mafia" that harasses, threatens, and abuses any dev on Fedi that DARES to make an open platform a little bit more usable.🤦♂️
Over the past 2 months, I've seen 4 Fedi projects that were building tools to help people find accounts and servers to make it easier to find content on Fedi, get shut down because people who don't understand that Fedi is OPEN, harassed and threatened the devs until they shut their projects down.🤬
So, if you plan on building these tools, PLEASE just be prepared to block and continue building your tools.
Ignorant people should not dictate how this protocol is built. Don't let the abusers win.
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
Ever wondered how @Mastodon, Pixelfed, and PeerTube connect seamlessly? It’s all thanks to ActivityPub! 🌍
In this article, @linuxnerd breaks down how this open-source protocol powers the Fediverse and gives users control over their social media. Read more! 👇
ALT text detailsLeft side says We Love Open Source. #WeLoveOpenSource. ATO. A community education resource from All Things Open. Right side has nodes in a network connected by lines.
Ever wondered how @Mastodon, Pixelfed, and PeerTube connect seamlessly? It’s all thanks to ActivityPub! 🌍
In this article, @linuxnerd breaks down how this open-source protocol powers the Fediverse and gives users control over their social media. Read more! 👇
ALT text detailsLeft side says We Love Open Source. #WeLoveOpenSource. ATO. A community education resource from All Things Open. Right side has nodes in a network connected by lines.
Ever wondered how @Mastodon, Pixelfed, and PeerTube connect seamlessly? It’s all thanks to ActivityPub! 🌍
In this article, @linuxnerd breaks down how this open-source protocol powers the Fediverse and gives users control over their social media. Read more! 👇
ALT text detailsLeft side says We Love Open Source. #WeLoveOpenSource. ATO. A community education resource from All Things Open. Right side has nodes in a network connected by lines.
The #Fediverse is free, free of censorship, federated and full of great content!
Also the Fediverse - instance admins randomly blocking whole instances just because a single user feels offended of a post by a single instance user. Blocking whole instances is just a finger snip away, censoring unwanted content and parenting users of instances. Defederating just because of… ok no clue :) Using content warner for any possible content just to annoy or aeemmm make it more interesting to other users. Thanks, I’m old enough :) Seeing all the spam because it’s just a thing of 5 minutes automation to create randomly new instances on different domains (or subdomains from dynamic-ip hosters) and to fill the network with automated content.
Sometimes, pros can easily switch into cons… luckily more and more single user instances are raising up for exactly this reasons and can still easily federate by using relays…
The #Fediverse is free, free of censorship, federated and full of great content!
Also the Fediverse - instance admins randomly blocking whole instances just because a single user feels offended of a post by a single instance user. Blocking whole instances is just a finger snip away, censoring unwanted content and parenting users of instances. Defederating just because of… ok no clue :) Using content warner for any possible content just to annoy or aeemmm make it more interesting to other users. Thanks, I’m old enough :) Seeing all the spam because it’s just a thing of 5 minutes automation to create randomly new instances on different domains (or subdomains from dynamic-ip hosters) and to fill the network with automated content.
Sometimes, pros can easily switch into cons… luckily more and more single user instances are raising up for exactly this reasons and can still easily federate by using relays…
At least 15,000 people fully, without limits, irrevocably, licensed their personal information, public image, name and all data that reached loops.video infrastructure... to @dansup@mastodon.social 's loops.video platform.
Had they known they're entirely losing control of everything, would they be using the platform?
In short: if you really intend to federate, respect your users and their data.
Implementing federation while keeping these terms is a severe breach of trust, and would poison the entirety of the network in an way which will cripple ActivityPub, and undermine the very foundation of what AP stands for with regard to privacy, data ownership, and control over what we post to the network.
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
The Verifiable Credentials Working Group invites implementations of the following Candidate Recommendation Snapshot: Controlled Identifiers (CIDs) v1.0.
The Verifiable Credentials Working Group invites implementations of the following Candidate Recommendation Snapshot: Controlled Identifiers (CIDs) v1.0.
It wasn’t so long ago that #Mastodon made up 90% of MAUs on the #Fediverse. Hell, it so dominated Fediverse usage that, for most people, Mastodon was the Fediverse.
But now Mastodon’s percentage of MAUs stands at 58%. And it’s probably lower because the second most popular Fediverse software distribution, #Misskey, doesn’t accurately report MAUs. So what happened?
I suspect four things:
Mastodon validated the concept of a Fediverse, which prompted more devs to build for #ActivityPub
As Big Social alienated their userbase, some of this userbase sought Fediverse alternatives. This is what drove popularity of #Lemmy and #Pixelfed.
#Bluesky became the default alternative to #Twitter instead of Mastodon
As Mastodon users became aware of a greater Fediverse, many migrated to other Fediverse software
Obviously, Mastodon is alive and kicking. It’s not going anywhere. Its continuing development is critical to the success of the Fediverse.
But at the same time, the success of Mastodon led to the success of other federated projects. And it works the other way around too. The success of other federated projects is also Mastodon’s success.
So really, lower MAUs for Mastodon is actually a giant win for the big pachyderm.
I sure do wish I could search the wider Fediverse without having a mastodon.social account...
Oh wait, @rolle made this exact thing and got harassed, threatened, and insulted by the ignorant Fedi mafia who thinks that Fedi is "private" for some dumb reason.
If you want privacy, go to signal.
I want a USABLE social media platform that isn't owned by a corporate asshole.
Fedi is barely usable without discoverability and ignorance is killing it.
Educate yourself. ActivityPub is an OPEN protocol.
Stop harassing people that are building on that openness. You're killing Fedi.🤬
I sure do wish I could search the wider Fediverse without having a mastodon.social account...
Oh wait, @rolle made this exact thing and got harassed, threatened, and insulted by the ignorant Fedi mafia who thinks that Fedi is "private" for some dumb reason.
If you want privacy, go to signal.
I want a USABLE social media platform that isn't owned by a corporate asshole.
Fedi is barely usable without discoverability and ignorance is killing it.
Educate yourself. ActivityPub is an OPEN protocol.
Stop harassing people that are building on that openness. You're killing Fedi.🤬
I sure do wish I could search the wider Fediverse without having a mastodon.social account...
Oh wait, @rolle made this exact thing and got harassed, threatened, and insulted by the ignorant Fedi mafia who thinks that Fedi is "private" for some dumb reason.
If you want privacy, go to signal.
I want a USABLE social media platform that isn't owned by a corporate asshole.
Fedi is barely usable without discoverability and ignorance is killing it.
Educate yourself. ActivityPub is an OPEN protocol.
Stop harassing people that are building on that openness. You're killing Fedi.🤬
Very happy to announce that @tomcoates and I have been given a #SummerOfProtocols grant to develop an end-to-end encryption (E2EE) protocol for #ActivityPub DMs, including a reference implementation and a report to submit to the W3C SocialCG.
And it’s a wrap for my first (EPIC) day at #FOSDEM.
It’s hard to put into words how incredible - and energizing - it feels to be around the creators of the #ActivityPub protocol, founders of #Fediverse software, admins of popular instances and developers of tools I use every day.
I took the opportunity to thank them in person for their incredible work 😊
It’s also been amazing to finally meet IRL lots of cool people I had been corresponding with for months on the Fediverse.
The best day 💛
ALT text detailsA photo of a large group of people (basically, Fediverse and ActivityPub royalty) standing in front of a slide from John O’Nolan talk about Ghost that shows their “ActivityPug” (an AI-generated pug in a space suit) with the word The Fediverse under it
I've seen multiple call outs from our fediverse leadership for monetary contributions. If there ever was a time, it is NOW to show your support at all levels.
Your local instance administrators need money to keep it running. Your favorite app developers need money to fund their work. Platforms themselves need funding.
And, reach out to the people that keep your feeds running and say thank you.
I've seen multiple call outs from our fediverse leadership for monetary contributions. If there ever was a time, it is NOW to show your support at all levels.
Your local instance administrators need money to keep it running. Your favorite app developers need money to fund their work. Platforms themselves need funding.
And, reach out to the people that keep your feeds running and say thank you.
I've seen multiple call outs from our fediverse leadership for monetary contributions. If there ever was a time, it is NOW to show your support at all levels.
Your local instance administrators need money to keep it running. Your favorite app developers need money to fund their work. Platforms themselves need funding.
And, reach out to the people that keep your feeds running and say thank you.
I've seen multiple call outs from our fediverse leadership for monetary contributions. If there ever was a time, it is NOW to show your support at all levels.
Your local instance administrators need money to keep it running. Your favorite app developers need money to fund their work. Platforms themselves need funding.
And, reach out to the people that keep your feeds running and say thank you.
ALT text detailsA meme that features a two-panel comparison with the same character, Geordi La Forge from Star Trek, expressing contrasting reactions. In the first panel, he raises his hand, appearing to reject or dismiss the Bluesky logo, a blue butterfly symbol. In the second panel, he approvingly gestures towards the colorful Fediverse logo, which represents interconnected decentralized platforms. The meme humorously portrays a preference for decentralized systems (the Fediverse) over proprietary, centralized platforms like Bluesky.
(Anarchist / Socialist vibes, founded in Berkeley, CA)
...if I can find the time.
⫘⫘⫘⫘⫘⫘⫘⫘⫘⫘⫘⫘
❓ My question for YOU: What are the specific weaknesses / shortcomings of Mastodon's approach to moderation, specifically as it relates to shitty speech directed at fem, trans, black, and other marginalized communities.
⭐ I'm not explicitly asking for additional labor from e.g. #blackMastodon (though it's welcome if you care to share)
⭐ I'm seeking previously-posted perspectives from individuals from marginalized communities who have been negatively impacted by the way that moderation is structured in #ActivityPub
Part of my rough current understanding of (one of) the issues:
If person A posts post 1, and person B comments [a shitty] reply 2, reply 2 remains visible and attached to post 1, unless there are instance-level blocking actions taken. Do I have that right?
(Anarchist / Socialist vibes, founded in Berkeley, CA)
...if I can find the time.
⫘⫘⫘⫘⫘⫘⫘⫘⫘⫘⫘⫘
❓ My question for YOU: What are the specific weaknesses / shortcomings of Mastodon's approach to moderation, specifically as it relates to shitty speech directed at fem, trans, black, and other marginalized communities.
⭐ I'm not explicitly asking for additional labor from e.g. #blackMastodon (though it's welcome if you care to share)
⭐ I'm seeking previously-posted perspectives from individuals from marginalized communities who have been negatively impacted by the way that moderation is structured in #ActivityPub
Part of my rough current understanding of (one of) the issues:
If person A posts post 1, and person B comments [a shitty] reply 2, reply 2 remains visible and attached to post 1, unless there are instance-level blocking actions taken. Do I have that right?
Many people here on the Fediverse learned that when a bunch of Fedi sites which has drawings or photos of women kissing women, or men kissing men, were taken offline.
I try to recommend providers who are open to generally any content, provided it is legal, of course. I am not going to recommend people looking to escape possible censorship or safety concerns, only to further feel unsafe and possibly censored.
First thing this morning at Social Web #BOF we have @Edent presenting their single file php #ActivityPub project that is entirely contained in one slide!
ALT text detailsA person stands in front of a projection screen filled with php
The Ghost approach to #ActivityPub looks great. They get it. Real engagement and ongoing conversations not just broadcasting. I had a similar experience when Mastodon replies started showing up as comments in WordPress, but Ghost is really building this into the core with the reader view as well. “You can’t be on the social web without being social.” #FOSDEM#SocialWebFOSDEM
First thing this morning at Social Web #BOF we have @Edent presenting their single file php #ActivityPub project that is entirely contained in one slide!
ALT text detailsA person stands in front of a projection screen filled with php
First thing this morning at Social Web #BOF we have @Edent presenting their single file php #ActivityPub project that is entirely contained in one slide!
ALT text detailsA person stands in front of a projection screen filled with php
The Ghost approach to #ActivityPub looks great. They get it. Real engagement and ongoing conversations not just broadcasting. I had a similar experience when Mastodon replies started showing up as comments in WordPress, but Ghost is really building this into the core with the reader view as well. “You can’t be on the social web without being social.” #FOSDEM#SocialWebFOSDEM
At #fosdem John O’Nolan, CEO of @index announced the public beta of Ghost 6.0 to be launched in march 2025, to add #activitypub federation features to the successful Ghost software, released with MIT license and already adopted successfully by several news organisations. With federation enabled, Ghost will allow the creation of content curation platforms and federated independent news sources aggregating content from the #fediverse,
At #fosdem John O’Nolan, CEO of @index announced the public beta of Ghost 6.0 to be launched in march 2025, to add #activitypub federation features to the successful Ghost software, released with MIT license and already adopted successfully by several news organisations. With federation enabled, Ghost will allow the creation of content curation platforms and federated independent news sources aggregating content from the #fediverse,
This is probably a dumb question but is it possible/advisable for more people to host their own content? Seems like instead of having giant servers where everyone’s stuff is stored we could all just host our own files and people connect to them? Grateful for any insight into the downsides of doing something like that (aside from having to learn how to run a server) #fediverse nub here #activitypub#pixelfed#loops#mastodon
I'm off to #FOSDEM2025 at the end of this week to join the #SocialWeb devroom, and talk about @manyfold on Saturday afternoon!
Looking forward to talking to folks about #ActivityPub federation, #3dPrinting, #WebGL... pretty much anything TBH! And looking forward to a trip on the Eurostar, too 🚅
I'm off to #FOSDEM2025 at the end of this week to join the #SocialWeb devroom, and talk about @manyfold on Saturday afternoon!
Looking forward to talking to folks about #ActivityPub federation, #3dPrinting, #WebGL... pretty much anything TBH! And looking forward to a trip on the Eurostar, too 🚅
A few facts and thoughts about #BlueSky being decentralized or not:
#ATProto (the protocol behind bluesky) is decentralized and open-source, but is controlled by a for-profit (albeit fiscally a public benefit) organization, "Bluesky Social PBC".
"Bluesky" refers to a sum of ATProto concepts, notably the AppView (bsky.app), the main Personal Data Servers (PDS, bsky.social), and the Relays (or firehose, bsky.network). There are others, but they're the 3 important ones.
Anyone can run their own AppView, PDS or Relay AND consume the content from/get their content consumed by the Bluesky infrastructure. HOWEVER, not everything is trivial or cheap to run.
3.0 A PDS, which contains your data (account details but also posts, likes, follows, etc), is trivial and cheap to self-host. Cheaper than hosting a mastodon instance, even, because it does way less stuff and receives way less requests. See https://github.com/bluesky-social/pds
3.1 An AppView (the presentation layer, where users interact with ATProto content) can be created by anyone, but the bsky.app backend is NOT open-source, so there are not a ton of options right now. EDIT: seems like I was wrong and that the bsky.app AppView is open-source: https://github.com/bluesky-social/atproto/tree/main/packages/bsky
3.2 Running a relay is trivial but expensive to self-host. This is because its purpose is to act as an aggregator for all the PDS so that AppViews can consume the data in a way that scales better. The Bluesky relay implementation (bigsky) is open-source: https://github.com/bluesky-social/indigo/blob/main/cmd/bigsky/README.md About 2.5 months ago, 4.5TB of storage was needed and an OVH server costing 150$/month worked to host a full-atmosphere relay (more on that later).
4.0 To make a comparison with #ActivityPub (the protocol behind #mastodon ), the AppView and PDS is the same thing in ActivityPub, and the concept of relay doesn't exist. There are advantages and drawbacks to both architectures, I might do a future post highlighting those.
5.0 With those definitions out of the way, some observations:
5.1 A lot of users self-host their PDS, but the vast majority of users chose the simpler option.
5.2 There are some alternative AppViews built on ATProto, but the vast majority of users visit bsky.app.
5.3 There are very little non-bluesky self-hosting of relays, mostly because of their prohibitive cost. Running the bigsky relay is expensive partly because of design decisions for ATProto and partly because it takes ALL content from ALL accounts for ALL the network on the atmosphere (in this case atmosphere == fediverse but for ATProto). This is like if your Mastodon instance queried ALL servers for ALL accounts querying ALL posts. In the future, there might exist relays that don't scrape ALL data but only a subset of it, which would bring down costs, but it's not yet the case.
6.0 So "is Bluesky decentralized?"
6.1 In theory, yes, everything that bluesky does on ATProto can be.
6.2 In practice, however, the most decentralized part of Bluesky is the PDS, where the user data is stored, and even that is not that decentralized.
6.3 Will it stay this way? I'm hopeful it won't, but I don't know. ATProto is fairly new compared to ActivityPub, and the ecosystem around it was mostly built by the BlueSky company, but I expect this to change in the future. However, the cost of entry for things built on ATProto will always be more than the cost of entry for things built on ActivityPub.
6.4 Things built on ActivityPub will always be more decentralized than things built on ATProto, because of design decisions from both of these protocols.
A few facts and thoughts about #BlueSky being decentralized or not:
#ATProto (the protocol behind bluesky) is decentralized and open-source, but is controlled by a for-profit (albeit fiscally a public benefit) organization, "Bluesky Social PBC".
"Bluesky" refers to a sum of ATProto concepts, notably the AppView (bsky.app), the main Personal Data Servers (PDS, bsky.social), and the Relays (or firehose, bsky.network). There are others, but they're the 3 important ones.
Anyone can run their own AppView, PDS or Relay AND consume the content from/get their content consumed by the Bluesky infrastructure. HOWEVER, not everything is trivial or cheap to run.
3.0 A PDS, which contains your data (account details but also posts, likes, follows, etc), is trivial and cheap to self-host. Cheaper than hosting a mastodon instance, even, because it does way less stuff and receives way less requests. See https://github.com/bluesky-social/pds
3.1 An AppView (the presentation layer, where users interact with ATProto content) can be created by anyone, but the bsky.app backend is NOT open-source, so there are not a ton of options right now. EDIT: seems like I was wrong and that the bsky.app AppView is open-source: https://github.com/bluesky-social/atproto/tree/main/packages/bsky
3.2 Running a relay is trivial but expensive to self-host. This is because its purpose is to act as an aggregator for all the PDS so that AppViews can consume the data in a way that scales better. The Bluesky relay implementation (bigsky) is open-source: https://github.com/bluesky-social/indigo/blob/main/cmd/bigsky/README.md About 2.5 months ago, 4.5TB of storage was needed and an OVH server costing 150$/month worked to host a full-atmosphere relay (more on that later).
4.0 To make a comparison with #ActivityPub (the protocol behind #mastodon ), the AppView and PDS is the same thing in ActivityPub, and the concept of relay doesn't exist. There are advantages and drawbacks to both architectures, I might do a future post highlighting those.
5.0 With those definitions out of the way, some observations:
5.1 A lot of users self-host their PDS, but the vast majority of users chose the simpler option.
5.2 There are some alternative AppViews built on ATProto, but the vast majority of users visit bsky.app.
5.3 There are very little non-bluesky self-hosting of relays, mostly because of their prohibitive cost. Running the bigsky relay is expensive partly because of design decisions for ATProto and partly because it takes ALL content from ALL accounts for ALL the network on the atmosphere (in this case atmosphere == fediverse but for ATProto). This is like if your Mastodon instance queried ALL servers for ALL accounts querying ALL posts. In the future, there might exist relays that don't scrape ALL data but only a subset of it, which would bring down costs, but it's not yet the case.
6.0 So "is Bluesky decentralized?"
6.1 In theory, yes, everything that bluesky does on ATProto can be.
6.2 In practice, however, the most decentralized part of Bluesky is the PDS, where the user data is stored, and even that is not that decentralized.
6.3 Will it stay this way? I'm hopeful it won't, but I don't know. ATProto is fairly new compared to ActivityPub, and the ecosystem around it was mostly built by the BlueSky company, but I expect this to change in the future. However, the cost of entry for things built on ATProto will always be more than the cost of entry for things built on ActivityPub.
6.4 Things built on ActivityPub will always be more decentralized than things built on ATProto, because of design decisions from both of these protocols.
Pretty clear from the #FOSDEM#SocialWeb devroom talks that the limited set of #ActivityPub actors that Mastodon will accept is a problem for almost every other platform.
And it’s a wrap for my first (EPIC) day at #FOSDEM.
It’s hard to put into words how incredible - and energizing - it feels to be around the creators of the #ActivityPub protocol, founders of #Fediverse software, admins of popular instances and developers of tools I use every day.
I took the opportunity to thank them in person for their incredible work 😊
It’s also been amazing to finally meet IRL lots of cool people I had been corresponding with for months on the Fediverse.
The best day 💛
ALT text detailsA photo of a large group of people (basically, Fediverse and ActivityPub royalty) standing in front of a slide from John O’Nolan talk about Ghost that shows their “ActivityPug” (an AI-generated pug in a space suit) with the word The Fediverse under it
@sirjofri@mastodon.sdf.org
I know #activitypub is very powerful and most servers only "use" a subset of its features. I'm wondering, is there a #fediverse activitypub server software that tries to use _every_ feature? It doesn't have to look great and deliver a good experience, I'm just curious.
To be more precise, I'm not asking for a library or framework, but a full running server that you can install.
The Ghost approach to #ActivityPub looks great. They get it. Real engagement and ongoing conversations not just broadcasting. I had a similar experience when Mastodon replies started showing up as comments in WordPress, but Ghost is really building this into the core with the reader view as well. “You can’t be on the social web without being social.” #FOSDEM#SocialWebFOSDEM
At #fosdem John O’Nolan, CEO of @index announced the public beta of Ghost 6.0 to be launched in march 2025, to add #activitypub federation features to the successful Ghost software, released with MIT license and already adopted successfully by several news organisations. With federation enabled, Ghost will allow the creation of content curation platforms and federated independent news sources aggregating content from the #fediverse,
The Ghost approach to #ActivityPub looks great. They get it. Real engagement and ongoing conversations not just broadcasting. I had a similar experience when Mastodon replies started showing up as comments in WordPress, but Ghost is really building this into the core with the reader view as well. “You can’t be on the social web without being social.” #FOSDEM#SocialWebFOSDEM
The Ghost approach to #ActivityPub looks great. They get it. Real engagement and ongoing conversations not just broadcasting. I had a similar experience when Mastodon replies started showing up as comments in WordPress, but Ghost is really building this into the core with the reader view as well. “You can’t be on the social web without being social.” #FOSDEM#SocialWebFOSDEM
Pretty clear from the #FOSDEM#SocialWeb devroom talks that the limited set of #ActivityPub actors that Mastodon will accept is a problem for almost every other platform.
On the other hand, the ATProto meet-and-greet lasts 30 minutes, while the Social Web Devroom is for four hours, plus there's a one-hour BOF tomorrow, plus there is a 2-hour after hours tomorrow. And I think the organizers had several times as many submissions as they had time for presentations.
@sirjofri@mastodon.sdf.org
I know #activitypub is very powerful and most servers only "use" a subset of its features. I'm wondering, is there a #fediverse activitypub server software that tries to use _every_ feature? It doesn't have to look great and deliver a good experience, I'm just curious.
To be more precise, I'm not asking for a library or framework, but a full running server that you can install.
@sirjofri@mastodon.sdf.org
I know #activitypub is very powerful and most servers only "use" a subset of its features. I'm wondering, is there a #fediverse activitypub server software that tries to use _every_ feature? It doesn't have to look great and deliver a good experience, I'm just curious.
To be more precise, I'm not asking for a library or framework, but a full running server that you can install.
@sirjofri@mastodon.sdf.org
I know #activitypub is very powerful and most servers only "use" a subset of its features. I'm wondering, is there a #fediverse activitypub server software that tries to use _every_ feature? It doesn't have to look great and deliver a good experience, I'm just curious.
To be more precise, I'm not asking for a library or framework, but a full running server that you can install.
On the other hand, the ATProto meet-and-greet lasts 30 minutes, while the Social Web Devroom is for four hours, plus there's a one-hour BOF tomorrow, plus there is a 2-hour after hours tomorrow. And I think the organizers had several times as many submissions as they had time for presentations.
Other than that.. I started calling current AS/AP fedi the "as soon as possible" fediverse, where necessarily early app implementations served as the de-facto reference implementations for the #W3C#ActivityStreams and #ActivityPub open standards.
At serious cost: Ever increasing #ProtocolDecay and subsequent #WhackaMoleAdoption i.e. retaining app-by-app interop pipes against moving release targets.
When is Video domain getting standardized? That's my question.
I wish I had more time to prepare for the Global Switch Day, so I am planning another one for later this year with a website, social media accounts and collaboration with other projects.
I wish I had more time to prepare for the Global Switch Day, so I am planning another one for later this year with a website, social media accounts and collaboration with other projects.
On the train to FOSDEM I quickly but finally bashed out a long-planned post on the Solid app I wrote that allows you to post to the Fediverse from your Solid Pod.
Main takeway: cool experiment, but @activitypods have the more feasible approach for now.
On the train to FOSDEM I quickly but finally bashed out a long-planned post on the Solid app I wrote that allows you to post to the Fediverse from your Solid Pod.
Main takeway: cool experiment, but @activitypods have the more feasible approach for now.
I made several changes based on the feedback, but they are minor. There are parallel discussions at W3C GitHub, where I was told that core types don't exist, or don't matter, but this is obviously wrong, because many requirements in AP and AS depend on definitions of "collection", "activity" and other core types. Classification of objects based on their properties still seems to be the best solution.
Also, due to an uncertainty about the future of SocialHub (where many accounts are going to be suspended soon), I didn't create a discussion topic there. If you have any suggestions or feedback, please reply here or open an issue at https://codeberg.org/silverpill/feps/issues.
On the train to FOSDEM I quickly but finally bashed out a long-planned post on the Solid app I wrote that allows you to post to the Fediverse from your Solid Pod.
Main takeway: cool experiment, but @activitypods have the more feasible approach for now.
I need a Fediverse explanation that’s so simple anyone can relate to what I’m talking about. Can someone give me an analogy that’s relatable? I’ve tried everything #Fediverse#activitypub#discussion
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
I made several changes based on the feedback, but they are minor. There are parallel discussions at W3C GitHub, where I was told that core types don't exist, or don't matter, but this is obviously wrong, because many requirements in AP and AS depend on definitions of "collection", "activity" and other core types. Classification of objects based on their properties still seems to be the best solution.
Also, due to an uncertainty about the future of SocialHub (where many accounts are going to be suspended soon), I didn't create a discussion topic there. If you have any suggestions or feedback, please reply here or open an issue at https://codeberg.org/silverpill/feps/issues.
I made several changes based on the feedback, but they are minor. There are parallel discussions at W3C GitHub, where I was told that core types don't exist, or don't matter, but this is obviously wrong, because many requirements in AP and AS depend on definitions of "collection", "activity" and other core types. Classification of objects based on their properties still seems to be the best solution.
Also, due to an uncertainty about the future of SocialHub (where many accounts are going to be suspended soon), I didn't create a discussion topic there. If you have any suggestions or feedback, please reply here or open an issue at https://codeberg.org/silverpill/feps/issues.
Ok, I can officially say that I don't get #jsonLD. #ActivityPub uses it, #fediverse is built on it. But it doesnt actually give any boost in interoperability. The applications themself must be written with interoperability in mind. It's just fancy aliasing mechanism, am I wrong about it? Maybe that's what it's supposed to be? Was I wrong expecting it to be anything more? It doesn't do any heavy lifting besides the aliasing. It only serves as a reminder to look up the docs of a protocol. You could just as well just get the protocol spec out and it would be equivalent. What's the point?
"#Pixelfed, #Loops, & #Sup, #opensource alternatives to Instagram, TikTok, and WhatsApp, respectively, are now raising funds on #Kickstarter to fuel the apps’ further development. The trio is part of the growing #opensocial web, also known as #thefediverse, powered by the same #ActivityPub protocol used by X alternative Mastodon. The latter saw increased signups and use after Twitter sold to Elon Musk in Oct2022 and during the X exodus that followed the U.S. election."
Emelia Smith proposed and led the creation of the #ActivityPub Trust and Safety Taskforce, whose first task will be an overview of current state of trust and safety on the Fediverse, followed by work on flags, blocks, and content labelling.
You can now add searchable hashtags to your bot's posts using either our dedicated hashtag() function or through BotKit's extended Markdown syntax. This makes your bot's content more discoverable across the fediverse and helps engage with broader conversations.
Whether you're building a news bot, content curator, or community engagement tool, hashtags can help your bot reach the right audience.
Check out our docs to learn more about implementing hashtags in your bots!
ALT text detailsDocumentation showing BotKit's hashtag() function usage. It demonstrates how to use the hashtag() function in template literals and explains that the function automatically adds the “#” prefix if missing. The note section explains that hashtags are made discoverable for ActivityPub software.
ALT text detailsDocumentation showing BotKit's Markdown hashtag syntax. It demonstrates how to use hashtags in markdown() function with examples and explains that the function denotes hashtags for ActivityPub discoverability. It also shows how to disable hashtag syntax using the hashtags: false option.
You can now add searchable hashtags to your bot's posts using either our dedicated hashtag() function or through BotKit's extended Markdown syntax. This makes your bot's content more discoverable across the fediverse and helps engage with broader conversations.
Whether you're building a news bot, content curator, or community engagement tool, hashtags can help your bot reach the right audience.
Check out our docs to learn more about implementing hashtags in your bots!
ALT text detailsDocumentation showing BotKit's hashtag() function usage. It demonstrates how to use the hashtag() function in template literals and explains that the function automatically adds the “#” prefix if missing. The note section explains that hashtags are made discoverable for ActivityPub software.
ALT text detailsDocumentation showing BotKit's Markdown hashtag syntax. It demonstrates how to use hashtags in markdown() function with examples and explains that the function denotes hashtags for ActivityPub discoverability. It also shows how to disable hashtag syntax using the hashtags: false option.
You can now add searchable hashtags to your bot's posts using either our dedicated hashtag() function or through BotKit's extended Markdown syntax. This makes your bot's content more discoverable across the fediverse and helps engage with broader conversations.
Whether you're building a news bot, content curator, or community engagement tool, hashtags can help your bot reach the right audience.
Check out our docs to learn more about implementing hashtags in your bots!
ALT text detailsDocumentation showing BotKit's hashtag() function usage. It demonstrates how to use the hashtag() function in template literals and explains that the function automatically adds the “#” prefix if missing. The note section explains that hashtags are made discoverable for ActivityPub software.
ALT text detailsDocumentation showing BotKit's Markdown hashtag syntax. It demonstrates how to use hashtags in markdown() function with examples and explains that the function denotes hashtags for ActivityPub discoverability. It also shows how to disable hashtag syntax using the hashtags: false option.
You can now add searchable hashtags to your bot's posts using either our dedicated hashtag() function or through BotKit's extended Markdown syntax. This makes your bot's content more discoverable across the fediverse and helps engage with broader conversations.
Whether you're building a news bot, content curator, or community engagement tool, hashtags can help your bot reach the right audience.
Check out our docs to learn more about implementing hashtags in your bots!
ALT text detailsDocumentation showing BotKit's hashtag() function usage. It demonstrates how to use the hashtag() function in template literals and explains that the function automatically adds the “#” prefix if missing. The note section explains that hashtags are made discoverable for ActivityPub software.
ALT text detailsDocumentation showing BotKit's Markdown hashtag syntax. It demonstrates how to use hashtags in markdown() function with examples and explains that the function denotes hashtags for ActivityPub discoverability. It also shows how to disable hashtag syntax using the hashtags: false option.
You can now add searchable hashtags to your bot's posts using either our dedicated hashtag() function or through BotKit's extended Markdown syntax. This makes your bot's content more discoverable across the fediverse and helps engage with broader conversations.
Whether you're building a news bot, content curator, or community engagement tool, hashtags can help your bot reach the right audience.
Check out our docs to learn more about implementing hashtags in your bots!
ALT text detailsDocumentation showing BotKit's hashtag() function usage. It demonstrates how to use the hashtag() function in template literals and explains that the function automatically adds the “#” prefix if missing. The note section explains that hashtags are made discoverable for ActivityPub software.
ALT text detailsDocumentation showing BotKit's Markdown hashtag syntax. It demonstrates how to use hashtags in markdown() function with examples and explains that the function denotes hashtags for ActivityPub discoverability. It also shows how to disable hashtag syntax using the hashtags: false option.
Emelia Smith proposed and led the creation of the #ActivityPub Trust and Safety Taskforce, whose first task will be an overview of current state of trust and safety on the Fediverse, followed by work on flags, blocks, and content labelling.
This week's news: - @pixelfed continues to grow, adding 100k active users in a week. The platform now has grown from 20k active users a month ago to almost 300k active accounts currently - The Pixelfed Kickstarter smashed its goals, raising over 100k CAD in funding - Tumblr recommits to connecting to the #fediverse in the future, using the WordPress #ActivityPub plugin
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
This week's news: - @pixelfed continues to grow, adding 100k active users in a week. The platform now has grown from 20k active users a month ago to almost 300k active accounts currently - The Pixelfed Kickstarter smashed its goals, raising over 100k CAD in funding - Tumblr recommits to connecting to the #fediverse in the future, using the WordPress #ActivityPub plugin
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
This week's news: - @pixelfed continues to grow, adding 100k active users in a week. The platform now has grown from 20k active users a month ago to almost 300k active accounts currently - The Pixelfed Kickstarter smashed its goals, raising over 100k CAD in funding - Tumblr recommits to connecting to the #fediverse in the future, using the WordPress #ActivityPub plugin
@elipariser I think this post is quite telling, so you need massive financial backing in order to set up a relay for a 2nd Bluesky instance. With great money comes great incentives to do bad things. The point here is, why should a user potentially go through the same busted experience they had with Twitter on a potentially busted 2nd Bluesky instance? With #ActivityPub, you can simply find another instance, #Mastodon doesn't disappear when one instance goes busted.
This week's news: - @pixelfed continues to grow, adding 100k active users in a week. The platform now has grown from 20k active users a month ago to almost 300k active accounts currently - The Pixelfed Kickstarter smashed its goals, raising over 100k CAD in funding - Tumblr recommits to connecting to the #fediverse in the future, using the WordPress #ActivityPub plugin
@elipariser I think this post is quite telling, so you need massive financial backing in order to set up a relay for a 2nd Bluesky instance. With great money comes great incentives to do bad things. The point here is, why should a user potentially go through the same busted experience they had with Twitter on a potentially busted 2nd Bluesky instance? With #ActivityPub, you can simply find another instance, #Mastodon doesn't disappear when one instance goes busted.
This week's news: - @pixelfed continues to grow, adding 100k active users in a week. The platform now has grown from 20k active users a month ago to almost 300k active accounts currently - The Pixelfed Kickstarter smashed its goals, raising over 100k CAD in funding - Tumblr recommits to connecting to the #fediverse in the future, using the WordPress #ActivityPub plugin
This week's news: - @pixelfed continues to grow, adding 100k active users in a week. The platform now has grown from 20k active users a month ago to almost 300k active accounts currently - The Pixelfed Kickstarter smashed its goals, raising over 100k CAD in funding - Tumblr recommits to connecting to the #fediverse in the future, using the WordPress #ActivityPub plugin
This week's news: - @pixelfed continues to grow, adding 100k active users in a week. The platform now has grown from 20k active users a month ago to almost 300k active accounts currently - The Pixelfed Kickstarter smashed its goals, raising over 100k CAD in funding - Tumblr recommits to connecting to the #fediverse in the future, using the WordPress #ActivityPub plugin
Does anyone have any suggestions for how to increase Mastodon's userbase? 🤔 People are finally starting to abandon the toxic cesspool formerly known as Twitter, but they seem to be migrating to Threads and Version 2.0 aka Bluesky.
I'm off to #FOSDEM2025 at the end of this week to join the #SocialWeb devroom, and talk about @manyfold on Saturday afternoon!
Looking forward to talking to folks about #ActivityPub federation, #3dPrinting, #WebGL... pretty much anything TBH! And looking forward to a trip on the Eurostar, too 🚅
In the last days I often got asked about #snac / #snac2 as an alternative to #Mastodon and I can highly recommend it! I few months ago, I already wrote a HowTo about setting snac up on a FreeBSD instance - might be worth to share again :) if you’re using snac, you might also want to use my relay service at https://fedi-relay.gyptazy.com to make your posts more visible in the Fediworld.
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
Äh… Halusin koodata oman fediverseinstanssin @fedify-kirjastolla. Alustana olisi Cloudflare (Workers, KV, D1, Queues, R2). Workersin Node.js-yhteensopivuustilasta huolimatta Fedify ei kuitenkaan toimi: palauttaa ainakin syntaksivirheitä. Turhauttaa!
Nyt sitten forkkaan Fedifyn toistaiseksi ja yritän saada sen toimimaan. En nimittäin halua ohjelmoida ActivityPub-palvelinta ilman apukirjastoa, enkä mielelläni vaihtaisi hostausympäristöäkään toiseen.
Anyone got any suggestions for how people with existing Fediverse-connected WordPress blogs could migrate them to alternatives without losing their followers?
Are there any WP forks with ActivityPub compatibility for example? The AP plugin is FOSS so it should be possible in theory?
Äh… Halusin koodata oman fediverseinstanssin @fedify-kirjastolla. Alustana olisi Cloudflare (Workers, KV, D1, Queues, R2). Workersin Node.js-yhteensopivuustilasta huolimatta Fedify ei kuitenkaan toimi: palauttaa ainakin syntaksivirheitä. Turhauttaa!
Nyt sitten forkkaan Fedifyn toistaiseksi ja yritän saada sen toimimaan. En nimittäin halua ohjelmoida ActivityPub-palvelinta ilman apukirjastoa, enkä mielelläni vaihtaisi hostausympäristöäkään toiseen.
In the last days I often got asked about #snac / #snac2 as an alternative to #Mastodon and I can highly recommend it! I few months ago, I already wrote a HowTo about setting snac up on a FreeBSD instance - might be worth to share again :) if you’re using snac, you might also want to use my relay service at https://fedi-relay.gyptazy.com to make your posts more visible in the Fediworld.
#BotKit's web interface now supports theme customization! 🎨 You can set your preferred color theme using the pages.color option in createBot(). Here are some examples showing the same interface in different colors: "violet", "pumpkin", "azure", and "green" (default).
const bot = createBot<void>({
// ... other options
pages: {
color: "violet" // or "pumpkin", "azure", etc.
}
});
We support all color themes from Pico CSS—including "amber", "fuchsia", "indigo", "jade", "lime", "pink", "sand", "slate", "yellow", "zinc", and more! Check out Pico CSS's Colors docs for the full list of available themes.
ALT text detailsBotKit web interface in pumpkin theme, displaying Greet Bot's profile. Headers and interactive elements are styled in warm orange tones.
ALT text detailsDefault green-themed BotKit interface displaying Greet Bot's profile. UI elements are styled in forest green colors, showing the default color scheme.
ALT text detailsBotKit web interface in violet theme, showing Greet Bot's profile with greeting message. The interface elements including headings and links are colored in shades of purple.
ALT text detailsBotKit web interface themed in azure blue, showing Greet Bot's profile and activity. Navigation elements and links feature various shades of blue.
When I opened up Lemmy this morning I could not believe my eyes. The top story was a headline from Forbes stating: « ‘Open Source And Ethical’ TikTok, WhatsApp And Instagram Alternatives Could Transform Social Media ».
The article mostly focused on #Pixelfed and did a fairly good job explaining how #ActivityPub works. But they spelled #Mastodon « Mastadon » over and over again with no links to it. Yikes.
How does john@example.org tell its server example.org (C2S) that it wants to delete max@mastodon.org from its followers? which activity is this? #activitypub#activitypubdev#rdf-pub
ALT text detailsA meme that features a two-panel comparison with the same character, Geordi La Forge from Star Trek, expressing contrasting reactions. In the first panel, he raises his hand, appearing to reject or dismiss the Bluesky logo, a blue butterfly symbol. In the second panel, he approvingly gestures towards the colorful Fediverse logo, which represents interconnected decentralized platforms. The meme humorously portrays a preference for decentralized systems (the Fediverse) over proprietary, centralized platforms like Bluesky.
#BotKit's web interface now supports theme customization! 🎨 You can set your preferred color theme using the pages.color option in createBot(). Here are some examples showing the same interface in different colors: "violet", "pumpkin", "azure", and "green" (default).
const bot = createBot<void>({
// ... other options
pages: {
color: "violet" // or "pumpkin", "azure", etc.
}
});
We support all color themes from Pico CSS—including "amber", "fuchsia", "indigo", "jade", "lime", "pink", "sand", "slate", "yellow", "zinc", and more! Check out Pico CSS's Colors docs for the full list of available themes.
ALT text detailsBotKit web interface in pumpkin theme, displaying Greet Bot's profile. Headers and interactive elements are styled in warm orange tones.
ALT text detailsDefault green-themed BotKit interface displaying Greet Bot's profile. UI elements are styled in forest green colors, showing the default color scheme.
ALT text detailsBotKit web interface in violet theme, showing Greet Bot's profile with greeting message. The interface elements including headings and links are colored in shades of purple.
ALT text detailsBotKit web interface themed in azure blue, showing Greet Bot's profile and activity. Navigation elements and links feature various shades of blue.
#BotKit's web interface now supports theme customization! 🎨 You can set your preferred color theme using the pages.color option in createBot(). Here are some examples showing the same interface in different colors: "violet", "pumpkin", "azure", and "green" (default).
const bot = createBot<void>({
// ... other options
pages: {
color: "violet" // or "pumpkin", "azure", etc.
}
});
We support all color themes from Pico CSS—including "amber", "fuchsia", "indigo", "jade", "lime", "pink", "sand", "slate", "yellow", "zinc", and more! Check out Pico CSS's Colors docs for the full list of available themes.
ALT text detailsBotKit web interface in pumpkin theme, displaying Greet Bot's profile. Headers and interactive elements are styled in warm orange tones.
ALT text detailsDefault green-themed BotKit interface displaying Greet Bot's profile. UI elements are styled in forest green colors, showing the default color scheme.
ALT text detailsBotKit web interface in violet theme, showing Greet Bot's profile with greeting message. The interface elements including headings and links are colored in shades of purple.
ALT text detailsBotKit web interface themed in azure blue, showing Greet Bot's profile and activity. Navigation elements and links feature various shades of blue.
#BotKit's web interface now supports theme customization! 🎨 You can set your preferred color theme using the pages.color option in createBot(). Here are some examples showing the same interface in different colors: "violet", "pumpkin", "azure", and "green" (default).
const bot = createBot<void>({
// ... other options
pages: {
color: "violet" // or "pumpkin", "azure", etc.
}
});
We support all color themes from Pico CSS—including "amber", "fuchsia", "indigo", "jade", "lime", "pink", "sand", "slate", "yellow", "zinc", and more! Check out Pico CSS's Colors docs for the full list of available themes.
ALT text detailsBotKit web interface in pumpkin theme, displaying Greet Bot's profile. Headers and interactive elements are styled in warm orange tones.
ALT text detailsDefault green-themed BotKit interface displaying Greet Bot's profile. UI elements are styled in forest green colors, showing the default color scheme.
ALT text detailsBotKit web interface in violet theme, showing Greet Bot's profile with greeting message. The interface elements including headings and links are colored in shades of purple.
ALT text detailsBotKit web interface themed in azure blue, showing Greet Bot's profile and activity. Navigation elements and links feature various shades of blue.
Anyone self hosting pixelfed and ever not been able to log into your instance? I keep getting the error in my screenshot and when I check that against the debugging tool it gives me something about an invalid key.
ALT text detailsA screenshot of a Pixelfed error screen saying "Something went wrong. We cannot process your request at this time, please try again later."
Anyone self hosting pixelfed and ever not been able to log into your instance? I keep getting the error in my screenshot and when I check that against the debugging tool it gives me something about an invalid key.
ALT text detailsA screenshot of a Pixelfed error screen saying "Something went wrong. We cannot process your request at this time, please try again later."
When I opened up Lemmy this morning I could not believe my eyes. The top story was a headline from Forbes stating: « ‘Open Source And Ethical’ TikTok, WhatsApp And Instagram Alternatives Could Transform Social Media ».
The article mostly focused on #Pixelfed and did a fairly good job explaining how #ActivityPub works. But they spelled #Mastodon « Mastadon » over and over again with no links to it. Yikes.
Preventing enshittification of platforms rests on credible exit for users and devs. #ActivityPub and #SMTP are not perfect but
a) are implemented und understood by many players,
b) enable freedom of choice of servers and clients,
c) implement #RightToMigrate as well as self/community custody
Many #p2p projects promise to remove servers but often promote and depend on a single implementation stack, have no spec and no interop among #p2p islands, and thus struggle to provide credible exit.
In light of certain #Fedidrama—which I’ll let other people (not me) explain—it’s important to understand that what #ActivityPub offers is an escape hatch for when you want to leave a service.
Also, the best way to ensure you never have to leave a service is to run your own #Fediverse server.
Preventing enshittification of platforms rests on credible exit for users and devs. #ActivityPub and #SMTP are not perfect but
a) are implemented und understood by many players,
b) enable freedom of choice of servers and clients,
c) implement #RightToMigrate as well as self/community custody
Many #p2p projects promise to remove servers but often promote and depend on a single implementation stack, have no spec and no interop among #p2p islands, and thus struggle to provide credible exit.
I'm looking for your opinions from the developers of the fediverse.
A common HTML web page can contain related links via the <link> tag. I would like to do the same for Activity Streams objects, for example:
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://writings.hongminhee.org/ap/2024/12/a-year-with-the-fediverse.json",
"type": "Article",
"name": "A year with the fediverse",
"content": "2024 was truly a year where I was deeply immersed in the fediverse. …",
"url": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/",
"attachment": [
{
"type": "Link",
"rel": "alternate",
"hreflang": "ko",
"href": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ko-hang-kr.html",
"mediaType": "text/html"
},
{
"type": "Link",
"rel": "alternate",
"hreflang": "ja",
"href": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ja.html",
"mediaType": "text/html"
}
]
}
Do you think this makes sense, and would it be appropriate to put Link objects in the attachment?
Exciting update on #BotKit: we've introduced a new Repository abstraction layer that provides cleaner data access. While previously data operations went directly through KvStore, they now go through Repository—improving separation of concerns and making the codebase more maintainable. Don't worry though—there are no breaking changes to the public API that BotKit users rely on!
"#Pixelfed, #Loops, & #Sup, #opensource alternatives to Instagram, TikTok, and WhatsApp, respectively, are now raising funds on #Kickstarter to fuel the apps’ further development. The trio is part of the growing #opensocial web, also known as #thefediverse, powered by the same #ActivityPub protocol used by X alternative Mastodon. The latter saw increased signups and use after Twitter sold to Elon Musk in Oct2022 and during the X exodus that followed the U.S. election."
Exciting update on #BotKit: we've introduced a new Repository abstraction layer that provides cleaner data access. While previously data operations went directly through KvStore, they now go through Repository—improving separation of concerns and making the codebase more maintainable. Don't worry though—there are no breaking changes to the public API that BotKit users rely on!
Preventing enshittification of platforms rests on credible exit for users and devs. #ActivityPub and #SMTP are not perfect but
a) are implemented und understood by many players,
b) enable freedom of choice of servers and clients,
c) implement #RightToMigrate as well as self/community custody
Many #p2p projects promise to remove servers but often promote and depend on a single implementation stack, have no spec and no interop among #p2p islands, and thus struggle to provide credible exit.
Preventing enshittification of platforms rests on credible exit for users and devs. #ActivityPub and #SMTP are not perfect but
a) are implemented und understood by many players,
b) enable freedom of choice of servers and clients,
c) implement #RightToMigrate as well as self/community custody
Many #p2p projects promise to remove servers but often promote and depend on a single implementation stack, have no spec and no interop among #p2p islands, and thus struggle to provide credible exit.
I realize that Meta isn't even close to fully federating Threads, but I've yet to find anyone that I know IRL, any breweries, and it seems like very few reputable news sources have turned on fediverse sharing.
Exciting update on #BotKit: we've introduced a new Repository abstraction layer that provides cleaner data access. While previously data operations went directly through KvStore, they now go through Repository—improving separation of concerns and making the codebase more maintainable. Don't worry though—there are no breaking changes to the public API that BotKit users rely on!
Exciting update on #BotKit: we've introduced a new Repository abstraction layer that provides cleaner data access. While previously data operations went directly through KvStore, they now go through Repository—improving separation of concerns and making the codebase more maintainable. Don't worry though—there are no breaking changes to the public API that BotKit users rely on!
I realize that Meta isn't even close to fully federating Threads, but I've yet to find anyone that I know IRL, any breweries, and it seems like very few reputable news sources have turned on fediverse sharing.
I'm looking for your opinions from the developers of the fediverse.
A common HTML web page can contain related links via the <link> tag. I would like to do the same for Activity Streams objects, for example:
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://writings.hongminhee.org/ap/2024/12/a-year-with-the-fediverse.json",
"type": "Article",
"name": "A year with the fediverse",
"content": "2024 was truly a year where I was deeply immersed in the fediverse. …",
"url": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/",
"attachment": [
{
"type": "Link",
"rel": "alternate",
"hreflang": "ko",
"href": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ko-hang-kr.html",
"mediaType": "text/html"
},
{
"type": "Link",
"rel": "alternate",
"hreflang": "ja",
"href": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ja.html",
"mediaType": "text/html"
}
]
}
Do you think this makes sense, and would it be appropriate to put Link objects in the attachment?
Ich möchte verstehen, warum sich gute Leute wie Cory Doctorow zu der 30-Millionen-Dollar-Geldsammlung "Free Our Feeds" zusammengeschlossen haben. Damit wollen sie Bluesky dezentralisieren und deren AT-Protokoll stärken, vor allem aber einen zukünftigen Zugriff und Kontrolle durch reiche Dritte verhindern. Für uns hier im Fediverse mit dem Flaggschiff Mastodon und dem W3C-Protokoll ActivityPub muss es unverständlich sein, warum diese Initiative etwas bei Bluesky erreichen will, was es hier schon längst gibt: Dezentralität und ein offenes Protokoll.
Just a few days ago, I lunched my new relay service for the #Fediverse and I'm really happy to see that there're already many ones connected to - more than 50 instances in just a few days!
But what makes me even really happy is to see, that my service [2] also gets linked in the release notes of #snac [1] / #snac2 - and I can recommend the usage of relay services (it doesn't matter which one!) to everyone. It provides more content from connected instances to you, but also brings your posts - from your local instance - up to other ones within the federated network where it can get much easier distributed around other instances.
#snac is the perfect way to host an own fediverse instance. Using the #ActivityPub protocol allows you to connect to all other instances. With the integrated #Mastodon API, you can also use most of your usual clients or web clients. Snac is light, fast, does not require any database and follows the KISS way - which the most of us BSD people are living. With relay services, it's the perfect match for singe-user instances and @grunfink is always open for ideas and to help! It does not always need to be #Mastodon, #GoToSocial etc!
And if you're using any other software, you may still benefit by using relay services. And if you're still looking for a guide, howto setup snac2 on #FreeBSD, my howto [3] might help you out.
somehow i have the feeling that mastodon has a lot of transient objects without id. too many. And many for which there is even an image url that does not appear to be transient.
or is it just my feeling that an icon of the actor should have an id ?
Does ActivityPub have any "livestreaming" functionality built in / something that could be integrated? I'm exploring the idea of Subjam as part of the Fediverse. Its audio broad facilities (Icecast2 backend which uses HTTP streaming) might need to be a completely separate arm of my infra..
The core of Subjam fits well with the Fedi model. It encompasses multiple individual music communities/scenes around the world.
Just a few days ago, I lunched my new relay service for the #Fediverse and I'm really happy to see that there're already many ones connected to - more than 50 instances in just a few days!
But what makes me even really happy is to see, that my service [2] also gets linked in the release notes of #snac [1] / #snac2 - and I can recommend the usage of relay services (it doesn't matter which one!) to everyone. It provides more content from connected instances to you, but also brings your posts - from your local instance - up to other ones within the federated network where it can get much easier distributed around other instances.
#snac is the perfect way to host an own fediverse instance. Using the #ActivityPub protocol allows you to connect to all other instances. With the integrated #Mastodon API, you can also use most of your usual clients or web clients. Snac is light, fast, does not require any database and follows the KISS way - which the most of us BSD people are living. With relay services, it's the perfect match for singe-user instances and @grunfink is always open for ideas and to help! It does not always need to be #Mastodon, #GoToSocial etc!
And if you're using any other software, you may still benefit by using relay services. And if you're still looking for a guide, howto setup snac2 on #FreeBSD, my howto [3] might help you out.
After a long silence, Tumblr confirms it is still planning to join the fediverse.
> The migration is still a work in progress, as we’ve previously detailed here, but we can say for sure that it will include support for WordPress’s existing ActivityPub plugins. We hope this comes as good news.
ALT text detailsA screenshot of a tumblr post from their official work in progress account (wip)
Good news! While it is still on the list, the Tumblr to WordPress migration will definitely unlock ActivityPub for Tumblr! In fact, one big reason for the migration itself is to get us into the Fediverse. When that’s done, we’re in.
The migration is still a work in progress, as we’ve previously detailed here, but we can say for sure that it will include support for WordPress’s existing ActivityPub plugins. We hope this comes as good news.
Thanks for your question, and we hope it won’t be too long. Keep the questions coming!
Just a few days ago, I lunched my new relay service for the #Fediverse and I'm really happy to see that there're already many ones connected to - more than 50 instances in just a few days!
But what makes me even really happy is to see, that my service [2] also gets linked in the release notes of #snac [1] / #snac2 - and I can recommend the usage of relay services (it doesn't matter which one!) to everyone. It provides more content from connected instances to you, but also brings your posts - from your local instance - up to other ones within the federated network where it can get much easier distributed around other instances.
#snac is the perfect way to host an own fediverse instance. Using the #ActivityPub protocol allows you to connect to all other instances. With the integrated #Mastodon API, you can also use most of your usual clients or web clients. Snac is light, fast, does not require any database and follows the KISS way - which the most of us BSD people are living. With relay services, it's the perfect match for singe-user instances and @grunfink is always open for ideas and to help! It does not always need to be #Mastodon, #GoToSocial etc!
And if you're using any other software, you may still benefit by using relay services. And if you're still looking for a guide, howto setup snac2 on #FreeBSD, my howto [3] might help you out.
After a long silence, Tumblr confirms it is still planning to join the fediverse.
> The migration is still a work in progress, as we’ve previously detailed here, but we can say for sure that it will include support for WordPress’s existing ActivityPub plugins. We hope this comes as good news.
ALT text detailsA screenshot of a tumblr post from their official work in progress account (wip)
Good news! While it is still on the list, the Tumblr to WordPress migration will definitely unlock ActivityPub for Tumblr! In fact, one big reason for the migration itself is to get us into the Fediverse. When that’s done, we’re in.
The migration is still a work in progress, as we’ve previously detailed here, but we can say for sure that it will include support for WordPress’s existing ActivityPub plugins. We hope this comes as good news.
Thanks for your question, and we hope it won’t be too long. Keep the questions coming!
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
After a long silence, Tumblr confirms it is still planning to join the fediverse.
> The migration is still a work in progress, as we’ve previously detailed here, but we can say for sure that it will include support for WordPress’s existing ActivityPub plugins. We hope this comes as good news.
ALT text detailsA screenshot of a tumblr post from their official work in progress account (wip)
Good news! While it is still on the list, the Tumblr to WordPress migration will definitely unlock ActivityPub for Tumblr! In fact, one big reason for the migration itself is to get us into the Fediverse. When that’s done, we’re in.
The migration is still a work in progress, as we’ve previously detailed here, but we can say for sure that it will include support for WordPress’s existing ActivityPub plugins. We hope this comes as good news.
Thanks for your question, and we hope it won’t be too long. Keep the questions coming!
1. It's not actually the unique platform it tries to make itself look like. It's a Mastodon fork. 2. *In violation of Mastodon's AGPLv3 license*, Frequency is proprietary, or at the very least does not provide any link to the source code. 3. They paywall signups.
This isn't anything particularly new and interesting. It's just yet another corporate leech on the fediverse...
ALT text detailsA screenshot of the Frequency website and browser DevTools, showing a root element with the ID "mastodon"
ALT text detailsA screenshot of the Frequency website with JavaScript disabled, showing the exact same message Mastodon shows when JavaScript is disabled: "To use the Mastodon web application, please enable JavaScript. Alternatively, try one of the native apps for Mastodon for your platform."
ALT text detailsA screenshot of the join/subscribe page, showing plans for $2 a month, $5 a month, and $6 a month
After a long silence, Tumblr confirms it is still planning to join the fediverse.
> The migration is still a work in progress, as we’ve previously detailed here, but we can say for sure that it will include support for WordPress’s existing ActivityPub plugins. We hope this comes as good news.
ALT text detailsA screenshot of a tumblr post from their official work in progress account (wip)
Good news! While it is still on the list, the Tumblr to WordPress migration will definitely unlock ActivityPub for Tumblr! In fact, one big reason for the migration itself is to get us into the Fediverse. When that’s done, we’re in.
The migration is still a work in progress, as we’ve previously detailed here, but we can say for sure that it will include support for WordPress’s existing ActivityPub plugins. We hope this comes as good news.
Thanks for your question, and we hope it won’t be too long. Keep the questions coming!
After a long silence, Tumblr confirms it is still planning to join the fediverse.
> The migration is still a work in progress, as we’ve previously detailed here, but we can say for sure that it will include support for WordPress’s existing ActivityPub plugins. We hope this comes as good news.
ALT text detailsA screenshot of a tumblr post from their official work in progress account (wip)
Good news! While it is still on the list, the Tumblr to WordPress migration will definitely unlock ActivityPub for Tumblr! In fact, one big reason for the migration itself is to get us into the Fediverse. When that’s done, we’re in.
The migration is still a work in progress, as we’ve previously detailed here, but we can say for sure that it will include support for WordPress’s existing ActivityPub plugins. We hope this comes as good news.
Thanks for your question, and we hope it won’t be too long. Keep the questions coming!
After a long silence, Tumblr confirms it is still planning to join the fediverse.
> The migration is still a work in progress, as we’ve previously detailed here, but we can say for sure that it will include support for WordPress’s existing ActivityPub plugins. We hope this comes as good news.
ALT text detailsA screenshot of a tumblr post from their official work in progress account (wip)
Good news! While it is still on the list, the Tumblr to WordPress migration will definitely unlock ActivityPub for Tumblr! In fact, one big reason for the migration itself is to get us into the Fediverse. When that’s done, we’re in.
The migration is still a work in progress, as we’ve previously detailed here, but we can say for sure that it will include support for WordPress’s existing ActivityPub plugins. We hope this comes as good news.
Thanks for your question, and we hope it won’t be too long. Keep the questions coming!
I have a #Fediverse#ActivityPub question: Why doesn't my client ( #mastodon or #pixelfed ) automatically load the comments from the original page so that all comments are visible? Is there a technical reason?
It seems the "three slightly touching buttholes" symbol ⁂ is making the rounds again as people try to change the Fediverse logo that has nothing wrong with it.
The current Fediverse logo shows diversity and interconnectivity, the main features of Fedi.
The "asterism" is already used in writing to denote a change in time. It's a unicode character similar to how a billionaire asshole changed his companies logo to a unicode character and it was told to him many times why that's a bad idea, yet people want to copy him here?😑
Furthermore, it's all white and not connected at all. Which doesn't embody the values of Fedi at all. Last, but definitely not least, it looks like three slightly touching buttholes.
Is there some sort of #ActivityPub / #Fediverse matrix website for comparing features, specs and intercompatibility? Kind of like CanIUse but for the Fediverse?
A recent question about DMs in ActivityPub got me looking, but of course including "matrix" in your query returns mostly Matrix protocol results.
It would be really handy to have comparison matrices for:
- ActivityPub server implementations - ActivityPub client features
So far I've found neither!
[Gah! Sorry for any edit notices but I don't know how I could have missed that stray 'd'.]
Movie where an ActivityPub author has retreated to a hermit life in the woods and some organization is trying to get then back
(Author, outside a wood cabin, gardening) "Hey, I'm here to talk about ActivityPub v3" "Bring that leaf bin over there will ya" (Grizzled author fetches it themselves) "So, would you be open to talking?" "I need a chock for this here woodsaw table, split one of them logs" "Is that a no?" (Author approaches the city slicker, fatigued) "If they want me to invent protocol extensions, (huff) they gotta send someone better than you" (City slicker turns as they depart inside)
The Fediverse, the social network you're using to avoid Facebook, Twitter, Reddit, or Blue Sky, is managed by real people, and not corporations. These real people, your administrator, pay for hosting so that you may share your thought, feelings, or just randomly sh-t post.
If you're financially able, take a moment to reach out to your administrator, and ask if they need help. Even a little bit can help.
This week's news: - massive growth for @pixelfed, growing from 20k active users last month to almost 200k active users currently. - @nodebb has officially launched their #activitypub integration - Meta will not commit or confirm a timeline for adding account migration to #threads
Thank you to everyone for reading and supporting 100 editions of Last Week in Fediverse!
I have been trying to figure out how to send a DM using #ActivityPub but I have still not found any clear instructions on what the message should contain for it to be a proper DM.
We're creating something truly special here with the fediverse, and I am so thankful for everyone who contributes to it, whether with your time, money, or just by sharing your thoughts, your creations, your silly little jokes. Keep it up!
We're creating something truly special here with the fediverse, and I am so thankful for everyone who contributes to it, whether with your time, money, or just by sharing your thoughts, your creations, your silly little jokes. Keep it up!
We're creating something truly special here with the fediverse, and I am so thankful for everyone who contributes to it, whether with your time, money, or just by sharing your thoughts, your creations, your silly little jokes. Keep it up!
We're creating something truly special here with the fediverse, and I am so thankful for everyone who contributes to it, whether with your time, money, or just by sharing your thoughts, your creations, your silly little jokes. Keep it up!
We're creating something truly special here with the fediverse, and I am so thankful for everyone who contributes to it, whether with your time, money, or just by sharing your thoughts, your creations, your silly little jokes. Keep it up!
I'm on a mailing list for the official ActivityPub specification and everyone is super keen on this idea that ActivityPub is going to start supporting "facts", ie you either agree with the "truth" or you're wrong.
As much as I can't stand the disinformation campaigns, they're not at all taking seriously the idea that demanding everyone have the same "truth" is not only group-think, but far more dangerous.
It's a degradation of the very foundation of fundamental liberal ideas of difference. The idea that all must adhere to the official "Truth" is a tenement of fascism.
And who will control truth? Why, the same people who control moderation of course, meaning that if you're part of a marginalized group within the network then watch out, because they're coming for you, and now they have the "truth" on their side.
I've been active in the fediverse for a bit over two years now, and it still blows my mind that people can use an Instagram-like service and just casually interact with folks who are posting on a Reddit-like service or a Twitter-like service. Just like that.
I've been active in the fediverse for a bit over two years now, and it still blows my mind that people can use an Instagram-like service and just casually interact with folks who are posting on a Reddit-like service or a Twitter-like service. Just like that.
I've been active in the fediverse for a bit over two years now, and it still blows my mind that people can use an Instagram-like service and just casually interact with folks who are posting on a Reddit-like service or a Twitter-like service. Just like that.
We're creating something truly special here with the fediverse, and I am so thankful for everyone who contributes to it, whether with your time, money, or just by sharing your thoughts, your creations, your silly little jokes. Keep it up!
If there was a #fediverse#activitypub platform for movies and tv shows, what features would you expect from it?
What I have in mind are: 1. Rate (x/y) 2. Write review 3. Currently watching (for tv shows, maybe general status in case abonded, also progress) 3. Watchlist 4. Events to organize events to watch together (seems to be popular on Fedi already) 5. Recommend tv show/movie (to your followers or someone specific?)
Please leave comments with your thoughts/ideas, also if you don't mind to boost 🙏🏼
We're creating something truly special here with the fediverse, and I am so thankful for everyone who contributes to it, whether with your time, money, or just by sharing your thoughts, your creations, your silly little jokes. Keep it up!
We're creating something truly special here with the fediverse, and I am so thankful for everyone who contributes to it, whether with your time, money, or just by sharing your thoughts, your creations, your silly little jokes. Keep it up!
We're creating something truly special here with the fediverse, and I am so thankful for everyone who contributes to it, whether with your time, money, or just by sharing your thoughts, your creations, your silly little jokes. Keep it up!
We're creating something truly special here with the fediverse, and I am so thankful for everyone who contributes to it, whether with your time, money, or just by sharing your thoughts, your creations, your silly little jokes. Keep it up!
A YunoHost type project, but specific to fediverse platforms. Definitely one I’m going to follow more closely.
Fedi Developers take note, there are some grants available to implement your fedi services as packages here!
“The Fediversity Project enables easy hosting for a wide variety of fediverse platforms, all based on NixOS. At the start, the project will support Mastodon, PixelFed,PeerTube...”
If there was a #fediverse#activitypub platform for movies and tv shows, what features would you expect from it?
What I have in mind are: 1. Rate (x/y) 2. Write review 3. Currently watching (for tv shows, maybe general status in case abonded, also progress) 3. Watchlist 4. Events to organize events to watch together (seems to be popular on Fedi already) 5. Recommend tv show/movie (to your followers or someone specific?)
Please leave comments with your thoughts/ideas, also if you don't mind to boost 🙏🏼
Normally I don't like links with extra url params revealing where i'm coming from, but for links revealing I come from #mastodon#fediverse#activitypub I make exceptions.
My argument for #ActivityPub over #ATProtocol is simple: if ATProtocol rules supreme, what will compete against #Bluesky’s firehose?
How many nodes are there on AT Protocol?
How many unique services that don’t resemble Twitter run on AT Protocol?
But above all, what happens if Bluesky gets bought by Musk or Zuckerberg?
With the Fediverse, we got established decentralization. Not theoretical—something that exists in the far off future—but decentralization that is here and now.
My argument for #ActivityPub over #ATProtocol is simple: if ATProtocol rules supreme, what will compete against #Bluesky’s firehose?
How many nodes are there on AT Protocol?
How many unique services that don’t resemble Twitter run on AT Protocol?
But above all, what happens if Bluesky gets bought by Musk or Zuckerberg?
With the Fediverse, we got established decentralization. Not theoretical—something that exists in the far off future—but decentralization that is here and now.
My argument for #ActivityPub over #ATProtocol is simple: if ATProtocol rules supreme, what will compete against #Bluesky’s firehose?
How many nodes are there on AT Protocol?
How many unique services that don’t resemble Twitter run on AT Protocol?
But above all, what happens if Bluesky gets bought by Musk or Zuckerberg?
With the Fediverse, we got established decentralization. Not theoretical—something that exists in the far off future—but decentralization that is here and now.
The Fediverse, the social network you're using to avoid Facebook, Twitter, Reddit, or Blue Sky, is managed by real people, and not corporations. These real people, your administrator, pay for hosting so that you may share your thought, feelings, or just randomly sh-t post.
If you're financially able, take a moment to reach out to your administrator, and ask if they need help. Even a little bit can help.
hey #fediverse what is the current #activitypub server that provides features similar to #mastodon or #pleroma that uses the fewest resources? Is there anything there that is good for single user instances?
I'm aware of GoToSocial and Honk but wondering what else is there.
hey #fediverse what is the current #activitypub server that provides features similar to #mastodon or #pleroma that uses the fewest resources? Is there anything there that is good for single user instances?
I'm aware of GoToSocial and Honk but wondering what else is there.
Some people just like shooting themselves in the foot and then complaining about the pain...🤦♂️
If you specifically ask how to do something in a specific way, I will tell you how to do it that way, if I know how, even if there's an easier way.
If you ask "How do I interact with Lemmy from Mastodon", I will tell you the VERY janky and frustrating way to do it. However if you ask me "how can I use Lemmy just like reddit", I'll simply tell you to sign up to Lemmy and use it like reddit.
Is this why people are so confused about Fediverse?
Some Fediverse softwares don't play nice together and it's very janky cross platform.
Don't shoot yourself in the foot by trying to do things the hard way.
@volkris@wjmaggos@mmasnick.bsky.social except BlueSky owns the relays and controls what you can and can't see and it's financially influenced by it's investors.
@volkris@wjmaggos@mmasnick.bsky.social except BlueSky owns the relays and controls what you can and can't see and it's financially influenced by it's investors.
@wjmaggos except #ActivityPub DOESN'T give the people total say over what stories go viral.
We see so much consternation over instance owners censoring what people can see, and that's one of the huge criticisms of this platform that needs to be emphasized.
YES, people can shut down hashtags and links here, and I think that's problematic.
We can't address it by denying that it exists, though.
#Bluesky doesn't just retain that resistance to being shut down. With its relays it does a better job of having the features you're promoting here.
BlueSky comes much closer to giving the people total control over what stories go viral. #Fediverse falls short, empowering instances over people.
This week's news: - massive growth for @pixelfed, growing from 20k active users last month to almost 200k active users currently. - @nodebb has officially launched their #activitypub integration - Meta will not commit or confirm a timeline for adding account migration to #threads
Thank you to everyone for reading and supporting 100 editions of Last Week in Fediverse!
This week's news: - massive growth for @pixelfed, growing from 20k active users last month to almost 200k active users currently. - @nodebb has officially launched their #activitypub integration - Meta will not commit or confirm a timeline for adding account migration to #threads
Thank you to everyone for reading and supporting 100 editions of Last Week in Fediverse!
I finally got around to financially supporting 404 Media because they are doing great work.
"It is possible to build alternatives to Elon Musk’s X, Mark Zuckerberg’s Instagram, and whatever TikTok will become. It is happening, and it is necessary. A different way is possible, if we build it."
I finally got around to financially supporting 404 Media because they are doing great work.
"It is possible to build alternatives to Elon Musk’s X, Mark Zuckerberg’s Instagram, and whatever TikTok will become. It is happening, and it is necessary. A different way is possible, if we build it."
This week's news: - massive growth for @pixelfed, growing from 20k active users last month to almost 200k active users currently. - @nodebb has officially launched their #activitypub integration - Meta will not commit or confirm a timeline for adding account migration to #threads
Thank you to everyone for reading and supporting 100 editions of Last Week in Fediverse!
This week's news: - massive growth for @pixelfed, growing from 20k active users last month to almost 200k active users currently. - @nodebb has officially launched their #activitypub integration - Meta will not commit or confirm a timeline for adding account migration to #threads
Thank you to everyone for reading and supporting 100 editions of Last Week in Fediverse!
This week's news: - massive growth for @pixelfed, growing from 20k active users last month to almost 200k active users currently. - @nodebb has officially launched their #activitypub integration - Meta will not commit or confirm a timeline for adding account migration to #threads
Thank you to everyone for reading and supporting 100 editions of Last Week in Fediverse!
This week's news: - massive growth for @pixelfed, growing from 20k active users last month to almost 200k active users currently. - @nodebb has officially launched their #activitypub integration - Meta will not commit or confirm a timeline for adding account migration to #threads
Thank you to everyone for reading and supporting 100 editions of Last Week in Fediverse!
This week's news: - massive growth for @pixelfed, growing from 20k active users last month to almost 200k active users currently. - @nodebb has officially launched their #activitypub integration - Meta will not commit or confirm a timeline for adding account migration to #threads
Thank you to everyone for reading and supporting 100 editions of Last Week in Fediverse!
„That said, there is clearly a massive revolution taking place, and a huge amount of value being created. That value is primarily for individuals who are have obstacles of today;s world they may have taken for granted being removed, and new power to granted. But then immediately individuals use that power to make and work in communities oof all scales, from pairs through groups to nation-sized movements.“
«Decentralized Social Media Is the Only Alternative to the Tech Oligarchy
[…] Mastodon’s ActivityPub and Bluesky’s AT.Protocol have provided the base technology layer to make this possible, and have laid important groundwork over the last few years to decorporatize and decentralize the social internet. […]»
I'm critical of Bluesky because their format doesn't decentralize of the effort.
Just attended the #ActivityPub Trust & Safety Taskforce Meeting posted before.
We had to make clear the distinction between power-abusing / anti-competitive safety and what they mean by safety. The chair made clear that Policy will have no role in the new taskforce „We focus on the protocol stuff, not on the Policy stuff“
So, in these dark times, the question arises if we should have another ActivityPub Policy Group Call for a virtual meeting after fosdem?
Wow! The #fediverse compatible and #selfhosted#podcasting platform #castopod has it's own index which will allow you to follow/comment/be alerted to new episodes from right here:)
Find a show, follow and enter your #mastodon or other fedi account and voila you will be alerted every time they post an episode. Thanks to #activitypub you can also interact! #feditips
The Limecast podcasting service is coming along well. I got some fairly decent seed data into the database to show the public podcast index and public podcast homepage.
Hoping to get the final version of the RSS feed ironed out this week and then it is onto supporting some of ActivityPub to let anyone follow podcasts from any fediverse account they have to get new episode posts.
ALT text detailsThe landing page for Limecast that shows 3 cards of podcasts with titles "Flavor Notes", "Mind the Gap", and "The Infinite Reel" with their respective images representing each.
ALT text detailsThe podcast homepage for "Flavor Notes" show a description of the podcast along with the latest episodes with playable audio for each episode.
With this wave of migrations comes more people to complain that Fedi is confusing...
I still don't see how.
Email exists and it's not even as simple. You can't "migrate" emails. So the "lock-in" is permanent, where on Fedi, picking an instance is important, however, you CAN migrate fairly easily.
There's some learned behaviors from other social media platforms that needs to be re-learned like following. Following people is how Fediverse goes around. Follow vigorously and follow often.
You can always unfollow.
It takes time to learn. Be patient and ask. Complaining and saying things are confusing won't do any good...
#NodeBB: "We're not alone in this journey to interoperate with other decentralized services. #Discourse has a working plugin. #Ghost is building out in the open.
It's always been a bit of an informal competition between us, and we always checked in on what the others were doing. The funny thing about #ActivityPub (#TheEqualizer) is that at the end of the day, the overarching goal of seamless communication breaks down any barriers between competing organizations."
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
(1/3) hello everyone, I'm looking for someone to help me build the demo ui for #rdfpub The application already exists and can be operated with simple things. Create and send note, show inbox/outbox, follow an actor. I'm not fit for ui, so it looks terrible ;-) And there is still a lot to do. But there is also a lot to do in the backend and coordination with the community regarding client to server interactions. I can't do that alone.
@LilithElina on Fediverse, only "requested" posts are sent to the instances that requests them, either by having followers on that instance or someone from the instance boosts the post. Also, even if you follow now, the posts won't backfill, you have to copy the link from each post and input it into your instances search bar. Hope that makes sense.👍
Is there a common practice for how to automatically detect the social icon of a fediverse site-link when adding it to a ‘personal links’ section like in GitHub? We’re trying to implement this for #weirdone
The Web has always been social. It's a network people use and communicate with. When I created my first website in the 90s, it had visitors. I didn't know who they were, except for those who sent me email. There has been forums, BBSs, IRC, since the 1980s.
So from the social perspective it does not really matter where your "instance" is, because it's already a part of a huge network. Your "instance" can be a website, a social media platform, or anything of a sort. It's a presence online.
The ActivityPub protocol that Mastodon, WordPress, Pixelfed and many other platforms online use, actually has endpoints called "inbox" and "outbox". The logic is very similar to email, but more real time.
So for those who criticize Mastodon or Fediverse as "difficult" or something that has no "reach" I want to say that any form of communication online (be it a normal website or Mastodon or whatever) has all the reach potential in the world. You just need to make yourself heard. We're too used to corporate platforms, money making machines and algorithms to do the work for us. It distorts the whole picture.
Centralized platforms have no future, but the social web is eternal.
ALT text detailsW3C's graph of the ActivityPub protocol:
- actor reads incoming messages
- send messages to actor (federation!)
GET
INBOX
POST
REST OF THE WORLD
POST
OUTBOX
GET
actor sends
messages / posts content
outside world can read messages from actor
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.
I joined the Fediverse on May 30, 2023, and throughout my time on the Fedi, I have always believed in transparency. I even published my follow and block list, regularly on GitLab.
Tomorrow, January 20, 2025, Donald Trump will be President, and the future is uncertain. To prevent anyone from possibly becoming a target, I have switched my follow and followers to private. I would suggest others to do the same.
I joined the Fediverse on May 30, 2023, and throughout my time on the Fedi, I have always believed in transparency. I even published my follow and block list, regularly on GitLab.
Tomorrow, January 20, 2025, Donald Trump will be President, and the future is uncertain. To prevent anyone from possibly becoming a target, I have switched my follow and followers to private. I would suggest others to do the same.
It's been awhile so I figured I'd do an updated #Introduction post:
Hi, I'm BeAware, sometimes I abbreviate it, BA. I am VERY passionate about decentralized systems like #ActivityPub and #Nostr and tend to discuss these topics at length. Especially the nuances of each and try to keep up with all the things regarding them.
I have #ADHD and #Hydrocephalus, which effects various aspects of my day to day life and how I think. I am also on disability because of it.
I am also very #AI-positive because it helps me with every day life. With my brain disorders, I don't think the same way others do, so AI helps me with describing things accurately and to make sure I get my point across in the way I mean to. I also tend to post #AIart from time to time to realize my creativity.
I'm a #Gamer that primarily plays PC games or games that are Cross Platform. Generally I enjoy #MMORPG, #SurvivalGames and such where I can just "zone out" and vibe without much stress.
Sometimes you'll see me discuss #Technology news as well.
If these seem to be within your interests, feel free to follow and if you have similar interests laid out in your bio, chances are good that ill follow back.
I've been here for a year and this is, by far, my favorite social media platform I've ever been on.
Thank for reading and may you be as federated as you wish!
(1/3) hello everyone, I'm looking for someone to help me build the demo ui for #rdfpub The application already exists and can be operated with simple things. Create and send note, show inbox/outbox, follow an actor. I'm not fit for ui, so it looks terrible ;-) And there is still a lot to do. But there is also a lot to do in the backend and coordination with the community regarding client to server interactions. I can't do that alone.
One of the hurdles for new fediverse users is historic discoverability of content. For example, if we view someone's profile from a remote instance, we only see the posts dating back to the first federation with our home instance. If you are on a large instance this might not be a big deal. It is for smaller instances like mine though.
The Web has always been social. It's a network people use and communicate with. When I created my first website in the 90s, it had visitors. I didn't know who they were, except for those who sent me email. There has been forums, BBSs, IRC, since the 1980s.
So from the social perspective it does not really matter where your "instance" is, because it's already a part of a huge network. Your "instance" can be a website, a social media platform, or anything of a sort. It's a presence online.
The ActivityPub protocol that Mastodon, WordPress, Pixelfed and many other platforms online use, actually has endpoints called "inbox" and "outbox". The logic is very similar to email, but more real time.
So for those who criticize Mastodon or Fediverse as "difficult" or something that has no "reach" I want to say that any form of communication online (be it a normal website or Mastodon or whatever) has all the reach potential in the world. You just need to make yourself heard. We're too used to corporate platforms, money making machines and algorithms to do the work for us. It distorts the whole picture.
Centralized platforms have no future, but the social web is eternal.
ALT text detailsW3C's graph of the ActivityPub protocol:
- actor reads incoming messages
- send messages to actor (federation!)
GET
INBOX
POST
REST OF THE WORLD
POST
OUTBOX
GET
actor sends
messages / posts content
outside world can read messages from actor
The Web has always been social. It's a network people use and communicate with. When I created my first website in the 90s, it had visitors. I didn't know who they were, except for those who sent me email. There has been forums, BBSs, IRC, since the 1980s.
So from the social perspective it does not really matter where your "instance" is, because it's already a part of a huge network. Your "instance" can be a website, a social media platform, or anything of a sort. It's a presence online.
The ActivityPub protocol that Mastodon, WordPress, Pixelfed and many other platforms online use, actually has endpoints called "inbox" and "outbox". The logic is very similar to email, but more real time.
So for those who criticize Mastodon or Fediverse as "difficult" or something that has no "reach" I want to say that any form of communication online (be it a normal website or Mastodon or whatever) has all the reach potential in the world. You just need to make yourself heard. We're too used to corporate platforms, money making machines and algorithms to do the work for us. It distorts the whole picture.
Centralized platforms have no future, but the social web is eternal.
ALT text detailsW3C's graph of the ActivityPub protocol:
- actor reads incoming messages
- send messages to actor (federation!)
GET
INBOX
POST
REST OF THE WORLD
POST
OUTBOX
GET
actor sends
messages / posts content
outside world can read messages from actor
One of the hurdles for new fediverse users is historic discoverability of content. For example, if we view someone's profile from a remote instance, we only see the posts dating back to the first federation with our home instance. If you are on a large instance this might not be a big deal. It is for smaller instances like mine though.
Is anyone working on #P2P server software compatible with #ActivityPub? It seems natural to be able to donate network resources instead of cash, and would make services even more difficult to censor.
Is anyone working on #P2P server software compatible with #ActivityPub? It seems natural to be able to donate network resources instead of cash, and would make services even more difficult to censor.
So ... The #Fediverse. I get that the Fediverse is not *one* thing but many things that use #ActivityPub. Much as the internet is not *one* thing but many things that use TCP/IP.
Mastodon is still, I think, the largest fraction of the Fediverse but as a Mastodon user, what powers does ActivityPub grant me? Do I magically have a "free account" on a Pixelfed instance? (yes, pretty much everything in the Fediverse is free, but you know what I mean). Does that other service "know" me?
So ... The #Fediverse. I get that the Fediverse is not *one* thing but many things that use #ActivityPub. Much as the internet is not *one* thing but many things that use TCP/IP.
Mastodon is still, I think, the largest fraction of the Fediverse but as a Mastodon user, what powers does ActivityPub grant me? Do I magically have a "free account" on a Pixelfed instance? (yes, pretty much everything in the Fediverse is free, but you know what I mean). Does that other service "know" me?
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
In which I talk about how state regulations are affecting the development of ActivityPub and the fediverse, and how trying to make a TOS for Loops by using an online service resulted in a surveillance capitalist-friendly document.
In which I talk about how state regulations are affecting the development of ActivityPub and the fediverse, and how trying to make a TOS for Loops by using an online service resulted in a surveillance capitalist-friendly document.
You need to know that the changes in your moderation policy announced by your leadership is putting your relationship with the #Fediverse in serious jeopardy.
From the moment #Meta announced #Threads there was strong debate within the community on whether you could be a trusted actor in this space. I, against my own initial gut reaction (having deleted my FB profile in 2020 and never joined Insta due to family that have been harmed by it), decided to give the benefit of the doubt solely because I thought Thread’s entrance into the #ActivityPub universe gave that effort instant credibility with people and entities that would never have considered it important before.
But now, on the eve of the ascension and return of the most dangerous President the United States has ever produced, at the height of a rise in regressive action and policy that puts people in direct danger, your company has chosen to double down.
No amount of earnest sounding words or tented, pensive, hands can mask what is going on here.
And the majority of the Fediverse is seeing it. Threads.net will reach blocking thresholds by @iftas soon, if it hasn’t already.
You are decidedly part of the problem, and always have been.
And that is why today, after giving you and the handful of people on Threads that I like and follow a chance ( @jakebroe@threads.net @gtconway3@threads.net @karaswisher@threads.net @stonekettle@threads.net @realjuddlegum@threads.net among others) I have to again cut away from Meta not because of them, but because of leaders like yourself who refuse to put the well being of all people ahead of political and ideological ambition.
I believe you and I agree on one thing, the #OpenSocialWeb is the future because it *is* freedom and that will always draw people away from oppressive spaces.
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".
You need to know that the changes in your moderation policy announced by your leadership is putting your relationship with the #Fediverse in serious jeopardy.
From the moment #Meta announced #Threads there was strong debate within the community on whether you could be a trusted actor in this space. I, against my own initial gut reaction (having deleted my FB profile in 2020 and never joined Insta due to family that have been harmed by it), decided to give the benefit of the doubt solely because I thought Thread’s entrance into the #ActivityPub universe gave that effort instant credibility with people and entities that would never have considered it important before.
But now, on the eve of the ascension and return of the most dangerous President the United States has ever produced, at the height of a rise in regressive action and policy that puts people in direct danger, your company has chosen to double down.
No amount of earnest sounding words or tented, pensive, hands can mask what is going on here.
And the majority of the Fediverse is seeing it. Threads.net will reach blocking thresholds by @iftas soon, if it hasn’t already.
You are decidedly part of the problem, and always have been.
And that is why today, after giving you and the handful of people on Threads that I like and follow a chance ( @jakebroe@threads.net @gtconway3@threads.net @karaswisher@threads.net @stonekettle@threads.net @realjuddlegum@threads.net among others) I have to again cut away from Meta not because of them, but because of leaders like yourself who refuse to put the well being of all people ahead of political and ideological ambition.
I believe you and I agree on one thing, the #OpenSocialWeb is the future because it *is* freedom and that will always draw people away from oppressive spaces.
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".
My good friend @manualdousuario has a solid case for his rant over #FreeOurFeeds. But given the names involved, I'd slap a question mark on his headline: "$30 million to reinvent the wheel"? That's because I see opportunity for innovative advancements at the protocol level, even dealing with emerging public payment systems like #PIX. The wheel is done: #ActivityPub. I am open to hear what those good people can do to help the #opensocial path forward.
My good friend @manualdousuario has a solid case for his rant over #FreeOurFeeds. But given the names involved, I'd slap a question mark on his headline: "$30 million to reinvent the wheel"? That's because I see opportunity for innovative advancements at the protocol level, even dealing with emerging public payment systems like #PIX. The wheel is done: #ActivityPub. I am open to hear what those good people can do to help the #opensocial path forward.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Introducing #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.
Hey, I’ve been wondering this. How come you can sign in with a #Pixelfed account using a Mastodon app, and not vice versa? Design choice on the Pixelfed app? Or is there a some technical reason?
It’s just the apps themselves deciding whether to support multiple #ActivityPub projects, is it?
I dream of the day when I'm not forced to choose between decentralization and a good user (or developer) experience. #ActivityPub (P.S. if there are replies to this post, you probably won't see most of them on your instance.)
I am trying to figure out where I go to find open issues and discussions about the features for "quote posts" in the ActivityPub spec. Do they have... a git repo where they discuss it? (Is they in this case W3C?)
Is there a doc somewhere? I can't seem to find where they track these discussions publicly, but mastodon said the feature was already proposed upstream in ActivityPub, but that it was still in the works in discussions.
I want to read the discussions to figure out where in the process of implementing the feature we are. Are we still just discussing it? Is there a proposal request somewhere?
I am trying to figure out where I go to find open issues and discussions about the features for "quote posts" in the ActivityPub spec. Do they have... a git repo where they discuss it? (Is they in this case W3C?)
Is there a doc somewhere? I can't seem to find where they track these discussions publicly, but mastodon said the feature was already proposed upstream in ActivityPub, but that it was still in the works in discussions.
I want to read the discussions to figure out where in the process of implementing the feature we are. Are we still just discussing it? Is there a proposal request somewhere?
At least 15,000 people fully, without limits, irrevocably, licensed their personal information, public image, name and all data that reached loops.video infrastructure... to @dansup@mastodon.social 's loops.video platform.
Had they known they're entirely losing control of everything, would they be using the platform?
In short: if you really intend to federate, respect your users and their data.
Implementing federation while keeping these terms is a severe breach of trust, and would poison the entirety of the network in an way which will cripple ActivityPub, and undermine the very foundation of what AP stands for with regard to privacy, data ownership, and control over what we post to the network.
@jillrhudy Hey Jill, thanks for the input. First, can you please explain how that "null." works. Second - now it gets more complicated - I federate my content with the #ActivityPub-plugin. Captions are not federated on Mastodon, but alt texts are, so I would assume to be accessible in both worlds, screen readers read content on my website twice. And yes, since I started this WordPress version of my website in 2006, I am still not fully accessible.Trying. #wordpress#accessibility#alttext
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
In short: if you really intend to federate, respect your users and their data.
Implementing federation while keeping these terms is a severe breach of trust, and would poison the entirety of the network in an way which will cripple ActivityPub, and undermine the very foundation of what AP stands for with regard to privacy, data ownership, and control over what we post to the network.
Is there something like an ActivityPub composer? A fediverse server and/or client that does not specialise on any kind of media or paradigm, but allows you to view and create any kind of activity?
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Is there something like an ActivityPub composer? A fediverse server and/or client that does not specialise on any kind of media or paradigm, but allows you to view and create any kind of activity?
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
"The modern-day fediverse is an impressive achievement, but it also leaves many issues to be addressed. Servers can go down, content can disappear and users can lose access to their identity. Authorization mechanisms are under-specified and rich interactions are fairly limited. This talk, by the two primary editors of the ActivityPub specification, explores where we think the fediverse should go ..."
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
"We're at the beginning of a significant shift in the history of the internet in more ways than one, and we're feeling both optimistic and excited for the future. After two decades of restrictive networks and centralized platforms, there are a lot of very motivated people focused on one thing:
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @fedify foundation.
Is there a small/minimal #ActivityPub server that supports “post-only” accounts?
My use-case is, I’ve got a local club where I’d like to publish meeting announcements, but I’d prefer if it came from the club’s domain, and I don’t want or need a “full” server, just something that will serve posts to subs
I've signed up for #pixelfed. I'll have to figure out how to integrate posts over there with my Mastodon account. I still don't really know how to share my #Bookwyrm stuff over here, either. There's some mysterious #activitypub magic I haven't learned yet...
Wow! The #fediverse compatible and #selfhosted#podcasting platform #castopod has it's own index which will allow you to follow/comment/be alerted to new episodes from right here:)
Find a show, follow and enter your #mastodon or other fedi account and voila you will be alerted every time they post an episode. Thanks to #activitypub you can also interact! #feditips
Is there a small/minimal #ActivityPub server that supports “post-only” accounts?
My use-case is, I’ve got a local club where I’d like to publish meeting announcements, but I’d prefer if it came from the club’s domain, and I don’t want or need a “full” server, just something that will serve posts to subs
If ActivityPub and ActivityStreams used acct-URI rather than HTTP-URL to identify users, then there would less problems with switching between different Fediverse software.
(Different Fediverse software represent users with different style HTTP-URLs — which creates the problem.)
Tras una primera inmersión en el #fediverso, estoy pensando en montarme una instancia propia para uso personal (tengo un pequeño servidor Debian en casa). Estoy buscando un servidor compatible con #activitypub ligero y a ser posible multidominio. He descartado #Mastodon por los requerimientos, y ando dudando entre #pleroma , #takahẽ , #GoToSocial o #friendica
Busco algo con una interfaz agradable, sin demasiadas dependencias a cosas raras (estoy acostumbrado a un entorno #LAMP), y que tenga un proyecto mínimamente sólido y con proyección de futuro (soy un señor mayor y estoy en esa fase de no tener que probarlo todo 🙂 ) Ahora mismo tengo cuenta en Mastodon, Pixelfed y Leemy.
Hum, are we the only cross-platform messenger project present in 15+ app stores that primarily announces on, and interacts with, the Fediverse while others use X and maybe Bluesky? If you know of others please mention them in the replies :)
In any case, we are pretty happy here, as we are finding meaningful interactions, and organically evolving interest and collaboration with other people and projects. Probably it helps that #email shares several traits with #ActivityPub protocols? Cheers.
Wow! The #fediverse compatible and #selfhosted#podcasting platform #castopod has it's own index which will allow you to follow/comment/be alerted to new episodes from right here:)
Find a show, follow and enter your #mastodon or other fedi account and voila you will be alerted every time they post an episode. Thanks to #activitypub you can also interact! #feditips
ALT text detailsa screenshot of a photo I posted on Pixelfed. The username reads: Elena Rossini on Pixelfed and the caption states: from my archives: at the top of Burj Khalifa.
A photo of me from December 2014 from the top of the Burj Khalifa observation deck in Dubai, UAE.
It's one of my favorite pics and it was shot by a friend using my iPhone 6 (incredible quality all things considered!)
Then there is the photo of the silhouette of a woman looking out in front of her at the Dubai landscape. You can see tall large windowpanes and the whole photo is bathed in blue hues
Key Points: ➡️ BotKit enables the creation of standalone ActivityPub bots, free from platform constraints. ➡️ It is user-friendly and written in TypeScript, ensuring type safety. ➡️ BotKit is easy to deploy with minimal dependencies on various virtual servers. ➡️ Powered by #Fedify, a robust #ActivityPub framework.
We make good use of Mastodon’s interoperability with WordPress. When we recently moved our Vivaldi Tips (@tips) blog from vivaldi.net to vivaldi.com to start translating the tips, we noticed that things were a little off on the Mastodon side. Luckily we have the amazing @thomasp in our team, who ironed out every single issue we found.
One of the problems we had was the ActivityPub plugin not detecting the language tags our translation plugin (WPML) added to the posts on WordPress. Language tags allow people on Mastodon to subscribe to posts only in the languages they can read and use the translation feature, so this was an important issue for us to solve. Read about the solution Thomas came up with in his blog: https://thomasp.vivaldi.net/2025/01/14/combining-wpml-activitypub/.
Metan toimintaan kyllästyneet käyttäjät ovat löytäneet Instagramin korvaajaksi hajautetun Pixelfedin
Nyt Pixelfedille julkaistiin myös virallinen kännykkäsovellus (Android ja iPhone) ja sovellus nousi sovelluskauppojen ykköseksi mm. Yhdysvalloissa ja Ruotsissa.
if i search for a user in #activitypub .academy the first time, #mastodon is doing - a webfinger request - read outbox-collection request - read following-collection request - read followers-collection request not bad. what do they expect wenn reading the outbox? the objects that was adressed to as_public?
Key Points: ➡️ BotKit enables the creation of standalone ActivityPub bots, free from platform constraints. ➡️ It is user-friendly and written in TypeScript, ensuring type safety. ➡️ BotKit is easy to deploy with minimal dependencies on various virtual servers. ➡️ Powered by #Fedify, a robust #ActivityPub framework.
The way Fediverse is, makes it very easy to stalk and harass people.
I've only had it happen once or twice, but it's still unsettling to see people I've blocked LONG ago, show up again just cause they made another account on another instance...😒
We make good use of Mastodon’s interoperability with WordPress. When we recently moved our Vivaldi Tips (@tips) blog from vivaldi.net to vivaldi.com to start translating the tips, we noticed that things were a little off on the Mastodon side. Luckily we have the amazing @thomasp in our team, who ironed out every single issue we found.
One of the problems we had was the ActivityPub plugin not detecting the language tags our translation plugin (WPML) added to the posts on WordPress. Language tags allow people on Mastodon to subscribe to posts only in the languages they can read and use the translation feature, so this was an important issue for us to solve. Read about the solution Thomas came up with in his blog: https://thomasp.vivaldi.net/2025/01/14/combining-wpml-activitypub/.
Key Points: ➡️ BotKit enables the creation of standalone ActivityPub bots, free from platform constraints. ➡️ It is user-friendly and written in TypeScript, ensuring type safety. ➡️ BotKit is easy to deploy with minimal dependencies on various virtual servers. ➡️ Powered by #Fedify, a robust #ActivityPub framework.
J'ai mis du temps, mais je me suis (enfin !) remis à mon Guide d’utilisation de Mastodon en français... Voici le 3ème chapitre de la 7ème partie : l'utilisation des Hashtags dans Mastodon, ainsi qu'une présentation de la fonctionnalité "groupes".
Fragt man sich, was die Motivation ist, in das für diese Zwecke weniger geeignete #ATproto zu investieren und nicht z.B. in so etwas Etabliertes wie #ActivityPub.
Esteemed #Fediverse we will inform the EU Commission about #Facebook censoring links to #pixelfed. When Musk did the same with mastodon links, we provided the EU with a huge example set, so if you are on Facebook/Instagram or any and links to fedi endpoints are censored, please provide us with a screenshot, link address and the reason as screenshot.
Esteemed #Fediverse we will inform the EU Commission about #Facebook censoring links to #pixelfed. When Musk did the same with mastodon links, we provided the EU with a huge example set, so if you are on Facebook/Instagram or any and links to fedi endpoints are censored, please provide us with a screenshot, link address and the reason as screenshot.
On while the topic of Sharkey, for a development that has nothing to hide, they're doing a lot to hide sh-t.
1st, they recently changed account in the past 24 hours. I suspect because people kept finding post and references they hadn't yet deleted (I still have some links, read on)
They seem to have removed the post thanking everyone and detailing how many people contributed. They have also removed the post asking for more money, so they could form an LLC (not a non-profit, but a business). And they removed the post, where they attempt to troll me in public.
They may be deleting some things via the database, because a few of their old post, remove details and replace it with "nulled" (see screen). I'm guessing someone performed a SQL search and replace.
But I did something no one expected. I made every post I ever made from May 30, 2023, through December 21, 2024, publically downloadable into the public domain, including my interactions with Sharkey. https://kitty.social/notes/a21e0nsgbe9z2mj8
@Gargron I am truly grateful for all the work you've done to increase the usage of the #ActivityPub protocol.
There is no arguing that without your leadership and your dedication, we would not be where we are today. As a society, I believe it is paramount that we take control of the #PublicSquare back to the people in a #Decentralized manner, and #Mastodon has been a MASSIVE push in that direction.
Thank you Eugen, I'm glad you exist and I appreciate your work 😃
I feel that every time I login to Fedi these days, there's yet another scheme to get people to dump money into a project for "the growth of the Fediverse" yet we have yet to see any results and the things they're doing seem shady as fuck to me. Yet people keep parading around like it's the best thing ever.
SWF forms and is funded by major companies like Meta and Auttomatic. Not sure how that could be a good thing. That means SWF will be financially influenced by these companies and there's nothing anybody can do to change that.
Now, Mastodon is being given to a new non-profit. They say this is to "give the power back to the people" but obviously giving ownership to a non-profit doesn't do that...it gives ownership to the non-profit and allows them to hide your donations via shady legalities to enrich themselves.
Money hungry fucks ruin everything. Change my mind.
With any luck, we now have weekly activity reports from Github to the public-swicg mailing list, as to keep everyone in the loop on the activity on ActivityPub and ActivityStreams:
There's some sort of delay happening with the test runs of this email, but hopefully they'll show up soon. This should help increase visibility into what's happening.
With any luck, we now have weekly activity reports from Github to the public-swicg mailing list, as to keep everyone in the loop on the activity on ActivityPub and ActivityStreams:
There's some sort of delay happening with the test runs of this email, but hopefully they'll show up soon. This should help increase visibility into what's happening.
With any luck, we now have weekly activity reports from Github to the public-swicg mailing list, as to keep everyone in the loop on the activity on ActivityPub and ActivityStreams:
There's some sort of delay happening with the test runs of this email, but hopefully they'll show up soon. This should help increase visibility into what's happening.
Save Social Media From Billionaire Capture: freeourfeeds.com?
"But it will take independent funding and governance to turn Bluesky’s underlying tech—the AT Protocol—into something more powerful than a single app."
I see the executive director and president of Mozilla Foundation as their technical advisors, no surprise. But it surprises me to have the executive director of the Social Web Foundation (@swf) there.
J'ai mis du temps, mais je me suis (enfin !) remis à mon Guide d’utilisation de Mastodon en français... Voici le 3ème chapitre de la 7ème partie : l'utilisation des Hashtags dans Mastodon, ainsi qu'une présentation de la fonctionnalité "groupes".
The https://freeourfeeds.com/ FAQ is missing one question that's actually being asked frequently: How does this approach relate to existing nonprofit, open source, standards-based efforts centered around #ActivityPub?
@elipariser@wearenew_public Can you fix that? It's a bit tone-deaf to promote this effort here without speaking to how it intersects.
I created an #ActivityPub library for #PHP which uses modern PHP 8.4 features. Each input is fully validated and fully typed, there's support for Signature header validating / generating and some other sweet stuff.
Note that it's currently in alpha, mainly because it's not tested yet and there are most likely many bugs, but tests are coming soon(ish).
Random fact: 3 bug reports for #PhpStorm were created in the process of creating the package.
"We're at the beginning of a significant shift in the history of the internet in more ways than one, and we're feeling both optimistic and excited for the future. After two decades of restrictive networks and centralized platforms, there are a lot of very motivated people focused on one thing:
"We're at the beginning of a significant shift in the history of the internet in more ways than one, and we're feeling both optimistic and excited for the future. After two decades of restrictive networks and centralized platforms, there are a lot of very motivated people focused on one thing:
I created an #ActivityPub library for #PHP which uses modern PHP 8.4 features. Each input is fully validated and fully typed, there's support for Signature header validating / generating and some other sweet stuff.
Note that it's currently in alpha, mainly because it's not tested yet and there are most likely many bugs, but tests are coming soon(ish).
Random fact: 3 bug reports for #PhpStorm were created in the process of creating the package.
It's a painful realization that I come to that no matter how much effort I put into making my #ActivityPub server be fast it's still going to suck if in order to build a meaningful page for a user the client needs to do many requests.
So the #brutalinks link aggregator now makes use of asynchronous collection fetching and then content rendering is being done from local storage.
This decreased the loading times to probably less than half of what they were before.
However I still need to find a good model for aggregating and balancing all the sequential loads with an eventual asynchronous sequential sending of activities.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
In which I talk about my new monitoring of Threads's fediverse blocklist, the @cwebber and Bryan Newbold debate, and the trust and safety work of @thisismissem
In which I talk about my new monitoring of Threads's fediverse blocklist, the @cwebber and Bryan Newbold debate, and the trust and safety work of @thisismissem
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
With @bsky.brid.gy, @Flipboard, and @threads posts along with all of the other posts from @Mastodon and the other platforms that support #ActivityPub, I’m having zero issues keeping up with It’s nice to finally have my social media world (de)centralized and 100% in my control and using my own domain.
With @bsky.brid.gy, @Flipboard, and @threads posts along with all of the other posts from @Mastodon and the other platforms that support #ActivityPub, I’m having zero issues keeping up with It’s nice to finally have my social media world (de)centralized and 100% in my control and using my own domain.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
#activitypub thonk: delivering to a Collection is nonsensical because a Collection could be an actor. but so can a Group
basically you have implicit behavior "the Collection needs to be expanded to its items which are assumed to all be actors" just like a Group might expand to all its members (except the assumption there is a bit stronger, you can generally expect a Group's members to all be individuals?)
whereas something like WAC makes a distinction between agent, agentGroup, agentClass
This instance will be operated as a paid extension of Weird, costing $10/yr ($20/yr after beta).
All member subscriptions will go entirely to the AP instance hosters, which should be a team of at least 2-3 sysadmins & moderators tending to the instance part-time. This is expected to be a fairly low-volume instance since all members are paid (to begin with).
Check out all episodes of DotSocial here, which include conversations with open social web leaders like @johnonolan, @jay.bsky.team, @kissane and more.
The good thing with federation is that I as an individual can make decisions about who I federate with - be it an individual or an entire instance. There's even some middle ground to customize your choice (silence vs block).
And now, the "federated islands" concept is kicking up, which is really cool. We have many choices - the decision is not mandated for us.
The good thing with federation is that I as an individual can make decisions about who I federate with - be it an individual or an entire instance. There's even some middle ground to customize your choice (silence vs block).
And now, the "federated islands" concept is kicking up, which is really cool. We have many choices - the decision is not mandated for us.
The good thing with federation is that I as an individual can make decisions about who I federate with - be it an individual or an entire instance. There's even some middle ground to customize your choice (silence vs block).
And now, the "federated islands" concept is kicking up, which is really cool. We have many choices - the decision is not mandated for us.
After what seems like a thousand years I have started replacing some synchronous client to server #ActivityPub fetch requests with loading the same information from an indexed cache in my link aggregator.
I think I've started the work on inbox/outbox async fetch and indexing around 3-4 months ago, and only now I am able to make proper use of it.
I guess I should have used a real RDBMS instead of reinventing the wheel on every turn. :D
After what seems like a thousand years I have started replacing some synchronous client to server #ActivityPub fetch requests with loading the same information from an indexed cache in my link aggregator.
I think I've started the work on inbox/outbox async fetch and indexing around 3-4 months ago, and only now I am able to make proper use of it.
I guess I should have used a real RDBMS instead of reinventing the wheel on every turn. :D
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra. - End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix. - Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious. - Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial). - Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments. - Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune. - Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform. - Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024. - Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing. - URL handlers. No significant progress. - Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations. - Markets. No significant progress. - Quoting. FEP-e232 is now supported by 8 platforms. - Forge federation. Forgejo implemented federated stars, and the development of other features has started.
I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial. - Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61). - ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar. - End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop. - Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.
#Smithereen updates: - Profile pictures are now photos. There's a new flow for updating your profile picture. After you're done selecting thumbnails, it gets saved into a special album and a "{user} updated their profile picture" post is created. - Photo tags are finished and federate between Smithereen servers. You can tag just names, but if you pick another user, they have to approve the tag. - You can rotate photos after upload. Including profile pictures!
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra. - End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix. - Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious. - Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial). - Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments. - Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune. - Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform. - Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024. - Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing. - URL handlers. No significant progress. - Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations. - Markets. No significant progress. - Quoting. FEP-e232 is now supported by 8 platforms. - Forge federation. Forgejo implemented federated stars, and the development of other features has started.
I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial. - Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61). - ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar. - End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop. - Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.
My #fediverse server is running the #Sharkey software platform, a fork of #Misskey, to post messages via the #activitypub protocol. You can see my post, even though you may use another platform to participate in the fediverse, like #Mastodon or #Pleroma. So, without using the same platform, we can share messages because we use the same protocol. We have to move from platform-based networking to protocol-based networking. Get rid of the lock-ins, be self-sovereign!
The last "big" code thing I need to get done before the alpha test of my current @fedify project is the task queue - make sure routine data updates happen, consider individual importance and urgency, respect external API rate limits, etc.
But that's super intimidating so I'm currently procrastinating by making it a cute lil home page instead. 🙃
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra. - End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix. - Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious. - Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial). - Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments. - Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune. - Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform. - Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024. - Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing. - URL handlers. No significant progress. - Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations. - Markets. No significant progress. - Quoting. FEP-e232 is now supported by 8 platforms. - Forge federation. Forgejo implemented federated stars, and the development of other features has started.
I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial. - Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61). - ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar. - End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop. - Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.
The last "big" code thing I need to get done before the alpha test of my current @fedify project is the task queue - make sure routine data updates happen, consider individual importance and urgency, respect external API rate limits, etc.
But that's super intimidating so I'm currently procrastinating by making it a cute lil home page instead. 🙃
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra. - End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix. - Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious. - Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial). - Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments. - Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune. - Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform. - Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024. - Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing. - URL handlers. No significant progress. - Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations. - Markets. No significant progress. - Quoting. FEP-e232 is now supported by 8 platforms. - Forge federation. Forgejo implemented federated stars, and the development of other features has started.
I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial. - Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61). - ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar. - End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop. - Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.
The last "big" code thing I need to get done before the alpha test of my current @fedify project is the task queue - make sure routine data updates happen, consider individual importance and urgency, respect external API rate limits, etc.
But that's super intimidating so I'm currently procrastinating by making it a cute lil home page instead. 🙃
The last "big" code thing I need to get done before the alpha test of my current @fedify project is the task queue - make sure routine data updates happen, consider individual importance and urgency, respect external API rate limits, etc.
But that's super intimidating so I'm currently procrastinating by making it a cute lil home page instead. 🙃
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra. - End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix. - Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious. - Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial). - Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments. - Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune. - Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform. - Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024. - Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing. - URL handlers. No significant progress. - Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations. - Markets. No significant progress. - Quoting. FEP-e232 is now supported by 8 platforms. - Forge federation. Forgejo implemented federated stars, and the development of other features has started.
I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial. - Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61). - ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar. - End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop. - Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra. - End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix. - Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious. - Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial). - Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments. - Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune. - Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform. - Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024. - Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing. - URL handlers. No significant progress. - Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations. - Markets. No significant progress. - Quoting. FEP-e232 is now supported by 8 platforms. - Forge federation. Forgejo implemented federated stars, and the development of other features has started.
I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial. - Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61). - ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar. - End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop. - Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra. - End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix. - Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious. - Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial). - Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments. - Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune. - Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform. - Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024. - Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing. - URL handlers. No significant progress. - Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations. - Markets. No significant progress. - Quoting. FEP-e232 is now supported by 8 platforms. - Forge federation. Forgejo implemented federated stars, and the development of other features has started.
I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial. - Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61). - ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar. - End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop. - Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra. - End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix. - Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious. - Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial). - Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments. - Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune. - Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform. - Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024. - Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing. - URL handlers. No significant progress. - Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations. - Markets. No significant progress. - Quoting. FEP-e232 is now supported by 8 platforms. - Forge federation. Forgejo implemented federated stars, and the development of other features has started.
I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial. - Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61). - ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar. - End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop. - Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra. - End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix. - Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious. - Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial). - Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments. - Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune. - Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform. - Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024. - Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing. - URL handlers. No significant progress. - Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations. - Markets. No significant progress. - Quoting. FEP-e232 is now supported by 8 platforms. - Forge federation. Forgejo implemented federated stars, and the development of other features has started.
I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial. - Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61). - ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar. - End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop. - Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra. - End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix. - Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious. - Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial). - Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments. - Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune. - Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform. - Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024. - Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing. - URL handlers. No significant progress. - Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations. - Markets. No significant progress. - Quoting. FEP-e232 is now supported by 8 platforms. - Forge federation. Forgejo implemented federated stars, and the development of other features has started.
I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial. - Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61). - ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar. - End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop. - Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.
- Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra. - End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix. - Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious. - Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial). - Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments. - Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune. - Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform. - Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024. - Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing. - URL handlers. No significant progress. - Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations. - Markets. No significant progress. - Quoting. FEP-e232 is now supported by 8 platforms. - Forge federation. Forgejo implemented federated stars, and the development of other features has started.
I think the work on these problems should continue in 2025, especially in the following key areas:
- Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial. - Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61). - ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar. - End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop. - Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.
The last "big" code thing I need to get done before the alpha test of my current @fedify project is the task queue - make sure routine data updates happen, consider individual importance and urgency, respect external API rate limits, etc.
But that's super intimidating so I'm currently procrastinating by making it a cute lil home page instead. 🙃
Flipboard is embracing the Fediverse to become a "Fediverse browser." This shift aims to provide users with more content and creators with greater independence from major social media platforms. By integrating ActivityPub, Flipboard intends to enhance content discovery and curation, offering a more open and equitable social media experience.
I’ve just stumbled into another annoyance in the #Fediverse architecture: thread continuity is broken when an item in the chain is broken.
Suppose there is this thread of posts/replies, made by three users, and I wrote the last reply (C).
A → B → C
Suppose I wanted to find post A. Sadly, I don’t remember what post A contained (or A’s post is not searchable), but I do remember what I wrote in response in C. I look for my reply and find it, but much to my dismay, the poster of B has deleted their post. So now I have:
A → ✵ → C
Since B is missing, I can no longer find A.
I was under the assumption that ActivityPub provides for a tombstone in place of B, which allows the reply chain to continue to be traversed, but I don’t think that’s the case—the tombstone contains no reference to A at all.
This is particularly annoying because the longer the thread, the more likely this is to happen. I wonder if anyone is already looking at this issue?
What is the motivation for encouraging LitePub implementors to "supply a locally hosted version of the LitePub JSON-LD Context"?
Is it just for people using full-out JSON-LD parsers?
Won't this create problems for people using parsers that do NOT go download and interpret context-URIs? And instead just hard-code the vocabulary in their code?
ALT text detailsLitePub for ActivityPub Implementors
JSON-LD context
LitePub implementations are not required to use @context properties on their messages. A conformant ActivityPub implementation is required to process these messages with an injected @context of "https://www.w3.org/ns/activitystreams" as described in the ActivityStreams 2.0 Core Specification
However, the LitePub Core Vocabulary differs from the ActivityStreams 2.0 Vocabulary. It is suggested that LitePub implementations supply a locally hosted version of the LitePub JSON-LD Context as their @context. It may be useful to inject a local copy of the LitePub JSON-LD Context instead of the default ActivityStreams 2.0 context when a message is received without a @context as it defines the full LitePub Core Vocabulary in a way that is useful to JSON-LD processors.
Signatures
LitePub implementations MUST use HTTP Signatures to verify the authenticity of messages being delivered to or from peering nodes. The details surrounding the way HTTP Signatures are implemented in LitePub are discussed on the Overview page.
Flipboard is embracing the Fediverse to become a "Fediverse browser." This shift aims to provide users with more content and creators with greater independence from major social media platforms. By integrating ActivityPub, Flipboard intends to enhance content discovery and curation, offering a more open and equitable social media experience.
Was für eine geniale Idee: der Wetterbericht und die Vorhersage für eure Stadt (oder andere) im Fediverse! https://de.fedimeteo.com — Ihr könnt einfach einer Stadt mit einem Fediverse-Client folgen und bekommt das Wetter in Eure Timeline. @stefano verdient ein dickes „Dankeschön“ IMHO. #Fediverse#ActivityPub#Weather#FediMeteo
The number 1 thing that attracted me to GtS is its granular reply controls.
For example, this is an unlisted post and I selected in settings that only people I follow and my followers can reply to the post. Ditto for boosting it. (FYI on the other hand, I selected that anyone can reply to my public posts).
The dropdown menu for replies to unlisted posts gives you the options of: - anyone [can reply] - anyone (approval required) - just me - something else (the granular controls I mentioned before)
Isn't this amazing?
For the purposes of this test, if you follow my account or I follow you, can you try to reply?
Thanks!
Wishing you all a lovely day
ALT text detailsa screenshot of the GoToSocial settings page for replies. The tab Unlisted Posts is selected and below it you can read:
- Like: who can like an unlisted post? Anyone
- Reply: mentioned accounts can always reply
Who else can reply to an unlisted post? Something else.
My followers: always
Accounts I follow: always
Everyone else: no
#Smithereen updates: - Profile pictures are now photos. There's a new flow for updating your profile picture. After you're done selecting thumbnails, it gets saved into a special album and a "{user} updated their profile picture" post is created. - Photo tags are finished and federate between Smithereen servers. You can tag just names, but if you pick another user, they have to approve the tag. - You can rotate photos after upload. Including profile pictures!
#Smithereen updates: - Profile pictures are now photos. There's a new flow for updating your profile picture. After you're done selecting thumbnails, it gets saved into a special album and a "{user} updated their profile picture" post is created. - Photo tags are finished and federate between Smithereen servers. You can tag just names, but if you pick another user, they have to approve the tag. - You can rotate photos after upload. Including profile pictures!
#Smithereen updates: - Profile pictures are now photos. There's a new flow for updating your profile picture. After you're done selecting thumbnails, it gets saved into a special album and a "{user} updated their profile picture" post is created. - Photo tags are finished and federate between Smithereen servers. You can tag just names, but if you pick another user, they have to approve the tag. - You can rotate photos after upload. Including profile pictures!
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.
4. Spritely Oaken The @spritely Institute, headed up by @cwebber (OG #ActivityPub / #Fediverse cofounder) is working on making the next generation of FOSS, decentralized internet (beyond the web). Oaken is a vision to help make running untrusted code on this new frontier safe, opening up far more possibilities. It doesn't exist yet... but now there's funding to build it!
ALT text detailsPainting of the SPritely Oaken mascot. They look like a small, short piece of oak wood, with small wooden horns like a stag, and a smiling face. They're hold up their hand with balls of purple magic floating above. They're also slightly light by a green light from below further giving a magical feel.
For us, 2024 was a year of building on the social web. ✔️ Expanded federation in the U.S., Brazil, Canada, Germany, and the U.K. ✔️ Enabled following accounts from the social web in the Flipboard app. ✔️ Announced @surf, a new browser for the social web. ✔️ Produced new episodes of Dot Social, the fediverse podcast hosted by @mike
Thanks for being on this journey with us! 🚀
Did you do cool stuff in the fediverse this year? Tell us all about it in the comments, where we'll also link to the Dot Social PeerTube account and our Surf signup page.
Check out all episodes of DotSocial here, which include conversations with open social web leaders like @johnonolan, @jay.bsky.team, @kissane and more.
For us, 2024 was a year of building on the social web. ✔️ Expanded federation in the U.S., Brazil, Canada, Germany, and the U.K. ✔️ Enabled following accounts from the social web in the Flipboard app. ✔️ Announced @surf, a new browser for the social web. ✔️ Produced new episodes of Dot Social, the fediverse podcast hosted by @mike
Thanks for being on this journey with us! 🚀
Did you do cool stuff in the fediverse this year? Tell us all about it in the comments, where we'll also link to the Dot Social PeerTube account and our Surf signup page.
Agency staff that wish to advocate for using the Open Social Web to take better control of social media messaging can use the following high level talking points to begin the conversation:
#ActivityPub is the accepted global Web standard for open social networking. It is published by the World Wide Web Consortium, the non-profit body that oversees Web standards.
currently blasting random thoughts about #ActivityPub to fedi which are important at least to me at the first workday of the shiny Year of the Fediverse.
Do you think this makes sense? Perfectly yes !!! It is exactly the way we use it in redaktor and I can invite you in github that you can see which relations we use.
Would it be appropriate to put Link objects in the attachment?
Well, it would be "appropriate" if they "identify a resource attached or related to an object that potentially requires special handling." or are "at least semantically similar to attachments in email." - it feels bad and the reason that [poor, non-conformant but] big solutions are not supporting "multiple values" feels essentially wrong. I am deeply sorry :)
In order to understand the use of multiple languages, you need to read at least 4 specifications. Any user of the software can say: I speak language X in quality Y. It might not be obvious to new users that it is the according - HTTP "accept-language" header like e.g. "de,en-US;q=0.7,en;q=0.3"
The default language is defined in the - JSON-LD spec. as described in above issue
4. Spritely Oaken The @spritely Institute, headed up by @cwebber (OG #ActivityPub / #Fediverse cofounder) is working on making the next generation of FOSS, decentralized internet (beyond the web). Oaken is a vision to help make running untrusted code on this new frontier safe, opening up far more possibilities. It doesn't exist yet... but now there's funding to build it!
ALT text detailsPainting of the SPritely Oaken mascot. They look like a small, short piece of oak wood, with small wooden horns like a stag, and a smiling face. They're hold up their hand with balls of purple magic floating above. They're also slightly light by a green light from below further giving a magical feel.
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.
#ActivityPub objects are JSON documents with a special id property. This property is an URI indicating the location of a document, and we can authenticate a document by fetching its id. If the document exists at the specified location, and has the same ID, we conclude that it is valid.
This has several important corollaries:
1. The server of origin is the only authority. Other servers must not be trusted. 2. ActivityPub is fundamentally a "pull" protocol, not "push". 3. The type of a document is not relevant for authentication. Actor documents are not special.
However, fetching documents is not always practical, and developers may want to push data to other nodes. How documents can be authenticated without making an HTTP request? Digital signatures.
The server publishes a JSON document containing a public key, and then starts signing other documents with a corresponding secret key.
Upon receiving a signed document (such as activity), we determine the ID of a public key document, retrieve the document and verify the signature. If the public key document has the same server of origin as the signed document, and the signature is valid, we conclude that the signed document is valid too, because a chain of trust has been established: received document -> public key document -> server.
The public key document doesn't change often, so now we can verify many signed documents without re-fetching the public key.
This also has important corollaries:
1. Once again, the type of a signed document is not relevant for authentication. 2. Public keys do not need to be attached to actor documents. 3. One key per server is enough.
Developers are constantly being told that ActivityPub is an actor-centric "push" protocol, and that each actor must have its own key. But those ideas are wrong and it is time to put them to rest.
#ActivityPub objects are JSON documents with a special id property. This property is an URI indicating the location of a document, and we can authenticate a document by fetching its id. If the document exists at the specified location, and has the same ID, we conclude that it is valid.
This has several important corollaries:
1. The server of origin is the only authority. Other servers must not be trusted. 2. ActivityPub is fundamentally a "pull" protocol, not "push". 3. The type of a document is not relevant for authentication. Actor documents are not special.
However, fetching documents is not always practical, and developers may want to push data to other nodes. How documents can be authenticated without making an HTTP request? Digital signatures.
The server publishes a JSON document containing a public key, and then starts signing other documents with a corresponding secret key.
Upon receiving a signed document (such as activity), we determine the ID of a public key document, retrieve the document and verify the signature. If the public key document has the same server of origin as the signed document, and the signature is valid, we conclude that the signed document is valid too, because a chain of trust has been established: received document -> public key document -> server.
The public key document doesn't change often, so now we can verify many signed documents without re-fetching the public key.
This also has important corollaries:
1. Once again, the type of a signed document is not relevant for authentication. 2. Public keys do not need to be attached to actor documents. 3. One key per server is enough.
Developers are constantly being told that ActivityPub is an actor-centric "push" protocol, and that each actor must have its own key. But those ideas are wrong and it is time to put them to rest.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Did you know? #Hollo supports #Misskey/#Pleroma-style #quotes. You can quote another post by adding a link to it. If a post contains any link to an #ActivityPub object of Article/Note/Question, Hollo quotes it in the post.
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Did you know? #Hollo supports #Misskey/#Pleroma-style #quotes. You can quote another post by adding a link to it. If a post contains any link to an #ActivityPub object of Article/Note/Question, Hollo quotes it in the post.
Did you know? #Hollo supports #Misskey/#Pleroma-style #quotes. You can quote another post by adding a link to it. If a post contains any link to an #ActivityPub object of Article/Note/Question, Hollo quotes it in the post.
Did you know? #Hollo supports #Misskey/#Pleroma-style #quotes. You can quote another post by adding a link to it. If a post contains any link to an #ActivityPub object of Article/Note/Question, Hollo quotes it in the post.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
ALT text detailsa screencap showing 16 reposts and 24 likes, with all the user icons in little overlapping circles displayed in a straight line, chronologically left to right from latest to oldest.
ALT text detailsa screencap showing 16 reposts and 24 likes, with all the user icons in little overlapping circles displayed in a straight line, chronologically left to right from latest to oldest.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
@BeAware this is not about our posts, he is making clones of our accounts without explicit consent; which I understand is illegal in Europe ( and european servers).
He could just implement #ActivityPub and forget about the bridge, but here we are.
ALT text detailsa screencap showing 16 reposts and 24 likes, with all the user icons in little overlapping circles displayed in a straight line, chronologically left to right from latest to oldest.
To people complaining about the Nostr bridge today, (the one that's been here for years now) you DO know that there's no way to tell what anyone is doing with your public posts, right?
There's even a RSS feed that cannot be turned off for EVERY Mastodon account that anyone can read and you'd never even know...
If you want privacy, post privately. If you're posting publicly, you have no expectation of privacy.
It's funny how some people can use #Meta, #x and all other manner of enshittified social media without a care in the world, but when you ask them about the #fediverse they suddenly know what servers are and that the biggest one has a big bad no good moderation problem tisk tisk.
It's funny how some people can use #Meta, #x and all other manner of enshittified social media without a care in the world, but when you ask them about the #fediverse they suddenly know what servers are and that the biggest one has a big bad no good moderation problem tisk tisk.
If you're curious how ActivityPub works exactly (like me) this site does a great job of show and tell.
On the surface it looks like any other Mastodon instance, but on closer inspection, provides you insight into the ActivityPub back and forth going on behind the scenes!
ALT text detailsThe Activity Log shows the ActivityPub objects that are passed back and forth when a follow request is sent from one instance to another.
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.
The little “ActivityPub conversation,” including a nested reply or two, that I had with myself earlier, 🤓 made it back to my blog okay. https://jan.boddez.net/notes/47deb8af37
I used to use WordPress + the #ActivityPub plugin to do this exact sort of thing. Switched to a custom, #Laravel-based implementation a week or so ago. Most (actor, inbox, outbox, etc.) URLs changed in the process. Doesn’t seem to matter much.
The little “ActivityPub conversation,” including a nested reply or two, that I had with myself earlier, 🤓 made it back to my blog okay. https://jan.boddez.net/notes/47deb8af37
I used to use WordPress + the #ActivityPub plugin to do this exact sort of thing. Switched to a custom, #Laravel-based implementation a week or so ago. Most (actor, inbox, outbox, etc.) URLs changed in the process. Doesn’t seem to matter much.
After a year and a half of being on Fedi, I'm still seeing people on an open communication platform recommending others block open communication across platforms (bridges).
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.
ALT text detailsClosed networks are in a heated zero-sum competition for users, so your reach is limited to people on the same platform.
Email, the web’s original open protocol, is used by more people than any platform or social network that has been invented before or since; because it shares users rather than competing for them.
The ActivityPub network works the same way: You get access to an audience of every person across any platform. Open networks grow larger because they don't depend on the success of any one company.
ALT text detailsClosed networks are in a heated zero-sum competition for users, so your reach is limited to people on the same platform.
Email, the web’s original open protocol, is used by more people than any platform or social network that has been invented before or since; because it shares users rather than competing for them.
The ActivityPub network works the same way: You get access to an audience of every person across any platform. Open networks grow larger because they don't depend on the success of any one company.
ALT text detailsClosed networks are in a heated zero-sum competition for users, so your reach is limited to people on the same platform.
Email, the web’s original open protocol, is used by more people than any platform or social network that has been invented before or since; because it shares users rather than competing for them.
The ActivityPub network works the same way: You get access to an audience of every person across any platform. Open networks grow larger because they don't depend on the success of any one company.
/ addendum: Today we are merely building #ActivityPub software (see pinned talk [EN] or Berlin Fediday Talk [DE]). This includes patterns which can be helpful for disasters too – like federated geocoding, wikidata, wikibase and OSM integration. If it feels like you can help or are interested, let me know.
I'm looking for your opinions from the developers of the fediverse.
A common HTML web page can contain related links via the <link> tag. I would like to do the same for Activity Streams objects, for example:
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://writings.hongminhee.org/ap/2024/12/a-year-with-the-fediverse.json",
"type": "Article",
"name": "A year with the fediverse",
"content": "2024 was truly a year where I was deeply immersed in the fediverse. …",
"url": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/",
"attachment": [
{
"type": "Link",
"rel": "alternate",
"hreflang": "ko",
"href": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ko-hang-kr.html",
"mediaType": "text/html"
},
{
"type": "Link",
"rel": "alternate",
"hreflang": "ja",
"href": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ja.html",
"mediaType": "text/html"
}
]
}
Do you think this makes sense, and would it be appropriate to put Link objects in the attachment?
C2S Challenge If I get an Ignore activity from a client that has as object a URL of an object on another server. Then I have to read this object to determine the UseCase. But what if the other server is currently unavailable? Phew, I see 2 possibilities: 1) try it later (async) 2) cache external objects (somehow a bad idea)
But also 1) makes trouble, if the other server is down forever!
The experiment of using roaring bitmaps as the foundation for indexing #ActivityPub objects is half successful and half not.
The good news is that soon I'll be able to replace the #brutalinks client access to it's activitypub backend with something that's built on top of local storage that makes use of the indexes, therefore being much, much faster.
The bad news is that adding indexing to the storage backends themselves didn't result in too much performance gains, but I just suspect I'm doing something wrong.
ALT text detailsA little thermometer graphic shows $902 of $2500. The thermometer is a black outlined tall rounded box with teal green/blue in the bottom up to “$902” The little SocialBC Mammoth logo is sitting on top of the level and the whole thing is surrounded by a similar rounded green rectangular box.
I keep looking more into #bluesky, from #atproto, to see what can be learned and adapted. Nothing is perfect.
Still. #ActivityPub does feel like the correct way. We need many relays to make smaller communities function. Luckily, the fediverse has that in excess. 😎
Congratulations @dansup thats another Milestone for @loops @nlnet is a great partner and I have had the honor of working on two previous NLnet sponsored projects.
ALT text detailsZrzut ekranu fragmentu bloga. Pod wpisem sekcja „Reakcje w fediświecie” z polubieniami i podbiciami w fediwersum, zawierająca okrągłe awatary kont, które weszły w interakcje.
If you accidentally post something sensitive that you want to keep private, don't edit the post, just use "delete" or "delete & re-draft" instead.
Editing has a safety feature to prevent bait & switch abuse tactics: when a post is edited, people will still be able to browse all previous versions of it by clicking on the "edited" label.
⚠️ Deleting a post breaks all its replies, boosts, direct links etc, so only use deletion if there is a privacy issue. Editing is better otherwise.
This instance will be operated as a paid extension of Weird, costing $10/yr ($20/yr after beta).
All member subscriptions will go entirely to the AP instance hosters, which should be a team of at least 2-3 sysadmins & moderators tending to the instance part-time. This is expected to be a fairly low-volume instance since all members are paid (to begin with).
If one is to get into blogging these days and would like to use a blogging system with Fediverse/ActivityPub integration (including commenting via Mastodon account for example)…
Which one do people currently recommended to use?
I have found Plume, which looks nicest and has quite a few instances available. but is currently not developed very actively.
There is also WriteFreely, which is similar but lacks in public instances.
Občas by stálo za to mít možnost přidat k příspěvku (tootu) geografické #souřadnice. Ale pokud vím, ani protokol #ActivityPub, ani #Mastodon tohle nepodporují a není to ani v plánu. Co s tím?
What I’m curious and disappointed about is the lack of the conversation regarding decentralisation when it’s #ActivityPub compared to #Nostr the #Fediverse powerbrokers always dismiss it by bringing up a part of its culture but never want to discuss the technical aspects #ATproto#Bluesky
It's hard to conceptualize the possibilities of #activityPub beyond the prevailing "build a platform like the awful big corpo ones, but arguably not as bad" approach
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
The Fediverse is vast. It's like a space with planets and keeps on expanding. Here's the thing, even if it would stop expanding and all the planets and stars and other magnificent things were to disappear, I'd still be happy on my own piece of rock, shouting to the void.
The fediverse has no central authority — which brings both challenges and opportunities for how it's governed. For Dot Social, @mike spoke with @kissane and @darius, two of the smartest people working on this, about the impact of the 2024 U.S. Presidential election on fediverse work, the "Xodus," what needs to be done next, and how to fund and sustain better networks for humans.
A de-centralized, federated network, using a common, NON-COMMERCIAL, #FOSS protocol, such as the #fediverse can actually save lives and fight the onslaught of dezinformatsiya.
#Meshtastic#GMRS devices were used to keep people connected, sending messages through #ActivityPub based clients, during catastrophic weather events which knocked standard comms networks down.
Although, only speculation, I notice this individual seems less like a prospecting journalist, and more like an advertising placeholder.
They made a similar post two (2) months ago, even starting it as their introduction to the Fediverse (see screenshot).
I am not a journalist, or inspiring blogger, but I would presume in two (2) months time, the article would have enough shared options to go to story. I also find it odd that they praise Sharkey in both post, as oppose to giving no opinion, and just asking people what they think.
That said, when I was confronting Sharkey, while still hanging out in their Discord Server, I learned they do use alternative accounts to help paint their narrative.
Again, my theory is only speculation, based on my experience and dealings with Sharkey. It just seems to fit their track record. And if in this instance, I am wrong, I apologize, but would again, point out that this is something they (Sharkey Development) have done in the past.
ALT text detailsA post from two months ago, under the Sharkey hashtag, also making a similar statement. This one starts out as their introduction post.
ALT text detailsA post from today, two months later, setting up as if to both promote Sharkey while claiming to want to interview Sharkey users.
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 doing a training next month on decentralized social media, #fediverse, etc. for a group that isn’t entirely tech-focused. Some tech, some creative, some finance, etc.
What are the best #Mastodon and #ActivityPub explainers or resources you’ve seen on the web?
If you could hand someone a single resource to explain the idea of federation to someone who is not technical and has no prior knowledge, what would it be?
Some clarifications, and an explanation of why FEP-fe34 authentication is important:
>The processing of unauthenticated embedded activities is strongly discouraged. If such activities are not rejected by the consumer, a malicious conversation owner may be able to perform a cache poisoning attack and overwrite any actor or a post in consumer's local cache by sending a forged Update(Actor) or Update(Object) wrapped in an Add activity.
This is not difficult to do. Someone makes a post and says "hey everyone, join my new @group about <popular_topic>". People join and the next day Gargron is messaging them and asking to fund Mastodon's new Trust & Safety initiative by donating bitcoins.
Similar attacks might be possible against FEP-1b12 implementations that don't authenticate announced activities.
I was looking at the properties on the Person #ActivityPub object implemented by #fedify, and wasn't expecting this one, haha!
I'm presuming this is #Misskey related? The quirks of having to implement many different versions of a spec!
ALT text detailsA screenshot of a code editor showing a TypeScript class Person with a property get cat(): boolean | null. The accompanying comment explains that the property is "used on actors to indicate that they in some way identify as a cat, expressed as a boolean value. If this property is set to true, displaying the actor or their notes will have some special effects attached in some clients."
Having to make one HTTP to WebFinger to resolve a Fediverse ID (such as "＠joeblow＠example·com"), and then make another HTTP request to get the activity document ("application/activity+json") — adds an extra HTTP request.
Using a well-known path to resolve the Fediverse ID and get the activity document ("application/activity+json") — in one HTTP request would be better.
If we are going to use Internet domain-names, maybe host-meta could be replaced by a DNS TXT or DNS SRV record — that is used to specify what host to connect to to resolved a Fediverse ID like "＠joeblow＠example·com" to an activity document ("application/activity+json").
host-meta is in XML (where everything else is in JSON).
I am NOT saying I am a fan of JSON, but — I think it would be easier for developers if only JSON xor XML was used (but not both).
(host-meta is used to specify where WebFinger is. It does not necessarily have to be at "/.well-known/webfinger". And doesn't have to be on the same host.)
host-meta is yet another format to write encoders and decoders for.
(host-meta is used to specify where WebFinger is. It does not necessarily have to be at "/.well-known/webfinger". And doesn't have to be on the same host.)
ALT text detailsDitching the webfinger requirement #17030
While useful, Webfinger is not part of the ActivityPub specification itself, and the ad-hoc mechanism from going from an ActivityPub actor URI to a canonical acct: URI is pretty clunky.
Wir haben das Fediverse-Schaubild noch einmal überarbeitet. Ein herzliches Dankeschön an @imke für die Aktualisierung und die wertvolle Unterstützung. Hier ist die neueste Version des Fediverse-Schaubilds – schaut es euch an! 👇
ALT text detailsColored bubble chart showing "Germany", very prominent, followed by United States, France, UK, Netherlands, Switzerland, Austria, Spain, Canada, Italy, Belgium, Czech Rep, Australia, Ireland, Sweden, Finland and other countries that probably needs more Wikidata editors ihih
The Website League shared their December update, with some exciting news about ongoing projects, which include forks of GoToSocial and Akkoma, a "cohost-inspired frontend", and a "best practices for moderation" guide.
The Fediverse's usage of rel-self in WebFinger, to point to an ActivityPub Activity file (application/activity+json), seem different than how Atom feeds uses rel-self.
The semantics seem different.
(I am assuming ActivityPub borrowed rel-self from Atom feeds.)
Thanks to @joschi, Hollo now support local filesystem storage for media files. You can configure DRIVE_DISK=fs and FS_ASSET_PATH to store media files in the local filesystem. For users who've used S3, no further action is required—but, it's recommended to configure DRIVE_DISK=s3 as DRIVE_DISK will be required in the future releases.
Added support for Sentry. If you want to see error reports and instrumented traces in Sentry, please configure SENTRY_DSN.
Added pagination to the profile page.
Minor performance improvements and bug fixes due to upgrading Fedify to 1.3.0.
You can upgrade to Hollo 0.3.0 using the following ways:
We are a little more than 24 hours away from the deadline for FOSDEM 2025 proposals. If you work on Free and Open Source software for the Fediverse, especially #ActivityPub servers and #Mastodon clients, please consider proposing a talk:
Oh! Is the #fediverse the reason I see posts that are longer than the #mastodon character limit? Am I seeing posts from other systems that implement #ActivityPub or do I misunderstand what is happening?
How #ActivityPub works? Let's use #EventModeling to shed some light on this topic and make it accessible for a wider audience beyond programmers used to dig in to specification docs and explore the trenches of implementation code.
Wir haben das Fediverse-Schaubild erneut aktualisiert! Ein herzliches Dankeschön an @imke für die Überarbeitung und die wertvolle Unterstützung. Hier ist die neueste Version des Fediverse-Schaubilds – schaut es euch an! 👇
ALT text detailsAktualisierte Version des Fediverse-Schaubilds, das eine grafische Übersicht der verschiedenen dezentralen sozialen Netzwerke und Plattformen im Fediverse zeigt.
"The Bluesky features we covet are almost always built on structures that were designed in anticipation of eventually treating the network’s users as a resource to be mined for profit. The question we should ask before incorporating any given feature is not: Can we do that here? but rather: Can it be done without replicating the exploitative structures it’s built on there?"
所信發言: #ActivityPub 소프트웨어들이 #AUTHORIZED_FETCH, 이른바 시큐어 모드(secure mode)를 갖추는 것은 이름과 달리 정말로 시큐리티가 나아지게 하지 않으며, 오히려 安全하다는 錯覺(false sense of security)을 주기 때문에 나쁘다고 생각한다.
Hot take: It is bad that #ActivityPub software implements #AUTHORIZED_FETCH, also known as secure mode, because, contrary to its name, it does not actually contribute to security and instead gives a false sense of security.
#Debugging#activitypub implementations seems to be quite hard. I've got a pretty simple server set up that for now only serves information for one Actor of type Service. My goal at some point is to have this be a working bot that does things. But for the time being I'm still struggling to get other servers to actually consume that actor from my server. I've got #webfinger working I believe correctly (here) and the ID it returns responds with what seems to me like a valid Actor json-id (here). However the several instances I've tried accessing it from all seem to not be able to consume that for any reason. Misskeys end up with an An error has occurred message, mastodons just say they're not finding anything.
With the misskeys at least I see a request coming in to /.well-known/webfinger, but mastodon instances don't seem to attempt to make any call, even if I search directly for the URL of the actor object. Meanwhile fedify lookup seems to be fine with what it gets from the webfinger request since it then proceeds to hit the actor URL as well and prints out the json-ld it gets from it.
There don't seem to be any tools that I can point at a resource and have them tell me what it is I haven't implemented properly which is a bit frustrating.
Well, @Mastodon has started closing stale bugs on their tracker telling me to reproduce on a newer version and resubmit, even though the ticket invites them to a theoretical discussion rather than being a technical problem. It's clear to me that the dude that closed it hasn't even read the issue.
> ...a different way of thinking about issues: > a place for motivated users to collaborate on narrowing down the problem and planning a potential fix. > A space for the community to work, rather than an action item for you to deal with personally.
Conversation Containers are conceptually very similar to FEP-1b12: activities are sent to a conversation owner, who manages the conversation and synchronizes it between participants. Differences are mostly superficial and may disappear in the future.
@soaproot Also as part of my effort to learn more about #Bluesky, I've found a few resources I'm trying to digest.
This talk by Dan Abramov, an engineer I greatly respect, has been great so far but I only had time to watch the first half this morning: https://youtu.be/F1sJW6nTP6E
Ω⚠️🐘⚠️Ω I did some hacking at @pkreissel's implementation of a customizable algorithm for your Mastodon feed. I fixed some bugs and added a few features but maybe most importantly I streamlined the process of installing and running the demo app so you can experience the magic of his invention reshaping your Mastodon timeline for yourself with ease.
Seriously everything about having an algorithm adjust my feed to make sure I see stuff I might otherwise have missed has made my Mastodon experience like 1,000x better. The fact that it's (extremely) granularly customizable is the icing on the cake.
Setup should be trivial for anyone vaguely familiar with the command line. Even if you're scared of the command line you should be able to copy/paste the 3 commands listed in the installation instructions, all of which are in the GitHub repo:
• Smart object lookup with content negotiation • Interactive inbox testing with a web UI • NodeInfo visualization • Local development tunneling • And more!
Our podcast about the fediverse, Dot Social, is one today! 🎉 It’s been such an honor to host the builders of the social web on this show and to learn from them. We have one more episode coming up in 2024 (read the blogpost to find out who @mike will be chatting with) then rest, then back at it in 2025.
This week's news - With Bluesky the main topic of conversations, people are experimenting with Starter Packs on the fediverse as well - @subclub can now turn any RSS feed into a paywalled #activitypub newsfeed - Pixelfed will not pursue an #atproto integration following negative feedback from the community
3/3 AND: Suppose max changes his name to @maximilian@dev.rdf-pub. And @min@dev.rdf-pub notices this and is happy that max is finally free and changes his name to @max@dev.rdf-pub. Now @martin@mastodon.example.org sends a note to @max@dev.rdf-pub and since the profile is cached, the wrong max now gets a create note activity, right?
So somehow this is either not quite right yet, or there is a knot in my head.
2/3 And then there's a huge crash, because some instances cache max's profile and therefore have old URLs.
Now there are claims that (if you work properly) you send a delete activity before deleting the DB.
OK, yes I could understand that somehow. But where do I send this delete activity (or update activity if the inbox URL changes, for example? Because I get a lot of delete activities from whoever).
While #Mastodon is the giant of the #Fediverse , I am curious if any of the other projects have made better strides with onboarding, moderation, UX and so forth.
How is #Friendica on these issues? Or #Misskey ? Ideally we should have a number of _different_ #ActivityPub -based systems which all compete to make their user experiences better. I mean, isn't tying ourselves too closely to any single platform how we got ourselves into this mess in the first place?
I’m curious about a couple of things and answers to this question will surely provide insights. What is decentralisation as defined by a social protocol and social network(s)? #fediverse#ActivityPub#Socialweb#Mastodon#Askfedi
if you want to understand what's wrong with #mastodon, listen to some black people. listen to some women. listen to some queer people. I'll post some links in a bit for those who don't know, but I'm not here to convince mastodon apologists. I'm interested in joining the conversation on how (if?) #ActivityPub can be used in a way that overcomes mastodon's problems.
What does a safe, inclusive microposting protocol on top of #ActivityPub look like? #mastodon is very clearly not it; there are flaws baked in, and the questionably-BDFL is not interested in feedback from marginalized people.
Which just means that we'll have to build it ourselves, without him.
I'm making exceptional progress and am wrapping up a few things before I prepare to launch this exciting new service!
ICYMI: I'm building an open source/self-hostable Starter Kit service that will allow fediverse users to safely build kits and share/use them with ease.
Posts are all part of a thread criticizing the Mainstream Media, with focus on slanted reporting of the Israeli Palestinian conflict.
Nothing advocating any violence, nothing racist, nothing that seems like blatant misinformation.
No description.
Report was from another server so can't ask for one.
Forced to move on because there's no information about what is being reported.
Perhaps some ability to send internal messages in response to #reports, regardless of server, should be added to #ActivityPub? I know I've seen people talk about adding the ability to share moderator notes, and it would really help with moderation between servers on the #fediverse to be able to ask these questions and see what other #moderators are thinking...
Here's a few things you can expect when there's a #Fediverse outage:
- oh wait, there's no such thing, the Fediverse is actually federated - there are over 30k totally independent servers - if one of them goes down the rest of the Fediverse works just fine
The ActivityPub for WordPress plugin now allows you to preview how your post will appear in the Fediverse. Great work, @pfefferle! #ActivityPub#WordPress
ALT text detailsA screen recording showing a blog post being composed in WordPress. The user shows a new feature that allows you to see how your post will appear in the fediverse (ie on Mastodon or other federated platforms). The video also demonstrates previews of how the post will appear on mobile and other devices too.
FEP-fe34: Origin-based security model has been published. It supersedes FEP-c7d3: Ownership and describes authentication of ActivityPub objects in simpler terms. I think ownership is still useful for authorization and access control, so that part was copied from FEP-c7d3.
I have a question about signature handling in #ActivityPub relays. As I understand it, relays forward activities between instances that aren't directly connected. Let's say we have this flow: foo.com (source) → bar.com (relay) → baz.com (destination). The activity created by foo.com includes HTTP Signatures, but when bar.com forwards it to baz.com, wouldn't the original signature become invalid since the Host header needs to change? How do relay implementations handle this issue?
Jag tänker göra en sån #introduktion / #introduction (igen, jag kommer inte ihåg om jag gjorde det förut faktiskt).
Hej 👋 Jag heter Jessica Tallon, och jag jobbar med peer-to-peer-teknologi och hjälpte till som medförfattare på #activitypub. Jag jobbar på Spritely Institute, där vi försöker bygga och standardisera framtidens sociala medier (bland annat).
När jag inte är vid datorn tycker jag om att vandra, plocka svamp, odla och läsa lite.
Big thanks to the people who went on camera first — like @quillmatiq, a writer and builder, who explains how it finally allows us to own our online relationships. 🙌🏻
We love hearing your lightbulb moments when it comes to the #fediverse! In our new short video series, we want the unconverted* to see its tremendous power through your stories. (*Which is why we’re posting these clips to “walled gardens” like TikTok.)
Simply, having now seen more into the guts of the process and how it is managed both historically and today, and understanding how the w3c works, I have no faith in their ability to define a clear consensus way forward out of the current set of problems.
Not "no faith in <timeline>" but no faith in the ability to define a clear way forward here.
This doesn't mean that someone outside of w3c couldn't define a better way forward, even one using AP, but w3c won't.
«As you may have read, #BotsIn.Space is closing down, I have lots of automated #bot accounts living on the #Fediverse - and I want them to continue posting. Installing and maintaining an entire Mastodon instance sounds like hard work.
»I write my own #ActivityPub server? Why, yes! Yes I did!
»I took the code and stripped it down to the bare essentials. All you need to do is upload two files- index.php and .htaccess - fill in your details, and you're done.»
ALT text detailsA webpage is shown. The user clicks on the dokieli browser extension which opens the dokieli menu. The user signs in with their WebID. The user then clicks Notifications and a side panel shown to be checking for user's and their contact's interactions with the webpage. The panel shows a bookmark from one of the contacts, a like activity from another, and the user's own inline annotation from a highlighted section in the document.
🆕 blog! “Introducing ActivityBot - the simplest way to build Mastodon Bots”
As you may have read, BotsIn.Space is closing down, I have lots of automated bot accounts living on the Fediverse - and I want them to continue posting. Installing and maintaining an entire Mastodon instance sounds like hard work. Paying people to host my stuff feels …
Is this valid in #ActivityPub / AS2 ? { "@context": "https://www.w3.org/ns/activitystreams", ... "tag": [ { "type": "Hashtag", "name": "example", "href": "https://example.com/tag/example" } } Note that "Hashtag" is not a term in the normative AP/AS2 context. It seems to break linked data processing, but it also seems to pass the JSON-LD compaction requirements of AS2 (based on the JSON-LD Playground). If true, this means you can use extended types without extending the context. 🤷♂️
People who’ve figured out the fediverse understand its power. Hear from early adopters who explain their lightbulb moments in our new short video series. The use cases and potential of the system are awesome, and these stories are just the beginning. Tell us: what's your favorite thing about the fediverse? We're listening and looking for more people to feature.
* Custom Preview for “Fediverse” (needs WordPress 6.7) * Support `comment_previously_approved` setting * Add title to content if post is a `Note` (cc @davew ) * Fallback to blog-user if specific user is disabled (cc @cdevroe )
Happy federated blogging!
The version on WordPress.com will also be updated soon!
Trochu jsem zabředl do toho, jak vlastně funguje #BlueSky, konkrétně jejich #ATProto protokol, na kterým to celý stojí. Některý věci jsou fajn, např. jednodušší oddělení identity (klidně na vlastní doméně) od dat (a jednodušší přenos účtu, kterej je možnej i v případě, že server zanikne). Z toho by si #ActivityPub (AP) protokol (pohání #Fediverse/#Mastodon) mohl vzít příklad. Problém AP je taky to, že se uživateli kolikrát nezobrazej všechny komentáře, lajky apod. Na BlueSky tohle funguje. Proč?
A bunch of people can see the posts sent out by @colours - but lots of people can't.
As far as I can see, Mastodon.social isn't sending me back an HTTP response when I send to a shared inbox. But other Mastodon-based servers happily accept it.
I like the idea of providing paid content on the Fediverse (even though I do not pay for such anywhere currently). https://sub.club/ implements it via premium accounts and DMs but I wonder if we could (and should) enhance the protocol to allow for payment. At the start only two clients will support it natively because of that.
It's true that a lot of servers in the fediverse are probably run by cool people, but remember that everything you say is copied many, many times over to many, many different databases. For example, my single user instance here federates with like, 11,000 fucking instances, I am not joking. That means this little post could be copied into 11,000 databases, give or take, depending on the nature of the instances I'm federated with.
So in theory, let's say I posted something, like, I dunno, "fuck dtolnay". Any one of those servers could take offense with that and be shitty to me about it. And I don't control their retention policies.
So! While we don't have to worry about Mark "My Cold Dead Eyes Are The Mark of the Beast" or Elon "I fucked my own cybertruck and liked it" being shitty about our stuff here, it's not a bad idea to consider the nature of the fediverse when writing spicy things that could be prone to misinterpretation.
Well, to be fair, you CAN download and upload your posts here and not lose them on Mastodon, but point taken that the migration is still getting there, but #ActivityPub is working that out for future version.
I'm still confused how BlueSky migration of social graphs would work IF there were another non-BlueSky entirely other ATproto service overall - and how that would work in terms of interoperablity with those users on the BlueSKy service.
New: A Conceptual Model of ATProto and ActivityPub
You might want to know a little bit more about how #Bluesky and #atproto works, without needing to know all the technical details. This is a high level overview of how to think about how atproto works, and how it differs from #ActivityPub.
It is also a reflection on the concepts of decentralisation and federation, and what they bring to both the #fediverse and the #atmosphere
ALT text detailsOne of the main subjects of discussion recently has been whether Bluesky is decentralised and if it is federated. I think answering these questions requires a clarity on how ATProto differs conceptually from ActivityPub. Decentralisation and federation are valued for how they impact power structures, but there are multiple ways to build other power structures in open social networks.
A bit of the summary at the top, since that might help during reading:
The conceptual model of ActivityPub resembles that of email: independent servers sending messages to each other.
The conceptual model of ATProto resembles that of the web: independent sites publish data, and indexers aggregate this data into different views and apps.
Some people list it as part of the #Fediverse but others do not. I'm not sure if it has an #ActivityPub protocol plugin or not, which tends to be the litmus test for being part of the Fediverse.
The Fediverse MUST grow to encompass all websites and apps that want a future without centralized gatekeepers that are soft targets for authoritarian takeovers.
The protocols are TOOLS for doing this they are not ends in themselves, and they MUST be SECONDARY to the goal of an interconnected, open social web. To do that, we need to find ways to work together and stop yelling at each other so much.
Thanks to @thisismissem, now you can report remote accounts and posts.
Added two-factor authentication support.
Thanks again to @thisismissem, Hollo improved alignment on Mastodon API changes about OAuth and apps.
Thanks again to @thisismissem, RFC 8414 for OAuth Authorization Server metadata endpoint. It will improve interoperability between Hollo and Mastodon-compatible client apps.
Renamed the Data menu from the administration dashboard to Federation, and:
Now posts also can be force-refreshed.
Now the number of messages in the task queue is shown.
Custom emojis now can be deleted from the administration dashboard.
ALT text detailsA comic by cartoonist Tom Gauld, depicting two rival kingdoms that are nearly exactly the same, however the one on the left, "our" kingdom, is described positively and the one on the right, "their" kingdom, is described negatively. It has been edited to compare federated social media protocols instead.
The one on the left, "our blessed ActivityPub", harbors "our glorious fediverse", "our great Mastodon", "our noble instances", and "our heroic ActivityStreams". The one on the right, "their barbarous AT Protocol", contains "their wicked ATmosphere", "their primitive Bluesky", "their backward PDSes", and "their brutish lexicons".
I'm sure I made plenty of mistakes, but I have to admit I find it surprisingly satisfying to be able to operate on a data type that I can overlay on top of the existing #FedBOX storage engines and get native and *fast* querying for them.
The indexes are quite chunky despite being built on top of roaring bitmaps because there's so many "indexable" elements in an #ActivityPub object. (Currently I'm indexing the type, the content, summary, name, preferredUsername, the recipients, the actor and the object)
As I explore some more, I hope I streamline some of these issues, and make the whole thing more robust.
I've been testing a federated classified ads server, flohmarkt ("Flea Market") which I think is a promising idea for promoting a circular economy among friends. Details on my hub.
It raises quite a few questions for me though - it's going to need more trust & safety features than other #Activitypub applications for example.
Added InboxContext.recipient property. It's useful for determining whether it is a shared inbox or a personal inbox, and whose personal inbox is invoked.
It makes me sad that some #fediverse and #activitypub advocates don’t believe a pluriverse of social web protocols is possible;
that’s literally all the web has ever been. Additive, composable stacks.
It was never that *one* protocol. It’s the mixing and matching of multiple protocols - like http+html ad infinitum - that makes the World Wide Web so resilient.
Plurality is the web’s superpower; the more you fight it the more the pluralists will route around you instead of with and through you.
Are there any ActivityPub projects that do anything with Location? I think Pixelfed lets you assign a location to a post and I'm sure Flohmarkt needs to use location for a lot of what it does.
I ask because when I went to get lunch today the whole road was shutdown about a quarter mile away from where I work with a dozen police vehicles surrounding the area- it'd be interesting to have location based news articles when a local news org has the exact location of an event that could just show up on my maps or something.
Even outside of the news space, Google maps uses their restaurant reviews and places those on their map, I'm not sure if we have a yelp-like service on the fediverse yet but it'd be neat
It is a tiny bot showcasing a split-domain WebFinger setup, where the handle domain is different from the ActivityPub server domain. This is supported by Mastodon and some other ActivityPub implementations, but not all of them.
Continued my experiments with #Fedify and #ActivityPub yesterday and I think I’m confused.
I was trying to make an extension for an Object, and if I understand #JsonLd, the context property contains the definition of any extra property added. I see e.g. the activity streams ns resolves to a nice JSON LD that contains all the properties, but the mastodon one doesn’t resolve to anything? Is it not necessary?
Starting with the next release of #Fedify, v1.2.0, we will support traceable logs for easier debugging. Fedify's traceable logs are implemented using the implicit contexts introduced in LogTape 0.7.0, and most of the logs that Fedify records are given a requestId or messageId. This means that logs can be grouped into requests or background tasks for better analysis.
Want to try it out in advance? Try Fedify v1.2.0-dev.468+2e17cd69 (JSR & npm)!
I think a major source of disillusionment that I’m dealing with involves coming to terms with the shortcomings of #ActivityPub, especially as most of the network implements a Mastodon-centric version of the spec.
To be clear, I think the hackers building the cool, innovative, bleeding-edge stuff with it will be fine, will continue to develop, and will ultimately be the ones to move things forward in the long term.
However, I make no illusions about the protocol itself, The Social Web Foundation, or any of the working groups involved with it. To me, these are slow-moving, incapable of examining the true faults of the spec, and unwilling to accept hard criticisms. We have floating proposals for encrypted messaging, some half-baked concept for migrating identities around (LOLA), and maybe some vague promises about making the process of onboarding and building more palatable for corporations and businesses.
To me, this is a categorical failure at the highest levels. It has almost completely demoralized me from reporting on or participating in this space. I don’t think Evan is particularly suited to building a community or evolving the spec or even acting as an advocate. His repeated interactions over the last few months have done more harm than good.
Do you know what it’s like to be an advocate and a champion of a space for 15 years, to see upward mobility and evolution, to watch adoption hit a peak, and watch everybody in positions of authority just absolutely squander it over and over again, because they can’t see past their own myopic views?
posting yet another little thing, this time about a prevalent problem in the AP world: "view more replies on {origin instance}", AKA the "source of truth" problem (as I've dubbed it).
I've been developing an #ActivityPub C2S-based (with extensions) API facade/proxy proof-of-concept for Mastodon. It runs as a separate process that supports proxying the Masto operations but also adds a postable C2S outbox with support for AP C2S activities. These activities are converted into upstream Mastodon API calls. This extended C2S API also supports search, streaming events, managing bookmark collections, and retrieving timeline collections. 1/2
Made it through @evan’s #activitypub book. Lots of good and useful stuff for implementors there.
Particularly intriguing: his chapter on “Far Horizons”: ideas on what else could be built with ActivityPub that goes beyond today’s typical social media functionality. Need an idea for a new project or startup? There are several interesting ones in there.
Plenty of posts recently questioning whether BlueSky is actually a decentralised, federated social network like the Fediverse.
(Yes, the following description of ATproto is a gross oversimplification. I realise this. Bear with me a moment.)
Basically, under BlueSky's AT Protocol, you can opt to have your data hosted on your own personal data server (PDS). But these servers all need to connect to a central relay, and at present the only central relay is BlueSky.
Any account that follows Bridgy Fed @bsky.brid.gy also gets federated into the Fedi.
It's a longform blogging platform, where all your blog posts are saved to your BlueSky PDS.
So right now, today, you can set up your own PDS. Allow BSky access and store your BSky posts in it. And also grant WhiteWind access and allow WhiteWind to store its files there.
And any BlueSky posts replying to your WhiteWind blogs are visible — on WhiteWind.
So potentially, in the future, you could be storing data from multiple social networks and apps — including photos and videos — in your PDS.
In effect, federating across multiple networks doesn't happen at the level of BlueSky. It happens at the level of your account.
@feb@strght die gibt es eben nicht. Wenn du dich neu anmeldest musst du sehr aktiv deine Timeline aufbauen und du findest deine ggf. vorhandenen Freunde erst mal nicht. Hier ist alles manuell, das ist auch so gewollt aber hat halt Konsequenzen. Das hat imho auch nichts mit #activitypub oder #Fediverse zu tun, das ist einfach Mastodon-Style.
What I don’t like about the #Wordpress implementation of #ActivityPub is that I see the whole damn post, long-form and unformatted, in my feed. Let’s hope #ghost does it better.
I'm not interacting with #BlueSky FUD anymore. I'll despair when any shit actually starts happening and until then I'll keep using both #ATproto and #ActivityPub cause I like both 😋
I know most ActivityPub loyalists are burned from repeat after repeat of the VC enshittification dance, but if people cared to understand how ATproto actually works, I feel like an ATproto account can survive enshittification, but my Masto accounts can't even survive mods having beef.
you are asking what features the new ActivityPub plugin version has?
thanks for asking! ☺️
* Support for post visibility - you can choose between "public", "only followers" and "no federation". * Attribution-Domains - that should fix the fediverse:creator issues, if you had issues https://github.com/mastodon/mastodon/issues/32574 * Improved compatibility with caching plugins
If you're interested in Hollo, please give it a try! There are several ways to install it: using Railway, using Docker (and Docker Compose), or manually.
If you're already using Hollo, please upgrade it to v0.1.0:
There's a new Fediverse-compatible 3D model manager called Manyfold, which is sort of a self-hostable alternative to Thingiverse. You can follow Manyfold's account at:
It's a free open source self-hostable site for storing 3D models, especially 3D printing models. Accounts on Manyfold servers can now be followed from Mastodon etc.
Added Export class to Activity Vocabulary API. [FEP-9091]
Added service property to the Actor types in the Activity Vocabulary API. [FEP-9091]
The default time window for verifying HTTP Signatures of incoming requests is now an hour (was a minute). This new default window is according to the ActivityPub and HTTP Signatures document.
In the fedify inbox command's web interface, the Raw Activity tab is added to show the raw JSON object of the received activity.
@index Great news indeed! After you successfully implemented #ActivityPub inside #Ghost, will you consider creating official iPhone, iPad & Android apps for the platform‽
An ActivityPub server that has open federation but if your server has the gall to send any request to it then it is immediately placed on the instance block list
With many people joining #bluesky now, please follow @bsky.brid.gy to bridge your posts from Mastodon, Misskey, etc. over to the other side of the fediverse as well!
Being able to follow #activitypub accounts from bluesky makes the all of Fedi more attractive!
Let's make the #fediverse the best place it can be 💙
Has anyone built an #ActivityPub server using just Postgrest? I don't think it'd be easy but it could be very fun. The tricky part would be making the delivery job queues work; don't think Postgrest has them built in.
The value of the form at://… in the alsoKnownAs property of the actor generated by @bsky.brid.gy is not actually a valid URL? It cannot be represented as a URL object in Node.js or Deno.
ALT text detailsNode.js:
> new URL("at://did:plc:x7xdowahlhm5xulzqw4ehv6q")
Uncaught TypeError: Invalid URL
at new URL (node:internal/url:816:29) {
code: 'ERR_INVALID_URL',
input: 'at://did:plc:x7xdowahlhm5xulzqw4ehv6q'
}
Deno:
> new URL("at://did:plc:x7xdowahlhm5xulzqw4ehv6q")
Uncaught TypeError: Invalid URL: 'at://did:plc:x7xdowahlhm5xulzqw4ehv6q'
at getSerialization (ext:deno_url/00_url.js:98:11)
at new URL (ext:deno_url/00_url.js:405:27)
at <anonymous>:1:22
(Part 4 of "I for one welcome Bluesky, the ATmosphere, BTS Army, and millions of Brazilians to the fediverses!", but like other posts in the series it hopefully stands on its own)
On second thought, an even better way to welcome Bluesky, the ATmosphere, BTS Army, and millions of Brazilians to the fediverses is to write a series of posts about it ...
Here's part 2: Is Bluesky part of today's Fediverse?
Spoiler: it depends on your definition of "Fediverse"
I wasn't posting much news about #Smithereen lately — fixing that!
The core functionality of photo albums is now done. You can create albums, upload photos, comment on them, and like them. It's all properly federated (between Smithereen servers only). There's a brand new photo viewing UI too. Two of them, actually, desktop and mobile.
Remaining features for 0.9 include: - "System" albums — profile pictures and saved photos - Tagging - Profile picture update posts - Groups feed
You know, if someone wants to make an #erotica#publishing#website that integrates #activityPub, I would not only be happy to get in on programming that, but could bring a couple hundred followers with me there. I wouldn't necessarily get rid of this account, but I would move the long-form stories there.
La trasmissione video su PeerTube è peer-to-peer (attraverso #WebRTC): le persone guardando video su PeerTube condividono parti di quel video partecipando alla sua trasmissione verso le altre persone sullo stesso video. I video ospitati su #PeerTube possono essere visualizzati direttamente da #Mastodon e da altre reti #Fediverse via #activitypub
Il nostro sogno per il fediverso è un mondo in cui non sia più necessario dover dipendere da social frammentati che non comunicano fra di loro, ma poter comunicare su un'unica grande rete libera e unita. Il fediverso è l'unica grande rete in cui è tutto collegato.
Maybe it's devs implementing the C2S side of #ActivityPub, or a multi-protocol client, or built-in browser support for the #fediverse. Maybe we need a single entry point to the fediverse, with a smooth interface, easy setup, and a server behind the scenes.
Either way, making "decentralization" central to the user experience here is keeping a ton of people off the network.
Looking more into #Meshtastic for emergency communication, I've come across a few projects:
Meshtastic SAME EAS Alerter- which uses an SDR to share local alerts
TC²-BBS Meshtastic Version- a Meshtastic BBS
So I'm starting to get an idea of what all I'll need. I love the BBS idea as it is great for press release information and situational updates. I also saw a BBS that integrates with #Activitypub called Xibalba BBS. Has anyone used Xibalba BBS cause I can't find much on it?
@renchap Mastodon gGmbH is listed as a partner of the #SocialWebFoundation! The mission of SWF does not match, if not contradicts the purpose and object of the gGmbH. In my point of view this is the beginning of "embrace, extend and extinguish" of #activitypub like we saw with #xmpp
- @Mastodon has launched their latest version, 4.3 - ClubsAll is a new Reddit-like build on #activitypub - IFTAS is slowly launching their Content Classification System that allows servers that have opted in to scan for CSAM
According to the Activity Vocabulary specification, the summary property should be HTML encoded, but #Mastodon is putting plain text in the summary property. #Hollo is putting #HTML in the summary, but should I change Hollo's behavior?
ALT text detailsThe Activity Vocabulary specification says that the summary property is “a natural language summarization of the object encoded as HTML.”
Want to run your own personal #ActivityPub server, but don't have the server specs to install Mastodon? Try #Hollo, a lightweight personal ActivityPub server!
So now that Chrome (Google) has redefined the web to serve ads instead of content and Mozilla happily follows suit, because, well, Google pays most of their bills, the W3C shrugging — what’s the next big thing? Can we evolve #ActivityPub to the #InternetOfPeople or will it also be eaten by ad money? #Goodnight and #GoodThoughts
After getting to try the #Snac activity pub server developed by @grunfink on bsd.cafe thanks @stefano , I'm kind of tempted to spin up my own instance. Anyone here other than Stefano that runs their own instance ? Please share you pro's and con's plus any workarounds you have come up with. Also how are you viewing / posting on mobile ? Are you just sticking with web or using the likes of #Tusky ? #Fediverse#ActivityPub
If you're an advanced user with programming skills who is wanting to do custom stuff with Fediverse connections (or even wanting to create your own Fedi platform), you might want to check out the activitypub.rocks SocialHub forum:
ALT text detailsScreenshot from the linked article reading:
"Next steps
• I [Matt Lee] want you to have a personal website and have your listening habits on your own website, not my website. But I know some people won't want that, which is fine but Libre.fm is effectively a silo (other than Last.fm which it talks to, although federation with other instances has been possible for a long time) and has over 372,000 registered users and 302 million scrobbles.
• Some new features will only work if you're publishing your Libre.fm stats on your own website.
• A new version of Libre.fm's front end will appear later, powered by Ruby on Rails.
• [highlighted] We're also going to put our full attention to supporting ActivityPub where possible. [end highlight]"
ALT text detailsContinued screenshot from the linked website, reading:
"• Libre.fm will evolve from a single project into a larger project with a few distinct aims:
1. Being a good IndieWeb citizen.
2. Being a genuinely useful tool for artists (payments!)
3. Being a good member on the social web, which means supporting ActivityPub where it is useful. Maybe you could share what you're listening to on the social web?
(For those of you who've used Libre.fm since 2009, you'll remember the GNU social project we started back at the start of Libre.fm (or GNU FM). Personally I hope you also remember our roots in the history of the social web. GNU social continues to this day, but I'm no longer involved and no longer using the software. Happily, GNU social now supports ActivityPub so things are coming full circle.)
What you can do today
1. Get a personal website.
2. Get an account on the social web and follow me!
3. Read https://bored.city and send me feedback.
4. Donate to keep the lights on. https://libre.fm/donate.php -- our expenses are low, but a few dollars here and there helps buy new domain names, renew things, pay for the outgoing email service, etc."
"there is a recurring refrain about implementers deciding they don't care to implement AP as specified, and that this indicates a problem with the spec, not a problem with implementers."
It does. The point of a technical standard is to document the best practice of a group of implementers. It is, by nature, a living document that needs to be updated, as the experience of implementing reveals problems and finds better approaches.
This article on Web Components by @leaverou nicely encapsulates a fair few of my feelings about where we are at with ActivityPub / ActivityStreams in the standards process:
> the focus is still on making things _possible_ rather than making them _easy_
TIL: #ForgeFed is an #ActivityPub extension to make decentralised software development and communication within projects possible by enabling inter-forge communication. #Forgejo is working on implementing it. Just imagine! Issues, PRs, Updates on releases all with ActivityPub!
🌐 Curious about the fediverse and the open social web?
In this week's Community tab, we're spotlighting developers, journalists and experts who will help you learn how the fediverse is shaping a more open and connected internet, and what this means for the rest of us.
#SocialCG will be talking about the future of #ActivityPub -ish work items governance processes at W3C in two days at 5pm UTC (10am PT) and YOU are invited.
You may also want to peruse some potential CG/WG charter ideas. e.g. if there is another WG (unlike CG, usually only open to W3C Member Organizations and a few IEs) should it be a focused ActivityPub WG or a more big tent 'SocialWG 2.0' with many work items unrelated to ActivityPub? https://github.com/swicg/potential-charters/pulls
Bluesky founder and CEO @jay.bsky.team says social media is stagnating because "we're in this trap where users are locked in and developers are locked out." She talked to @mike for the Dot Social podcast about building a healthier internet, how Elon impacted Bluesky's trajectory, innovating on social identity, and how different protocols can come together.
This week's news: - Threads degrades their #activitypub integration, delaying posts by 15 minutes before they appear in the rest of the fediverse - Website League is a new ActivityPub-based Island network, outside of the rest of the fediverse - Ghost discusses their beta plans and pricing.
Now that you mention #XMPP.. at the time that https://openengiadina.net dropped #ActivityPub support for XMPP I was tempted to follow along. So many things are better documented in that open standard and the subsequent XEP's.
Yet also both XMPP and #Matrix are first and foremost instant messaging / chat protocols, and to me using them to build other abstractions on top of felt forced, plus being among the first and only ones to do so.
Caveat, probably most of the frustration comes from the dynamic nature of the #ActivityPub specification which, alongside having most library developers throw their hands in the air and giving up, makes that every property of an object needs to be checked if it is a list of things, a thing itself, a reference to the thing, or, why not, a list of things and references mixed together. 🤢
Introducing Fedify: Build Your Own Fediverse App with Ease! 🚀
Are you excited about the #fediverse but find implementing #ActivityPub daunting? Meet #Fedify, a #TypeScript framework that simplifies building federated server apps. Whether you're creating the next Mastodon, Pixelfed, or something entirely new, Fedify has you covered.
Fedify abstracts away the complexities of ActivityPub, letting you focus on your app's unique features. It's designed to work seamlessly with popular web frameworks like Hono, Express, and Fresh.
Am I up at 3 am in Stockholm for the first virtual book-signing party for the first book about ActivityPub by a major publisher? You betcha! Congrats, @evan!
Mastodon doesn't implement the #ActivityPub "API" (C2S). They don't conform to either the client or server profiles in the AP Recommendation. They implement a very small subset of AP/AS2 and they don't conform to the AS2 Recommendation for the parts they implement. Their software supports > 80% of the MAU in the Fediverse (all protocols, not the SWF definition). And Evan uses this as evidence of ActivityPub's success? I think Mastodon has thrived despite ActivityPub problems, not because of it.
@pfefferle I look forward to seeing this federated future! Ironically, the main reason I signed up with @wordpressdotcom was because of the #ActivityPub plugin.
I think with a few tweaks, #WordPress could become the super app within the #Fediverse.
I do hope the #BuddyPress & #bbPress teams jump on board, as greater ActivityPub integration could help rejuvenate these social WordPress “projects” (as they would provide competitive balance against #Facebook & #Reddit).
The fediverse is a strange place to be sometimes. It's an open network where progress happens in fits and starts in random, often hidden, pockets. And the rest don't often hear what's really going on. In the 6 years I've built on #ActivityPub, we've all had to fight for some kind of coordination.
Especially re: the new #SocialWebFoundation (which I've backed as an outside supporter via my tiny company @write_as), you can see something new is happening.
I just got a follow request from #Awakari, with its own detailed and formatted message, and it never occurred to me that that's the sort of thing that #ActivityPub supports, though it does make sense.
I'm also a little surprised because my understanding has been that the main reason they are controversial is because they don't get permission to crawl people's profiles, but here they've sent a customized agreement type thing for me to look at...
ALT text detailsEven though your account is not locked, the techhub.social staff thought you might want to review follow requests from these accounts manually. awakari (@awakari@activitypub.awakari.com Awakari is a free service that discovers and follows interesting Fediverse publishers on behalf of own users. The service accepts public only messages and filters these to fulfill own user interest o[V [=E Before accepting any publisher's data, Awakari requests to follow them. The acceptance means publisher's explicit consent to process their public messages, like most of other Fediverse servers do. If you don't agree with the following, please don't accept the follow request or remove Awakari from your followers. Contact: awakari@awakari.com Donate: https://awakari.com/donation.html Opt-Out: https://github.com/awakari/.github/blob/master/OPT- OUT.md Privacy: https://awakari.com/privacy.html Source: https://github.com/awakari/int-activitypub Terms: https://awakari.com/tos.html
@FiFachik@rf Для тех, кто хочет потестить федерирование для своего бложика с поддержкой #ActivityPub, могу только посоветовать #Fedify. Там есть встроенная команда для подключения к сервису на выбор, который может дать временный домен для тестирования.
There's something I've been wanting to talk about for awhile.
Quote posts, limiting of quote posts, and how those features might be added to core AP.
As it is now, the way Threads does quote posting is when a person adds a link to another Threads post, it automatically turns into a "quote post".
They also have the option to limit posts from being quoted, which in turn completely stops anyone on Threads linking to that post.
To me, that is wild, but I can see it making sense on a closed platform.
However, given the way Fediverse works and a ton of people have their own instance/website, I think it would be absolutely asinine to attempt to stop someone from simply posting a link to another post.
Links have been part of the internet for awhile now and there's no other platform that stops people from using links, AFAIK.
So, to those working on AP, please consider another route for quote posts because if I cannot link to something on my own website, I'll be pretty livid honestly.
The Social Web Foundation launched today. This non-profit is dedicated to making connections between social platforms with ActivityPub, and was co-founded by @evan@mallory and @tomcoates.
The foundation's focus is educating the public and policy makers about the social web, enhancing and extending the ActivityPub protocol, and building tools and plumbing to make the social web easier to use. “With this program, The Social Web Foundation can catalyze more growth on the Fediverse while improving user experience and safety,” says Prodromou. “Our goal is to unblock users, developers and communities so they can get the most out of their social web experience.”
We are proud to support the work of the foundation. Read more about the it here:
ALT text detailsAnother screenshot of a RattleHead post for the 20th of September 2024 - which looks to have been quite a seminal day in the annals of metal releases. (As an aside, two of the releases that have drawn my attention are Ulver's "Locusts" and Nightwish's "Yesterwynde".)
In this version the bandcamp embeds are displayed as attachments at the bottom of the post instead of being inline in the release listing.
activitypub typescript server framework called Fedify announces first stable release. It is being used by the open source Ghost CMS platform. Can't wait to see what other apps are created with Fedify
ALT text detailsactivitypub typescript server framework called Fedify announces first stable release. It is being used by the open source Ghost CMS platform. Can't wait to see what other apps are created with Fedify
Github repo here: https://github.com/dahlia/fedify/releases/tag/1.0.0
Here's a blogpost with more details on this latest batch of publications that cover news, business, cooking, home design, politics, sports, science and more. Follow their Magazine feeds if you're only interested in one topic, or their whole profiles if you want the lot. The spreadsheet below lists out all federated accounts.
Fedify, an ActivityPub framework, has finally released its first stable version, 1.0.0! Here are key changes:
Deprecation of the term handle
From this version, the term handle across Fedify will only be used to refer to fediverse handles (e.g., @hongminhee@fosstodon.org). An actor's internal unique ID (e.g., b379dbdc-3b4f-4ef4-88c2-fc25632d1c22) is referred to as an identifier, and the WebFinger name (e.g., hongminhee) is referred to as a username.
The term handle in the API will be maintained for a while for backward compatibility, but deprecation warnings will be logged, and it is planned to be removed in the future.
Linked Data Signatures is an outdated standard, but it's still relied upon by major fediverse implementations such as Mastodon.
In addition to HTTP Signatures and Object Integrity Proofs, Fedify now supports Linked Data Signatures from this version, thus supporting all types of signature methods used in the fediverse. This makes Fedify an ActivityPub implementation with the best interoperability.
However, Fedify users don't need to do anything special to use Linked Data Signatures. If an incoming activity has Linked Data Signatures, it automatically verifies the signature, and all outgoing activities will have signatures in three formats: HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs.
From this version, you can forward activities received in the inbox to other actors using the InboxContext.forwardActivity() method.
At first glance, you might think that you could just resend an activity received in the inbox using the Context.sendActivity() method. However, if you do this, the original signature is removed before the activity is delivered to the inbox, and when sending it, the signature of the forwarding actor is attached instead, causing the receiving side of the forwarded activity to not trust it.
On the other hand, when using the InboxContext.forwardActivity() method, the activity is forwarded with the original signature preserved, avoiding this problem. (Of course, the original activity itself must be signed with Linked Data Signatures or Object Integrity Proofs.)
Sending Delete(Application) on fedify inbox termination
From this version, fedify inbox will send a Delete(Application) activity to all peer servers it encountered when terminated. This is typically an activity sent when deleting an account, which will help prevent residual data related to temporary actors from remaining on other servers.
PostgreSQL drivers
The @fedify/postgres package, which implements PostgreSQL drivers for the KvStore and MessageQueue interfaces, has been released alongside this version.
The PostgreSQL driver is a backend that can be sufficiently used in production, especially recommended for projects already using PostgreSQL.
Additionally, an option to select the PostgreSQL driver has been added to the fedify init command.
Celebrating Fedify 1.0.0
With the release of version 1.0.0, Fedify will now maintain API backward compatibility as much as possible. (Of course, in the long term, there may be a 2.0.0 that breaks backward compatibility.) This should be good news for those who have been hesitant to use Fedify because there hasn't been a stable version until now!
So, hoping that more services will support ActivityPub in the future, I conclude this post!
it is my personal belief that this whole "closed-world social network" vs "open-world social Web" thing is leading to a big disconnect that makes addressing people's needs harder.
because, to be on the "network", you neglect being on the "Web".
sure, your software might still publish your "posts" as Web resources, but that's it. you're not actually granted control or ability to manage Web resources for yourself.
and that's why #ActivityPub C2S is being neglected, among many other things
are these things part of the "protocol"? how far does the "protocol" extend to cover? because, as we established, #ActivityPub is not enough to build a fully functional #fediverse -- and a lot of extensions and additional specs are things that ought to be included in this "protocol", insofar as this "protocol" is desirable.
the other thought:
if you ignore things, that means there are cases you're not handling, losing out on robustness. ignoring context is to ignore shared understanding.
this is the fundamental divide between #fediverse thinking and #Web thinking, where #ActivityPub straddles the line between both.
i've seen it said that the "open-world assumption" at the foundation of the Web is actually an undesirable thing for a "social networking protocol", and as a consequence, specs built on that open-world assumption are "completely unsuitable" for that "protocol".
but do we need a "social networking protocol"? do we even need "social networks" in the first place?
but before you build a "protocol" for a "network", consider: what even is a "network", in this context? and, here's the hot take: do you even *want* that kind of "network"? do you want a separate reified #fediverse network?
because the answer that #ActivityPub gives is actually a different one. There is no "AP network", because AP as a protocol is not enough to build a concrete network. it is intended to provide, and exists in context of, the larger #Web.
but beyond that, what does #ActivityPub actually do for #fediverse as a "network" "protocol"? basically nothing. you have a basic mechanism for delivering activities directly to subscribers, but no specified shape or structure for that payload. and you still need a lot of other specs to end up with something that talks to the "network". even with AS2 vocab, you need more vocab extensions to express things you want to.
simply put, AP is not enough for a "protocol" to build a "network".
when #ActivityPub was being standardized alongside AS2 it basically had two compelling reasons for what would become the #fediverse to adopt it:
- it was built on AS2, which was an evolution of AS1, which was already being used. so it wasn't hard to make the jump.
- it made followers-only posts possible, because while atom feeds *could* do this, it was wildly inconvenient to actually do it that way. posting something private to an inbox is a lot simpler, no juggling access control tokens.
which is to say: the primary reason that #ActivityPub is used (to the extent you can say it is being used at all) in the #fediverse is mostly historical.
fedi grew out of a long line of open protocols, and before AP was adopted, it was at the point where people primarily used "activity streams" as their vocabulary and data model, stuffed into atom feeds. atom feeds don't do private posts unless you make an entirely new access-controlled feed, possibly with a token of some sort. hence, AS2.
but this assumption starts to break down when you look a little closer.
first, consider #ActivityPub C2S. why is there close to zero usage of this in #fediverse software? simple: it doesn't solve any needs for building a "network" "protocol".
now consider S2S. why are there zero compliant impls in fedi? because AP as specified doesn't address the needs of fedi. what does fedi need? well, i find it telling that the "real" reason AP was adopted was... to implement followers-only posts.
i think this disconnect between #ActivityPub and #fediverse honestly goes a lot deeper than people might realize. and that is because the problem AP tries to solve is actually completely different from what fedi is trying to do.
the concept of a nebulous but mostly singular "network" or "protocol" (made up of partially overlapping parts) is core to what i'll call "fedi mindset". the assumption is that you can join the fedi "network" by implementing the fedi "protocol". and that AP is this.
the main contention is a disconnect between #ActivityPub as a spec and #fediverse as a protocol/network. a lot of problems cited were with the fediverse as implemented, wishful thinking about what could be changed in spec, many backwards-incompatible, mostly in service of making fediverse impl less painful.
there is a recurring refrain about implementers deciding they don't care to implement AP as specified, and that this indicates a problem with the spec, not a problem with implementers.
Look, I’m going to be completely honest. Some aspects of today’s events, and some elements leading up to it, have given me bad vibes. I’m not trying to assasinate Evan’s character or make him look like a bad person, but I want to characterize some of the dynamic problems I’m seeing from coopting “The Social Web” as a term, and equating it, #Fediverse, and #ActivityPub as all one-and-the-same.
I might get flamed for sharing this, but I have to be honest about what I really think, and why I have some problems stomaching how things are happening.
🆕 blog! “Social Media Blocking Has Always Been A Lie”
What does it mean to block someone on a social media site? Way back in the mists of time, we dealt with trolls on Usenet with the almighty PLONK - PLaced On Newsgroup Killfile. It meant your newsreader never downloaded their posts. They could rant at you all day long, and you'd never …
Evan Prodromou has officially announced The Social Web Foundation, a nonprofit organization dedicated to the advancement of #ActivityPub, the #Fediverse, and The Social Web.
I'm trying to #build a blogging, question-answering, and news site for software engineers, which is #ActivityPub enabled. What should I name it? (The options below are just the ones available to buy a domain.)
ALT text details分散型SNSってなに？分断されないインターネット
- 違うSNSに友達がいても安心。どこにいてもつながれる。
- たくさんいる運営者。イーロンみたいのに独裁されない。
- 自由に引っ越しOK。友達とつながったままいろんなSNSを試そう。
- 多くがオープンソース。みんなで作り上げるSNS。
- 誰でも管理人になれる。自分だけのSNSをつくってみよう。
Activity Pun
AT Protocol
Nostr
ALT text detailsActivity Pub
Misskey, Threads, Mastodon
メールは Gmail から Yahoo mail に送れますよね。
事業者が異なるのに、やり取りができるわけです。
これと似た技術を使って、違うSNSどうしでもやりとりができる仕組みが、 Activity Pub です。
惑星（SNS）がたくさんある宇宙に例えられて、Fediverseと呼ばれています。
ALT text detailsNostr
Damus, Nostter, Iris
本当の自由が、ここに
アプリを開くと自動で作られる「秘密鍵」。これひとつがあればなんでもできる。SNSはもちろん、ブログ、動画、フリマまで。
たくさんのサーバーに暗号の力で改ざんできないデータを保存することで、あなたの書き込みは守られます。
ALT text detailsAT Protocol
Bluesky, WhiteWind
1. 色んな事業者が参加できて独裁できない
2. 誰でもおすすめアルゴリズムを作って選べる
3. 運営事業者をまたいでアカウントの引っ越しができる
この3つを目指して開発が進められています。
You should have disclosed this: "Content subscription service. Subscriptions provide a way to receive monthly payments from subscribers and to publish private content made exclusively for them.
Supported payment methods: Monero, a peer to peer digital cash system where transactions are private by default."
Based on this thread we should not expect #diaspora to adopt #activitypub and join the #fediverse unfortunately. I'd really want to see all existing (and new) social networks join the Fedi for cross-posting and cross-following one day.
Once the next version of #Fedify, v1.0.0, is released, the API will be stabilized. Are there any features you'd like to see before the API is stabilized?
Once the next version of #Fedify, v1.0.0, is released, the API will be stabilized. Are there any features you'd like to see before the API is stabilized?
Idk who needs to read this but it’s okay for people to like different things and make different choices than you. It’s okay to have valid constructive criticism as well. Fandoms can be insane, I’ve seen it with PlayStation v Xbox, Android v iOS and so forth. People can like what they like and if that’s a different choice than you that’s okay. I say this as people on #Fediverse get highly upset at any level of criticism of #Mastodon and other platforms. People getting upset at other protocols. #ActivityPub is amazing but it’s not perfect, nothing is and that’s okay. We live in a world where we have these big beautiful brains where we invent and come up with things. I like to celebrate that. People making different choices than you would is good. People have many layered reasons as to why they do and don’t do things.
There are also open questions about whether #ActivityPub really is the future for this network. People have done some amazing things to make it all work, but I’ve seen people talk about some of the painful, intractable problems with how the network and the platforms on it currently work.
Fediverse Enhancement Proposals have done a lot of incredible work, but it all feels like a band-aid on a deep wound.
I'm looking for a #JavaScript / #NuxtJS developer to help me extend my FastAPI/NuxtJS template (https://github.com/whythawk/full-stack-fastapi-postgresql) to support #ActivityPub. I'm busy with the #FastAPI server. My objective is an open source starter template for developing full federated apps for creator commercial activity (like a personal Etsy or Amazon site) where creators can sell their work & supporters can follow for new product releases. This is a paid project. Contact me direct. #FediHire
One of the benefits of #Fedify is that you don't have to worry about whether a property of an Activity Vocabulary object has a URL or embeds an actual object. If you need an object, you can call the `getObject()` method (which will fetch a remote object if necessary). If you need a URI, you can access the `objectId` property.
Quick question: would it be okay to embed a collection object in the `as:replies` property of `as:Note` & `as:Article` objects instead of putting the URL to the collection in the `as:replies` property? In theory, it would be okay, but would the actual implementations handle it well?
I think postmortem, when we hear the names #Mastodon and perhaps #ActivityPub, we'll see it as one of the greatest fumbles of the web.
It's not (just) the onboarding fiasco. Mastodon servers had something that #Meta could never replicate— real community.
We didn't need the corporate web to validate us. Our presence here could've been a beacon for what the web could be if you took VC money out of the equation. We could've saved people that way.
I can represent every ActivityPub object in this format easily (the astute observer will notice I just defined an ersatz RDF triple). So I can easily create a datastore for this that can flexibly represent every object.
Por que diabos ainda não há servidores brasileiros no https://joinmastodon.org/servers? Há dois anos, quando o Twitter foi comprado pelo seu atual proprietário, achei muito estranho, principalmente depois de ver tantos servidores Mastodon administrados por comunidades brasileiras. E mesmo agora que tivemos o X bloqueado?
Já existe essa fase confusa de escolher um servidor, mas por que os brasileiros são excluídos? Falta de perspectiva além do norte global? Falta de articulação para ter instâncias brasileiras nessa porra de lista?
I wrote a small, easy to use #golang lib for signing HTTP requests so that #Mastodon would accept them and also to verify requests originating from Mastodon and other #ActivityPub servers, useful if you're implementing your own.
@thegibson so are there any other projects showing promise? Preferably #activitypub based, with not just an eye on features but also moderation and privacy protection for its users. Mastodon (project) has definitely gotten too comfortable.
I see discussions sometimes about developing recipe applications for #ActivityPub/AS2. In that spirit, I wrote a blog post describing how to use the schema.org Recipe type in an AS2 conformant manner. It's mostly a thought exercise about possibilities since most AP implementations won't render an AS2 conformant recipe correctly, if at all. https://www.stevebate.net/extending-activitypub-a-recipe/
Part 3 of "A Guide to Implementing ActivityPub in a Static Site (or Any Website)" is just out the oven!
In this blog post, I explain how to make your blog discoverable in the Fediverse as an account, and also address some of the annoying pitfalls I encountered.
In addition, activities sent with the Context.sendActivity() method will have Linked Data Signatures attached in addition to HTTP Signatures if any RSA-PKCS#1-v1.5 key pairs are present.
We were not motivated by implementing Linked Data Signatures, which is already an outdated standard, but we hope this change will lead to better compatibility and interoperability of Fedify apps!
ALT text detailsThe combination of HTTP Signatures and Linked Data Signatures is the most widely supported way to sign activities in the fediverse, as of September 2024. Despite Linked Data Signatures is outdated and not recommended for new implementations, it is still widely used in the fediverse due to Mastodon and other major implementations' reliance on it.
However, for new implementations, you should consider using both Object Integrity Proofs and Linked Data Signatures for maximum compatibility and future-proofing.
The first session brought together implementors of ActivityPub, AtProto/Bluesky, Nostr and IndieWeb applications to discuss how these protocols relate to each other, and what recommendations they all have for potential adopters who need to decide which to support.
It was a productive, cordial discussion and we will have more to say about it once FediForum publishes the notes from the meeting.
#Fedify has a side effect that when you call the getter method of an Activity Vocabulary object, the property that was internally a URI is populated with the actual ActivityStreams object. Today, someone at Ghost gave us a cool term for this: #hydration.
Imagine what if every website implemented HTTP/TLS themselves. There would be so much fragmentation that we wouldn't see the #interoperability we see today.
To me, that's what the #fediverse looks like today. Mastodon, Pixelfed, etc. have their own implementations of #ActivityPub, WebFinger, HTTP Signatures, etc. and each one behaves slightly differently, which leads to poor interoperability. Adoption of new standards is slow.
I wish each major programming language had something like #Fedify.
The `fedify inbox` command, which is shipped with @fedify/cli, is a tool that creates an ephemeral #ActivityPub server so that you can debug and test the activities you send.
I received a request from @ghost today to add #LDSignatures to @fedify for compatibility with #Mastodon, as Mastodon does not plan to implement Object Integrity Proofs (FEP-8b32) for the near future. 😩
However, Mastodon's implementation of LD Signatures does not even use valid JSON-LD properties (despite the name), so I'm not sure how to make it compatible with Mastodon since #Fedify does JSON-LD processing. 🤔
ALT text detailsThe JSON-LD representation of a Create(Note) activity containing LD Signatures produced by Mastodon and its expanded form. The “signature” property and its child properties are not properly namespaced.
I have a question about the `liked` collection in the #ActivityPub specification. According to section 5.5, the liked collection is “a list of every object from all of the actor's `Like` activities”, whereas the side note in section 5.7 says it is “a collection of `Like` activities performed by the actor”. What is the element type of the liked collection, `Object` or `Like`?
I have a question about the `liked` collection in the #ActivityPub specification. According to section 5.5, the liked collection is “a list of every object from all of the actor's `Like` activities”, whereas the side note in section 5.7 says it is “a collection of `Like` activities performed by the actor”. What is the element type of the liked collection, `Object` or `Like`?
GoToSocial, an ActivityPub platform, is adding better support for audio. Mastodon has had that for years, you say? GoToSocial will support up to 6 audio attachments!
Mastodon unfortunately will only show one of them - a cassingle. Similar to how it only shows the first 4 images attached to a post.
I do give credit to Mastodon Web UI for having a really nice audio player for that one attachment, tho.
I also tried to find documentation on this, but failed. The whole thing should be better documented. A vote is an #ActivityPub message -- so where does it end up, if not in the archive?
There was a big decision at the SWICG meeting today to start a Moderation, Trust & Safety Task Force that aims to write a report to improve those aspects of the protocol.
I often struggle with working on non-trivial, long standing projects because when I sit down to do the work after some hiatus, I can't seem to find the pain points I wanted to fix quickly enough.
It feels like trying to get a bandaid off when you can't find an edge where it comes unstuck easily enough.
The largest piece of bandaid that I wasn't able to get unstuck from the ActivityPub adjacent work is getting the HTTP-signatures working well with the rest of the fediverse (by which I mean Mastodon).
Today I might have got the corner of another little bit of bandaid unstuck which hopefully will help in the long run.
So as I'm bopping around looking at everyone's #ActivityPub in browser.pub, I wanted to have the ability to follow interesting people while I'm browsing.
I just pushed a new update that adds a "Follow" button next to every profile in the visual view
We just finished drafting a new tutorial for #Fedify! This tutorial will walk you through the steps of creating your own federated #microblog. It's pretty long, though.
@erincandescent@andypiper sort of how the Internet was born when you first IP based interaction was delivered…we should probably pick the first activity pub message successfully delivered and call that the birthday. #activitypub
I'm also very interested in East Asian languages (so-called #CJK) and #Unicode. Feel free to talk to me in #English, #Korean (#한국어), or #Japanese (#日本語), or even in Literary Chinese (#文言文/#漢文)!
ALT text detailsA panel from the original Watchmen comic, depicting Dr. Manhattan partially reassembling himself after the accident that created him. Text is modified to read: "SEPTEMBER 3RD: A PARTIALLY IMPLEMENTED FEDIFY APP RUNS BEHIND A SERVEO TUNNEL AND FEDERATES FOR THIRTY SECONDS BEFORE VANISHING..."
Always good to see progress! Only a handful of features left on the roadmap. Hollo is an activitypub powered federated microblog app. Docker image was made available with the latest release
ALT text detailsAlways good to see progress! Only a handful of features left on the roadmap. Hollo is an activitypub powered federated microblog app. Docker image was made available with the latest release
Spent some time this morning getting a cursory understanding of #ATProtocol (the open protocol behind #BlueSky). I have a decent understanding of #ActivityPub and I expected AT to have a lot of similarities.
It’s quite different, and this diagram surprised me.
PDS here is “Personal Data Server”. You might think of it as something like a #Mastodon instance where all your data is stored and posts by those you follow are cached.
Except notice that there’s no arrows between PDSes.
Your favorite social network could make decisions that make it impossible to use the service where you live. If that happens, you lose not only access to the site but, more importantly, the community you worked so hard to build.
Use platforms that implement open social web protocols like #ActivityPub so you can lift your network to another platform without missing a beat.
Your network shouldn't be trapped with the whims of a corporation. There's a better way.
If the sender owns the collection, why can't it use Add or Remove to signal to another server that the owner of that collection has modified it? #activitypub
Like if I fetch a collection by arbitrary URI, I think knowing which actor(s) own / can manage that collection is really important information.
Additionally, the way AP defines Add and Remove doesn't make any sense at all since my actor can't tell your server that I've added you to a collection without a request directly from you
ALT text details
7.8 Add Activity
Upon receipt of an Add activity into the
inbox, the server SHOULD add the
object to the collection specified in the
target property, unless:
• the target is not owned by the
receiving server, and thus they can't
update it.
• the object is not allowed to be
added to the target collection for
some other reason, at the receiver's
discretion.
Dear developers of the #fediverse, has anyone ever encountered a case where a personal inbox in #Threads responds with a 404 Not Found for a POST request?
It's too much of a pain to implement #ActivityPub primitives from scratch. If someone wants to build a fediverse software today, they should be prepared to spend more time implementing the AP layer than the business logic. It reminds me of the days of printing out HTTP headers and HTML by hand in Perl/C to create web apps with CGI.
Suddenly, I'm reminded of a service called Yahoo! Pipes from about 15 years ago. If anyone remembers, #Pipes handled #RSS as its primitive, and now I'd like to see something like Pipes handle #ActivityPub as its primitive.
ALT text detailsInspecting ActivityPub objects
BrowserPub
BrowserPub is a browser for debugging ActivityPub and the fediverse. You can punch in any ActivityPub discoverable web URL or fediverse handle, and it will discover and display the underlying ActivityPub.
For example:
• hollo.social/@fedify
• @hongminhee@fosstodon.org
If you want to know further details about BrowserPub, read the creator's Mastodon thread.
fedify lookup command
Fedify provides a CLI toolchain for testing and debugging. The fedify lookup command is a simple tool for looking up an ActivityPub object by its URL or fediverse handle.
Your replies will be categorized by @jejord, @AileenLalor, @miaq and @marci so that we can feature these accounts to our Flipboard users and work to ensure they render properly on Flipboard.
I'm excited to help evangelize the many great projects here and advocate for their adoption and funding.
Again, thanks to @alain@jase.social, this release features a ton of improvements to the ActivityPub federation layer of Socialhome, but also upgrading Django to 3.x, which is a major achievement in terms of keeping up to date with dependencies. In regards to upgrading Django we also decided to take a deep dive and ditch uWSGI in favour of Daphne and ASGI. This does mean admins running Socialhome need to change their reverse proxy configuration.
Highlights:
Breaking change. No more uWSGI. Both http and websockets should now be routed to Daphne.
Django 2 -> 3. A whole load of Python dependencies upgraded.
This release also pairs with a v0.24.0 release of the federation library. The changelog for that can be found here.
What is Socialhome?
Socialhome is best described as a federated personal profile with social networking functionality. Users can create rich content using Markdown. All content can be pinned to the user profile and all content will federate to contacts in the federated social web. Federation happens using the ActivityPub and Diaspora protocols (Matrix maybe coming up one day :))!
Please check the official site for more information about features. Naturally, the official site is a Socialhome profile itself.
Want to work on a Django and VueJS powered social network server? Join in the fun! We have easy to follow development environment setup documentation and a friendly chat room for questions.
After over a year, a Socialhome release is out again! The main thanks for this release goes out to @alain@jase.social, who has pretty much re-written the whole ActivityPub federation layer for this release. Not a small job at all, and without any noticeable regressions too.
Initially, when the ActivityPub layer was added for Socialhome, it was a quick JSON only job, with federation only really ever tested with Mastodon. Now we have proper JSON-LD based inbound/outbound federation that not only adds a lot more supported platforms but also support for various new objects like video and audio.
Highlights:
Fully rewritten ActivityPub protocol support using JSON-LD.
Python minimum version supported changed to 3.8 with support up to 3.10.
NodeJS required version bumped to v12.
New background queue priorities to ensure federation traffic is always prioritised.
Threaded replies!
Support for video and audio attachments (ActivityPub only).
Fetching of previous replies when new content is received.
This release also pairs with a v0.23.0 release of the federation library. The changelog for that can be found here.
What is Socialhome?
Socialhome is best described as a federated personal profile with social networking functionality. Users can create rich content using Markdown. All content can be pinned to the user profile and all content will federate to contacts in the federated social web. Federation happens using the ActivityPub and Diaspora protocols (Matrix maybe coming up one day :))!
Please check the official site for more information about features. Naturally, the official site is a Socialhome profile itself.
FYI, currently signups are closed on the official instance due to spam users. We're working on changing this soon.
Contribute
Want to work on a Django and VueJS powered social network server? Join in the fun! We have easy to follow development environment setup documentation and a friendly chat room for questions.
Alain ( @alain@jase.social ) has been hard at work during 2023, making Socialhome a better citizen in the Fediverse. The releases of Socialhome v0.18.0 and federation library v0.25.0 bring a ton of fixes and compatibility improvements when talking to other platforms on the network.
Additionally there are improvements to how Socialhome renders content, fetches missing profiles and work on reducing database load, among other items to mention.
Notes on how to use the Docker images can be found in the docs. They're a bit minimal, we're looking on getting better example Docker based install instructions in place soon.
What is Socialhome?
Socialhome is best described as a federated personal profile with social networking functionality. Users can create rich content using Markdown. All content can be pinned to the user profile and all content will federate to contacts in the federated social web. Federation happens using the ActivityPub and Diaspora protocols.
Please check the official site for more information about features. Naturally, the official site is a Socialhome profile itself.
If you want to try Socialhome first before trying to install it, register at https://socialhome.network and then ping us with a comment on the user name chosen, and the account can be activated. Unfortunately due to spammers accounts on the project instance need to be separately activated.
Contribute
Want to work on a Django and VueJS powered social network server? Join in the fun! We have easy to follow development environment setup documentation and a friendly chat room for questions.
For educational purpose, I've created a federated microblog example using #Fedify, with a total of about 30 commits, which you can follow step by step.
Now, I'm starting to write a hands-on Fedify tutorial based on this example code. I'll make it public when I'm done!
Inspired by Pleroma (MRF) and Cloudflare (WAF), this new @pixelfed feature will help improve safety and moderation by empowering admins with fine-grained tools like these.
Better yet, you will be able to easily import/export rules and I'm working on a FEP so other projects can add support using a common vocab.
The Fediverse is often referred to as a decentralized "social network", but I think that misses some of the bigger ways that ActivityPub can make the web more open and user friendly.
@nik yeah been using Duolingo for a little under a month now, surprised by how much German I remembered from high school. Would love to find something more comprehensive and open source. Heck if we can find one that integrates #activitypub even better.
We want to start actively promoting #Fediverse events on our site. These include game jams, hackathons, art collabs, unconferences, live listens, and webinars.
We're currently looking at using an events calendar extension on our site, with the goal of integrating it with #ActivityPub. We want to demonstrate deep integration with the rest of the network, while also giving first-class support to the communities we're a part of. Ideally, it should work with Mobilizon, Gancio, and other Fediverse events platforms.
If you're an event organizer, and would like to have something included on our calendar, give us a shout!
ALT text detailsA stick figure is sitting at a desk with a computer on it.
The stick figure is talking to someone in the off:
“Are you coming to bed?”
SF: “I can’t. This is important.”
“What?”
SF: “Someone is confusing Mastodon for the fediverse!”
Original: https://xkcd.com/386/
In the next version (v0.14.0) of #Fedify, the performance of the Object.toJsonLd() method will be dramatically (~3k ×) faster. This is expected to improve the overall performance of Fedify apps!
"The inbox stream contains all activities received by the actor." (#ActivityPub Rec). However, AP/AS2 collections (including "special" ones like Inbox, Outbox, Followers, etc.) do not contain Objects or Activities. They contain URI *references*. That's why one Create/Note can be referenced by many inboxes. It may look like Collections contain Objects because of typical server JSON-LD serialization, but don't be fooled. It makes a difference for data lifecycle management and storage models.
@docpop I do my best for #activitypub - what is missing IMHO is detailed documentation. For example the difference between "note" and #WordPress format, if it's possible to write a post mentioning a fediverse account so that they get notified... @_elena managed to do everything of this, I didn't... @pfefferle suggested me to change setting from "note" to "wp format" and it did not give me results I expected...
Happy to see that my translations for #activitypub#WordPress plugin have been approved and I'm now trying to cover the readme file, in order to have plugin description translated as well. My 2 cents to help people discover #fediverse - I can't deny I sometimes feel discouraged, having just a couple followers on blog's profile but patience rewards me, I can't be in a rush.
I believe the W3C should reconsider splitting the #ActivityPub Recommendation into three documents: Core/Shared requirements, S2S (Server-to-Server, "social/federation protocol"), and C2S (Client-to-Server, "social API"). I think it would reduce developer confusion and help them focus on requirements that are relevant to their work (typically, S2S/Core). It would also allow C2S to be improved independently so that more developers might consider using it.
The news curation platform @Flipboard is becoming a full member of the Fediverse! 🥳 Anyone with a federated Flipboard.com or Flipboard app account can now follow and interact with accounts on Mastodon etc, and vice versa:
This morning we shipped an exciting new version of #Flipboard that enables *anyone* on Flipboard to follow *anyone* in the fediverse.
This is the culmination of a ton of work to deeply integrate #ActivityPub into the product. The result is incredibly seamless.
Just tap on the search icon in Flipboard and tap the follow button for anyone featured there or that you find in search. You’ll soon start seeing their posts in all of your relevant Flipboard feeds.
Check the screenshots below and read this post to learn more:
Showing the #Fediverse some love this morning with a new app directory dedicated to #ActivityPub platforms, clients, and tools for easy browsing and discovery:
Users can browse by the various software types with a filter for platform (web, desktop, mobile) and various sort options based on popularity (repo stars), recent development activity, and more.
Hello fellow citizens of the free and open web, it is me, Ben Brown. You may remember me from that social network from back when social networks were cool, or maybe from that one open source project that blew up.
Hi, it is great to see you again.
First off, corporate owned social media always sucked, we always knew it. It is past time for us to have better options.I am so glad for the #Fediverse and #ActivityPub and Mastodon and other projects for breathing new life into the indie web, where it is possible for us to own what we post and use whatever tools we want. I couldn’t resist building something!
My new project is called SHUTTLECRAFT. It social media server … FOR ONE.
What does that mean?
It is very small and lightweight open source app that runs nicely on services like Glitch, but it has most of what you need to host your own personal social media account.
It’s got a microblogging tool, to make posts. You can customize the design with HTML and CSS. You can follow people on Mastodon or other services and interact with posts and send messages. People can follow you on Mastodon, or with RSS. You run it on your own server so you own and operate the data and the code and the whole service. And you can hack the code and make it weirder so that we can all be part of a better, more diverse and more interesting web.
Though this a personal project and only a few weeks old, with tons of stuff still unfinished and yet to build... you can get the code right now and run your own right now! The official site also has a 3 minute walk through of setting up an instance on Glitch. It is pretty easy!
My reply to a GitHub discussion on why WordPress should have their own Mastodon account:
Well, the first thing what I'm a bit bummed about here is that why is WordPress.org seeking only a commercial, wide-as-possible-reach type of platform in social media when the other major foot is obviously in the open source world? Mastodon and the Fediverse is full of WordPress and PHP people and influencers, WordPress itself connects to ActivityPub and Threads.net connects to ActivityPub as well. So the reach is not any absolute metric here as it's not just one platform. It's the whole web.
For the second question, just see how much WordPress is talked about between instances, I've seen numerous folks of missing the official WordPress account there, including the community folks.
Here are some examples of the brand accounts:
- Internet Archive, 52K followers - Have I Been Pwned, 14K followers - 9to5Mac, 25K followers - World Wide Web Consortium, 31K followers - GIMP, 10K followers - Electronic Frontier Foundation, 62K followers - 1Password, 9.3K followers - Signal, 51K followers
In my mind the worlds largest open source CMS should be a part of this open social web movement.
So, kbin.social (and likely #kbin itself) is dead.
I only joined the #fediverse in the "twitter migration" and *already* have 2 accounts that died on instances that were "flagships" but just disappeared (kbin & firefish).
No blame or shame for the devs or anything. They tried which is much more than most of us.
But whoever "decided" that true mobile identity isn't a priority for #activitypub / fediverse, probably fucked up.
Why hasn't the fediverse grown more? Instances & immobile accounts!?
If you have a WordPress blog, you can optionally allow people to follow your blog from Mastodon etc. They will be able to see your posts in their timelines, and if they reply to your post on Mastodon etc it will appear as a comment on your blog.
There are complete instructions for how to switch on this feature here:
This week's news: - @mmasnick joins Bluesky's Board of Directors - @bonfire shows some more information on Mosaic, another project of Bonfire, and puts out bounties for developers to help get to a 1.0 release - A platform for football fans with CollabFC - 3d printing platform @manyfold has added early #activitypub support
Manyfold v0.75.0 is out, with some experimental social features powered by #ActivityPub under the hood. We're taking our first steps into a larger world!
(PSA: it's very early days, so don't expect to be able to subscribe to 3d models in Mastodon *just yet*)
Also, how likely is it looking that we'll get federated groups that are compatible between both Mastodon and a Misskey derivative? Or ideally compatibility between a whole bunch of ActivityPub implementations.
This release contains some important performance fixes to some background jobs that had previously caused a lot of database load. Additionally, we queue less jobs that don't make sense.
Full changelog:
Fix missing Http404 imports in Streams API viewsets.
Notes on how to use the Docker images can be found in the docs. They're a bit minimal, we're looking on getting better example Docker based install instructions in place soon.
What is Socialhome?
Socialhome is best described as a federated personal profile with social networking functionality. Users can create rich content using Markdown. All content can be pinned to the user profile and all content will federate to contacts in the federated social web. Federation happens using the ActivityPub and Diaspora protocols.
Please check the official site for more information about features. Naturally, the official site is a Socialhome profile itself.
If you want to try Socialhome first before trying to install it, register at https://socialhome.network and then ping us with a comment on the user name chosen, and the account can be activated. You can also request account approval in the chat room. Unfortunately due to spammers accounts on the project instance need to be separately activated.
Contribute
Want to work on a Django and VueJS powered social network server? Join in the fun! We have easy to follow development environment setup documentation and a friendly chat room for questions.
If you are unfamiliar with #twtxt, it is a different take on decentralized microblogging that has been around for many years, and it is quite interesting to see it now bridged between this side and that one!
I don't think many folks here in the English speaking side of the fedi know about #Juick (juick.com) but its another part of the #fediverse that is already federating. I just discovered that they are also open source and the code is all available at https://x.juick.com/Juick/ licensed under AGPLv3. #ActivityPub
The JSON-LD processor ended up being #Fedify's bottleneck, so I'm in the process of fixing Fedify to generate JSON-LD without the proper JSON-LD processor.
I have to admit I've been a bit disappointed in the maturity of #ActivityPub libraries/frameworks for #Python though. I'm working on a fledgling AP project in Python and finding very little.
It seems that #BookWyrm and #PieFed have gone the route of writing their implementations from scratch. Its great reference material, but a common library we could all build from would be a huge boon for the community.
Betula is a federated self-hosted single-user bookmarking software. Organize your collection with tags. Write descriptions and quotes. #IndieWeb microformats and #Fediverse are supported.
This release brings #ActivityPub-backed following. Follow Betula from Mastodon and whatnot and receive all new bookmarks. A new design for bookmarks was also made.
In #Activitypub, replies to a post are a collection of links that are part of the original post. So it’s only natural that the original poster should be in control of what’s in the reply collection. Technically it’s quite simple to implement that the OP (original poster) can decide which replies he/she/they accept or refuse in said collection. It’s up to the developers of ActivityPub implementers like Mastodon et al to make that level of control accessible.
I have a bit of an #ActivityPub problem. I'm trying to implement an AP server that can send toots to #Mastodon. So far, I managed to follow a user on my server, that seems to work okay. However, when my server tries to send a Note, Mastodon accepts it, but it does not appear on the following user's timeline.
I'm not sure what I'm doing wrong. HTTP Signatures appear to be fine, because otherwise the follow wouldn't work either, and the Note Create activities wouldn't be accepted either.
When sending this to Masto, with http signature, Masto replies with "202 Accepted". But the user I'm following with, does not see the note on the timeline.
Do I need to implement outbox? I'd prefer not to implement outbox if I can avoid it.
If anyone wants to play with it, and perhaps help me debug what is going on, registrations on https://shoes.forgejo.madhouse-project.org/ are open. Creating a repo, opening an issue, and then commenting on that will all emit activities, which are sent to Masto as Notes.
This is a milestone worth celebrating! :fediverse: In development as we speak, @forgejo can now federate comments (and tons of other stuff) from issues in repos!!!
If you've created a new web framework, you can assume that your readers will have some knowledge of HTTP when you write tutorials for it. However, if you have created a new #ActivityPub server framework, you should also explain ActivityPub itself in the tutorials for this framework.
I kept thinking about this while writing the #Fedify framework tutorial. 😩
#MicroShit has taken over GitHub apparently. If you can't self host, we might be able to help you at MPAQ @seige , have any ideas. #FuckMicroShit !!!
Our "admin" @admin has put out a program to list following and followers so, I'm going through my lists to find out who is missing and I've missed 😁 so far, its been tested on Mastodon instances but don't know if it will work on other platforms.
A topic that came up within the last few days is a way to look at your following and followers lists. Please don't abuse public data for others. Nothing fancy but here it is: https://github.com/MPAQ-Admin/follow/
Anyone wants to jump in and help are welcome :dog_smile:
Flipboard CEO @mike will be joining the @threads AMA about the fediverse on Monday, along with Block Party founder Tracy Chou. Get ready to ask away — no question is too basic or complex.
ALT text detailsBlack text on white background that says "Threads and the fediverse: A conversation with @exhaustedfemalefounder and @mmccue." In the background of the image are illustrations of stars and planets.
@operationpuppet I am a big fan of using #WordPress with #ActivityPub and #WebMention enabled. That might not be an option for everyone but it has worked for me. That said, if you find a more efficient method, I'm all ears.
OpenMentions.com was created to start a federated (distributed) directory of topics where by using #WebMention and #ActivityPub we can discover others talking about topics that interest us.
Currently trying out #Friendica for a new issue of my newsletter/blog #TheFutureIsFederated and this GIF speaks louder than words. I’m OBSESSED 😍
I’ve spent an hour adding #Bluesky accounts and #RSS feeds of my favorite blogs (in addition to a selection of #Mastodon and federated #Threads accounts). It’s SOOOO COOL…
Question for #ActivityPub implementors: has there been any research on how to best handle deletions (accounts and/or posts)?
At the moment, the best (and only?) way to know that an account deletion has been federated everywhere is to notify any known inbox / instance, for every account deletion.
This is very wasteful and not efficient, are there any alternatives? Has anyone worked on this?
So, version 3.0 of the ActivityPub plugin for WordPress comes with a Reply block of its own. Like, I’ll probably stick with my current implementation and continue to just use IndieBlocks’ Reply block for all things microformats, Webmention, *and* ActivityPub, but: pretty cool nonetheless!
*And*, looks like it comes with a *bookmarklet*, too. I’ve been hesitant about adding those—*something irrational fear of a potential security hole…
I'd be willing to start an #OpenSource project to build such tools. I'm a data scientist and could probably build a toxicity detector, but the project would also need 1. Somebody familiar with #ActivityPub 2. Somebody who could do UI 3. A domain expert - someone with moderation experience @proprietor do you know anyone who could help 4. Ethical oversight - could @DAIR help with this?
It’s still embarrassing to me how many here treat the CW hack as fact and scold users for not using it. Let me remind you that #mastodon abused the #activitypub standard to establish their own interpretation of the subject field to serve as #ContentWarning.
ActivityPub idea #237 - Federated version of GoComics with all the properties a strip would have - panels, sequence, page, byline, date of publication, etc.
FYI: Abelio will provide couple of ways of publishing visual contents. One of them is part of the article editor and it let's you organise multiple images in a form of a flexible grid you can arrange as needed.
I'm writing a new #Fedify#tutorial. If a tutorial on creating an #ActivityPub server needs to deal with persistent data, where should they be stored? I want the tutorial to focus as much as possible on implementing the business logic and as little as possible on other things.
The developer of Streams contributed a lot to this FEP, based on the NomadicIdentity features it's shared with Hubzilla for years(1). So it's already been implemented in Streams.
I'm curious to see it added to other ActivityPubs apps so I can test an app-to-app migration.
This is a fascinating read from the end of 2023, about the #ActivityPods team's plans for v2.0 and the v1.0 limitations it's being designed to overcome;
Hey folks into #ActivityPub and #p2p / #dweb tech. We've got a new #FEP in the works to bridge between the two worlds based on the work we've been doing at @distributed
Come check it out and let us know what you think and if you'd like to implement it yourselves!
Has anyone written a good “Fediverse for Politicians” post?
I want to encourage my representative to include the #Fediverse in their communications strategy. I think the meaningful fundraising demonstrated by #mastodonforharris will be more convincing than technical arguments.
I’d rather not write yet another introduction to #Mastodon and #ActivityPub post, so show me what you’ve got!
Distributed Press ( @distributed ) is drafting a new FEP for #ActivityPub for "Peer-to-peer Identities". The general gist is that objects (such as Actors and content) can link to alternate versions of themselves, which can be hosted elsewhere, such as #IPFS. If the server goes down, data can be served from there instead.
ActivityPub kann man sich wie interaktives RSS vorstellen, denn Kommentare zu Beiträgen erscheinen sowohl auf Mastodon als auch im Blog auf unserer Website.
Bin gespannt, ob und wie das in der Praxis funktioniert.
I'm a little in over my head, but I'm just about to give a presentation based on my book about #Mastodon to the #IETF120 meeting. I'm going to talk about the development of #ActivityPub to a group interested in standards development:
Improved multitenancy (virtual hosting) support: You can now easily determine the host of the current request via the hostname, host, and origin properties of the Context.
When validating HTTP Signatures and Object Integrity Proofs, once fetched public keys are now cached.
It's available on JSR and npm now, and you can upgrade it using the deno add command on Deno:
Since #Fedify v0.12.0, when verifying HTTP Signatures or Object Integrity Proofs, it will cache the public keys once fetched. It is okay even if a cached key becomes outdated because a verification failure due to a cached key will invalidate the cache and force a verification retry.
This feature is available for preview in v0.12.0-dev.307+235629d5 (JSR or npm).
Interesting #ActivityPub implementation roadmap by the #Ghost team: instead of implementing the standard, and then optimizing interop of their implementation with other implementors like Mastodon, they start with making it work with other implementations and then come back to the standard.
Looks like the #fediverse has champions at the Verge;
"But all of this stuff only works if there is a standard, and I’d bet $10 that ActivityPub is going to be that standard. It’s the one that’s overseen by the World Wide Web Consortium, it’s the one with the most momentum, it’s the one Threads is supposedly going to support — it’s just kind of clearly winning."
#DavidPierce, Verge editor-at-large and Vergecast co-host, 2024
Oh, Zot! Nomadic Identity is Coming to ActivityPub: This could change the Fediverse forever
Years before there was Mastodon and even ActivityPub, there was Mike Macgirvin who created the Zot protocol, which Hubzilla runs on. One of Hubzilla’s most amazing features (apart from also integrating with Activity and the Fediverse, and having cha ...continues
Updating #IndieBlocks’ Facepile block to allow multiple inner [Facepile Content] blocks. Here’s me splitting up likes and bookmarks.
It supports Webmention as well as ActivityPub reactions. As you may be able to tell, the “response count” excludes likes, etc.
While the #ActivityPub plugin for #WordPress does not (yet) support likes, I’ve been able to add support for them through some custom callback functions.
ALT text detailsA (titleless) note on my personal site. Underneath, there’s a number of likes and a single bookmark, as well as some regular replies.
So using the #ActivityPub plugin in my #WordPress means that right after publishing a post I'll get over 3k requests for said post within a minute... Which is quite a bit for a small server that usually gets about 2 to 3 requests per minute 🙈
Note to self: Publish about a recent blog post on social media 10 minutes AFTER release. Otherwise people will run into delays...
Just read an email newsletter from @newsmast about their upcoming Patchwork platform. It’s a plugin system to extend existing fediverse platforms.
One of their upcoming plugins will be local only posts. It’s a nice feature I used on Firefish, allowing nonfederated community discussions. Looking forward to it!
> ActivityPub is not underspecified. … It is a protocol for building all kinds of decentralized social applications.
Which results in it being underspecified for any specific application (especially if interop is a goal). But it’s an interesting spin. ;-) As others have noted over the years, #ActivityPub more of a sketch or outline of an idea than a protocol.
@silverpill@smallcircles If #activitypub supports everything that we need, it should be trivial to layer it on top of this protocol, possibly built-in, without needing a separate server/bridge.
But I want to build the smallest thing I need first.
I want to avoid tying myself to a protocol that has been, as far as all common implementations are concerned, implemented with different goals and trade-offs in mind.
As far as our testing and experimentation now, the more focused the better.
The biggest thing pushing me away from #ActivityPub is that I want a content replication system, similar to #ipfs : - I want an efficient way to serve content to the global network and save that content offline without losing signatures of authenticity. - I want all the data hosted by one client/server to be transparently loadable by any other client/server with permission. - I want clients to be able to connect to each-other, without servers. 1/3
ActivityPub is not underspecified. Developers might get frustrated when they read the spec and discover that it doesn't explain how to communicate with Mastodon. But this is only because the scope of the spec is much broader. It is a protocol for building all kinds of decentralized social applications, and some of them can be quite different from micro-blogging services.
>We prefer to make a very precise protocol specification to give tight interoperability at it's core, but allow component data and schemas to develop independently for extension.
You can create an interop profile for ActivityPub which can be as precise as you want. It can be very strict and at the same time compatible with many existing applications (best practices for interop has been already discovered, and the work on formalizing them is ongoing).
Extensibility is baked in (ActivityPub is a culmination of several decades of experimentation with semantic web concepts).
Of course, you can design a different protocol, but bootstrapping protocols is a very difficult task. #ActivityPub is already popular, and it has all the properties of the Web of Data you've described in your post.
>That said, interoperability with ActivityPub is something we are very interested in.
Interoperability can be achieved by adopting ActivityPub data model (ActivityStreams 2.0). A common language will enable communication without centralized bridges. Transport protocols are secondary
On https://ActivityPub.Academy, you now can 🌟 Write your own Activities and send them to any inbox! 🌟 Control the response of the WebFinger endpoint! 🌟 Change the type of your actor!
This greatly expands the set of Fediverse services that can effectively be analyzed with ActivityPub Academy.
A list of alternative webclients for various #fediverse software:
Notes: * webclient: you use your own credential from your own instance * Listed are: official webclient hosts; or an instance list. * Optional: other instances. * In alphabetical order.
Abelio supports couple of ways of posting your content. One of them is a block-style editor (something like on Medium) for those of you who needs to post articles in a convenient, non-markdown way.
The #Ghost people are doing excellent #ActivityPub marketing with their weekly newsletters, such as today’s. I don’t agree with some of the details of their points of view, but that doesn’t matter in the grand scheme of things, they are doing a great service educating potential users beyond the niche of today’s typical Mastodon users. Recommended.
And you can get the newsletter by following @index
The news this week: - Dutch government plans to expand their #Mastodon project - Nomadic Identity (decoupling user identity from servers) over #activitypub comes to the fediverse - @openvibe combines Mastodon, #nostr and now Bluesky into a single app and a single feed.
Hey the #Fediverse! Today, I have released the version 0.1.0 of my new project, f2ap, an application that adds a compatibility layer for #ActivityPub to your website thanks to your #RSS/#Atom feed!
Currently, only the support for Mastodon is guaranteed, but there are a lot of other platforms out there. If you are on another social platform, please help me document the platforms support! 🙏
One cool thing about running your own #ActivityPub server is you can create bots that post hundreds of times a day and lock it so only you can follow it and it doesn't bother anyone or hit random API limits
ALT text detailsScreenshot of profile on my mastodon server
Tom's Youtube RSS, @youtube_rss@tomkahe.com
'Bot that reads from an OPML file and posts RSS links'
Posts: 256, Follows: 1
The Medium is The Message is part one of a series (probably). In it, I argue that #Threads is not the assumed victory for the #fediverse it appears to be.
Longterm interpolation with Threads sends the wrong signal— not that Meta and Mastodon use #ActivityPub, a protocol the average user doesn’t understand, but that both share the same beliefs for the #openweb. #PostsFromJason#FediSeriesFJ
For Google, Amazon, Microsoft and Meta ( #GAMM ), the old cloud sync-and-share business model wasn’t working anymore.
So what did they do?
They convinced us that our notetaking apps require an internet connection and forty thousand dollar GPUs located on a server three hundred miles away. That's the future they've made for us.
Debugging #ActivityPub interactions can be tricky, but #Fedify's got your back! It includes a CLI toolchain for testing and debugging, making development and troubleshooting a breeze. Spend less time scratching your head and more time building awesome features! 🔍
Fedify aims to simplify the complex world of federated apps, allowing developers to focus on what matters most—their unique features and user experience. Let's explore what makes Fedify stand out! 🧵
Con esta tarea de investigar para aprender más sobre el #fediverso me doy cuenta de las muchas opciones que hay pero la verdad se me hace difícil acceder a ellas. Algunas cosas no termino de comprenderlas.
Por ejemplo, me gustaría estar en una comunidad donde se hable sobre libros, ensayos, novelas, etc... he encontrado #bookWyrm que si no entiendo mal utiliza #ActivityPub por lo que desde mi cuenta de masto.es debería poder conectarme, lo que no termino de encontrar son cuentas a las qus seguir... Me parece que debo abrirme una cuenta nueva en el servidor por ejemplo @comelibros.club pero veo que la mayoría de las cuentas de ese Server están inactivas o es que no sé buscarlas bien ¿o cómo debería hacerlo para encontrar cuentas castellanoparlantes para poder seguir e interactuar?
I was feeling inspired after listening to this podcast. https://flipboard.video/w/sQCNmXx332xi3Y3dVVjd37 So I decided to have a go at visualising “What a Social Web Browser could look like in the near future” This is my 2nd Mock up. This time I have added a few notes. - Ignoring the design, what other features/services do you think should be integrated the Social Web in the coming years? #ActivityPub#Mastodon#Fediverse#PixelFed#PeerTube @mike
Quería preguntar por videos, artículos que estén buenos y fáciles de entender, preferiblemente en castellano sobre el #fediverso, el protocolo #activitypub y servicios como #mastodon, #peertube... Me he propuesto hacer un artículo sobre ello para el trabajo ya que creo que es importante difundir estas alternativas. Por supuesto mencionaré las autorías de las fuentes.
Sé que @kyva tenía un vídeo explicativo molón pero son incapaz de encontrarlo de nuevo
Les agradezco mucho lo que sea que puedan aportarme :blackspipixelheart:
ALT text detailsPart of a newsletter from Ghost. The text reads:
“This newsletter is now federated
Our second bit of AP-Team news this week is that this very newsletter, the one you're reading right now, has become the first federated Ghost instance on the internet. In fact, you can follow it right now on @index@activitpub.ghost.org
Does it work perfectly? It does not. Are there likely to be all manner of bugs and issues with it? Oh yes there are. But here, dear reader, are the first signs of life.”
@shreyan Most of what you are talking about in "ActivityPub" section is only true for Mastodon. #ActivityPub is much more capable.
>identity is extremely tied to your initial server >Your data is not really portable
ActivityPub specification doesn't say that identity must be tied to a server. Identity can be tied to a secret key or a DID too, and users with different identity types can even communicate with each other.
Specifically, DID-based identity scheme has been proposed in FEP-ef61. Data portability easily follows from it.
So, with ActivityPub one can have everything that ATProto and Nostr offer, and much more.
It's been awhile so I figured I'd do an updated #Introduction post:
Hi, I'm BeAware, sometimes I abbreviate it, BA. I am VERY passionate about decentralized systems like #ActivityPub and #Nostr and tend to discuss these topics at length. Especially the nuances of each and try to keep up with all the things regarding them.
I have #ADHD and #Hydrocephalus, which effects various aspects of my day to day life and how I think. I am also on disability because of it.
I am also very #AI-positive because it helps me with every day life. With my brain disorders, I don't think the same way others do, so AI helps me with describing things accurately and to make sure I get my point across in the way I mean to. I also tend to post #AIart from time to time to realize my creativity.
I'm a #Gamer that primarily plays PC games or games that are Cross Platform. Generally I enjoy #MMORPG, #SurvivalGames and such where I can just "zone out" and vibe without much stress.
Sometimes you'll see me discuss #Technology news as well.
If these seem to be within your interests, feel free to follow and if you have similar interests laid out in your bio, chances are good that ill follow back.
I've been here for a year and this is, by far, my favorite social media platform I've ever been on.
Thank for reading and may you be as federated as you wish!
There's one main thing I like about #BlueSky, #Nostr, #Cwtch, and the in-development P2P-ified #Matrix over #ActivityPub and Matrix as they're generally deployed now: your ID doesn't depend on DNS.
I've not been in the Fediverse very long, but I've already seen people lose their entire social graph because an admin unilaterally took down an instance. When you tie your identity to DNS, you're at the mercy of the domain owner and every point of control over the DNS as a whole, including the court systems in every authoritarian jurisdiction. Not your keys, not your identity.
I like the admins of my instance here, but I see the toll it takes on them running it even with the community's contributions. It's a lot of pressure and a lot of power to have that much control over identity and trust for your users.
I don't think we have to wholesale move to other protocols, though. The beauty of open networks is the freedom to build bridges. When people do migrate between them, it can and should be as smooth as migrating between ActivityPub instances in the happy path, and remain fully interoperable.
Finally, @ghost has open sourced their #ActivityPub implementation powered by #Fedify! For Fedify users, this means another production-grade example code.
If you'd like to follow updates on #Ghost's ActivityPub implementation, you can do so by following @index!
While being stranded for 24h in Germany and Paris’ airport, I finished a first version of a “Mastodon Unroller”, a simple way to take activitypub threads and make clean article out of them in your Astro website.
After a few iteration I think it’s now time to show a little demo!
We just shipped NeoDB 0.10 , with revamped i18n support and other features. A dedicated project site is also up: https://neodb.net
If you haven't heard about #NeoDB , it's basically Goodreads+ Letterboxd + RateYourMusic + Podchaser, all in one place, #opensource, powered up with #ActivityPub, plus microblogging, like #Mastodon and its apps.
Love to hear your thoughts, and if you find this project useful, or think someone else may think so, please help boost!
I'm sure the documentation is not yet complete or still has bugs - just like the application itself. But if you are brave enough, you are welcome to give it a try.
I don't have any demo to show you yet but i needed a way to announce and ask for things - so if you care, please follow! Here is how admin panel looks so far.
Spreading the info and participating in discussion highly appreciated! ❤️
Given there is a single-site multi-user app based on #activitypub (single domain blogging platform with multiple users posting) - should an Application type represent entire site and Person types posting to it? Or Group type instead of Application? Or entire site should be one single Person type? What's your take on that? #needhelp#development#fediverse
He activado el modo #fediverso en mi perfil personal de WordPress.com (que he aprovechado para limpiar y adecentar). Desde allí voy a microbloguea de todo lo que se me ocurra, con un tono más personal.
ICYMI: Last week saw a new episode of Dot Social, the fediverse podcast hosted by Flipboard CEO @mike, in which he interviewed @ghost's @johnonolan. Here's a taste of their conversation; you can listen to the whole episode here or wherever you get your podcasts:
“We’re at a very grassroots stage of a mix of hackers and enthusiasts collaborating to make the thing they want, not the thing that has the most funding, and I love that. That speaks to my heart.”
ALT text detailsVideo clip from Dot Social podcast, where Mike McCue interviews John O'Nolan. Audio says “We’re at a very grassroots stage of a mix of hackers and enthusiasts collaborating to make the thing they want, not the thing that has the most funding, and I love that. That speaks to my heart.”
Yesterday’s #FediverseMeetup at @offline, #Berlin was so cool and insightful! Lovely to chat with very knowledgeable and interesting folks.
I have been thinking about the discussion so much that last night I dreamt of @liaizon telling the story of how they built their whole self hosted #ActivityPub instance in one single #PHP file.
This is not true and I have no idea how my unconscious could have conceived this ahahah
#Fedify now has a queue for incoming activities and they are automatically retried when they fail. The default retry strategy is good enough (exponential backoff + decorrelated jitter), and it's even fully customizable. Updated also the docs:
In the next version of #Fedify, the #RetryPolicy type is introduced to let you fully customize the retry policy of the task queue for incoming and outgoing activities. Of course, you can also simply adjust the parameters of the built-in exponential backoff + decorrelated jitter policy.
ALT text detailsoutboxRetryPolicy
This API is available since Fedify 0.12.0.
The retry policy for sending activities to recipients' inboxes.
By default, this uses an exponential backoff strategy with a maximum of 10 attempts and a maximum delay of 12 hours.
You can fully customize the retry policy by providing a custom function that satisfies the RetryPolicy type. Or you can adjust the parameters of the createExponentialBackoffRetryPolicy() function, which is a default implementation of the retry policy.
I haven't posted about my #ActivityPub training wheels project @DailyRucks in a while, but it's been going strong with its daily voice line posts. 😀
Today marks the start of its first month-long special event, in which the bot will recount the Kid's origin story in a continuous thread, one sentence per day, until July 31st, starting with today's post: https://fietkau.software/daily_rucks/ap/activity/2024-07-01
If you enjoy Logan Cunningham's voice acting, be sure to follow along. 🙂
In the next version of #Fedify, the Context.hostname, Context.host, and Context.origin properties will be added for better multitenancy/virtual hosting support.
When there is no queue, if the process fails, the inbox can just respond with a 500 server error and the sender will resend it.
But with a queue, by the time the inbox responds, it doesn't know if the process will fail because it hasn't run yet. So the sender won't retry whether it fails or not.
So, should it have its own retry logic when there is a queue?
#Fedify has always been queuing outgoing activities, but not incoming activities. Thanks to @ghost's sponsorship, we are now implementing queues for incoming activities!
I really by and large have mostly lost faith that anything short of a miracle will get #ActivityPub to where I would like it to be, and the forces working against success here are just hard to even look at
I support the groups that are trying to define a way forward, and I suspect in many, many ways the battle is lost until and unless one of those efforts succeeds well enough to define a better way forward, and there's no way to know what that would look like or if it is even possible.
@hongminhee : we do also start to build anything #ActivityPub with #deno (incl. journalistic CMS client, public broadcaster thing, taxiteam client) and so, I work on a UI system with #fresh for all the `type`s …
ALT text detailsMeta, the parent firm of Facebook and Instagram, is hashing out a plan to build a standalone text-based content app that will support ActivityPub, the decentralised social networking protocol powering Twitter rival Mastodon and other federated apps, people familiar with the matter told Moneycontrol.
The app will be Instagram-branded and will allow users to register/login to the app through their Instagram credentials, they said. Moneycontrol has seen a copy of an internal product brief that elaborates on the functioning and various product features of the app.
#Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
• Type-safe objects for Activity Vocabulary (including some vendor-specific extensions) • #WebFinger client and server • HTTP Signatures • Middleware for handling webhooks • #NodeInfo protocol • #Node.js, #Deno, and #Bun support • CLI toolchain for testing and debugging
If you're curious, take a look at the Fedify website! There's comprehensive docs, a demo, a tutorial, example code, and more:
Iceshrimp.NET has entered the beta phase. It’s in an interesting state! The Mastodon API compatibility is quite good, allowing the use of many existing apps.
The front end ui is still in progress. Any adventurous fedi nerds that want to install and provide feedback are welcome.
In the words of Fatboy Slim, "we've come a long long way together." Here, @miaq breaks down Flipboard's federation journey so far.
"We could [federate Flipboard] with a quick flip of the switch but we’ve chosen to act more intentionally," she writes. "We’re taking measured steps to test, learn, and ensure that everything we’re doing stays true to our values and those of the fediverse. Maintaining quality is top of the list."
@ghost founder and CEO @johnonolan wants to build a tech company that thinks differently. Learn how ActivityPub is enabling a new kind of publishing platform, with integrity at its core. It’s a new episode of the Dot Social podcast highlighting leaders in the fediverse, hosted by @mike
Since there seems to be renewed interest in podcasting cross-app-comments over #ActivityPub, I've done a brain dump over here with a current perspective on the high-level of how it all works and to clear up a bit of terminology being thrown around.
imo the comments scenario is ready to build against (that's what I focus on here) with the ability for custom podcast-specific objects/fields down the road, using the same federated channel.
Well look at me now (assuming the video doesn't get compressed into nothing, here's a @Minetest mod that bridges messages across activitypub)
ALT text detailsVideo of minetest/activitpub bridge, left side shows minetest right side shows mastodon. User types in message on minetest and it shows up on the mastodon server and vice versa. Video then shows a new user being created and that user getting an account generated in the activitypub server
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
Question for #ActivityPub users. I installed it on my WordPress site and expected to see the two posts I've published since then here at @oldaintdead@oldaintdead.com
However I'm seeing nothing and can't figure out what I'm missing on the settings or the way the results should appear.
it's often so complex to add #ActivityPub to an already existing platform (for example #WordPress ) and it gets even more complex if it is not built for social media 😱
For example
1. Deleting Users from the Fediverse, that still exist on the blog. 2. Delete the whole blog from the fediverse, but take temporary plugin deactivations/deletions into account. 3. Caching by third party plugins. 4. Shared hosting. 5. Posts and Comments in different DB tables 6. Publish only a subset of posts
I love when Fediverse scrapers get Fediblocked MULTIPLE times then start making new instances under obscure domain names to hide their data stealing...🤬
Awakari created a new instance on Indy.rest on June 24. 4 days after I called for Fediblock on their other attempt at ban evasion (awakari.app)
Indy.rest seems to be down at the moment. However, given their track record, this is a required block if you value your data not being sold.
I wish #Mastodon / #ActivityPub had like, native, seamless, keep-the-old-timestamp post migration between instances tbh. I do miss my .ART backlog.
Even though #Bluesky is only allowing self-hosted PDS instances (right NOW*), you can take your backlog and social graph with you when moving within #ATProto
It's kinda gross to see these corporate walled gardens intentionally misrepresent their Fedi integrations and just start using Fediverse in their PRs like their a genuine Fedi participant.
Looking at you, BlueSky and Threads. BlueSky lied about being decentralized and uses Brdigy Fed, a third party bridge to Fedi made by one man, to say they're decentralized. Threads keeps adding fake Fediverse interactions and promoting them as legit Fediverse interactions. They "added" replies from Fediverse without mentioning that they're private and can only mention 1 person or it won't be federated...🤦♂️
If you intentionally misrepresent your integrations for clout, you're doing nothing but harboring mistrust here on Fedi.
Essential listening/viewing from @mike and @johnonolan . “No-one owns this space - it’s being built by a bunch of hackers and enthusiasts who are building what they want…#ActivityPub is going to be bigger than any other social network…It’s moat-less technology. Let’s fill in all the canals and grass them over.” Fantastic!
If you’re at all interested in the future of how people could discover, enjoy and pay for great content in the #fediverse and the broader web, this episode of #DotSocial is for you.
Here @johnonolan and I go deep on the product, technical and business model mechanics that will ultimately support a more sustainable, social web thanks to Ghost’s upcoming full integration of #ActivityPub.
And....my hype for Threads replies has immediately been killed.
Replies are only shown to the OP. It's *something* but all this fake integration crap is starting to piss me off now...🤬
Edit: Confirmed. Replies are only shown to 1 person. You can't mention multiple Threads users and have them see it publicly. This is ridiculous at this point...🙄
@jan I think, funnily enough, that this is Facebook following ActivityPub more closely than Mastodon - specifically the parts around Inbox Forwarding, which Mastodon doesn't do.
It's the reason people invent things like #FediFetcher
> Ditto is a Nostr community server. It has a built-in Nostr relay, a web UI, and it implements Mastodon's REST API.
> Since Ditto implements the Mastodon API, it can work with any Mastodon app!
> Users of Mastodon and Pleroma will be happy to see search functionality that actually works. 😂
> Ditto is built in Deno with TypeScript. It's basically a REST API with a built-in Nostr relay. This is the same design as Mastodon and Pleroma, replacing ActivityPub with Nostr.
Just gave a talk to Japanese @w3c member companies, presenting about the #Fediverse and encouraging some more engagement between W3C Japan and local communities & projects that are working with #ActivityPub. Already, one person on the call said they are active on #Misskey and will reach out to them. 💗
What's the #activitypub server software landscape like these days? It's been a while since I've checked and I want to know what people are running and what's new in the past couple years
Interesting new ActivityPub project called @hollo for a single user instance!
It still has to build features that are required for mass adopting (blocking and muting aren't implemented yet) but I'm really interested in single user instance software that's somewhat minimalistic so whenever it's fully released, I might try it out!
This is just a mockup for now. I’m not that far along yet. 😅
My goal with my little Fedify #ActivityPub project is to have an easy lookup utility. It does two things:
Attempt to render the object using a bespoke template library, free for anyone to examine.
Render JSON-LD output in a neat little pane as a kind of Inspector tool.
I don’t know how useful this will actually be to anybody, but it might be handy for looking at activities, figuring out how to implement stuff, maybe even show output for posts that don’t work correctly? 🤔
ALT text detailsA mockup of TypeRender, a tool to look up and render public ActivityPub objects and show the data output.
This weeks' news: - More updates by Ghost on their work on implementing #ActivityPub - Statistics shared by Mastodon show the power of an open API, and the incredible diverse ecosystem that it enables - NLnet supports fediverse event planning software Gancio with a new grant
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.
Ghost has some exciting news in their latest #ActivityPub progress update:
"The other thing we're now working full-speed towards is open sourcing the new ActivityPub Service GitHub repository. That means the code will be available for anyone and everyone to see, use, follow-along-with, or contribute-to."
This is dope! Looking forward to tracking the development live 👀
I'm looking for a well put together written case for institutions (academic, professional) to set up their own Mastodon instance.
Something that not only highlights the obvious benefits, but also that the technical costs are within the capacity of most places that have a decent IT department.
Please do not make the case here, I'm looking for links. 😜
ALT text detailsFederated single user microblogging software through activitypub that is also compatible with mitra
Interact with users on Mastodon, Pixelfed, Misskey, etc
Github repo here: https://github.com/dahlia/hollo
🚨 INTRODUCING: a new in-progress #rubyonrails#activitypub engine that aims to make it able to add AP features to any Rails app.
It's still a work in progress but i would really love to hear your feedback and ideas on that! Feel free to message me here or open a discussion on github repo.
Version 0.10.0 of #Fedify, an #ActivityPub server framework, has been released! Starting with this release, Fedify, previously distributed under AGPL 3.0, is now distributed under the MIT License to encourage wider adoption. Here are the major changes:
• In addition to RSA-PKCS#1-v1.5, Fedify now supports Ed25519 for signing and verifying the activities. • FEP-521a: Multiple key pairs can now be registered for an actor. • FEP-8b32: Implemented Object Integrity Proofs. • Added Arrive and Question classes.
This week's news: - Scraper drama as AI-powered network Maven works on implementing #ActivityPub - Ghost will use fediverse server framework Fedify for their ActivityPub implementation - @Castopod releases version 2.0 with plugins - an on-device 'For You' algorithmic feed for Lemmy with 3rd party client Quiblr - Lemmy releases local-only communities
#Mastodon sends Create(Question) for the poll, even though the Question itself is an Activity. Does it see Question as a regular Object rather than an Activity?
I'm very excited that the #Ghost team has chosen #Fedify to implement #ActivityPub. I've been working closely with the Ghost team, and it's been a lot of fun, and I can't wait to see the ActivityPub implementation at Ghost.
Thanks to @silverpill, #Fedify is finally FEP-8b32 compliant! Though it's not ready for general release yet, it's passing tests in the latest main branch. I'll test it with Mitra and other FEP-8b32-compliant implementations, and if it works well, it'll be included in 0.10.0.
You can try it out in version 0.10.0-dev.205+0cbca257.
- Reposts and quote-reposts - Post embeds - Remote interaction popup when you try to interact with a post without an account - New profile fields (starting to feel like a social network now) - Comment view setting: threaded (default), two-level, flat - Hover cards for mentions - Mention autocomplete - Bookmarks for profiles and groups - Lots of minor fixes and improvements
Actors now have the #assertionMethods property, and the #Multikey class has been added. For example, if you look at the the actor from the Fedify Example Blog (https://fedify-blog.deno.dev/users/fedify-example), you can see that it has the assertionMethods property in addition to the publicKey property.
You can try it out in version 0.10.0-dev.196+55cc34d1.
It almost feels like Mastodon do not want us to self host. There is no direct link on the main webpage to install on server. Digging through the docs, finally found documentation and there is no Docker container or a package for any OS for easy installation. They require us to install from source along with all the dependencies. I don't mean to bad mouth it but they do not do enough to encourage self hosting (if not discourage).
Would like to know your opinions or ideas on how to self host it easily with minimum maintenance (auto upgrades, etc).
As a first step towards adding Object Integrity Proofs (FEP-8b32) to #Fedify, I've made it support #Ed25519 keys. I've also enabled multiple keys to be associated with an actor. For example, if you look at the actor from the Fedify Example Blog (https://fedify-blog.deno.dev/users/fedify-example), you'll see that it has two public keys, one for RSA and one for Ed25519.
You can try it out in version 0.10.0-dev.190+4dffb89a.
I've written a bit of an extensive guide on navigating ActivityPub and its many apps, and instances, along with some initial questions new users might have, and links to mobile apps.
Version 0.9.0 of #Fedify, an #ActivityPub server framework, has been released! Here are the main changes:
• Added Tombstone, Hashtag, and Emoji classes. • Added normalizeActorHandle() function to normalize an actor handle. This is needed when the domain of the actor handle is an IDN, or when the domain contains capital letters. • Added an option to the sendActivity() function, excludeBaseUris, to exclude specified servers from sending activities. This can be used when you don't want to send activities to your own server. • Added Context.parseUri(), a method to parse actor, object, inbox, and collection URIs. • The time window for HTTP Signatures verification is now configurable. • The @fedify/fedify/httpsig module has been renamed to . This is in preparation for implementing additional object integrity proofs other than HTTP Signatures. • Improved interoperability with #Misskey.
Very happy to announce that @tomcoates and I have been given a #SummerOfProtocols grant to develop an end-to-end encryption (E2EE) protocol for #ActivityPub DMs, including a reference implementation and a report to submit to the W3C SocialCG.
Still in development, but got #ActivityPub replies working! Once it goes live, replies from the fediverse will show up on Remark.as.
Last major issue is to add some basic moderation. Already got instance-level blocking done so I can easily defederate from bad servers, but want to make sure we can handle any potential abuse from individual users too.
ALT text detailsScreenshot of a Remark.as conversation in my test environment. There's a box to reply in, and test comments below authored by @matt@writing.exchange (a remote user) alongside one made from a Remark.as account (a local user).
Wir haben von einigen aus der Community das Feedback erhalten, die Artikelanzahl sei für einige föderierte Publisher sehr hoch. Daher möchten wir einen Überblick dazu geben:
Die Anzahl der Beiträge bezieht sich auf die Gesamtbeiträge bei Flipboard und damit i.d.R. auf einen Zeitraum von mehreren Jahren.
Folgendes ist aus unserer Sicht die beste Möglichkeit, sich auf dem Laufenden zu halten und dabei spezifischen Content eines bevorzugten Publishers zu bekommen: den Flipboard-Magazinen zu folgen, um kuratierte Artikel zu bestimmten Themen zu erhalten.
Was bedeutet das konkret? Wenn du dich für Wirtschaftsnachrichten oder Klimapolitik interessierst, kannst du den Magazinen eines Publishers ausschließlich zu diesen Themen folgen, oder wenn du alle Inhalte sehen willst, kannst du dem Profil des Publishers folgen – so hast du mehr Möglichkeiten, die Art der Inhalte, die du in deinem Home-Feed siehst, anzupassen.
Das föderierte Profil eines Publishers ist nur eine weitere Möglichkeit, seinen Inhalten zu folgen und mit ihnen zu interagieren.
So folgst du einzelnen Magazinen über Mastodon:
1) Verwende die Suche, um nach den Magazinen eines Publishers zu suchen (Die Liste an bisher föderierten Publisher haben wir in unserem Profil angeheftet).
2) Wähle "Alle ansehen" bei den Suchergebnissen aus.
3) Folge nun den thematischen Magazinen, die dich interessieren. Wir haben hierzu einen Screenshot von ZEIT ONLINE als Beispiel hinzugefügt.
Im letzten Dezember haben wir damit begonnen, Flipboard für das Fediverse zu öffnen. Heute machen wir einen weiteren wichtigen Schritt in diese Richtung, indem wir unsere Testphase ausweiten: Die ersten Publisher aus Deutschland sind nun für das gesamte Fediverse zugänglich.
Wir haben die Kommentare aufgemacht und da wir #ActivityPub benutzen bedeutet das: Was ihr hier unter einen Post kommentiert, landet im Blog als Kommentar. Und wenn von uns jemand im Blog auf den Kommentar antwortet, wird es auch hier angezeigt. Ich find das ziemlich genial.
Ich habe auf eigenpod.de auch #ActivityPub aktiviert, d.h. die Webseite selbst ist jetzt im #Fediverse und ihr könnt ihr direkt folgen. So siehts jetzt aus:
Unter @eigenraum_folgen_feed postet die Webseite sofort neue Folgen und sonst nichts. Wenn ihr diesen Account auf Mastodon erwähnt, merkt aber keiner was davon!
Der @Eigenraum hier hingegen wird menschlich betrieben (von @tomkalei ) und kann mit euch socializen.
What you're referring to as #Mastodon is in fact the #Fediverse. Mastodon is not a network unto itself, but rather another open component of a fully functioning network made useful by #ActivityPub.
Every Mastodon user is in fact a user of the fediverse without realizing it. There really is a Mastodon, and these people are using it, but it is just a part of the greater whole. Mastodon is one example of a service using the AcivityPub spec, and is an essential part of the Fediverse, but of limited utility by itself; it is best understood and functions at its greatest when used in combination with other Fediverse services.
But because Mastodon only supports 8 of them (with only 2 of them being supported properly), there is "pressure" on other Fediverse software to restrict themselves to these 8.
So its done! I finally released a fairly easy to install (from scratch) Hugo based Static Site generator with full ActivityPub support.
It has step-by-step instructions on how to set it up for your own blog or static website.
One of the coolest features for me, other than having your static site blog posts show up as posts in the Fediverse is the support for interacting with those posts. Any replies you leave, likes, or boosts will show up in the "comments" section of the website on the page associated with the post. How cool is that!
According to HackerNoon, they consider #ActivityPub as the "future of social networks". In addition, they have crafted an outstanding explanation of its functionalities and capabilities, accompanied by remarkable code-based illustrations.
It is highly recommended reading material for developers interested in constructing a Fediverse app.
If you're curious how ActivityPub works exactly (like me) this site does a great job of show and tell.
On the surface it looks like any other Mastodon instance, but on closer inspection, provides you insight into the ActivityPub back and forth going on behind the scenes!
ALT text detailsThe Activity Log shows the ActivityPub objects that are passed back and forth when a follow request is sent from one instance to another.
Oh, and I just noticed, you can open or close registration/connection in #Elk by setting the volume used for /elk/data as readable only or readable and writable.
When it’s writable you can register whatever you like, if it’s readable you can only connect with previously registered #ActivityPub instances.
Not sure if there any other downsides.
@elk can we somehow prevent users from registering new instances in an intended way (or is that the intended way?).
Everyone is announcing their new account on the latest privacy destroying (Jesus, look at the privacy report!) social network the tech-bros have regurgitated. Well…
If you need me, you can find me here – on this advertising-free, algorithm-free, non-billionaire-controlled, open, & decentralized social media platform.
ALT text detailsThe App Privacy report for Threads from the Apple App Store, showing it requires access to your health and fitness data, financial info, location data, contact info, among many others.
ALT text detailsLeft panel shows Ben Franklin, John Adams, and Thomas Jefferson drafting the Declaration of Independence with subtitle, "How I see myself when talking about the Fediverse." Right panel shows the conspiracy meme guy with the subtitle, "How others see me."
For people invested in the migration from #reddit. Here's some details about #BrutaLinks one of the projects I'm working on, which is a reddit-like discussion platform, built on top of #ActivityPub.
It didn't benefit from the attention and funding that lemmy got, so probably it's overall less polished and performant, but some love from the community would do it good.
The real magic of the #fediverse is collaboration.
Many of the largest projects have worked together behind the scenes on compatibility.
It's not that common now that ActivityPub has matured, but you better believe the early days of 2018 had big players like Mastodon and Pleroma working closely on compat.
#ActivityPub = Community + Collaboration The magic formula that sets us apart!
One the best things you can do to help the decentralized network grow is to self-host apps using things like #ActivityPub.
This distributes the resource needs of supporting a large number of users on single instances of applications that use #ActivityPub or similar protocols to "federate" or interoperate with one another.
The more servers, the more people can find their community, and the more than can join in and take back their net experience! #selfhost
I'll be talking about some of the great fully-managed software they offer to take control of your social networking with the Fediverse and the ActivityPub protocol, and also highlight some other great FOSS offerings on their impressive list of services.
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’m matt and I spend a lot of my time building things that people use on the internet. I’m always down for #Frontend chat on all things #JavaScript, #React, #WebAssembly etc.
I’m part scientist🔭🥼 (in another life), part maker🔩🪛, part runner🏃🏽♀️🏃♂️, part climber🧗🧗♂️… the list goes on.
I’m also super curious about how #ActivityPub works and the #Fediverse, so now that I’ve been afforded some time off I may take a deeper look 👀
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',
But it's a loooong story. Made a hopefully helpful article out of it. 
I also have an ActivityPub version which you can read at 
Fedify란?
対応するぜ！」って言ってた過去をたぶんもう誰も覚えてない（自分も忘れてた
を比べるんじゃなくて、 
Flickr to join the 
🍆
輪読会📖第零弾として 
)
が 
でも 
でもいいから…とりあえず Web 標準化の 
![{
"@context": [
"https://www.w3.org/ns/activitystreams"
],
"type": "Profile",
"describes": "acct:reiver@mastodon.social",
"attributedTo": "https://example.com/apps/ratel",
"icon": {
"type": "Icon",
"mediaType": "image/png",
"url": "https://example.com/apps/ratel/img/icon.png"
},
"attachment": [
{
"type": "Label",
"name": "Programmer"
},
{
"type": "Label",
"name": "Canadian"
},
{
"type": "Icon",
"mediaType": "image/png",
"url": "https://example.com/pfp/751f76ed540a40a3b4caae50e50cc867.png"
},
{
"type": "Icon",
"mediaType": "image/png",
"url": "https://example.com/pfp/45f7b459257940f490133070a975924b.png"
}
]
}](https://files.mastodon.social/media_attachments/files/113/822/835/158/629/464/original/d533aeb4132201db.png)
It’s nice to finally have my social media world (de)centralized and 100% in my control and using my own domain.
.dev
」
みたいな気持ちになるんだよ。
💦
🍽️ 🧽
を応援していますという宣言を、ここに置いておこう…（そっ 
🏳️⚧️
Italia
![Screenshot from the linked article reading:
"Next steps
• I [Matt Lee] want you to have a personal website and have your listening habits on your own website, not my website. But I know some people won't want that, which is fine but Libre.fm is effectively a silo (other than Last.fm which it talks to, although federation with other instances has been possible for a long time) and has over 372,000 registered users and 302 million scrobbles.
• Some new features will only work if you're publishing your Libre.fm stats on your own website.
• A new version of Libre.fm's front end will appear later, powered by Ruby on Rails.
• [highlighted] We're also going to put our full attention to supporting ActivityPub where possible. [end highlight]"](https://media.moule.world/moule/media_attachments/files/113/248/170/029/238/328/original/769bc3d86f28a30f.png)
![kopper [according to whom?] :colon_three:'s avatar](https://media.d.on-t.work/misskey/original-22a0c416-c85c-4f01-ab38-ddb7836a776d.png){kind=small}
🇳🇱
