101010.pl is one of the many independent Mastodon servers you can use to participate in the fediverse.
101010.pl czyli najstarszy polski serwer Mastodon. Posiadamy wpisy do 2048 znaków.

Server stats:

492
active users

#activitypub

40 posts36 participants0 posts today

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

Did I miss any?

nlnet.nl/news/2025/20250624-an

nlnet.nlNLnet; 62 new projects contribute to digital commons

We're pleased to share that Encyclia has joined our success stories.

@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.

This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.

We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.

Learn more about Encyclia at https://encyclia.pub/. 📚

fedify.devWhy Fedify? | FedifyThis document explains why you should consider using Fedify for your ActivityPub server development.

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

The InProcessMessageQueue continues to use Fedify's internal retry mechanism, while ParallelMessageQueue inherits the retry behavior from its wrapped queue.

AMQP message queue improvements

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.

fedify.devMessage queue | FedifyFedify docs

I've built #Enigmatick to manage threading using conversation IDs like Mastodon uses. But that's not aligned with #ActivityPub - or at least it wasn't the least time I looked. ActivityPub uses inReplyTo to indicate direct parent relationships and doesn't have a concept for linking multiple objects under a single ID.

Other systems don't use the conversation convention and that's caused some discord in my timeline. So now I'm learning about closure tables and concepts I probably would already know if I had studied computer science in college. But it's never too late to learn!

From: blenderdumbass . org

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.

Includes an exclusive interview with Jerry.

Read or listen: blenderdumbass.org/articles/cl

blenderdumbass . orgClarifying Costs of Running the Fediverse with Jerry from Infosec.Exchange
Replied in thread

@christianp

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.

I read some time ago of people using #webAssembly to transcode video in a user's web-browser. blog.scottlogic.com/2020/11/23

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.

Scott LogicIn-browser transcoding of video files with FFmpeg and WebAssemblyThe WebAssembly build of FFmpeg allows you to run this powerful video processing tool directly within the browser. In this blog post I explore FFmpeg.wasm and create a simple client-side transcoder that streams data into a video element, with a bit of RxJS thrown in for good measure.

What we shipped so far in 2025

Alongside our upcoming plans, we’ve already shipped several important features in recent releases. Here are some highlights of what’s now available in the ActivityPub plugin.

Onboarding

We’ve added an onboarding flow after plugin activation to help guide new users through key decisions — such as selecting the Actor Mode.

It’s also a great opportunity to explain Fediverse concepts for users who are new to them.

More details:

👉 5.9.0 — Easier onboarding for your Fediverse […]

activitypub.blog/2025/06/24/wh

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.