est.social on üks paljudest sõltumatutest Mastodoni serveritest, mida saab fediversumis osalemiseks kasutada.
est.social on mõeldud Eestis üldkasutatavaks Mastodoni serveriks. est.social is meant to be a general use Mastodon server for Estonia.

Administraator:

Serveri statistika:

91
aktiivsed kasutajad

#fedidev

5 postitusega5 osalejaga1 postitust täna

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.

await ctx.sendActivity(
  { identifier: sender },
  "followers",
  activity,
  { 
    preferSharedInbox: true,
    syncCollection: true,  // Explicitly enable collection synchronization
  }
);

Enhanced Key Format Compatibility

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!

Released on March 28, 2025.


Improved activity delivery performance with large audiences through a two-stage queuing system.  Sending activities to many recipients (e.g., accounts with many follow...
GitHubRelease Fedify 1.5.0 · fedify-dev/fedifyReleased on March 28, 2025. Improved activity delivery performance with large audiences through a two-stage queuing system. Sending activities to many recipients (e.g., accounts with many follow...

I just discovered why some of my followers from larger #Mastodon instances (like mastodon.social) would mysteriously unfollow me after a while!

A pull request was just merged in Mastodon that fixes a critical bug in their follower synchronization mechanism.

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. 😊

Mastodon implements FEP-8fcf: Followers collection synchronization across servers, but requires every identifier to be in a single page.
The reasons for only supporting one page are:

Mastodon must...
GitHubFix follower synchronization mechanism erroneously removing followers from multi-page collections by ClearlyClaire · Pull Request #34272 · mastodon/mastodonClearlyClaire poolt
Jätkatud lõim

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:

  1. When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
  2. 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
// Example with custom fanout setting
await ctx.sendActivity(
  { identifier: "alice" },
  recipients,
  activity,
  { fanout: "skip" }  // Directly enqueues individual messages
);

This change represents months of performance testing and should make Fedify work beautifully even for extremely popular accounts!

For more details, check out our docs.

What other #performance optimizations would you like to see in future Fedify releases?

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.

https://github.com/fedify-dev/fedify/issues/220

Current design Currently, when Context.sendActivity() is called, Fedify creates separate queue entries for each recipient's inbox. This design has been intentional to achieve the following benefits...
GitHubOptimize activity delivery for large audiences · Issue #220 · fedify-dev/fedifydahlia poolt
Jätkatud lõim

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.

NoteWe've decided to postpone custom background task support to Fedify 2.0.0 instead of 1.5.0 as originally planned. This feature requires significant API changes that would be too disruptive for a...
GitHubSupport custom background tasks in worker · Issue #206 · fedify-dev/fedifydahlia poolt

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:

  1. 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!
  2. 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.

Released on March 20, 2025.


Fixed a bug of WebFinger handler where it had failed to match acct: URIs with a host having a port number. [#218, #219 by Revath S Kumar]


Fixed a server error thrown...
GitHubRelease Fedify 1.0.21 · fedify-dev/fedifyReleased on March 20, 2025. Fixed a bug of WebFinger handler where it had failed to match acct: URIs with a host having a port number. [#218, #219 by Revath S Kumar] Fixed a server error thrown...
Jätkatud lõim

今回、@lqez さんの『我々のコードを求めて』というYouTubeに出演させていただき、#フェディバース#ActivityPub#Fedify#Hollo 等についてお話させていただきました。日本語字幕が用意されていますので、FedifyやHolloの開発秘話などが気になる方はぜひご覧ください!

https://www.youtube.com/watch?v=sqxR8zscSDo

()@lqez 님의 《우리의 코드를 찾아서》에 出演(출연)하여 #페디버스, #ActivityPub, #Fedify, #Hollo ()()해 이야기를 나눴습니다. Fedify와 Hollo의 開發(개발) 祕話(비화) 같은 게 궁금하시다면 한 () 보셔도 재밌을지도 모르겠습니다. ㅎㅎㅎ

https://www.youtube.com/watch?v=sqxR8zscSDo

Jätkatud lõim

殆どのActivityPub実装では、NoteArticleの内容(content)内で他のアクター(actor)に言及(メンション)する場合、tag属性に該当するMentionオブジェクトを含めています。では、PersonGroupなどのアクターオブジェクトも、自己紹介(summary)内で他のアクターに言及する場合、tag属性に該当するMentionオブジェクトを含めるべきでしょうか?既にその様に動作している実装はあるでしょうか?(Mastodonは確認した結果、含めていない様です。)どの様にお考えですか?

Jätkatud lõim

大部分(대부분)#ActivityPub 具顯(구현)들이 NoteArticle內容(내용) (content) 안에서 누군가 다른 액터를 멘션할 境遇(경우) tag 屬性(속성)으로 該當(해당)하는 Mention 客體(객체)들을 包含(포함)시킵니다. 그러면 Person, Group () 액터 客體(객체)들도 略歷(약력) (summary) 안에서 누군가 다른 액터를 멘션할 境遇(경우) tag 屬性(속성)으로 該當(해당)하는 Mention 客體(객체)들을 包含(포함)해야 할까요? 或是(혹시) 이미 그렇게 動作(동작)하는 具顯(구현)이 있을까요? (Mastodon은 確認(확인)해 본 結果(결과) 包含(포함)시키지 않는 것 같습니다만.) 어떻게 보시나요?

#연합우주 #聯合宇宙(연합우주) #fedidev

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?

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!

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!

https://hackers.pub/@hongminhee/2025/hackers-pub-introduces-flexible-username-changes

hackers.pub · Hackers' Pub Introduces Flexible Username Changes: Breaking the Fediverse NormHackers' 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.

Hackers' Pub Introduces Flexible Username Changes: Breaking the Fediverse Norm

hackers.pub/@hongminhee/2025/h

hackers.pub · Hackers' Pub Introduces Flexible Username Changes: Breaking the Fediverse NormHackers' 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.